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

[Attila Lendvai]

> 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.