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).
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.
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.
> 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.
Thanks,
-Archie
--
Archie L. Cobbs
