[bug#41767] [PATCH 4/9] channels: 'latest-channel-instance' authenticates Git checkouts.

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> 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] https://git-scm.com/docs/hash-function-transition/
>
> On the Fediverse, someone pointed out that Bitcoin Core developers
> compute a SHA512 hash of Git trees to mitigate it:
>
>   https://github.com/bitcoin/bitcoin/tree/master/contrib/verify-commits
>
> What they do is add a “Tree-SHA512:” line to commit logs and check
> those in ‘verify-commits.py’:
>
> # 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
> <https://git-scm.com/docs/hash-function-transition/> 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,

Maxim