How about GPG distributed with a Linux distribution like Debian as a counterexample? It would be fairly difficult to backdoor GPG in that case without getting caught. Everything happens in the open both at the GPG level and the Linux distribution level. The binaries are signed by the distribution and are distributed by a bunch of mirrors. An evil Debian maintainer would have to make a change that was well enough disguised as something else to evade scrutiny.
Hm not necessarily. You "just" need to get code onto the system that is somehow being loaded into the gpg process or has the ability to load code into a gpg process.
Of course, still orders of magnitude harder than just modifying the js bundle, but not a counter-example.
Snake oil is just a fundamentally wrong label for the issues OP is seeing, even though those issues are of course real and relevant.
> An evil Debian maintainer would have to make a change that was well enough disguised as something else to evade scrutiny.
The xz utils hack got slurped up into sid before it was discovered by a researcher's performance regression in ssh. IIRC the hacked test file didn't even need to be added to the upstream source tree because Debian was blithely downloading release tarballs from Github. No evil Debian maintainer needed.
It's funny that when speculating about Debian's security you forget an actual state-level attack that got code into sid, but when speculating about Signal's insecurity in another thread you're quite happy to imagine potential state-level attacks.