On Tue, 2022-04-05 at 01:41 +0200, Jason A. Donenfeld wrote: > Hi, > > I'd like to propose the following for portage: > > - Only support one "secure" hash function (such as sha2, sha3, blake2, etc) > - Only generate and parse one hash function in Manifest files > - Remove support for multiple hash functions > > In other words, what are we actually getting by having _both_ SHA2-512 > and BLAKE2b for every file in every Manifest? It's not about file > integrity, since certainly a single hash handles that use case fine. > And it's not about security either, since for that we use gpg > signatures, and gpg signatures are carried out over a _single_ hash of > the plain text being hashed, so the security of the system reduces to > breaking SHA2-512 anyway. So, if it's not about file integrity and > it's not about security, what is it about?
If you mean "remove entirely", then that's a bad idea. While the original reasons for multiple hash functions might have been, erm, not exactly correct, the dual-hash situation is needed for transitional periods. Particularly because we have a number of fetch-restricted packages where we simply need to wait for someone with the distfile to rehash them (or eventually remove them, if we can't get a new hash). > I don't really care which one we use, so long as it's not already > broken or too obscure/new. So in other words, any one of SHA2-256, > SHA2-512, SHA3, BLAKE2b, BLAKE2s would be fine with me. Can we just > pick one and roll with it? Back when we added BLAKE2b, the idea was to eventually remove SHA512 (the previous hash). However, this was rejected afterwards. > PS: there _is_ a good reason for recording the file size in Manifest > files as we do now: it's quicker to compare sizes on large files than > it is to read and hash the whole thing, so this gives us a "free" way > of noticing quick corruption. The primary use of knowing the file size is to know whether to try to resume fetching. -- Best regards, Michał Górny
