Ok, so let's track our preparations for the manifest-hash switch. Not sure about specific dates yet. I think we want to do: manifest-hashes = SHA512 BLAKE2B for the migration period, then; manifest-hashes = BLAKE2B BLAKE2 is supported by Portage since March. However, only recently I've added pyblake2 fallback for py<3.6 and package (I've focused on SHA3 previously). Few notes: 1. I'd rather not remove existing hashes before adding BLAKE2B -- rather do both and once, and require devs to use both so that we avoid two-step updates. 2. I think it should be enough to have BLAKE2B for developers -- for users, Portage should ignore the new hash if it doesn't support it and use SHA512 (TODO: verify this). 3. Sometime later, we need to either update required hash const in Portage or finally kill it. AFAIR it only affects Manifest generation, so shouldn't harm users. 4. Then, when we can reliably assume that all our users have working BLAKE2B (1 year from stabilizing relevant Portage version on first arch?) we should remove SHA512.
(In reply to Michał Górny from comment #0) > Ok, so let's track our preparations for the manifest-hash switch. Not sure > about specific dates yet. > > > I think we want to do: > > manifest-hashes = SHA512 BLAKE2B This is fine if the goal is to keep two hashes in Manifest files. > for the migration period, then; > > manifest-hashes = BLAKE2B If we go for one hash only, then why not simply SHA512? It seems that would require the least changes, and it could be deployed immediately. Also SHA512 is still supported more widely. (Also note that for signing the top-level metamanifest, it has to be hashed by one of gnupg's internal hashes. Currently gnupg supports sha512 but not blake2, so when using blake2 in the tree we would have to rely on _both_ hashes being secure.)
The Council has decided that there's nothing more to be really tracked by the Council here. The switch has succeeded, and the hash replacement is tracked in the other bug.
