On Tue, Apr 8, 2008 at 6:20 PM, Archie Cobbs <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 8, 2008 at 2:16 AM, Xavier Hanin <[EMAIL PROTECTED]>
> wrote:
>
> > I really like it! It's simple to understand, powerful enough yet under
> > control. One thing that would be nice to ensure a good deal of security
> > would be to allow only relative paths in the file related operations.
> This
> > would ensure that the module builder has only access to a very limited
> > part
> > of the filesystem.
> >
>
> Yes I thought of that as well but was not sure I could squash every
> possible
> case. For example, I thought of disallowing leading slashes, but that
> doesn't work, because I could use a property to subvert this by saying:
>
> <property name="hack" value="/boot"/>
> ...
> <move file="foobar" to="${hack}/vmlinux"/>
>
> On the other hand, we could just get rid of <property> support... though
> that would make maintaining the builder.xml files more tedious. For
> example,
> one thing I like about the current system is that the builder.xml files
> for
> different revisions of a module can be identical (except for SHA1), thanks
> to the use of ${ivy.builder.revision}, etc.
>
> There are other possible problems with the children tags of <move>,
> <copy>,
> etc. such as the use of resource collections... ?
>
> In other words I'm definitely willing to try to tighten up the security
> aspects but we need to think carefully through all of the possible cases
> or
> else it won't be worth the trouble (can't float a boat having only 95% of
> the leaks fixed).
Yes, maybe this should be kept for later, because it's not easy to achieve.
One way to do it would be to use our own ant tasks instead of standard
tasks, those tasks extending the standard one and checking that everything
is done in sandbox only. But then we'd have to use custom tasks in Ant,
which require one more step in install...
> Another possible direction to take would be cryptographic signatures on
> the
> builder.xml files, similar to how digitally signed RPMs work. Maybe longer
> term, as this is more of a maintenance pain and places a burden on the
> user
> to find, evaluate, and import trusted keys.
Indeed.
>
>
> I also like the fact that you make sha1 mandatory on the resource element.
> > The drawback is that it means that we won't be able to download
> something
> > which has no available sha1.
> >
>
> Not a problem... the person who creates the builder.xml file can be
> responsible for computing the checksum manually if necessary.
You're absolutely right!
>
>
>
> > One thing which really needs to be done IMHO is the maven import
> > operation.
> > Many artifacts are available on maven repository, so I think good
> support
> > for importing artifacts from maven would be great. If we provide the
> org,
> > name and revision values to the build file or the xslt, something as
> > simple
> > as <m2resource qualifiers="default,source,javadoc" /> could be enough
> when
> > we use the same org/name as maven groupId/artifactId. In other cases it
> > could be <m2resource groupId="com.acme.foo" artifactId="foo-bar"
> > qualifiers="default,source,javadoc" />. Maybe we should put qualifiers
> as
> > subtags to allow defining expected sha1 for each artifact. This would be
> > converted in a download + checksum check + move to artifacts directory
> > operation. What do you think?
> >
>
> I agree completely and this should be very easy to do... unfortunately I
> have zero knowledge of maven. I do have lots of knowledge of XSLT though
> so
> if someone could walk me through what steps need to be done for a
> <m2resource> tag then I'll be happy to write it up in the XSLT.
If it's only to download artifacts, it's very easy. All you need is to
download the artifacts using a pattern like this:
[organisation]/[module]/[revision]/[artifact]-[revision](-[classifier]).[ext]
The classifier needs to be provided in the m2resource tag, except for the
main artifact, which has no classifier.
For instance here are the files available for Ivy itself on maven repo:
http://repo1.maven.org/maven2/org/apache/ivy/ivy/2.0.0-beta2/
As you can see there's the default artifact (the jar), an artifact for
'sources' classifier, and one for 'javadoc' classifier. Maybe we should also
be able to specify the ext for each artifact, and also the file path to use
once downloaded (relative to artifacts dir). Maybe something like:
<m2resource groupId="org.apache.ivy" artifactId="ivy" version="2.0.0-beta2">
<artifact ext="jar" tofile="jars/ivy.jar"
sha1="43188890f8eb2a105665d62c4bda4b24703568ee" />
<artifact qualifier="sources" ext="jar" tofile="sources/ivy.zip"
sha1="6ab99abd8a02a961a5054b0359b9ae75f2ae2972" />
<artifact qualifier="javadoc" ext="jar" tofile="javadocs/javadoc.zip"
sha1="6b3cf2877a1c79adb181fa218b99f3b20ceabbe5" />
</m2resource>
Not sure of the exact syntax, but you get the idea.
Xavier
>
> Thanks,
> -Archie
>
> --
> Archie L. Cobbs
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
