Filesize in Portfiles (was Re: [76684] trunk/dports/sysutils/rpm/Portfile)

[James Berry]

On Mar 8, 2011, at 12:29 AM, Anders F Björklund wrote:

> Jordan K. Hubbard wrote:
> 
>>> Currently, we are updating four: version (i.e. affecting the distfile), md5, sha1, rmd160. Just saying that it would be less clutter to have, say "SIZE" and "SHA256" collected in a "distinfo" file, since that's what FreeBSD Ports is using... ("make makesum") Just an observation from using both ports systems, really.
>> 
>> Kind of begs the question:  Do we need this many checksums?  md5 and sha1 are weak hashes, sure, but how about sha256?
> 
> Apparently MacPorts prefers using sha1+rmd160 over sha256, and also it was "too long" (fixed by automating, or using base-32)
> 
> The md5 is more of a left-over, though still used by many upstreams. But think it's currently being recommended against using ?


Per my recollection, sha256 is now supported in base (using base-32 encoding?). I know that one concern with use of base-32 was that if the checksum was mirroring one in upstream that the value would appear different. It would seem to be wise to try to auto-detect the format of this checksum based on length, so that ether the hex or base-32 encoding would be accepted. We would prefer base-32, but accept hex encoding as well for a case where upstream uses that format.

This ties back to the reason for continued support of legacy checksums such as md5: if that's what upstream uses to verify a dist file, then we want to also use that same checksum.

Clearly there is no need for any dist file to be tagged by more than a couple of checksums. The current usage of md5, sha1, and rmd160 is mostly because that's what port emits by default, so updating these three is a simple copy and paste. The concept behind having at least 2 checksums per file has simply been that while it might be possible to find a hash collision in one algorithm, it would seem very unlikely for one to be able to find an exploitable hash collision in two at once... :)

James