A post from the developer of WireGuard on the severe security flaws and lack of trustworthiness of F-Droid:
https://gitlab.com/fdroid/fdroiddata/-/issues/3110#note_1613430404
This led to them including a self-update system which was openly implemented and documented. F-Droid was unaware they'd shipped it for half a year, and by then WireGuard had essentially escaped from in their words being held hostage by F-Droid.
This was a rare case where an app used developer signing keys via their flawed reproducible builds system. Most don't.
For the vast majority of apps they package, F-Droid downloads and builds whatever developers publish, then sign it with their own keys and release it. They aren't doing any real review as people believe. What they really do is run things through basic scans looking for libraries they've disallowed, primitive antivirus checks for common Android malware as if that's what malicious code in an open source project would be, etc. It took them that long just to realize an app openly took over updates.
F-Droid has incredibly poor security practices and a strong anti-security attitude held by most of the people involved. They've consistently engaged in coverups of vulnerabilities and targeting multiple security researchers with libel and harassment.
It's a massive single point of failure and not worthy of the trust many people are placing in it. It's adding another trusted party compared to using the apps built and signed by the developers. It is not avoiding trust in the developers of apps.
Regularly not shipping critical Firefox security patches for months is the norm for the main F-Droid repository. Whether or not they sign the apps themselves as they do for the vast majority of apps, updates can be indefinitely delayed based on issues with their outdated infrastructure or their Debian-style downstream patches needing to be updated.
For the small subset signed by the app developers, many kinds of disagreements between F-Droid and developers will mean an end to receiving updates.
@newhinton @GrapheneOS In case you missed it, the bugs v1-only and v3.1-only APK certificate parsing were acknowledged, accepted, fixed, and released: https://floss.social/@fdroidorg/113871647937841033
We were asked not to ping the reporter anywhere, so that makes it difficult for us to give credit.
APK Signature pinning is still a research topic, there are no public implementations I know of besides ours. We welcome alternate implementations and experiments. Please dive in! It is not a simple problem, but important.
@newhinton @GrapheneOS There is a difference of opinion in a longer term fix. They want to maintain support for v1-only signatures, we are working to require v2/v3 signatures in order to use AllowedAPKSigningKeys. v1 signatures are deprecated and going away. And the design of v1 signatures is massively over-complicated, and will never really be possible to support properly.