1 |
On Mon, Feb 1, 2010 at 1:23 AM, Doug Goldstein <cardoe@g.o> wrote: |
2 |
> However, great work on this GLEP, you've put forth some good solid |
3 |
> research into it. |
4 |
|
5 |
Agreed. I would suggest to use this series of GLEPs as examples of |
6 |
what to do for future GLEP writers. |
7 |
|
8 |
> I do hope that we don't intend on settling on SHA512 as the end all |
9 |
> solution as well. We should retain a method for bumping the hashing |
10 |
> algorithm used when the SHA-3 family becomes available. |
11 |
|
12 |
From the way I understand it the GLEP implies that we can add hashes |
13 |
at will. But that's a good point, and a one-liner somewhere making it |
14 |
explicit would be useful. Thus, in "What should be done" I would I |
15 |
would for example replace |
16 |
"We should be prepared to add stronger checksums wherever possible, |
17 |
and to remove those that have been defeated." |
18 |
with: |
19 |
"Stronger checksums shall be added as soon as an implementation is |
20 |
available in Portage. Weak checksums may be removed as long as the |
21 |
depreciation process is followed (see below)." |
22 |
|
23 |
And then, in "Checksum depreciation timing" I would prefer that the |
24 |
description of what needs to be done in the present situation was used |
25 |
as an example after a more general rule is stated. Something like: |
26 |
"At least one older algorithm must remain until the new one(s) has |
27 |
(have) been in stable Portage for minimum one year." |
28 |
The one year period is debatable, what matters is we have well defined |
29 |
rules in order to avoid future flamewars. |
30 |
|
31 |
Denis. |