I see a number of ways to put a back door into an OSS project.

• Subvert the compiler. In OSS, the gcc compiler would be the target; for the Java stuff javac, jikes and the eclipse compiler would be the attack points...I don't think there's anywhere interesting to hide the back door in Ant or Maven.
• Subvert the source. I've always felt Xerces to be the juicy target here
  1. It's complex code, especially the XSD processing.
  2. It's built in to Java 5.
  3. It's behind most java-based XML servlet handlers, both Apache (Axis, Cocoon ,etc)
  4. It's not looked at by most developers. Add an extra processing instruction handler and suddenly you could run code on the system. But Java code is slightly harder to subvert than C++ code, because you can't sneak in an = for an == in an if () test and not expect the compiler to complain.
  5. After Xerces comes httpd, and the popular modules, SSL being another attack point. If you can subvert a security system -even to the extent to generating keys that aren't random enough then you are opening up a small loophole. Then there's Tomcat, cocoon and the SOAP stacks. Anything that listens on ports for data from untrusted sources. You can do some very subtle things here. For example, imagine getting happyaxis.jsp to print out some arguments (like a class name to look for) without escaping it. Hello, XSS attack. Same for the code in AxisFault to print a stack trace and error message to an HTML page. I don't know enough about Tomcat or Cocoon to know similar points of attack.
  Source subversion could be done by infiltrating a project, submitting a bad patch, or by getting at the stuff in SVN. I'd suspect that Sourceforge is an easier target there than Apache, because its a bigger organisation; more room for attack. It's why I don't trust logins there, and why at work we track the published checkin notifications to see if the SVN codebase ever differs from that explicitly checked in.
• Get a false release published. The Maven team are rigorous about the approval process for apache artifacts, so that would not work. And the Apache process even requires the PMC to check the artifact against their own source/builds, so that a malicous release manager would, in theory get caught. However, there are many things everyone uses (e.g. junit, testng, hibernate, spring) that come from external projects, and which are also added to the Maven repository, from where they are downloaded and executed. I think I could maybe sneak in an artifact from a non-Apache project onto the Maven Repo without adequate checks. It would depend upon the project, but if you subvert something common, your work propagates. You could even do it subtly by shipping the legit artifact with a malicious POM, one that depends on a malicious JAR you published in a separate project earlier.
• Subvert a mirror. This is the easiest tactic, as all it takes is a mirror not being kept up to date with patches. It gets easier the number of mirrors there are. Subverting an obscure mirror is good as it means it may take longer to get noticed. If you do a really good takeover you could even hide the malicious artifact from all apache.org callers, or even only serve it up to a chosen domain (.mil ?). If someone does that, you have a very hard time detecting it. This is why you should always download files from a mirror you trust to be well run (e.g the heanet and janet mirrors)
• Subvert a redistribution (e.g. JPackage, RPMs, etc). I don't know the process there. Once you've got in the signed distros from, say, redhat, you 0wn the planet.
• Subvert a proxy server, DNS server or the ARP cache in a LAN. This is what you can do if you take over someone's WLAN AP -point them at your own DNS server. Lets you redirect specific nslookups to your own hosts, good for sniffing telnet, web site, and possibly SSH passwords. With this, you can control any HTTP fetch, but HTTPS is out of your control, while SSH with private keys is still good as long as you react properly if your hostnames key changes unexpectedly.

Mirrors are a risk, and we need to think how to deal with them.

One option is only serve the KEYS list, MD5 and SHA1 sums and all other signatures up on apache HTTPS links. That way you have a chain of auth going back to apache, that can deal with both subverted artifacts on a mirror, and subverted DNS/proxies. People should only be pulling down checksums from connections we can control. For the maven repo, this should mean that we provide the md5 checksums of every artifact on an HTTPS server, even if the artifacts are served up elsewhere. The download clients then fetch the sums from that server, validating the artifacts wherever they come from. Alternatively, every MD5/SHA1 checksum is OpenPGP signed, and all programs that download artifacts must check those signatures against the trusted signatory list (which you now need to keep secure...)

Searching through the repository@apache list I see two instances of bad checksums. The first of these was interesting as even after Carlos fixed it, it wouldn't load until I did a shift-reload of the POM and checksum in firefox, which forced a reload in the proxy, after which Ivy got the correct checkums. Our work proxy was caching the bad values indefinitely.

Given that DNS or selective-domain filtering could hide subversion even from scans, any download clients we make (maven2, ivy, Smartfrog download components) need extra paranoia built in. Of course, then we need to build and distribute them securely so their chain of trusted CAs/PGP keys doesn't get subverted.