[Top][All Lists]

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

[bug#41767] [PATCH 4/9] channels: 'latest-channel-instance' authenticate

From: Maxim Cournoyer
Subject: [bug#41767] [PATCH 4/9] channels: 'latest-channel-instance' authenticates Git checkouts.
Date: Thu, 11 Jun 2020 09:15:07 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Hi Ludovic,

Ludovic Courtès <> writes:

> Hi Maxim,
> Maxim Cournoyer <> skribis:
>>> +(define %guix-channel-introduction
>>> +  ;; Introduction of the official 'guix channel.  The chosen commit is the
>>> +  ;; first one that introduces '.guix-authorizations' on the 'core-updates'
>>> +  ;; branch that was eventually merged in 'master'.  Any branch starting
>>> +  ;; before that commit cannot be merged or it will be rejected by 'guix 
>>> pull'
>>> +  ;; & co.
>>> +  (make-channel-introduction
>>> +   "87a40d7203a813921b3ef0805c2b46c0026d6c31"
>>> +   (base16-string->bytevector
>>> +    (string-downcase
>>> +     (string-filter char-set:hex-digit            ;mbakke
>>> +                    "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA")))
>>> +   #f))                   ;TODO: Add an intro signature so it can be 
>>> exported.
>> The GnuPG key fingerprint is SHA1 derived, which isn't cryptographically
>> secure.  This doesn't mean fingerprints are unsafe *now* (given that
>> forging a key to match it isn't currently practical),
> Fingerprints are used as an index in the keyring here.  If somebody
> introduced a second OpenPGP key with the same fingerprint in the keyring
> and we picked the wrong one when verifying a signature, signature
> verification would just fail.  So I think it’s perfectly OK here.

Agreed; thanks for pointing that out.  I don't see a problem with our
use of OpenPGP either then :-).


> The “SHA-1 is a Shambles” paper reads:
>   The GIT developers have been working on replacing SHA-1 for a
>   while[16], and they use a collision detection library [SS17] to
>   mitigate the risks of collision attacks.
>   [16]
> On the Fediverse, someone pointed out that Bitcoin Core developers
> compute a SHA512 hash of Git trees to mitigate it:
> What they do is add a “Tree-SHA512:” line to commit logs and check
> those in ‘’:
> # Check the Tree-SHA512
> if (verify_tree or prev_commit == "") and current_commit not in 
> incorrect_sha512_allowed:
>     tree_hash = tree_sha512sum(current_commit)
>     if ("Tree-SHA512: {}".format(tree_hash)) not in 
> subprocess.check_output([GIT, 'show', '-s', '--format=format:%B', 
> current_commit]).decode('utf8').splitlines():
>         print("Tree-SHA512 did not match for commit " + current_commit, 
> file=sys.stderr)
>         sys.exit(1)
> We could do something similar, maybe optionally, but verification would
> be expensive (you need to traverse all the blobs of the whole tree for
> each commit being authenticated).
> At this point, I’d wait for Git’s SHA256 migration to happen, though
> <> doesn’t specify an
> ETA.

Thanks for pointing that interesting workaround!  I agree that given
Git's plans to migrate to SHA256, it seems reasonable to wait for them
to upgrade and spend our energy somewhere else.

Your changes LGTM.

Thank you,


reply via email to

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