On Thursday, 17 February 2011, Siegmann Daniel, NY <[email protected]> wrote: > 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] > >
Daniel, that is the kind of setup I use. But normally the development network is not physically connected to the internet. But you also must agree that the central repository has become a bloated dumping group. I use to rsync it to my local network and remember it being 16GB, it is now >175GB last time I checked. Surely a more formal structure that give trust into what you are using is useful to everyone. People trust Linux software because it is signed and distributed with the source. Maybe using a similar method would help with greater adoption by Linux distributions. Also I could have acces to a 1GB unlimited bandwidth server in London but with max 30GB local diskspace. So I could offer fast mirror access to the core/releases, main/releases but not the whole central as it is currently structured. The hosting provider would also want confirmation that it was open source licenses being distributed so no potential copyright Law suite might follow. John --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
