| 1 |
On Tue, Oct 24, 2017 at 11:33:39PM +0200, Allan Wegan wrote: |
| 2 |
> >> That is currently the case with portage, but not an inevitable |
| 3 |
> >> consequence of having 3 hash functions in the Manifest. Portage could |
| 4 |
> >> be made to check only one or two of them (even by default), giving |
| 5 |
> >> the tie-breaking ability to those who need it, and speeding up things |
| 6 |
> >> for those who don't. |
| 7 |
> > No, it can't. The specification (GLEP 59) requires it to check all |
| 8 |
> > hashes. |
| 9 |
> |
| 10 |
> Of course it can: The code of the specification just has to be changed |
| 11 |
> before changing the code of portage. The question is not whether it is |
| 12 |
> possible to make portage skip hash verification - but whether it is a |
| 13 |
> good idea to make it do that... |
| 14 |
> |
| 15 |
> I would not mind as long as the default is to always check all the |
| 16 |
> hashes and the option to disable it is properly named (like |
| 17 |
> "--disable-hash-verification" or something similar) and documented. |
| 18 |
At that point, and this is a serious proposal: |
| 19 |
The package manager shall decide which hashes to check, but is required |
| 20 |
to check at least one hash. The choice may be 'fastest', 'most secure', |
| 21 |
or any local factor. |
| 22 |
|
| 23 |
For local values of 'most secure' or 'fastest'. |
| 24 |
|
| 25 |
I wrote GLEP59, and specified at the time that all hashes should be |
| 26 |
checked, based on prior experience with hash implementation problems. |
| 27 |
|
| 28 |
Skipping them entirely is a bad idea, but only checking one of them is a |
| 29 |
reasonable suggestion. |
| 30 |
|
| 31 |
I retract my prior suggestion that there should be 3 hashes, as I |
| 32 |
realize a key statements in GLEP59 that were NEVER implemented: |
| 33 |
>> - Removal of depreciated checksums shall happen after no less than 18 |
| 34 |
>> months or one major Portage version cycle, whichever is greater. |
| 35 |
>> ... |
| 36 |
>> After the majority of Portage installations include SHA512 support: |
| 37 |
>> - Remove SHA256. |
| 38 |
|
| 39 |
This GLEP to update the GLEP59 specification should state the following: |
| 40 |
- The package manager or verification tool is required to verify at |
| 41 |
least one hash, preferably the strongest supported hash. |
| 42 |
- Multiple hashes may be present for transitional periods. |
| 43 |
- SHA3 or BLAKE2B shall be added to the official Manifest2 hashes. |
| 44 |
|
| 45 |
For implementation: |
| 46 |
- Generation of WHIRLPOOL and SHA256 shall be disabled in the next |
| 47 |
Portage minor release (as soon as possible) |
| 48 |
- Generation of the next choice of hash, SHA3 or BLAKE2B shall be |
| 49 |
enabled in an upcoming minor Portage release (soon) |
| 50 |
- 18 months after the next GLEP is approved, SHA512 shall be dropped |
| 51 |
(put the date into the Portage code so it happens automatically this |
| 52 |
time, unlike SHA256 that should have been removed in 2010!). |
| 53 |
|
| 54 |
-- |
| 55 |
Robin Hugh Johnson |
| 56 |
Gentoo Linux: Dev, Infra Lead, Foundation Asst. Treasurer |
| 57 |
E-Mail : robbat2@g.o |
| 58 |
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 |
| 59 |
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 |
Archives