Did you read the link as I did? The server hosting the packages was compromised. This could have happened to any software, not just open source, and I'm sure it has.

>The same goes for "verified" binaries, packages, etc... apparently that is not always the case.

If proper package signing was in place, like most modern distros support, then this couldn't have happened. The backdoor was not in the main code in SVN or in Git, which specifically protects against this exact problem, but added to unprotected releases dumped on a server.

>What are the possibilities that such code could make its way into some piece of extremely popular public facing software, say Apache?

No bad code was added to the code base.

> The backdoor was not in the main code in SVN or in Git, which specifically protects against this exact problem

Pedant alert, but Subversion doesn't protect against malicious manipulation; it doesn't checksum its commits.

I think that phrase was intended to relate to just Git, although I could be wrong.

Git uses a lot of hashes but they're for speed, not for security. If you want security from Git, you must cryptographically sign your commits, which is pretty common in big projects.

I was specifically referring to Git.

While those points all matter, don't think of this as an open source issue. This can happen to any software provider, and often does.

the back door wasn't ever in the version control, it seems, which means it was probably someone broke into the servers storing the code after it was packaged. code is definitely read by someone, but open source projects never have the resources to continuously audit ever single package they have for download.

on the contrary, many open source projects sign and hash their packages, to anyone that verifies the signature and hash, the tampering will be immediately apparent.

Anyone who can backdoor a release on their FTP server can easily upload a new CHECKSUM file. Many users probably do not bother to check the hash. Even if you use public key crypto to sign the hash, users probably don't know your public key in advance. An attacker can sign their malicious hash with any valid public key they like.

yes, and its turtles all the way down, but its much harder to compromise (multiple) key servers than a simple download mirror. Its also trivial to setup some sort of totally unknown checking setup, that downloads the packages daily and checks if they are properly signed, and activates big red sirens if it is not.

MD5 hashing is known weak, and must not be used for security.

MD5 hashing is currently used to give quick and simple check on transmission download errors, rather than malicious attacks.

That's why you should use SHA-hashes when you need cryptographic security.

Typically the people looking "through the source code" are the developers working on the the project. Both occasional contributors who want to fix a bug or add a feature for themselves, or the main developers taking those patches and adding them to the main release branch after reviewing the code.

All those developers use VCS repositories, not the releases distributed through FTP sites and such -- which were the files affected here.

Wasn't there a serious backdoor situation with some Linux distros (Ubuntu?) last year? Some guy came out detailing a 10 year contract of silence or something...

You mean the OpenBSD IPSec backdoor controversy? Nothing found AFAIK.

HN discussion at the time: http://news.ycombinator.com/item?id=2029175

As I recall, numerous developers and security experts tore through the relevant code there, and they didn't find anything.

security is not a matter of being open or closed source

"given enough eyeballs, all bugs are shallow" There aren't enough eyeballs.