On 4/7/12 10:33 PM, Ryan Schmidt wrote:
On Apr 8, 2012, at 00:23, Blair Zajac wrote:
On 04/07/2012 10:04 PM, Ryan Schmidt wrote:
On Apr 6, 2012, at 08:33, Arno Hautala wrote:
On 2012-04-06, Clemens Lang<[email protected]> wrote:
We're documenting two hash algorithms that are "blessed". All others are
deprecated.
Is there an effort to remove the deprecated algorithms? Or a date /
version for support to be removed? Just curious.
Not yet. Personally I try to remove md5 checksums from ports as I update them.
Perhaps once most ports have had that done to them, we can consider doing a
batch md5 removal from the remaining ports and then removing md5 support from
MacPorts.
I don't know why we're so focused on removing md5 support.
Well we're not focused on it at all. I'm just saying probably eventually we
will want to remove md5 support from MacPorts, since md5 is a broken algorithm
at this point.
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.
Sure; I'll happily add to the above criteria that upstream maintainers should
have moved on to modern checksum algorithms as well before we remove md5 from
MacPorts. So that could take some time, or might never happen.
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.
I don't know what other maintainers do, but I don't verify upstream checksums.
Sorry. I don't have time to figure out how hundreds of different developers
publish them, if at all.
I do consider it a job of a maintainer to verify a checksum, if they provide it.
After all, it adds additional insurance that we're shipping the correct bits
and there wasn't a mistake made when the maintainer downloaded the tarball.
What I normally do is copy/paste upstream's checksum into the Portfile and then
generate the remaining ones by hand or using 'port -v fetch'.
As for security, if an attacker replaces a tarball, they will replace a
checksum, so there's really no additional value provided. What we should really
be concerning oneself with is if the tarball is signed, and even there, I don't
do that.
I update a port's version, download the new distfile, compute the checksums,
verify the port builds and looks somewhat sane, and commit it. The checksums
are there to ensure anyone else who tries to install the port gets the same
distfile I got.
Again, I we should check that the MacPorts user gets the same file that upstream
intends.
Blair
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
