Reproducible builds

[IzzySoft]

The current release fails RB. The reason is easy: you did not build from a clean tree at the commit the release tag points to, but modified the app/build.gradle.kts after that commit and then built without committing it (and pointing the tag to that commit).

Please always build your release APKs from a clean tree at the commit indicated by the tag. This time, it was easy enough to fix – but that's not always the case. Thanks in advance!

PS: We've prepared some hints on reproducible builds you might wish to take a look at, to avoid issues like this 😉

[IzzySoft]

Oh, besides: today's update was rejected by our repo, because…

2024-11-21 19:45:09,414 WARNING: "com.fadcam_8.apk" is signed by a key that is not allowed:
a85ed0677555011871e48b5a083a2c5c54464a381c665a068e28d7647deea3bb

What happened to your signing key? Your release notes do not mention it. Whoever wants to update to that version will fail, as Android will reject the update as well. Updates at IzzyOnDroid will be disabled until clarified – same will happen at F-Droid as your app there is also pinned to your previous signing key.

Previous key:

Signer #1 certificate DN: C=44, ST=UK, L=london, O=fadedhood, OU=fadcam, CN=fadcam
Signer #1 certificate SHA-256 digest: 999e27d8ee66a67319db6827e0f8549c37624601b86f0108c6970413279ef1d4
Signer #1 certificate SHA-1 digest: 323f4b552e345e75fae7927997f8e52a00e99c68
Signer #1 certificate MD5 digest: ab583ae95e9c9a6911b9d365ae6b2e4d
Signer #1 key algorithm: RSA
Signer #1 key size (bits): 2048

New key:

Signer #1 certificate DN: C=XX, ST=Unknown, L=Unknown, O=FadSec Lab, OU=App Development, CN=Faded Hood
Signer #1 certificate SHA-256 digest: a85ed0677555011871e48b5a083a2c5c54464a381c665a068e28d7647deea3bb
Signer #1 certificate SHA-1 digest: 2cc1eafac5a12fefccf3a5673eb193fa5e17e482
Signer #1 certificate MD5 digest: 6656435a82df413cdb6b68417a911ad3
Signer #1 key algorithm: RSA
Signer #1 key size (bits): 2048

I assume you tried to update the DN – which results in a different key. I hope you've kept a copy of the original key?

[anonfaded]

The current release fails RB. The reason is easy: you did not build from a clean tree at the commit the release tag points to, but modified the app/build.gradle.kts after that commit and then built without committing it (and pointing the tag to that commit).

Please always build your release APKs from a clean tree at the commit indicated by the tag. This time, it was easy enough to fix – but that's not always the case. Thanks in advance!

PS: We've prepared some hints on reproducible builds you might wish to take a look at, to avoid issues like this 😉

I build the apk from the latest master branch idk why this happened but thanks i will read that guide.
[Edit: Read the new comment below this please.]

What happened to your signing key?

And yeah i was thinking to discuss this with some staff of F-Droid but good that you asked. Actually i have that key file but i forgot the password as i made this app in July and i didn't know about keys so i randomly just made it at that time. But now i changed my PC and made a new key for this release as i don't have any other option, so please tell me now what to do? Then key file is with me but during generating the apk in android studio, it asks for password and i don't remember that sadly... :')

[anonfaded]

