GNU bug report logs - #50814
[PATCH] guix: git-authenticate: Also authenticate the channel intro commit.

Previous Next

Full log

View this message in rfc822 format

From: Attila Lendvai <attila <at> lendvai.name>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 50814 <at> debbugs.gnu.org
Subject: [bug#50814] [PATCH] guix: git-authenticate: Also authenticate the channel intro commit.
Date: Sun, 17 Oct 2021 10:09:24 +0000

> i'll investigate again later by running the test without the fix, and write
> up my results here, or better yet, in a better commit message.

i ran the test without my fix, and indeed it fails at two points:

1)

;; Should fail because it is signed with key2, not key1
(check-from "commit 3" #:should-fail? #true)

2)

;; It is not very intuitive why commit 1 and 2 should be trusted
;; at this point: commit 4 has previously been used as a channel
;; intro, thus it got marked as trusted in the ~/.cache/.
;; Because commit 1 and 2 are among its parents, it should also
;; be trusted at this point because of the cache.  Note that
;; it's debatable whether this semantics is a good idea, but
;; this is how git-authenticate is and has been implemented for
;; a while (modulo failing to update the cache in the past when
;; taking certain code paths).
(check-from "commit 1")
(check-from "commit 2")

note that i have extended the above comments compared to what's in the
commits that i have sent previously (and i also fixed the check for
the warning). i suspect there are still things to discuss, so i'll
wait for any feedback before i resend the patches. i did not touch the
test code itself, so you can easily find these points in it.


> Yes please.  In general, please start by reporting the bug: what you
> get, what you expected, and how to reproduce.  That makes it easier
> to understand and evaluate proposed fixes.


understood. the problem is that it all started out as adding a
warning, and the rest were just side-quests... :)


> Alright.  Please next time open one issue per topic: that’s a good
> way to maximize the chances that review happens in a timely fashion.
> :-)


can i mark dependencies between issues/patchsets?

because all that i could do here is split this into two sets of
commits (because of the dependencies between the commits):

1) the 3 test commits, and
2) the 2 guix commits.

i thought that separating the test that is exhibiting the bug, from
the fix that fixes it, would only hinder the process.


> I understand the behavior was surprising to you, but I’d like to see
> if we can pinpoint why.  Can you think of anything that could be
> added to the documentation?


if we assume that everyone reads and internalizes every page of the
documentation of every software that they use, then i guess nothing
needs to be added.

but if our goal is to maximize the effectiveness of the users, then no
amount of static, free-flowing text can compete with a warning that is
signalled in close context to the issue.

i think the right question to ask here is how often would this warning
be superfluous. my assumption is that very rarely, if ever, but i may
not be aware of some use-cases.

looking forward to any feedback on how to improve this.

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
If the source of fear is the unknown, and fear is the only way to be controlled, then knowledge is the only way to be free.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.