1 |
Hi Sam, |
2 |
|
3 |
On Wed, Apr 6, 2022 at 2:02 AM Sam James <sam@g.o> wrote: |
4 |
> This matches my views and recollection. We could revisit it |
5 |
> if there was a passionate advocate (which it looks like there may well be). |
6 |
> |
7 |
> While I wasn't against it before, I was sort of ambivalent given |
8 |
> we had no strong reason to, but I'm more willing now given |
9 |
> we're also cleaning out other Portage cruft at the same time. |
10 |
|
11 |
I think actually the argument I'm making this time might be subtly |
12 |
different from the motions that folks went through last year. |
13 |
Specifically, the idea last year was to switch to using BLAKE2b only. |
14 |
I think what the arguments I'm making now point to is switching to |
15 |
SHA2-512 only. |
16 |
|
17 |
There are two reasons for this. |
18 |
|
19 |
1) Security: since the GPG signatures use SHA2-512, then the whole |
20 |
system breaks if SHA2-512 breaks. If we choose BLAKE2b as our only |
21 |
hash, then if either SHA2-512 or BLAKE2b break, then the system |
22 |
breaks. But if we choose SHA2-512 as our only hash, then we only need |
23 |
to worry about SHA2-512 breaking. |
24 |
|
25 |
2) Comparability: other distros use SHA2-512, as well as various |
26 |
upstreams, which means we can compare our hashes to theirs easily. |
27 |
|
28 |
A reason why some people might prefer BLAKE2b over SHA2-512 is a |
29 |
performance improvement. However, seeing as right now we're opening |
30 |
the file, reading it, computing BLAKE2b, closing the file, opening the |
31 |
file again, reading it again, computing SHA2-512, closing the file, I |
32 |
don't think performance is actually something people care about. Seen |
33 |
differently, removing either one of them will already give us a |
34 |
performance "boost" or sorts. |
35 |
|
36 |
Jason |