oh again i forgot something!
I changed the versionCode and version name locally but i forgot to push that and i guess this caused the issue as you also mentioned the build.gradle.kts file.
But now i pushed it, so please let me know how to manage ahead? Like as i forgot the password for previous key (that i have now too but can't use it without pass). I think there is no way for previous key to use without password, but if there is then let me know.

[IzzySoft]

As for the signing key: without credentials it's useless. But before you delete it (you might remember the credentials suddenly), please read: How to keep your key safe and what measures to take for the event of loss?

As signing is a security task, we'll now need to verify it's not just some "imposter" having gained access to your repo here. You'll find background and details in the linked article, but in short, what can be taken as verification:

• signed commits: you didn't sign yours (though you let Github sign some, which the imposter could do as well)
• signing with the original key: you can't as you forgot your password
• another main contributor who knows you personally vouching for you: no other "main" contributor as far as I can see
• an alternative contact established before the incident: non established beforehand
• signing with another key that was already known to be yours before: I don't see such an app here at your Github account

So it seems we're in trouble here – unless you see something I might have missed.

I changed the versionCode and version name locally but i forgot to push that

Yepp, that you did. And that's how I fixed the build here as well, by (automatically) applying the very same change during the build process. Which is what made it RB again – though we cannot show it due to the signing issue. On both ends, F-Droids and ours.

[anonfaded]

Wait now everything got fixed😅

I just opened android studio on old PC (good that i didn't uninstall it yet) and then after clicking on 'generate signed apk' i saw the dialog and found the password and name for it. I just realized that i set one name there but now on new pc I was using another name which was causing the error. Now i saved this info and will store it on cloud.

Also i regenerated apks with the original key file so now check again please and now it will pass the build.

Also i want to ask something:
If i commit all things and make tag and upload apks too, but then i do some changes in the fastlane folder lets say i change the metadata, so will this cause issue on F Droid and IoD? Or this isn't linked with apk or tag so it's ok if i do changes and commit to fastlane folder. Thanks!

[IzzySoft]

Wait now everything got fixed😅

Now why was I expecting that? 😅

I just realized that i set one name there but now on new pc I was using another name which was causing the error.

That's only part of it, AFAIK. Whenever a new key is generated, even with the same DN, I'm not sure if it's identical to the previous one (need to check that to make sure). Better use the original keystore if you can.

The APK currently attached matches your original key. But as it's signed with a different key now than at the time the builder fetched it, the shield won't be up for this release – I guess that's something we can live with, the next release should have it up again fine I hope. Much more important the signing got fixed! Now that was achieved, may I strongly recommend to implement one or more of the measures outlined above? Start signing your commits (once established, it's not much overhead; I can help you with the steps to establish it if needed); maybe you have a personal website or (support) email address that could be added to the metadata on our end; and definitely make a good backup of your key as well as put the credentials into some password safe (I can recommend KeePassXC for that, available cross-platform, and as pendant on Android KeePassDX); maybe also name a contact who can vouch for you.

If i commit all things and make tag and upload apks too, but then i do some changes in the fastlane folder lets say i change the metadata, so will this cause issue on F Droid and IoD?

F-Droid will take the fastlane structure at the tag it builds from. IoD takes it at HEAD when the update is fetched (as the updater runs daily, there're usually no differences – but it gives us the flexibility to fetch "forgotten adjustments" easily with a separate call, in case of "urgency").

[anonfaded]

Yeah i was using that key from months. But didn't actually knew it was important until i learned about AppStores' requirements lol

And yes guide me on how to sign commits too.

And yeah you can save my info. I can delete the comment after you reply so leaving details below:

[anonfaded]

website: https://fadedhood.com
Email: [email protected]

For confirmation, I'm making a website for fadcam(this project too): https://fadcam.fadedhood.com

Let me know if any more info needed

[IzzySoft]

And yes guide me on how to sign commits too.

You'll need a GPG/PGP key for that. I don't know what OS you're working on, but there are good articles about setting up GPG and creating your own key. You can have multiple keys, e.g. one for development and another one for personal use.

Next, you'd need to tell your local Git installation which key it should use. You can do that globally (in $HOME/.gitconfig), but also per project. This would look like:

[user]
    email = [email protected]
    name = John Doe
    signingkey = 6752AA5CB1A4521F

Now, on each commit you use the -S parameter to tell git to sign it. Or you do it like me, and define an alias so you cannot forget:

[alias]
    ci = commit -S

Now, instead of "git commit" you can simply use "git ci".

And yeah you can save my info. I can delete the comment after you reply so leaving details below:

I'd add those details to the metadata of your app, so they'd be "public" as soon as metadata will be made available via a public git repo (which is planned). So if you need to keep those details secret, that would not work. So which of those details can be made public?

[IzzySoft]

PS: I've just added a page to our wiki for the commit signing stuff, including some steps for GPG setup.

[linsui]

Ah, the tag is on a wrong commit and the apk name format also changed. And the key is also changed? 🤦

[anonfaded]

And yes guide me on how to sign commits too.

You'll need a GPG/PGP key for that. I don't know what OS you're working on, but there are good articles about setting up GPG and creating your own key. You can have multiple keys, e.g. one for development and another one for personal use.

Next, you'd need to tell your local Git installation which key it should use. You can do that globally (in $HOME/.gitconfig), but also per project. This would look like:

[user]
    email = [email protected]
    name = John Doe
    signingkey = 6752AA5CB1A4521F

Now, on each commit you use the -S parameter to tell git to sign it. Or you do it like me, and define an alias so you cannot forget:

[alias]
    ci = commit -S

Now, instead of "git commit" you can simply use "git ci".

And yeah you can save my info. I can delete the comment after you reply so leaving details below:

I'd add those details to the metadata of your app, so they'd be "public" as soon as metadata will be made available via a public git repo (which is planned). So if you need to keep those details secret, that would not work. So which of those details can be made public?

Hmm I'll look into it, but if i don't do the signing gpg key part it will still be fine i hope?

And you can add that details, they are public. I was just talking about this comment in this issue, nevermind, you can use that all info.

[anonfaded]

Ah, the tag is on a wrong commit and the apk name format also changed. And the key is also changed? 🤦

Now it's all fixed, there were issues that are discussed above. What else issue you need to discuss?

[linsui]

The tag still points to a wrong commit. The apk name should be FadCam_v1.2.0_universal.apk as before. Glad that you get the old key back.

[anonfaded]

The tag still points to a wrong commit. The apk name should be FadCam_v1.2.0_universal.apk as before. Glad that you get the old key back.

Oh like to replace hyphens with underscores? But is that really needed? Need confirmation from @IzzySoft

[linsui]

@IzzySoft doesn't need that but F-Droid needs that. 🤷

[anonfaded]

@IzzySoft doesn't need that but F-Droid needs that. 🤷

Are you from f droid? He is linked with them somehow tho

[linsui]

@IzzySoft is here for their own repo. I'm here for F-Droid main repo. ;) https://gitlab.com/fdroid/fdroiddata/-/merge_requests/16904

[anonfaded]

@IzzySoft is here for their own repo. I'm here for F-Droid main repo. ;) https://gitlab.com/fdroid/fdroiddata/-/merge_requests/16904

Ok thanks.
So should i just rename the names and replace - with _ ? Is this enough?

[IzzySoft]

Hmm I'll look into it, but if i don't do the signing gpg key part it will still be fine i hope?

If you forget it once in a while, nobody will die of it. It's an additional security measure.

And you can add that details, they are public. I was just talking about this comment in this issue, nevermind, you can use that all info.

Thanks! Then I'll add them now… done.

@IzzySoft doesn't need that but F-Droid needs that. 🤷

@linsui is right there. All IzzyOnDroid has in that context is: ApkMatch: /armeabi-v7a/i – so that's the part that should be stable and unique for each release. And he's also right that, for this issue, I'm here for IzzyOnDroid – while linsui is asking for the builds at F-Droid.org.

To answer your question directed at him: you should decide for one variant, and then stick with it (so either hyphens or underscores – not one time these and another those). I'd suggest you leave the ones at v1.2.0 as they are (that build would fail at F-Droid anyway as the signing key is wrong), and go back to the original naming conventions with the next release, so F-Droid can pick it up properly.

@linsui guess you want to simply disable that tag/build on your end – it will fail RB as well as signature check. It failed both at IzzyOnDroid, too – you know we also pin signing keys. The next release will hopefully be fine again.

[anonfaded]

you should decide for one variant, and then stick with it (so either hyphens or underscores – not one time these and another those).

Okay, from next releases i will stick to hyphens only. Also next release will be pushed very soon so if this one has issues then IoD and F-Droid can wait for next update.

[linsui]

guess you want to simply disable that tag/build on your end – it will fail RB as well as signature check. It failed both at IzzyOnDroid, too – you know we also pin signing keys. The next release will hopefully be fine again.

I thought that the apk has been updated since the old password is found...

Then I'll wait for the next release, thanks!

[anonfaded]

I thought that the apk has been updated since the old password is found..

Right, the apks are now updated with the original key signature, but still if you want to wait for next release then its fine too. But the apks are now updated

[IzzySoft]

I thought that the apk has been updated since the old password is found...

Ah, right, the additional issue of replacing the APKs which had already been distributed – apologies, I got a bit lost here 🙈 So indeed, with the file names adjusted, they could work at F-Droid.

Well, IoD would not process that tag again. But rewriting/replacing an already distributed release is not exactly "best practice"; others might have picked up things as well and get confused (and RB results are becoming weird if the referenced file name disappeared). So if the next release is already close, as @anonfaded just stated, maybe best is waiting for that. Your choice of course 😉

[anonfaded]

I thought that the apk has been updated since the old password is found...

Ah, right, the additional issue of replacing the APKs which had already been distributed – apologies, I got a bit lost here 🙈 So indeed, with the file names adjusted, they could work at F-Droid.

Well, IoD would not process that tag again. But rewriting/replacing an already distributed release is not exactly "best practice"; others might have picked up things as well and get confused (and RB results are becoming weird if the referenced file name disappeared). So if the next release is already close, as @anonfaded just stated, maybe best is waiting for that. Your choice of course 😉

Yeah next release will be probably in 2-3 days, Thanks!

[IzzySoft]

Days, or weeks? 🤔

[anonfaded]

Days, or weeks? 🤔

Actually I'm waiting for a contributor who is fixing some issues, there is some high priority issue with video codec, so as soon as he is done, i will let you know.

Btw some days ago someone told me they downloaded the FadCam app from IzzyOnDroid and it wasn't working on samsung s24, due to armeabi build. So, using the arm64 next time is better i think.

[IzzySoft]

there is some high priority issue with video codec, so as soon as he is done, i will let you know.

Thanks – and best luck with that issue then!

using the arm64 next time is better i think.

Due to the size of the APKs, we can only have either-or. We can switch to arm64, but then people with 32bit devices may complain. To my knowledge there are rather few 64bit devices not supporting 32bit APKs (this is only the 2nd device I know of now), but no 32bit device (and yes, there are still some around) can run arm64 APKs. At IzzyOnDroid, we favor longevity and sustainability (i.e. using your (older) device as long as possible instead of producing more e-waste by switching every 2nd year) over having "the latest and greatest", hence we usually pick armeabi in such cases. Of course, as author you have a say there, too; if you say you want it that way, we can switch to arm64 here with the next release.