F-Droid vulnerability allows bypassing certificate pinning

GrapheneOS They almost entirely build and sign the apps themselves. For a small portion of the apps, they use the developer signed APKs if they match what they build. This can go very wrong where updates get indefinitely delayed especially with them using a problematic and outdated build environment. There are prebuilt libraries either way. They do not review anything when fetching and building the code but rather do automated scanning including with antivirus. Fetching and building the code is automated. Signing is triggered manually for batches of code. It's almost entirely automated on a server other than signing, and they might automate signing too. The signing not being automated doesn't mean there's some kind of review process before it's signed.

This did not answer my question. I wanted to know about the vulnerability this thread is about. What certificate pinning is it that is being bypassed?

GrapheneOS The xz situation in fact demonstrated that this packaging system even with reproducible builds will not stop developers shipping a backdoor to users via the source code built by these distributions / repositories.

Everything we are doing within the security community is raising the bar, the amount of effort an attacker need to spend to be able to compromise a user or project. No one will ever be totally immune to attacks. If you didn't have reproducible builds, you could easily insert a backdoor into GrapheneOS, and no one would ever be able to tell. But now you have reproducible builds. That means anyone who are diffing the changes from GrapheneOS release to release, would very likely discover your attempt to insert the backdoor, unless you have extremely advanced skills in how to write code that looks genuine and correct but in fact is malicious and has a backdoor. You would have to have the skills to fool the ones reading your code. That is a waay higher bar. Especially since the backdoor getting discovered would mean all trust in you and GrapheneOS immediately disappear, so you never get a second chance. Not even the malicious xz developer had those skills, it got discovered after all, and he was seemingly a very skilled state-employed hacker.

I think you are downplaying the value reproducible builds have. As far as I see it, it is one of the most important security advances we have had, right there alongside memory safe programming languages, and end-to-end encryption.

missing-root In practice, neither you or others are checking the sources. Even if you were checking the sources, finding an intentionally hidden vulnerability is unlikely. Serious vulnerabilities often last for widely used and widely reviewed projects like the Linux kernel for years or even decades. If accidental vulnerabilities can't be reliably spotted even after substantial review, auditing, etc. that doesn't bode well for the ability to find a backdoor.

The xz situation was brought up and that was not spotted in the source code after several rounds of them adding backdoor infrastructure to the Git repository. It wasn't spotted when they put the finishing touches in the source tarball for the release, but it's highly unlikely that would have been spotted if they'd pushed it to Git since the final touches were well disguised / hidden. It was only the overall set of changes which when put together triggered deobfuscating a payload and using it maliciously. Most of that was in the Git repository already before the final pieces were added. It's unclear why they took the risk of making a far more non-reproducible source tarball someone might have noticed differed from what got generated from the Git repository. It's an example of their lack of stealth and finesse despite the long term commitment to it. They also severely screwed up the performance and that's why it was discovered: unnecessarily causing huge spikes of CPU usage. That likely would have been spotted by others eventually. If they hadn't made those mistakes, there's a high chance it would have gone undiscovered for months or longer. Would it have made it to Debian stable? Probably not considering it has frozen packages for years and hasn't had a new release yet, but Debian stable is full of unpatched, known vulnerabilities in a lot of the packages, including things like web and mail servers which are remote-facing but typically don't classify all the little memory corruption bug fixes as security vulnerabilities with CVE assignments. Most projects don't seek out CVE assignments at all.

xuid0 github is not better here. It adds an additional middleman you need to trust.

Also Obtainium has no methods of verifying packages, only the android package manager solves this, if the APKs are signed.

Using F-Droid repos will be more performant and the F-Droid client is also more minimal. Using official repos from the devs should eliminate all risks with F-Droid, apart from maybe the client being outdated, then you can still use F-Droid Basic.

xuid0 We should be checking the APK every time it is downloaded. That means first install & updates.

The AOSP package manager which handles installation and updates of apps/apks pins the signature on install and then all updates must be signed with the same cert or they are rejected.

fid02 it is the "recommended" way to obtain APKs

Maybe "commonly recommended" would be more appropriate. Personally I feel this is generally implied when people say "recommended" without a specific source, but I suppose some might think its not clear where the recommendation comes from and lead to misunderstandings.