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