> the smartfrog solution is brute force unforgiving: you must declare
> the SHA1 or MD5 value in a download

Right... I'm sure users wanting security will put up with a certain
level of pain. I'm still not sure how you securely publish the value
initially (though this certainly prevents later tampering).

I'd still like to think this through a little more.

> The reason for sha1 emphasis is primarily that md5 is doomed: its too
> easy to break, 2-5 years left in it before it is as trusted as DES.
> Now, when it is finally broken, .rpm is the first juicy target. But
> md5 is old; it would be good if maven2 had .sha1 everywhere right from
> the outset.

Yes, I've always stated our md5s will be nothing more than checksum
verification that your download wasn't corrupted, rather than a
security feature.

As for m2... no problem: http://jira.codehaus.org/browse/MNG-287

I'm pretty sure it's trivial to add.

> yes. a legal string of valid names would be good, better than an
> exclusion list (as there are so many characters in unicode land. For
> x-platform support, that means lowercase ascii alphanumeric plus a few
> separators for all of the different elements:
> [a-z0-9.-+_]
> The weakness here is that it doesnt address the wants/needs of the
> non-ascii world., but since we are constructing HTTP URLs from the
> strings, we need to use that subset, not just those chars that are
> valid in filenames.

Yep, I definitely agree. We have readable names in our project
descriptors which should support non-ASCII.

- Brett

Reply via email to