Re: [gentoo-dev] proposal: use only one hash function in manifest files

[Michał Górny]

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