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).