signing key changed

[obfusk]

The F-Droid build for v1.0.6 failed because the signing key changed.

It looks like v1.0.4 was signed with a debug key by accident (which unfortunately we seem to have overlooked on our end) and you switched to a proper release key after that?

org.sirekanyan.knigopis-1.0.4-36-release.apk
Signer #1 certificate DN: C=US, O=Android, CN=Android Debug
Signer #1 certificate SHA-256 digest: 9090b45fc82ff715c4f1b7162f79fb3a69f3b00c28a7a1b13be603dba3fa9ca0

org.sirekanyan.knigopis-1.0.5-37-release.apk
Signer #1 certificate DN: CN=Vadik Sirekanyan, OU=Software Development, O=sirekanyan.org, L=Yerevan, ST=Yerevan, C=AM
Signer #1 certificate SHA-256 digest: 613948a35cdbe1d151954bfccb66eb74c830ea69242b308a44ddb55aacae4f2c

org.sirekanyan.knigopis-1.0.6-38-release.apk
Signer #1 certificate DN: CN=Vadik Sirekanyan, OU=Software Development, O=sirekanyan.org, L=Yerevan, ST=Yerevan, C=AM
Signer #1 certificate SHA-256 digest: 613948a35cdbe1d151954bfccb66eb74c830ea69242b308a44ddb55aacae4f2c

org.sirekanyan.knigopis-1.0.7-39-fdroid-release.apk
Signer #1 certificate DN: CN=Vadik Sirekanyan, OU=Software Development, O=sirekanyan.org, L=Yerevan, ST=Yerevan, C=AM
Signer #1 certificate SHA-256 digest: 613948a35cdbe1d151954bfccb66eb74c830ea69242b308a44ddb55aacae4f2c

cc @licaon-kter @IzzySoft

[IzzySoft]

@sirekanian I don't see any release notes about a key change. It's of course the right move to use a release key (and not a debug one) – but as you see, a key change causes build failures, so nobody who installed a previous version receives any updates until the builds are fixed, and even not afterwards (as a change of the signing key means one has to uninstall and re-install in order to get the new version).

As for us: we need to look to get a check established warning us in such a case (as this one here shows, it's not always that obvious as a debug key does not automatically imply a debug build).

As for you, @sirekanian – please see How to keep your key safe and what measures to take for the event of loss? Though it might not be "loss" here, the measures taken in case of are comparable. E.g. to confirm it was really you it would help to have a copy of one of the newer releases (i.e. an APK built from the same commit as e.g. v1.0.7) signed with the "old key". And there should be a hint with the release notes that a re-install is needed (generally it would be a good idea to have release notes; you've stopped updating yours in Triple-T after v1.0.5, which was the first affected one, and even for that there's no hint on the key change.

PS: Apologies if this sounds like a rant or even "scolding", it's not meant that way. It's meant as hints for improvements – and request for confirmation. Thanks!

[licaon-kter]

updated recipe, disabled all versions until this is cleared up: https://gitlab.com/fdroid/fdroiddata/-/commit/c6a42f2ccef9fe4e04836a5ef57842e2f5de5c54

/LE: also no AUM https://gitlab.com/fdroid/fdroiddata/-/commit/34277de7d198c051ff2a075fc617f63369992e03

[IzzySoft]

So have we proof fir the legitimacy of the new key meanwhile, @licaon-kter? I see no "reference APK" signed with the previous key at the release so we could check, as I suggested in my previous comment – nor any reference to a verification having taken place.

[licaon-kter]

@IzzySoft upstream did not interact here yet so 🤷

[IzzySoft]

upstream did not interact here yet so 🤷

So disable updates for now. If upstream does not even respond to a security issue after almost a full week, we must consider the repo compromised. @sirekanian (or their account) was active every day since (with the exception of September 11th) with multiple contributions each day, so "AFK" cannot be the reason. I see in your comment above you already did that, thanks! I've just added a comment to both commits for reference.

@sirekanian until this issue here is solved and we were able to verify the new signing key is legit, your app will not be available at F-Droid: all its versions have been disabled, and auto-update as well. Your turn now.