On Sun, 2021-07-25 at 01:12 +0200, Thomas Deutschmann wrote: > 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]?
Apparently it has not been 'put down' because it came back via open bugs. > 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? Define '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. ...which is entirely irrelevant given that both hashes need to be calculated. (SHA512 + BLAKE2B) can be as fast as the slower of two in the best scenario. > In addition it is even more likely that you will find SHA checksum files > with upstream release tarballs than BLAKE2B files. Again, I don't see how that's even remotely relevant. > 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... I don't see how this is relevant either. Are you admitting that you're criticizing all my ideas because I just happen to propose them? -- Best regards, Michał Górny
