sha1 and rmd160

Blair Zajac blair at orcaware.com
Sat Apr 7 22:58:50 PDT 2012


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<cal at macports.org>   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


More information about the macports-dev mailing list