Hi John, For companies which are this paranoid, perhaps they should not download artifacts from public repositories at all. Have you considered setting up a Nexus / Archiva installation which does not connect to any public repos? Then you can manually deploy any artifacts you wish to this repository, while ensuring they meet whatever stringent requirements you wish.
~Daniel -----Original Message----- From: John Patrick [mailto:[email protected]] Sent: Thursday, February 17, 2011 10:56 AM To: dev Subject: Repository Roadmap Evening, Morning, Hello, I'm wondering if their is a roadmap for repository design/functionality. I'm thinking something along the lines of Debian's repository structure and standards. I've been working with Maven since 2005 usually in Off-Line environments, where Companies question using it because it is open source so where do they purchase support and how secure is it. Overview of Suggested Changes 1) sha256 Checksum - Start using sha256 as the default checksum, as md5 can be forged given enough cpu power. 2) Include Checksum & Signature of Artifacts in Published POM's - Currently each published file is independently verified by checksum and signature. This means pom's and artifacts can be changed without anything be detected. When a pom is published the details of artifacts being published are injected into the released pom. 3) Repository Hierarchy - Merge snapshot and release repos and split central into sub directories - Strict publishing requirements for new core release repo - Relaxed publishing requirements for open repo(s) - Point pom to single repo and define what you are willing to accept - repo/core/release states to clients, only accept valid checksum and signatures - repo/open/release states to client, warn if checksum are missing or invalid and continue if you accept that risk e.g. repo defined in pom http://repo.maven.org/repo/ repo/ -> core/ -> snapshot/ -> release/ -> main -> snapshot/ -> release/ -> open -> snapshot/ -> release/ -> 3rdparty -> snapshot/ -> release/ 4) Core Publishing Requirements - Everything must be Signed - Everything mush have valid Checksum - Everything must publish JavaDoc (if appropriate, e.g. for jar/war/ear packaged artifact) - Everything must publish Source (if appropriate, e.g. for jar/war/ear packaged artifact) - Everything mush have Open Source License - Group ID must match project url, - Everything for only core functionality e.g. "mvn clean install deploy site" using any "org.apache.maven.plugins". 5) Main Publishing Requirements - Same requirements as (4) Core but ignoring the core functionality comment 6) Open Publishing Requirements - Everything accepted and also treated as untrusted. 7) 3rdparty Publishing Requirements - Probably wrong name, contains pom that are signed and checksum themself and refer to artifacts that can't be published to maven due to export/license restrictions. - Example is Oracle JDBC, or WebLogic jars. Lost of enterprise projects use these and everything includes them in different ways. A pom is defined which includes the checksum of the artifact, so when people talk about ojdbc 14, every know it is com.oracle.java.database.drivers:ojdbc:1.4:jar. 8) DNSSEC Integration - I realise dns sec is still being rolled out but getting maven trusting it might lead to more trust towards maven from the corporate world. I would really appreciate feedback regarding these suggestion. John --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
