I've always been very trusting of open source software. I've often thought "surely someone else has looked through this source code" and just assumed that malicious code never hits stable releases. The same goes for "verified" binaries, packages, etc... apparently that is not always the case.<p>What are the possibilities that such code could make its way into some piece of extremely popular public facing software, say Apache? How many cleverly hidden "bugs" already exist that open us up to complete pwnage for the clever bastard behind them?<p>Just think about the havoc someone could do with a few popular but nasty PyPi or RubyGem packages...
The comments on this page immediately reminded me of Ken Thompson's point: "You can't trust code that you did not totally create yourself."<p>He wrote this right after demonstrating how to create, step-by-step, an undetectable trojan horse in the C compiler. Here are the steps for creating such a trojan horse:<p><a href="http://cm.bell-labs.com/who/ken/trust.html" rel="nofollow">http://cm.bell-labs.com/who/ken/trust.html</a><p>[ Also see <a href="http://news.ycombinator.com/item?id=2642486" rel="nofollow">http://news.ycombinator.com/item?id=2642486</a> ]
So several Horde releases were trojaned for three months? That's pretty terrible. Good on them for coming clean.<p>What's the best way for open source projects to make it easy for their customers to get verified downloads? A lot of packages post MD5 checksums but no one tests them when downloading manually, do they? Automated signature checking on Debian packages seem to work better in practice; homebrew also verifies download checksums automatically.
Horde 4 is not affected. If you're running it, you're fine.<p>The affected releases are:<p>- Horde 3.3.12 downloaded between November 15 and February 7<p>- Horde Groupware 1.2.10 downloaded between November 9 and February 7<p>- Horde Groupware Webmail Edition 1.2.10 downloaded between November 2 and February 7