Not the parent and I will continue to use F-Droid but Obtanium is a popular alternative. It allows you to install apks directly from various supported sources (forges, F-Droid repos etc) so you typically use the apk that the app maintainer has produced in their CI pipeline rather than F-Droid's reproducible builds.
F-Droid would likely get APKs from the same place (if reproducible builds are on for the app in question). If this attack is implemented successfully, then that place was compromised as well, and Obtainium can’t do much here to detect that I’m afraid.
Edit: on second thought, they could pin certificate hashes like F-Droid does on the build server, but verify them client-side instead. If implemented correctly this could indeed work. However, I think F-Droid with reproducible builds is still a safer bet, as attacker would have to get write access to source repo as well and hide their malicious code so that F-Droid can build and verify it.
Okay, but sideloading is worse? AFAICT the problem we're discussing was in F-Droid doing extra verification (somewhat incorrectly, apparently) of an APK before handing it to Android to install. Regardless of F-Droid, Android will check signatures on updates against the installed version. So your response to F-Droid imperfectly checking signatures as an extra verification on first install... is to skip that entirely and do zero verification on first install? That's strictly worse for your security.
Sideloading sounds like a massively worse option than using F-Droid even with this flaw. Humans are way more likely in making mistakes, and you lose a lot of safeguards in between you and the APK when you sideload. Also, you don’t get updates as fast, which is a whole problem in itself.
So, IMO we should not fall into that trap of immediately removing apps that had a security flaw and falling back to a way worse alternative (which sideloading is) instead.
