It's really as many suspect - they are prepared for targeting the crypto implementations, through exploits or backdoors and if they can't they can target your computer.
Also, open-source is of course safer and some of us have been repeating for years that you can't trust binary blobs, security being just one reason out of many.
Only if you're auditing the code and building it yourself, or have a trusted place where that's done. I would wager that for the vast majority of users are just using the binary blob provided by someone. Otherwise, the "code" you're using could be as compromised as any closed source program.
To be sure, absent the measures you describe the effect is significantly weaker than with them, and other effects may dominate.
If you're not, then it absolutely is not an improvement. The attack vector has just shifted slightly.
Using FLOSS, alone, is a marginal improvement in security, other things being equal. It can be combined with still other measures to make a bigger difference.
Binary blobs can be checked easily if they originated from the source code published. Major Linux distributions, like Debian, have people all over the world auditing the repository. If a backdoor is planted, with the repository being public, most projects have a full history of whom added what and when. Code reviews happen too.
They would have to get the base distribution signing key, which is probably a shared secret that requires multiple people to unlock.
Have there been any hints of NSLs or FISC orders requiring the disclosure of private Linux distribution keys, some of which may not even be held in the US?
So, since they don't specifically need to patch your openssl package to compromise your openssl library, they could just as well suborn the signing key of (presuming Ubuntu) some PPA author, as long as the user they're trying to bug has that PPA in their sources.list.
Packaging systems do detect file collisions, however, and with something vaguely similar to checkinstall or fakeroot they could detect attempts to overwrite other packages' files in the pre- and post-install scripts.
http://www.oracle.com/technetwork/server-storage/solaris11/t...
That coupled with system wide snapshots is a great tool to audit a system after a patch is applied.
On the other hand, audit is possible, which is a hell of a lot better than the alternative, limiting their options to underhanded subversion is again better than the alternative, and to my knowledge nobody has actually ever picked up on a case of this happening (while we do know they have had the security of close-source software subverted).
(I wonder if anyone's audited gcc/clang binaries installed in readily available linux/bsd/MacOSX distros to see if they're free of "Reflections on Trusting Trust" concerns?)