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?

Thanks,
Ludo’.