I'm only suggesting this "build your own artifacts from source code" idea because of your comments in the original email...
I have personally submitted a few items to the repo, none of which I am actually an "official" developer for. If the official developers for these various projects were engaged with Maven, then there would be a lower chance of "bad code" getting into a Maven artifact, but alas, many projects are happy using Ant etc or simply have no interest in fully Maven-izing their build process. While I'm sure Carlos et al do their best to keep bad code out of the repo, unless they have some seriously advanced Jar-checker, its simply not possible for them to "guarantee" the compiled code in a given user-submitted Maven artifact is "clean" and contains only the bits delivered by the source code of original project. From what I can gather, there really is no "validation part" as you mentioned. The only way we could get real "validation" working would be if the entire nature of Maven was changed -- instead of storing binaries of artifacts in repos, we would only store the POMs themselves, and all artifacts would need to exist in published (and publicly accessible) read-only source code repos. When you wanted to build a project for the first time, the poms for all dependencies would be downloaded, then the source code location (cvs, svn, etc) would be extracted from the pom and the artifact's source code itself would be retrieved, compiled, installed, and finally the project itself would be built. This would "guarantee" that the source code in your local jar is identical to that which the project has written/delivered. But I don't see this happening any time soon. Wayne On 7/20/06, Wayne Fay <[EMAIL PROTECTED]> wrote:
If you can't trust external jars, then perhaps you should just start pulling the source for every project/artifact you use and make your own internal "from source" jar library/Maven artifact repo. It will probably be difficult to keep track of versions etc, but you could trust all the code as you would have all the source yourself. You could keep all the <dependencies> in your poms but you wouldn't use any Maven proxy etc, as all the code would remain internal. In fact, you would want to disable all the ibiblio repos to ensure no "tainted" outside code ever got into your organization. Then you would need to develop a process to examine the thousands of source code lines for every project you are using to look for possible backdoors etc, check it again any time the project has a new version, etc. Sounds exhausting. Personally, I'll trust the jars until I run into a problem. Wayne On 7/20/06, Mykel Alvis <[EMAIL PROTECTED]> wrote: > If your concern is that you don't want to have m2 work the "standard way", > and by that I mean connected to the net to download whatever dependency you > need on demand, then I think the answer to that is yes. > > One thing you COULD do is have a sandbox user's repo that is done by > connecting to the net, do the install online and connected to the public > repositories, thereby building up the respository for the sandbox user, and > then hand-checking the checksums for the artifacts in the sandbox user's > local repo and sticking those elements into the company's internal > repository for use by everyone using deploy:deploy-file. > > On 7/20/06, EJ Ciramella <[EMAIL PROTECTED]> wrote: > > > > What stinks about this solution is maven upgrades. > > > > All of a sudden, we'll be installing a bazillion jars/poms. Right? > > > > -----Original Message----- > > From: Tamás Cservenák [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, July 19, 2006 9:45 PM > > To: Maven Users List > > Subject: Re: Maven 2 - more questions > > > > Hi EJ, > > > > i would like to provide a half of answer for question number 2. > > > > As i wrote that before, Proximity is able to work offline. If your IT > > is too paranoid to let Proximity fetch what is requested from it (and > > not found in the cache or found but expired), then i would suggest you > > to run Proximity OFFLINE, and create some corporate mechanism to > > request the new needed resources. > > > > On every resource (artifact) request, someone would get it, check it, > > and deploy it into "inhouse" (or central, non-cached ) repository > > under proximity. > > > > ---- > > > > I ensure you, that M2 makes proper (but not mandatory, although it's > > configurable) checksum validation, Proximity itself is NOT INVOLVED in > > this validation, it ONLY SERVES the artifact AND the checksum file > > using the SAME MECHANISMS. > > > > The actual remote fetch occures only in: > > > > http://proximity.abstracthorizon.org/px-core/xref/hu/ismicro/commons/proximity/base/remote/HttpClientRemotePeer.html > > and as you can see, the px-core (the Proximity Core) is not even Maven > > aware! You can think about Proximity as a simple HTTP proxy. > > > > The Maven "awareness" is given by these classes (px-core-maven, the > > maven bindings): > > http://proximity.abstracthorizon.org/px-core-maven/xref/index.html > > and those are merely involved in artifact/file "recognition", > > possibility for their separate expiration (logic) and indexing. > > > > Since indexing is NOT USED in core functionality of Proximity (it is > > just an "extra" service offered on search page), the leftover is > > "mostly harmless" :) > > > > ~t~ > > > > On 7/19/06, EJ Ciramella <[EMAIL PROTECTED]> wrote: > > > As we edge closer to moving more people onto maven 2 here, there are a > > > few questions that keep popping up, can anyone help with these? > > > > > > 1 - How are items submitted to repo1? I've read the article here > > > (http://maven.apache.org/guides/mini/guide-ibiblio-upload.html), but I > > > don't see a validation part. What the powers that be are afraid of is > > > someone putting in some junk or malicious code into one of the > > > dependency jars. > > > > > > 2 - Is there a https mirror for maven 2 repositories? We'd LIKE to use > > > proximity as a proxy, but because of the ever growing threat of man in > > > the middle attacks, having anything just automatically go out to the web > > > is dangerous in their eyes. > > > > > > If there are no answers, could someone point me directly to the code > > > involved? I need to see how the checksums are getting validated. > > > > > > Thanks in advance! > > > > > > > > > > --------------------------------------------------------------------- > > 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] > > > > > > > -- > > Never wear anything that panics the cat. -- P. J. O'Rourke > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
