[Bug Report] F-Droid reproducible build failed

[linsui]

Bug Report Checklist

• I have written the bug report in English with a clear, descriptive title.
• I confirmed there are no existing bug reports — open or closed — that already cover this issue.
• I checked the CHANGELOG to ensure the bug hasn’t already been fixed.
• I reproduced the bug on the latest GitHub release.
• I included clear reproduction steps, expected vs. actual behavior, and any relevant logs or screenshots.
• This submission describes one bug only.
• I understand that incomplete or vague reports may be closed without investigation.
• I optionally donated to support the MultiLauncher mission.

App version

1.11.3.4

Android version

16

How did you download the software?

Github (Release)

Bug description

https://gitlab.com/fdroid/fdroiddata/-/jobs/12708725137 The signing key is changed. What happended?

Steps to reproduce the bug

Check the signing key

Expected behavior

The key is not changed

Screenshots/Screen recordings

No response

Logs

No response

Additional information

No response

Terms and Conditions

• I have read all the rules above and filled in the requiered fields to the best of my ability.
• I accept that if I fail to follow the rules listed above that i will be blocked from interactions with this project.

[CreativeCodeCat]

👋 Thanks for reporting!

We will get back to you soon about this issue.

[CreativeCodeCat]

Lost my old key access so using the same one I have for Google play.

[linsui]

Oh no...

[CreativeCodeCat]

Oh no...

ya so ill have to use this new key now :(

[IzzySoft]

ya so ill have to use this new key now :(

It's not that easy. Signing is a security measure. Anyone who managed to e.g. overtake your Github account could simply attach an APK, claiming it's the official one – but they could not sign it with your key, without having it. So what would such an imposter do? Saying they lost the signing key, and you should simply trust them and switch over.

That's why such a key change needs to be verified, see e.g. How to keep your key safe and what measures to take for the event of loss?

So now let's see what remedy we might have:

• the old key is lost, so it cannot serve as verification element (e.g. by signing the very same APK with it) ❌
• your commits are signed with your GPG key, at least occasionally – and the key of the last signed commit matches the one for commits before the previous release ✔️
• you've left an alternative way to contact you, so we can have a double proof ✔️

@linsui I'd say number 2 is sufficient to allow the migration to a new signing key? Should number 3 add to this (which I expect it will), this IMHO is even icing on that sour cake.

@CreativeCodeCat good you took proper precautions! A suggestion of an additional one, from the linked article: make good backups (maybe even store an encrypted USB stick with good friends to top that). While it can be cured, it's always better it isn't even needed. Additionally, please add a corresponding note at the top of your release notes! 💩 happens to the best of us, but we need to be transparent. Which also helps building up trust (this is nothing people will miss: they cannot simply update now, Android will deny that, for security reasons – so they need to uninstall and reinstall the app).

[CreativeCodeCat]

google playstore has always been signed with this key too and its linked to 2 usb's for safty so it doesnt happen again

[IzzySoft]

Thanks! Second channel confirmed as well. But as I'm just here:

! repo/app.mlauncher_1110304.apk contains signature block blobs: 0x504b4453 (DEPENDENCY_INFO_BLOCK; GOOGLE)

That can easily be avoided with adding just a few lines to your build.gradle:

android {
    dependenciesInfo {
        // Disables dependency metadata when building APKs (for IzzyOnDroid/F-Droid)
        includeInApk = false
        // Disables dependency metadata when building Android App Bundles (for Google Play)
        includeInBundle = false
    }
}

For some background: that BLOB is supposed to be just a binary representation of your app's dependency tree. But as it's encrypted with a public key belonging to Google, only Google can read it – and nobody else can even verify what it really contains. More details can be found e.g. in our documentation on Signing Block Checks at our website, and in our blog article Ramping up security: additional APK checks are in place with the IzzyOnDroid repo.

Could you please do that for future releases? Thanks in advance!

[CreativeCodeCat]

That can easily be avoided with adding just a few lines to your build.gradle:

Added thanks for that infomation.

[linsui]

In fact, I thought it's better and easier to just use a new appid with the new key. No migration anyway.

[IzzySoft]

I don't think that is needed. It would also mean quite some overhead at ALL places:

• dev needs to adjust the app (namespace and all)
• repos need to retire one app and establish a new one
• those using the app don't get a clue, as there's no hint; keeping the appid, they at least see there are newer versions

So at IzzyOnDroid, we're fine with keeping the AppId. A key change is why, in the app's YAML metadata, AllowedAPKSigningKeys can be an array, btw – exactly for situations like this (temporarily allowing 2 keys, for the time of the transition). Which at IzzyOnDroid now is in place: new key allowed in addition to the old one for now, and the old one being removed in about a month (together with the APKs using it).