bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Tobias Geerinckx-Rice
Subject: bug#58561: Source hash mismatch with aggregator + possible guix bug with hashes.
Date: Sun, 16 Oct 2022 11:45:00 +0200

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: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]