1 |
On 2021-07-25 08:27, Michał Górny wrote: |
2 |
> On Sun, 2021-07-25 at 01:12 +0200, Thomas Deutschmann wrote: |
3 |
>> I don't understand. Isn't it the same motion we put down just 2 |
4 |
>> months ago [1]? Or is this something new? |
5 |
>> |
6 |
>> If this isn't something new, what has changed since May [2]? |
7 |
> |
8 |
> Apparently it has not been 'put down' because it came back via open |
9 |
> bugs. |
10 |
|
11 |
Open bugs? Could you please link them here? |
12 |
|
13 |
|
14 |
>> To remember: Currently we have two different hashes for every |
15 |
>> distfile. If we are going to throw this data away, we should really |
16 |
>> have good reasons to do that. Like said during that council |
17 |
>> meeting, BLAKE2B and SHA512 are competing hashes. What's wrong with |
18 |
>> having a backup plan even for a very unlikely scenario, that |
19 |
>> BLAKE2B will get broken? |
20 |
> |
21 |
> Define 'broken'. |
22 |
|
23 |
To quote from chapter 9 of the Handbook of Applied Cryptography, by |
24 |
Menezes, van Oorschot and Vanstone: |
25 |
|
26 |
> If, for a given hash function, an attack is found, which, by |
27 |
> exploiting special details of how the hash function operates, finds a |
28 |
> preimage, a second preimage or a collision faster than the |
29 |
> corresponding generic attack, then the hash function is said to be |
30 |
> "broken". |
31 |
|
32 |
This happened publicly for SHA1 in 2017. |
33 |
|
34 |
|
35 |
>> Remember that verify-sig.eclass I criticized last year? Of course |
36 |
>> some scenarios I outlined were very unlikely and I never expected |
37 |
>> that I can run around in near future saying "I told you". But in |
38 |
>> January 2021, CVE-2021-3345 happened in libgcrypt... |
39 |
> |
40 |
> I don't see how this is relevant either. Are you admitting that |
41 |
> you're criticizing all my ideas because I just happen to propose |
42 |
> them? |
43 |
|
44 |
No, I am not criticizing ideas because *you* proposed them. I share my |
45 |
criticism when I have some concerns or believe the proposal has some |
46 |
flaws. You maybe have that impression because you are very active and |
47 |
most proposals are coming from you. In the end, we both are hopefully |
48 |
sharing the same goal to make Gentoo better... |
49 |
|
50 |
|
51 |
-- |
52 |
Regards, |
53 |
Thomas Deutschmann / Gentoo Linux Developer |
54 |
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 |