what should happen if a channel-introduction commit does not update the .guix-authorizations file?
this means that this single commit will get through the authentication (channel intro commits are always trusted), but any later commits signed with the same key will be rejected.
this is the situation that got me confused, and thrust me into attempting to fix this (trying to `guix pull` from a local git checkout of guix containing my patches).
i wrote the code for this, but i don't know what should be its UI. how should this be reported to the user?
using `(warning ...)` will just print something to stderr.
i was hoping to raise a continuable condition of type &warning, that i can even check for in the tests, but i have failed to put that together. the scheme/guile condition system is a bit messy/convoluted.
can someone help me out with a hint/outline about how to report this that best fits the rest of guix?
note that it's not really an error, because until another commit is added with the new key, this channel is valid.
(address . email@example.com)(name . Attila Lendvai)(address . firstname.lastname@example.org)
Always verify the channel introduction commit, so that no commit can slip
through that was signed with a different key.
Always update the cache, because it affects the behavior of later calls.
Signal a continuable compound-condition (with type &warning included) when a
channel introduction commit doesn't also update the '.guix-authentications'
* guix/git-authenticate.scm (authenticate-commit): Reword and extend the error
message to point to the relevant part of the manual.
(authenticate-repository): Eliminate optimizations to make the code path less
dependent on the input. Always trust the intro-commit itself. Always call
(verify-introductory-commit): Check if the commit contains the key that was
used to sign it, and issue a warning otherwise. This is to avoid the confusion
caused by only the *second* commit yielding an error, because intro-commits
are always trusted.
(authenticate-commit): Clarify error message.
(authorized-keys-at-commit): Factored out to the toplevel from
An example output with this patch:
$ ./pre-inst-env guix pull --allow-downgrades
Updating channel 'guix' from Git repository at '/path/guix'...
guix pull: warning: moving channel 'guix' from 26a979105a58e99c6e0fbb51cb1500dfa2bc2cec to unrelated commit 17fc5e35699d2219e6fae1f0583bb8c2ec3deb25
guix pull: warning: initial commit 17fc5e35699d2219e6fae1f0583bb8c2ec3deb25 does not add the key it is signed with (2E4F C7F5 07AB F022 36D3 D51F 31EE D3BE 74EC 3A1F) to the '.guix-authorizations' file.
Authenticating channel 'guix', commits 17fc5e3 to 17fc5e3 (0 new commits)...
FTR, apparently, i have abandoned the pursuit of this issue.
to sum up my perspective:
guix pull's behavior has greatly confused me once by accepting a commit that it (much) later rejected (when it wasn't the tip of the history anymore). i have wasted quite some time debugging/understanding this, which included reading the code. due to my annoyance i got into the presented work/patch while in the process.
if this is not considered an issue, then i don't have a dog in this fight anymore. i have learned this quirk by now, so it won't bite me again, and the rest is up to the maintainers to decide.
feel free to take from this patch whatever you find useful, or close it if you find no more value in it.
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
“Nothing is so permanent as a temporary government program.”