Hi! First of all, I’d like to thank you @Bubu and @hans (and everyone else) for your work on F-Droid. It’s the only thing that makes android bearable for me. I’m really happy that this idea has been given so much positive attention. This has been high on my wishlist since I discovered conscrypt could be bundled with apps. This will benefit all devices, not just old ones (improved security, TLSv1.3, etc.)
I was originally planning to bring this up when I had a good idea for how to implement it, but since it’s already being discussed I’d like to add my thoughts on implementation and why using signatures could be a big problem. Most of this is just repeating what I’ve written here and here, but I’ve already written way to much there and I’ll try to keep this short and summarize my thoughts. [[[me from the future: turns out this became a giant wall of text… sorry everyone! I hope it’s still decipherable…]]]
If the solution relies on all apps checking a signature, no matter how it’s implemented, if that signature changes then all apps (and relevant versions of them) will have to be rebuilt against the new signature. Since most apps will benefit from the increased security and supported protocols (and cipher suites), even on relatively modern platforms, it’s possible that in the future the number of apps having to be rebuilt will become vary large, possibly without any clear way of telling which app will need to be rebuilt or not. And it possibly includes apps outside f-droid (which may or may not be easy to rebuild).
Compare this to the Privilege Extension: right now when building the F-Droid client with a different signature, it only requires rebuilding the Privilege Extension against the new build (Application ID, key fingerprint). This is just as easy as building the Client, and how to do this is even documented (very nicely) in the README. Rebuilding every single f-droid app requires setting up a build server and a lot more work (and time).
And there are many situations where the signature would change (=all apps rebuilt):
- If a developer/contributor wants to improve f-droid (or conscrypt provider/installer depending on how it’s done) and/or the bundled conscrypt (like fix errors or update the conscrypt version), and then test it on his/her phone with apps before submitting the changes.
- If someone wants to make a fork of the F-Droid client. In fact, there already is a (work in progress) fork that tries to restore the old/classic user interface. Should all apps then be rebuilt by that person? Or should F-Droid rebuild the apps against both signatures? Should this be done for every future fork?
- If the signature leaks it can lead to extensive (and easy) attack vectors with code execution in every single app that relies on it. Completely fixing it will require rebuilding all apps, including old versions that people might have installed. And tracking down apps outside f-droid that might be affected… and finally get everyone to update…
- If someone wants to make an alternative conscrypt provider/installer that is compatible with the f-droid apps… they would need to rebuild them and host an entire app repo.
- If someone wants/needs to make a fork of the entire F-Droid project. Possibly because the project gets overtaken similar to CyanogenMod and needs to be rebranded. Admittedly this would be the easiest problem to fix (since new build servers would be set up anyway).
Also I feel that this would lead to a weird kind of Tivoization (“here are the sources for the f-droid client/conscryptprovider, but you can’t actually use them for real”). And possibly be a problem for Software Freedoms #1 and #3 (the freedom to change and to distribute changed versions). But if nothing else, it’ll be very impractical in the situations listed above. Imagine if manually building a new openssl package for debian also would require rebuilding every single package relying on it?
The reason I originally suggested using the Security Extension (or something like it) is mainly because the way it’s installed (via a .zip through recovery) gives it special access to the OS. This could be a way to implement a safe/reliable API (that no normal app can mimic) for apps without requiring signature checks. And since it has a safe communication channel with the f-droid Client, the client could update the conscrypt version. Also it would not increase the normal f-droid client apk size. And no need to enable “untrusted sources” to install another apk. I see 3 approaches in this spirit (this is what I wanted to test and evaluate before starting this discussion, but maybe it’s for the best if everyone look at it):
- Add support for an API to the Privilege Extension which no normal app can mimic, through which normal apps can get conscrypt, and the f-droid Client can update conscrypt.
- Create a new “app” like the privilege extension (a .zip installed through recovery), but with the sole purpose of handling the conscrypt stuff. More modular, allows people to install only if needed (but even modern devices will benefit from an up-to-date conscrypt).
- The most interesting: create a .zip for installation through recovery that adds a new .jar file to the os files, which gets run at startup and does something similar to “Security.insertProviderAt(Conscrypt.newProvider(), 1)” but on a global level (like the security providers included in the os). The cool part about this is that it will replace the default security provider for the entire os, for default apps and installed apps (from f-droid or not) without requiring any app changes! Does anyone know how feasible this is?
Also it would avoid the catch-22 of the fdroid client needing conscrypt to download conscrypt (which will probably be necessary in the future since KitKat misses most/all sane cipher suites used for TLSv1.2). But of course that could also be solved by bundling conscrypt with the f-droid client, but it will increase the apk size. And as I’ve said above sharing the bundled conscrypt with other apps should not be done directly by having each app checking the signature of the f-droid client.
Ideally I’d like to see something like (3) above, combined with the ability of upgrading the provider through F-Droid. On the exact details, if either conscrypt is bundled with f-droid and provided to the conscrypt-/providerinstaller (with a signature check like Privilege Extension) which in turns provides it to other apps (inserted globally). Or if the F-Droid client updates conscrypt as a file which the conscryptsprovider/-installer blindly uses (like “libconscrypt_jni.so” in google’s SecurityProvider… I think)… well, I’m not sure. I’m leaning towards the later because then the conscrypt can be inserted at os-level before the f-droid client has even started or if it’s missing.
Also, this might be important to keep in mind: in order to make sure an app uses TLSv1.3 on all platforms and disables obsolete/insecure protocols (SSLv3, TLSv1.0, TLSv1.1), it’s not enough to just use an a modern conscrypt version. A little bit more work is necessary, see my example for bundling conscrypt. This could possibly be done automatically through the conscryptinstaller/API. Or at least it should be mentioned in some documentation.
So… I’m sorry for writing so much text! I just want to add, that I don’t believe that I know everything here, and in the end I trust you to make the right decision on this. I’m just worried that the wrong decision at this point can end up causing a lot of problem down the line. And it could become really difficult to undo once it’s in place and used by many apps. At some point in the future we might even have “historical” apps that can’t be rebuilt anymore, which could make the f-droid signature incredibly important (or dangerous…) for their compatibility.
There is one more thing I wanted to bring up: until this is turned into reality, would it be possible to put two versions of AntennaPod on F-Droid? I can probably change my pull request so that the Free flavor can be built both with and without bundling Conscrypt. Or even better, I could provide my changes as a .patch, which I think the f-droid build system can use through the build metadata(?). There has been concern about the increased apk size so giving people the option might be best.