| Message ID | 20200608215224.2672-1-ludo@gnu.org |
|---|---|
| Headers | show |
Ludovic Courtès <ludo@gnu.org> skribis: > This patch series does it! It integrates checkout authentication > with (guix channels). Now, ‘guix pull’, ‘guix time-machine’ etc. > automatically authenticate the commits they fetch and raise an > error if they find an unsigned commit or a commit signed by an > unauthorized party¹. [...] > ¹ https://issues.guix.gnu.org/issue/22883#64 Something we didn’t discuss is that this model forbids a merge-request kind of workflow, or at least the person who merges must sign the commits, rewriting the merged branch. I think it’s a reasonable tradeoff in this space, but it’s worth keeping in mind. Ludo’.
Hello Guix! Ludovic Courtès <ludo@gnu.org> skribis: > This patch series does it! It integrates checkout authentication > with (guix channels). Now, ‘guix pull’, ‘guix time-machine’ etc. > automatically authenticate the commits they fetch and raise an > error if they find an unsigned commit or a commit signed by an > unauthorized party¹. Last days to comment on this change! :-) https://issues.guix.gnu.org/41767 If there are no objections by then, I’ll push on Tuesday 16th. Ludo’.
Hi Ludo, Thank you for explaining. All is clear. :-) >> git clone https://git.savannah.gnu.org/git/guix.git >> git worktree add -b foo wk/foo >> cd wk/foo >> # add my unready stuff >> ./pre-inst-env guix pull --branch=foo --url=$PWS -p /tmp/foo >> /tmp/foo/bin/guix install unready-stuff >> >> In this case, do I have to use the option '--disable-authentication'? > > Yes, you can always use it. "Qui peut le plus peut le moins." ;-) The question is: is it mandatory? > Note that this patch set changes nothing for third-party channels. > (Attentive readers will find out how to make an authenticated channel, > but it’s undocumented and inconvenient to use.) > > In the future, I think ‘guix pull’ will merely print a warning when > using an unauthenticated channel. That’s something we’ll have to > discuss. > > If you want to fork an “authenticated channel”, you don’t have to keep > it authenticated. In essence, something who writes: > > (channel (name 'zimoun) (url "https://zimoun.example.org")) > > states that they want to fetch code from your channel, but that no > authentication will take place because there’s no ‘introduction’ field. The root of my question is answered. :-) And I do not know if I am an attentive reader but my concerns were about this future discussion. So let discuss that in the future. ;-) Thank you for this nice piece of work! All the best, simon ps: Sorry for the delay, I changed how I process emails and this message "disappeared". And I am not sure this answer will be correctly delivered. Sorry in advance if I mess something.
Hi Guix! This patch series does it! It integrates checkout authentication with (guix channels). Now, ‘guix pull’, ‘guix time-machine’ etc. automatically authenticate the commits they fetch and raise an error if they find an unsigned commit or a commit signed by an unauthorized party¹. Channel introductions² are implemented but not exposed. Thus, third-party channels cannot use the authentication mechanism yet. Conversely, the ‘guix’ channel is authenticated by default. Any commit in the closure of the introduction’s first commit is considered authentic (for instance, the commit pointed to by ‘v0.5’ is considered authentic, even though it’s not even signed.) Conversely, any commit that does _not_ contain the introduction’s first commit in its closure is considered inauthentic. The patch marked “DROP?” implements “prehistorical authorizations”, i.e., authorizations for when ‘.guix-authorizations’ didn’t exist (“make authenticate” does that as well). Without that patch, we take 87a40d7203a813921b3ef0805c2b46c0026d6c31 (May 5th) as the introduction’s first commit. In concrete terms, what the patch marked as “DROP?” would buy us is the ability to merge branches created between ‘v1.0.0’ and 87a40…. I think it’s not that useful, so I’m willing to drop it. (We can always take it later if we want to.) There’s a ‘--disable-authentication’ escape hatch for ‘guix pull’, but not for ‘guix time-machine’ (we’d need to make sure we don’t cache an inferior that was not authenticated.) I would much welcome feedback! I’m happy to answer questions if anything’s unclear. Don’t hesitate, because after that it’ll be harder to change! Ludo’. ¹ https://issues.guix.gnu.org/issue/22883#64 ² https://issues.guix.gnu.org/issue/22883#69 Ludovic Courtès (9): git-authenticate: Cache takes a key parameter. git-authenticate: 'authenticate-commits' takes a #:keyring parameter. tests: Move OpenPGP helpers to (guix tests gnupg). channels: 'latest-channel-instance' authenticates Git checkouts. channels: Make 'validate-pull' call right after clone/pull. .guix-channel: Add 'keyring-reference'. channels: Automatically add introduction for the official 'guix' channel. pull: Add '--disable-authentication'. DROP? channels: Add prehistorical authorizations to <channel-introduction>. .dir-locals.el | 1 + .guix-channel | 3 +- build-aux/git-authenticate.scm | 246 +------------------ doc/guix.texi | 20 +- guix/channels.scm | 437 +++++++++++++++++++++++++++++++-- guix/git-authenticate.scm | 32 +-- guix/scripts/pull.scm | 24 +- guix/tests/gnupg.scm | 32 ++- tests/channels.scm | 128 +++++++++- tests/git-authenticate.scm | 25 -- 10 files changed, 634 insertions(+), 314 deletions(-)