> 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.
Sadly, SHA-1 is also "doomed"...See, e.g. http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html
Assuming goal is just checksum, however, this is np. Also, SHA-1 still definitely has more runway than MD5. Quoting from Shneier,
"Jon Callas, PGP's CTO, put it best: 'It's time to walk, but not run, to the fire exits. You don't see smoke, but the fire alarms have gone off.'"
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.