sha1 and rmd160

[Jeremy Lavergne]

> I don't know why we're so focused on removing md5 support.

We're not officially about removing md5, unless it's used alone. We're really about ensuring more than one hash is used.

> I was thinking why I'm resistant to removing md5 support and it comes down to make it easier for somebody to verify that the port is correct, given that many sites only list a md5 checksum and not a better one.
> 
> As much as we're concerned about a bad actor messing with a tarball, the bad actor could be a MacPorts committer.  So comparing the md5 in the port with the md5 from upstream is much easier than downloading upstream's tarball, comparing the upstream's md5 with the computed md5, then generating a sha256 or rmd160 from it and comparing that with the portfile.
> 
> Maybe the underlying issue for me is a way for MacPorts users to verify that the portfile's checksums with the upstream's checksum.

This is still doable---a user can add in the md5 checksum to the Portfile at anytime. If it's considered too much effort to allow the user verify that checksum X from upstream is part of the checksums explicitly defined in the Portfile then we could certainly add _all_ checksums to the Portfile.

Nowadays though, I'd argue it's a matter of what's needed to get the pre-built archives installed. The occasional local build is set to become less and less an occurrence.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 8796 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20120408/46e1663e/attachment.bin>