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

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

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 1971 bytes --]

Ludovic,

(+ guix-devel)

Ludovic Courtès <ludo@gnu.org> writes:

> Hello,
>
> Ludovic Courtès <ludo@gnu.org> skribis:
>
>> Another option would be to create a <hash> data type that specifies
>> its algorithm and its value.  We’d replace the ‘sha256’ field with
>> a ‘hash’ field of that type (in a backward-compatible way).  Thinking
>> about it, this is perhaps the better option.
>
> Here’s a v2 that does that: instead of adding a ‘sha512’ field to
> <origin>, it replaces the ‘sha256’ field with ‘hash’ and introduces a
> <content-hash> data type (similar to the <uuid> data type we have).
>
> One can now write things like:
>
>   (origin
>     ;; …
>     (hash (content-hash (base64 "…") sha512)))
>
> Since it’s a bit verbose, one can also pass a literal string directly,
> in which case it’s base32-decoded:
>
>   (origin
>     ;; …
>     (hash (content-hash "…")))
>
> ‘content-hash’ uses macrology to validate as much as possible at
> macro-expansion time.
>
> There’s a compatibility ‘origin’ macro intended to allow people to keep
> writing:
>
>   (origin
>     (url …)
>     (method …)
>     (sha256 …))
>
> 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.

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).

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

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

0: https://en.wikipedia.org/wiki/Length_extension_attack

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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

[Ludovic Courtès]

Hi!

Marius Bakke <mbakke@fastmail.com> 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’.

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

[Ludovic Courtès]

Pushed the whole series:

  ce0be5675b packages: Introduce <content-hash> and use it in <origin>.
  56f7ca6e7c packages: Add 'base64' macro.
  0e4e9c8e76 guix hash, guix download: Support base64 format.
  18ae1ec3ec guix hash, guix download: Add '--hash'.
  9418aaa00d tests: Test fixed-output derivations with several hash algorithms.
  73b27eaa64 tests: Test 'add-to-store' with several hash algorithms.

You’ll have to recompile due to the ABI change:

  make clean-go && make

I realized several tests needed to be adjusted for proper syntax-case
matching, which I did in ce0be5675b.

Ludo’.