> 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
