Hans-Christoph Steiner @eighthave@librem.one

Don't get me wrong, I love #apksigner for signing and verifying. It is a vast improvement over jarsigner, etc. And @fdroidorg relies on it. Passing apksigner should remain a requirement for any APK published on f-droid.org. As things stand now, I would be staunchly opposed to removing `apksigner verify` checks for f-droid.org. I also recommend that all repos also require apksigner. 3/3

For example, #fdroidserver is coded against apksigner from build-tools version vX.0.0. Someone does `pip install fdroidserver`. Then at some point, the user upgrades apksigner to version vY.0.0 which breaks the parsing before fdroidserver supports apksigner vY.0.0. That breakage needs to fail gracefully, and that is really hard to do. Much harder than just writing pure Python code to extract the certificates which is tested against the apksigner test suite. 2/3

I'm sometimes asked why #fdroidserver implements somethings in #Python rather than scraping #apksigner output. Reliably and securely parsing CLI output over the long term is really hard to get right because deployed fdroidserver code has to be future proof, in that it has to support newer apksigner versions that might have changed its output. 1/3

@IzzyOnDroid Good to hear you have more layers of verification. I'd like to read about what you're doing, since you've been handling the auto-download of APKs for a long time, so perhaps there is more we could add to `fdroid update`. Could you point me to them? There is a good foundation for us to build on: APK v2+ signatures are quite robust and APK signing keys tend to be quite stable over time. That makes it possible to automate checks so repo operators don't have to know all about signing.

@IzzyOnDroid Things with the Mobifree label are things that are being considered as part of that grant. It is definitely not a promise. It is quite likely we will work on AllowedAPKSigningKeys as part of Mobifree, I'd like to, but no guarantees. Currently, I'm thinking of making AllowedAPKSigningKeys only support v2+ signatures, since v1 signatures are deprecated, on their way out, and really overly complicated. I see no sense in trying to build security guarantees on top of them.

@IzzyOnDroid I'm not sure the point you're trying to make here. EU Horizon grants such as Mobifree are large partnerships between around 10 projects. The work and goals are all nailed down between the partners. These kinds of funds are not free money to spend as we please.

@IzzyOnDroid indeed AllowedAPKSigningKeys was inspired by the various custom scripts and processes we had in place already. We welcome contributions to improve AllowedAPKSigningKeys. We don't currently have funding to work on it. We would gladly help someone put together a funding proposal to work on it.

@IzzyOnDroid I understand your concern. From what I know, the IzzySoft repo relies much more on AllowedAPKSigningKeys to provide a secure repo than f-droid.org or guardianproject.info (the repos I'm involved in running). Both had extra verification before AllowedAPKSigningKeys existed, so there, its just an extra layer of protection. The goal of AllowedAPKSigningKeys is to make it easy for non-technical people to manage binary APK repos securely. That is a work in progress, and your reports help

@IzzyOnDroid the regex fix is a good one, we'll look into merging that. I'd need to see a v2-signed APK that is installable on Android that demonstrates the exploit it in order to consider this an actionable security vulnerability. APKs signed by v1-only are not even installable on latest Android versions, and Android 7.0 and above support v2+ signatures. Looks like obfusk's proof of concept is a v1-only APK. Do you even ship v1-only APKs in IzzySoft anymore?

@Fr333k one has to do everything to survive the dark, cold, deeply foggy winter! So why not embrace the dark!

@captainepoch @cnx @fdroidorg @husky hehe you're welcome. That's perfect! If we focus on fixing things upstream as much as possible, many apps will just automatically become #ReproducibleBuilds without the devs even being aware. Your message made me feel like we're on the right track, thanks!

@IzzyOnDroid @S1m @fdroidorg @SylvieLorxu The issue you are pointing to is only for APKs that have APKv1 signatures. That means apps with minSdkVersion less than 24 (Android 6 and older). That is devices that have not had an OS update since 2015. That is maybe a couple of percent of Android users? So I decided my limited time was better spent elsewhere rather than sinking days of work to supporting a small percentage of apps on a tiny percentage of devices. That said, I welcome contributions.

@obfusk @fdroidorg @IzzyOnDroid I agree it is important to mention when there are patches, and the build environment is also often relevant. We use a minimal Debian/stable build environment both in CI containers and in production VMs to provide as neutral a build environment as possible. Plus we also like that #Debian is the most reproducible base OS that is currently feasible to use for Android builds.

@cnx @fdroidorg @captainepoch @husky All our rebuilds of Husky from v1.4.0 til v1.5.3 have been reproducible, so most likely, the newer ones still are. We'll see for sure once our rebuilders catch up with the backlog.

@AAMfP @fdroidorg It looks our current rebuild hasn't reached your latest releases yet. Based on the output from v6.8.0, it looks like an issue from the tooling itself that is likely fixed in newer versions. I don't recognize the specific issue, perhaps someone else does? I'll try to bump up the priority of rebuilding your latest release.

https://verification.f-droid.org/name.bresciani.marco.tkcompanionapp_680.apk.diffoscope.html

@SylvieLorxu @fdroidorg @IzzyOnDroid I totally agree that people should only file useful issues based on concrete solutions. Most of the #ReproducibleBuilds issues we are seeing in our mass rebuilds are the classic timestamps and sort order issues. These are generally easy to spot in the #diffoscope output we are providing. For fixing timestamps, I recommend https://reproducible-builds.org/docs/source-date-epoch/ For sort order issues, usually the dev has to just add sorting to the code, like https://codeberg.org/iNPUTmice/Conversations/commit/37f51949fda2f04cd64eab76a1cc91343695f52e

@IzzyOnDroid @S1m @fdroidorg @SylvieLorxu we aim to support signer key rotation. We would greatly appreciate it if those who know about bugs would file them in our issue tracker so that we can track them. Also, we welcome contributions there.

@IzzyOnDroid @fdroidorg @SylvieLorxu I would be happy to see your repo become #FreeSoftware! As you well know, F-Droid only endorses verifiable free software projects.

It is also great to see all your work on #ReproducibleBuilds. We are continuing to build upon our years of effort there. Our approach is focused on identifying issues and getting things fixed upstream as much as possible. Then devs do not need to use any special tools to achieve reproducible builds.

@voxel @fdroidorg It is now. v1.20.0 and newer are all reproducible, for example: https://verification.f-droid.org/org.fdroid.basic_1020050.apk.json

The "failed" page only shows failures since we are highlighting those to fix them. Check the JSON API for the full history, e.g. https://verification.f-droid.org/org.fdroid.basic.json