Hans-Christoph Steiner @eighthave@librem.one

@mnalis @IzzyOnDroid It has been years since we let new v1-only APKs into f-droid.org. There are some v1-only APKs there because they have been there for many years. It is one factor we consider when reviewing which APKs should archived.

@IzzyOnDroid fdroidserver is fully safe for the tasks it was built for. It has been independently audited as well (we have two more audits coming up). If you have a trusted collection of APKs, then fdroidserver provides the entry point to a trustworthy pipe to the F-Droid client. It cannot protect against malicious upstreams, upstreams losing their signing keys, etc. It cannot fix the deprecated v1 signatures. Require v2+ signatures, and AllowedAPKSigningKeys works with no known weaknesses.

@IzzyOnDroid I'm saying v1 signatures should not be something that anyone relies on any more. Our current thinking is to remove support for v1-only signatures from AllowedAPKSigningKeys because of the weakness of v1 signatures means we cannot provide good security, so it would only provide a false sense of security. For distributing v1-only signed APKs, I'd recommend verifying them via an alternate method other than certificate pinning.

@IzzyOnDroid Since you're investing a lot of effort into AllowedAPKSigningKeys, I highly recommend switching the effort to parsing the signing certificate from v2+ signatures, and away from inspecting the deprecated v1 signatures. Apps with targetSdkVersion 30 or higher entirely ignore v1 signatures, so they are gradually disappearing from use.

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.