Hi,I don't understand. Isn't it the same motion we put down just 2 months ago [1]? Or is this something new?
If this isn't something new, what has changed since May [2]?To remember: Currently we have two different hashes for every distfile. If we are going to throw this data away, we should really have good reasons to do that. Like said during that council meeting, BLAKE2B and SHA512 are competing hashes. What's wrong with having a backup plan even for a very unlikely scenario, that BLAKE2B will get broken?
It's not like SHA512 is requiring any additional deps which are unmaintained or something like that. SHA has even hardware acceleration support in modern systems.
In addition it is even more likely that you will find SHA checksum files with upstream release tarballs than BLAKE2B files.
Remember that verify-sig.eclass I criticized last year? Of course some scenarios I outlined were very unlikely and I never expected that I can run around in near future saying "I told you". But in January 2021, CVE-2021-3345 happened in libgcrypt...
So again: Why should we throw the data we currently have away and put Gentoo unnecessarily at risk that we will end up without hashes because the only hash algorithm we used became broken and given that we will be unable to re-hash every file in a timely manner (remember how long it took to get a BLAKE2B hash for every file)?
See also: ========= [1] https://bugs.gentoo.org/784710 [2] https://projects.gentoo.org/council/meeting-logs/20210509.txt -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
OpenPGP_signature
Description: OpenPGP digital signature
