On 18/02/2011, at 2:56 AM, John Patrick wrote: > 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.
We don't really use checksums for security purposes, so this hasn't been a concern. That said, I remember someone asking about this not too long ago - it should be easy to use instead / as well if it's of value (performance is the main issue - for calculation and for the extra HTTP request if not there). > > 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. https://cwiki.apache.org/confluence/display/MAVENOLD/Repository+Security ? I did some work but didn't get much traction and ran out of steam. Still interested in picking it back up. > > 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/ Not quite sure what you're getting at here. I don't think "open" repositories as you've defined are a good idea - even permissive acceptance should do decent signature / checksum / metadata before being used. Are you referring to this structure for any repository, or specifically for central? I think there might be other ways to approach the problem you are trying to solve. > > 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". > I think each org. will have their own rules about javadoc/source/open source license. The other rules seem appropriate anywhere and are being checked now for central. Again, not quite sure what you are targetting. > 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. Not really sure how you see that applying? - Brett -- Brett Porter [email protected] http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
