On Wed, 2004-06-09 at 02:10, Jason van Zyl wrote: > On Wed, 2004-06-09 at 00:11, Julian C. Dunn wrote: > > > Well, we all "hope" that nobody mucks up the repository, but that only > > gets you so far -- all you have to do is to ask the Debian or FSF > > maintainers whose sites got cracked how far "hope" gets you. > > Yes, I'm well aware. It's not like I'm floating along in la-la land. But > I don't have infinite time and I tackle what I can as does anyone else > contributing to maven.
Understood. I just took exception to your remark that security is a "bogey man" when, in fact, there have been demonstrated instances of people (script kiddies and otherwise) breaking into repository servers and wreaking all manner of havoc. > > In my mind, the correct approach as suggested by Casey, Pryce et al. is to > > store the MD5 or SHA1 checksums offline, i.e. not in the same place the > > JARs themselves, and then to to transfer those securely. This is basically > > the approach used by the FreeBSD ports system or NetBSD pkgsrc. The actual > > transfer of the JARs need not be secure as long as the checksums are > > trustworthy. > > If you would like to expand on that and make a little doc with some > references I will happily add it to the wiki material that exists there > already. Sure. My document is attached as a text file. - Julian -- Julian C. Dunn, B.A.Sc. <[EMAIL PROTECTED]> Software Developer, CBC New Media Operations Office: 2C310-I * Tel.: (416) 205-3311 x5592
A number of key security issues have been identified in the way Maven resolves and retrieves dependencies. These issues have been identified in documents written by Nat Pryce and John Casey: http://docs.codehaus.org/display/MAVEN/Repository+-+Security http://docs.codehaus.org/display/MAVEN/Repository+-+Security+by+nat+pryce Casey proposes to tighten up the repository upload procedure, which is a good first step. However, signing all artifacts (and in particular, the ongoing workload of needing to distribute derivative certificates) may prove to be too onerous a procedure. Pryce proposes an reasonable solution from a security perspective: storing JAR signatures in the repository as well. Presumably users would then obtain the public keys of the signers through some non-Maven means. However, whether this would actually happen is a matter of discussion. My suspicion is that most people (aside from the truly paranoid) don't even do this for the code they download from the main Apache repository, e.g httpd. A solution that I propose is to adopt the model taken by both the FreeBSD and NetBSD projects for their software packaging. In the "ports" (FreeBSD) or "pkgsrc" (NetBSD) systems, the checksums and sizes of the source tarballs are stored in a separate location, i.e. in the ports/pkgsrc CVS repository itself. Access to CVS is tightly controlled, just as it would be for the actual code itself. The checksums and sizes are transferred to the users' machines by a secure mechanism, i.e. CVS over SSH or cvsup. Adapting the model to the Maven project would entail the following: 1. Store checksums and sizes of JARs/distributions at Apache.org. Apply the same control to the checksum repo as would be kept for actual CVS commits to the code. 2. When Maven requires an artifact, it securely (e.g. over HTTPS) retrieves the size/checksum information from Apache.org. 3. It then retrieves the artifact from ibiblio. If ibiblio has been compromised, the checksum/size will not match and Maven would refuse to continue. References: ----------- [1] Using FreeBSD Ports: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports-using.html [2] NetBSD Pkgsrc: http://www.netbsd.org/Documentation/pkgsrc/ [3] NetBSD Pkgsrc info about 'distinfo' where checksum/size info is stored: http://www.netbsd.org/Documentation/pkgsrc/components.html#components.distinfo
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
