versioning and tag names

[IzzySoft]

For over a year now, there's always only a single tag named "latest", and the app never gets a newer versionCode/versionName. This makes update checks very hard. Would you consider proper versioning (especially with versionCode increased for each release), at least every now and then? Like, having "stable tags" like v1.1.0 etc 2 (or more) times a year, while keeping the "latest" for test/development if needed? Thanks in advance!

[mrrfv]

I'll see what I can do.

The reason the companion app never had any versioning is because users are generally expected to just use the latest version of the bash backup script which then downloads & installs the app via a permalink:

https://github.com/mrrfv/linux-android-backup/blob/a9d3c62dcff9ff6090cd4a53e1e61a6b75bc6e22/functions/helper.sh#L50-L56

I understand that this is not the best behavior, as incompatible versions of the app, script and/or backup archives could potentially make it impossible to automatically restore backups.

[mrrfv]

Done: https://github.com/mrrfv/linux-android-backup/tags

The latest release and tag will still be updated as they are kept for old versions of the script, as a fallback and for users who would like to test an experimental version.

Like, having "stable tags" like v1.1.0 etc 2 (or more) times a year, while keeping the "latest" for test/development if needed?

Could you expand on that? I thought that releases/tags should be created every time a new tested change is introduced, not every 6 months - this is my first time adding versioning to a project :p.

[IzzySoft]

Tags look very fine now, and so does versionName – thanks! Any by "2 (or more) times a year" I meant to not put too much burden on you. Of course, make a new release with proper versioning as often as you feel fit (well, you won't overdo that with hourlies, will you? :see_no_evil:).

Two things left now:

• please remember to always increase versionCode with each release you make – as that's what Android uses to tell versions apart. Without that, updates become complicated: new versions are not announced to the users, and updates would only be possibly by side-loading.
• you currently use com.example.companion_app as applicationId. Not a real problem for my repo (or F-Droid's) or for end-users – but you'd never get the app to Play that way (no need for that, I agree). Still, com.example.* is no name space one should consider for "releases" – as the name suggests, that's rather for examples and "trying things" (also, collisions with other devs are much more likely, as I see that used quite often with "new developers"). If you own a domain, you could use that "in reverse" (as com.example.* would reflect example.com). If you do not, another "unique thing" could be used. Maybe mrrfv.backup.companion_app?

The latter is just a suggestion – the former is important for future releases. So what do you think about the applicationId?

[mrrfv]

Thank you so much for all these suggestions. Just changed the Application ID :)

This change might break old/legacy installations of the script that haven't cached the companion app, but there's nothing preventing people from just updating to a newer version. Haven't created a tag yet because I'd like to test everything first.

well, you won't overdo that with hourlies, will you?

I do have days where I introduce lots of changes and fixes in a single day, but I'll make sure to first do all that in master and then create a new release when I'm done :)

Btw, how did the companion app get added to your F-Droid repository? I feel honored to have it present in one of the most well-known repos, but I don't see the reason why would somebody download it outside of using it as a contacts mass-importer or SMS/contacts exporter because everything's already handled by the Bash script.

[IzzySoft]

I do have days where I introduce lots of changes and fixes in a single day

But I see you then do want to test first to make sure everything works before you make a new release. So it will rarely be more than one release per day, which is fine.

how did the companion app get added to your F-Droid repository?

My crawler found it, informed me, I checked the find and added it – while contacting you with all the above details. If you think it should not be in my repo for the reasons outlined, I can of course remove it again – otherwise I'd just switch it to the new applicationId when my updater complains about the "mismatch" with the current one.

Should you decide the app shall stay with my repo, I gladly open a PR with the metadata here to send them to you in Fastlane structure, so you can adjust everything to your liking, and changes would be pulled along with the next release. Should you instead prefer me to remove it, no bad feelings: if the presence there would just "mess up" how everything is supposed to work, that would be bad, full understanding then.

already handled by the Bash script

Oh, now it gets interesting (peeking into the code) Ah, nice! The SMS part would be something I'd like to adopt wouldn't it need an app on the device. Didn't find a way to do that without. Contacts could probably be grabbed by triggering the intent of the Contacts app, but SMS unfortunately not. You might wish to take a look at my Adebar, which does create backup scripts, device documentation and more with plain Bash & ADB as well. Especially getapk and its counter-part restoreapks for handling split-APKs – from a quick glance I didn't see your script handling such, but maybe I've just missed that. Adebar works without any companion app. It doesn't write anything to the device unless explicitly told so (stuff from the transfer directories), so I can simply attach any device with USB debugging enabled and have a nice device doc (see examples here), or users can send me a "dummy device" for "remote debugging", etc :wink:

[mrrfv]

My crawler found it, informed me, I checked the find and added it – while contacting you with all the above details

I do not recall getting an e-mail nor a notification on GitHub regarding this, but I remember keeping my e-mail address hidden back in early 2022 so there's a chance you just had no means of contacting me.

Should you decide the app shall stay with my repo

The companion app does technically work without the script, but because the directory paths are hardcoded you'd have to look into the app's source code to actually use it independently. I can update the app to partially support usage without a computer or just create a new app based on the current code if there's demand for a tool that mass-imports .csv files or pulls contacts and SMS devices off the device's database. Will be able to make the decision in a week though, because I'm busy at the moment.

handling split-APKs – from a quick glance I didn't see your script handling such

I forgot split APKs even existed. Thanks for the suggestion, will see if support for them can be added.

