bug#58561: Source hash mismatch with aggregator + possible guix bug with hashes.

[Tobias Geerinckx-Rice via Bug reports for GNU Guix <bug-guix@gnu.org>]

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

Hi Brendan,

Oh!  This is a fun one!

Brendan Tildesley 写道：
> However what concerned me more is that when I look in the source 
> code
> it looks like this:
>
> (sha256
>         (base32 
> "9yy5c29zxpli4cddknmdvjkgii3j7pvw6lhwqfrqjc8jh83gm8f8"))
>
>
> Notice how at the start its a '9', not a '1'?
[…]
> Is there a bug with how guix is reading/writing sha256 hashes?

It's… not a bug.  It's the opposite, kind of, although maybe 
(probably) Guix could (should) reject clearly bogus input like 
this.

What's happening is this:

In what can be described only as a bizarre coincidence, sha256 
produces hashes that are 256 bits long.

Base32¹ encodes 5 bits per character.  Our ‘hash’ strings are 
currently 52 characters long, meaning they encode 260 bits.

If you poke around Guix, you'll notice that every valid base32 
‘sha256’ hash starts with a 0 or a 1, because those 4 leftmost 
bits are never used, and hence set to zero.

In the case of this "9…" ‘hash’ (which was random data, I guess?), 
Guix still reads only 256 bits of the 260, and ignores those 4 
‘extra’ leftmost bits.

When it later prints the hash, it converts those 256 bits back to 
base32, now padded with zeroes, and you see a ‘hash’ starting with 
1.

What Guix could do is refuse to continue when it detects set 
higher bits, as they always indicate programmer error.

Kind regards,

T G-R

1: Guix uses ‘nix-base32’ which uses a slightly different alphabet 
from the more common base32 variant, but is otherwise identical in 
operation.

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