[75134] trunk/dports/net/mtr/Portfile

Jeremy Lavergne jeremy at lavergne.gotdns.org
Sun Jan 16 11:58:12 PST 2011

I misunderstood then.

Yea, we could include it but we don't have to. Just as long as we have at least two, regardless of which two.

"Blair Zajac" <blair at orcaware.com> wrote:

>I'm not sure what you're saying.  Let me restate myself, if the
>upstream only provides an md5, then we should at least include that
>one, plus a sha1 or rmd160.
>On Jan 16, 2011, at 10:40 AM, Jeremy Lavergne wrote:
>> That doesn't make much sense.
>> Why would we restrict ourselves below the preferred 2 hashes?
>> "Blair Zajac" <blair at orcaware.com> wrote:
>>> On 1/16/11 3:10 AM, Ryan Schmidt wrote:
>>>> On Jan 16, 2011, at 00:59, Joshua Root wrote:
>>>> [in response to a commit by snc]
>>>>> You've committed a lot of updates lately where the submitter's
>>>>> contained an rmd160 checksum but you removed it. Is there a good
>>> reason
>>>>> for this?
>>>> I've committed lots of updates lately where I use only the sha1 and
>>> rmd160 checksums, omitting the md5 checksum. As we've discussed
>>> there is good reason to use more than just a single checksum
>>> (security against a vulnerability being discovered in any one
>>> algorithm), but I see no point to using more than two checksum
>>> algorithms. And I picked the two newest algorithms, since for many
>>> other applications md5 is already considered obsolete. I suggest
>>> is what we should do going forward. Perhaps we could change the
>>> -d checksum" output to no longer suggest the md5 checksums. As we
>>> update ports, we should remove md5 checksums, preferring the
>>> sha1/rmd160 pair. And perhaps a couple years down the road we can
>>> remove md5 support from MacPorts entirely.
>>> However, if the upstream source only provides an md5 checksum, then
>>> should 
>>> use that checksum.
>>> Blair
>>> _______________________________________________
>>> macports-dev mailing list
>>> macports-dev at lists.macosforge.org
>>> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

More information about the macports-dev mailing list