In addition, I also have this patch for prt-get to support the new -cs/-is options, again keeping the old -um/-im options for compatibility. (Also, slight note, I made a typo above, I meant -um/-im/-cm, not -cm/-im/-cm)

Well, to be honest, I don't get the point here. IMO md5sum's are "good enough" for our purpose and a change to
sha256 would lead to incompatible ports. So, what's the reason/advantages?

MD5 has a higher chance of hash collisions and has been defeated as a method of verifying integrity as-of last year [1], making it's usefulness for pkgutils purpose questionable. SHA256 on the other hand SHA256 currently does not have any known attacks on it, making it a superior choice for verifying integrity.

1: http://www.win.tue.nl/hashclash/SoftIntCodeSign/

So we should accept incompatible ports because of a pure theoretical chance of hash collision which has never happened in the last years? Sorry no, my vote here is a strong -1.

I proposed this exact same type of change awhile ago and got the same exact answer, "No MD5 is fine, there's only theoretical problems with it now", when producing a hash collision with MD5 is now easy. It's not rare, it's not theoretical, see the reference I presented, it's doable on desktop boxes. I didn't break ports (I never even touched ports), pkgutils or prt-get, I left all the old options in place, I left MD5 in place, this merely adds SHA256 support and changes some things to represent this. New ports will still have the old .md5sum files, as both are generated.

CRUX is supposed to be forward moving, why are you defending a defeated integrity verification scheme? If CRUX is not going to be serious about it, you might as well remove the MD5 verification method as well.

Please, I don't mean to sound like I'm attacking you here, but there is no reason to resist this change, it makes perfect sense to slowly transition away from MD5, as it is a defeated algorithm. Unless you never even looked at my patch, you should know that's exactly what I've provided here: A slow transitional route for moving to SHA256.

I've took the time to read [1] carefully. As you might have noticed as well it's _not_ possible to target a given hash value, so you can not create an infected file with the same md5sum as the original file.

<quote>Existing files with a known hash that have not been prepared in this way are not vulnerable.</quote>

We are not using the md5sum in a application where a collision-resistant hash function is required, but in a one-way function, so in our usage the md5sum is still secure. [2]

Anyway, I got the feeling that the whole md5/sha256 discussion is getting more emotional than constructive, but I'd like to go back to the later.
Basically I have nothing against using sha256 or something else instead of md5, but I don't see any need for hurry here, and I'd like to see a solution that fits best for CRUX and works at least for the next years.
WRT the implementation we should consider a hard break without backwards compatibility as well, which, of course, creates more rumor, but can be done easy and fast at least for the official repos. Seems more CRUX like to me.

Finally I correct my above vote to 0.

[2] ftp://ftp.rsasecurity.com/pub/cryptobytes/crypto2n2.pdf

You could use the same attack I mentioned to generate tarballs which would produce identical md5sums, potentially meaning a malicious open-source developer could generate two different tarballs and silently replace a clean one with a malicious one, without the md5sum changing. However, I will give you that such an event is unlikely. I'll produce a hard-break patch and submit it here later, as a hard break seems to be the preferred solution by most people.