[bug#41382] [PATCH 0/6] Allow for a cryptographic hash function migration

[Ludovic Courtès]

Hi!

Marius Bakke <address@hidden> skribis:

[...]

>> and to automatically “convert” the ‘sha256’ field specification to a
>> ‘content-hash’.  Due to the way identifiers are matched, there are cases
>> where we can’t preserve the illusion of compatibility, as can be seen
>> with the patch below.  Perhaps that’s acceptable, though.
>>
>> Thoughts?
>
> This is a great initiative, and the patches LGTM.

Great, thanks for taking a look.

> I think that if we are to move away from SHA256, we should go with
> something that is immune to length extension attacks[0] such as BLAKE2/3
> or SHA-3 (Keccak).

That makes sense to me.

I think we have time to think about it.  When we choose to switch, we
should change all the tools (importers, ‘guix download’, etc.) and
documentation to default to the new hash so migration can happen
consistently.

> Although I don't know any Guile implementations of those as of yet.

Libgcrypt supports them, so we can definitely use them.  I realize we
also need to extend nix/libutil/hash.{cc,hh}.

> SHA512 does not improve much security-wise IMO, but maybe it's
> worthwhile as s stop-gap.

Yeah, I’m not sure.  We should definitely keep an eye on what others are
doing and what crypto folks recommend.

Ludo’.