Dear #Android #App #Developers, as it still happens far too often (no naming, no shaming! 💩 happens to everyone of us) a reminder to take good care of your #signing keys – and also take precautions for the case that your keystore might get lost. Please take a look at: https://f-droid.org/2023/09/03/reproducible-builds-signing-keys-and-binary-repos.html#lessons-learned-2-how-to-keep-your-key-safe-and-what-measures-to-take-for-the-event-of-loss where I outline this topic.
Thanks!
#security
@[email protected] I have my doubts towards the former (that would mean rolling back their implementation, at least in parts, and using the suggested patches instead, which they rejected. The argument was that f-droid.org itself does not need key rotation, IIRC.). And as long as we still use fdroidserver, the only way we can notify is via the inlined per-release changelogs (aka “Fastlane changelogs”), which is what we do.
@[email protected] Hm, there should be a way to set a warning for a version in the index that the client can use to inform users
@[email protected] which needs to be implemented serverside (fdroidserver writing the index) AND clientside (to show it). Without the index itself supporting it, there’s nothing the clients can do. So: https://gitlab.com/fdroid/fdroidserver/-/issues/301 ? https://gitlab.com/fdroid/fdroidclient/-/issues/195 ? Does not look like this will happen.
@[email protected] I’ll try to open issues for more specific messages then: metadata to warn about removed application, and metadata to warn about application that need to be reinstalled
@[email protected] Remember that WE cannot implement those. Everything that needs changes to the index, is out of our hands – at least as long as we’re still bound to fdroidserver. So such issues would need to be filed there – with the tools that generate the indexes. Our client devs would surely pick up those data once available.
@[email protected] Yep, I know ! Will share once done