[IzzySoft]

I do not recall getting an e-mail nor a notification on GitHub regarding this, but I remember keeping my e-mail address hidden back in early 2022

I can update the app to partially support usage without a computer

That might be a good idea. If there's a simple GUI to just push some buttons and (optionally) configure the path, there'd be some basic usage as-is. App description could then point out the real intention behind it and suggest to use it that way. Same could be shown when the app is launched. So whoever finds your app via my repo will finally come here – and your project has one more sign post to be discovered more easily :smiley:

I forgot split APKs even existed.

:rofl:

Thanks for the suggestion, will see if support for them can be added.

Feel free to take inspiration from the files pointed out in my previous comment :smile:

[mrrfv]

I published my email on my GitHub profile a few months ago, and the companion app has been added to your F-Droid repo all the way back in early 2022. That's why I'm saying that it could be my fault that you didn't contact me.

[IzzySoft]

Ah, now I see. Well, we finally succeeded with the contact I'd say :smiley:

[IzzySoft]

I've just checked again today and found a bunch of new releases, with versioned tag names, and a fine new applicationId – wonderful! But could we now get things in sync? App at v1.0.11 still identifies as

package: name='mrrfv.backup.companion' versionCode='2' versionName='1.0.4'

where I had expected a versionName='1.0.11' and aversionCode='10'` (remember the latter must be increased with each release, or Android wouldn't see it as an update).

[IzzySoft]

Hmpf. The APK of the new release still has versionCode: 1 – you must increase that with each new release or the updates never reach those having the app already installed! Especially, never decrease it or Android would see it as a downgrade, which it won't accept:

- version: 1.0.4+2
+ version: 1.0.12+1

And much more important: What happened to your signing key? I got an alert that the checksum of your certificate is invalid, so it must be a different signing key / keystore being used. But there's no hint on that in the release notes. This raises the question whether the repo was potentially compromised. So I must ask you for proof whether the new key is legit. Please see How to keep your key safe and what measures to take for the event of loss? Then please give me the means of verification – and put a corresponding hint to the release notes. Until then, updates are disabled in my repo as APKs with a non-matching signature are ignored (security measure).

@mrrfv Pinging you explicitly as the latter ^^ is crucial!!!

Old key:

Signer #1 certificate DN: C=US, O=Android, CN=Android Debug
Signer #1 certificate SHA-256 digest: 9b1b6fd5763e897f322861fb57246206c8d666e5d76480c3bf091b95f40ae4d0

New key:

Signer #1 certificate DN: C=US, O=Android, CN=Android Debug
Signer #1 certificate SHA-256 digest: 2376d72a517cc44c0b14f8fb8d4e229a9c19f430790dc129f4692a189d35ada3

So both keys are debug keys even :scream: You should use a proper release key for signing apps intended for the public. Debug keys are just for local testing!

[mrrfv]

Sorry for the mess with the Android app. I've never paid attention to the signing keys or other important details because the app "just worked" with the Flutter-provided defaults.

This raises the question whether the repo was potentially compromised.

My GitHub account is protected with 2FA (SMS disabled), I don't use any personal access tokens or deploy keys, there are no collaborators (with direct access to the repo) outside of me and I can recognize all devices logged in to my account. It's extremely unlikely the repo was compromised. No signing keys were ever permanently stored anywhere until now, so a probable explanation is that my build system was simply generating a new debug key for each build.

The latest release now uses my own signing key:

Owner: CN=mrrfv, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown
Issuer: CN=mrrfv, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown
Valid from: Sun Sep 17 10:04:37 CEST 2023 until: Thu Feb 02 09:04:37 CET 2051
Certificate fingerprints:
         SHA1: 55:2F:5B:0F:BE:E4:42:ED:0B:96:30:15:99:15:88:4E:52:FE:9C:E0
         SHA256: BF:78:B5:FD:16:39:01:4E:5F:B7:ED:7D:24:3C:B0:28:FF:ED:22:11:98:18:41:19:F8:7A:58:80:A8:AD:0C:29
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3

Then please give me the means of verification

I created a TXT record under android-signing-key-verification.openandroidbackup.me containing basic information about the new key. If you're on Linux, you can view this information using this command:

host -t txt "android-signing-key-verification.openandroidbackup.me"

Additionally, I can send you (izzy at qumran dot org) an e-mail verifying my identity.

[IzzySoft]

Thanks, that should suffice for proof – though the WHOIS information is "anonymized":

• domain was registered 2023-05-08 (i.e. before the incident)
• it is used for and links to your app/repo etc
• there were multiple releases since (between domain registration and incident)

It is still possible that an imposter did this in advance, but I think it rather unlikely. So I re-enabled updates, accepted the latest version, and removed all older ones (which were using the old key). Thanks for your help!

Not sure if any of the points in this issue are still unsolved – else it could be closed now.

[IzzySoft]

PS: Thanks again for the idea with "DNS verification", I didn't have that on the radar. Still, as a friend of mine correctly pointed out, it's hard to verify when such an entry was added or modified (though doing that would require an even higher level of compromising). You might also consider adding DNSSEC as an additional level of security.

Btw, is this type of TXT entry documented somewhere, so one could point to the RFC or such when recommending it to others? I think of adding that to our documentation here as a means of being prepared.

[mrrfv]

Cloudflare has some basic documentation on TXT records, available here. RFC 1035 defines the TXT record.

You might also consider adding DNSSEC as an additional level of security.

Good idea, thanks - I'll do that.