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