www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <steve.lough...@gmail.com>
Subject Re: Maven repository policies
Date Tue, 26 Jul 2005 13:53:50 GMT
On 7/26/05, Brett Porter <brett.porter@gmail.com> wrote:
> On 7/25/05, Steve Loughran <steve.loughran@gmail.com> wrote:
> > +1
> >
> > if there is one problem here, it is finding stuff if you dont know its
> > origin. For example, if I am browsing for commons-lang, should i have
> > to know it is a jakarta-commons project?
> I'm not sure where you started from here? Someone that has a
> commons-lang JAR file from somewhere else might have this problem.
> Someone with a project with that dependency can see where it came
> from, as can someone finding commons-lang through Jakarta (hopefully).

its more a matter of knowing the full path to a project as part of the
browse-for-a-version preamble. I like the idea of a search form

> > > 6) all files in the /dist/ repository must have a .asc signature. We
> > > will need to get this automated by the final release of Maven 2.
> >
> > yes, we have a big security issue here waiting to be found and abused.
> It's not quite that bad - for ASF artifacts it would still rely on the
> ASF box getting compromised. Though where pretty good at doing that
> ourselves (refer to commons-cli). Lots of tools needed in this area.

xerces is the juicy target. subvert that, insert a new PI in and then
every SOAP or REST endpoint that takes XML is owned by the backdoor:

<? owned exec="rm -rf /" ?>

If I had admin rights to the project, i'd just hide the attack in the
source of a 100+KB commit, so have the email skipped, a binary attack
downstream is less ubiquitous, but potentially easier. What is worse,
any attack will destroy trust in the repository system. (a source
attack would damage apache as a whole, if it wasnt caught fast)

> > 7. All distributable files must have a .pom, even if it is a minimal
> > (zero dependency) one. Without this the maven tasks break.
> Not any more :)


> > Some script also needs to run through all files, get their poms and
> > verify that the dependencies can all be satisfied by the repositories,
> http://jira.codehaus.org/browse/MRM-2

yes, a graph walking tool.

> > or that somehow the artifacts are marked as non-uploadable (eg. sun
> > jars with limited distribution)
> Sun artifacts now have POMs so that they can be identified (though
> they just contain a download link).
> > I also worry about pom files with excessively tight dependencies to
> > things like xml parser implementations (e.g. jdom demands dom4j that
> > isnt found).
> Yes, though I think the metadata is improving through increased use.
> Spec. dependencies (which have been left for a bit later) will help
> with the xml/j2ee/etc dependencies.
> Nice job on the presentation, btw. - caught it on your blog.

you might also be interested to know that smartfrog-xml is the first
project using maven tasks in gump. gump is doing the fetch but
sticking to its own classpath.


View raw message