Hans-Christoph Steiner @eighthave@librem.one

In the official release of the #AndroidSDK package "build-tools_r35.0.1_linux.zip", they included what looks like a hand-edited "source.properties" metadata file that is a key part of the "sdkmanager" packaging system:

```
Pkg.UserSrc=false
Pkg.UserSrc=false
Pkg.Revision=35.0.1
#Pkg.Revision=35.0.0 rc4h
```

I mean really? The Android SDK packages are not automatically generated?

https://gitlab.com/fdroid/sdkmanager/-/merge_requests/26

#android #sdkmanager

@gwagner With Big Oil gaining more power via Trump, it is time for individuals to take responsibility. If you believe in climate change, get rid of your second car, ride a bike, take a train.

It is also time for city and state governments to step up. They have the power to do a lot of the things that Trump wants to stop the Federal Government from doing. And those actions would be out of reach of Trump's executive orders.

@rysiek oh wow, this is awesome! I live somewhere where the Nazis reigned for 7 years, and I have been playing a version of this game with my family for a while now. This quote is prescient these days:

> Nazism has nothing to do with race and nationality. It appeals to a certain type of mind

Fun article

@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.