> 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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
