Message ID | 87sgf2araw.fsf@gnu.org |
---|---|
State | Accepted |
Headers | show |
Series | None | expand |
Context | Check | Description |
---|---|---|
cbaines/applying patch | fail | View Laminar job |
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
diff --git a/guix/channels.scm b/guix/channels.scm index c2ea0e26ff..036c8d9b5d 100644 --- a/guix/channels.scm +++ b/guix/channels.scm @@ -369,10 +369,9 @@ commits ~a to ~a (~h new commits)...~%") #:keyring keyring #:report-progress report))) - (unless (null? commits) - (cache-authenticated-commit cache-key - (oid->string - (commit-id end-commit)))))))) + (cache-authenticated-commit cache-key + (oid->string + (commit-id end-commit))))))) (define* (latest-channel-instance store channel #:key (patches %patches) @@ -392,7 +391,8 @@ relation to STARTING-COMMIT when provided." ;; TODO: Warn for all the channels once the authentication interface ;; is public. (when (guix-channel? channel) - (warning (G_ "the code of channel '~a' cannot be authenticated~%") + (warning (G_ "channel '~a' lacks an introduction and \ +cannot be authenticated~%") (channel-name channel)))) (when (guix-channel? channel)