unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Ricardo Wurmus <rekado@elephly.net>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 22883@debbugs.gnu.org
Subject: bug#22883: Authenticating a Git checkout
Date: Fri, 27 Dec 2019 20:48:05 +0100	[thread overview]
Message-ID: <87png9o8i2.fsf@elephly.net> (raw)
In-Reply-To: <87bmkwm8ed.fsf@gnu.org>


Ludovic Courtès <ludo@gnu.org> writes:

> Hello,
>
> Just a note for later…
>
> ludo@gnu.org (Ludovic Courtès) skribis:
>
>> With the quick-hack libgit2 bindings attached, I can run this program,
>> which authenticates HEAD:
>
> [...]
>
>> So I think we can go from here.  Our repo would contain a Scheme list of
>> authorized OpenPGP fingerprints, and we’d check whether the fingerprint
>> that shows up in ‘valid-signature’ above is among them
>
> Storing the list of authorized keys in a file in the repo is
> inconvenient: simply to retrieve it, you’d need to make a checkout.  So
> for each commit we verify, we have to check out the whole repo, which is
> inefficient.
>
> While reading
> <http://karl.kornel.us/2017/10/welp-there-go-my-git-signatures/>, I
> realized we could store in empty Git commit messages, which would
> address the above problem (we could use a custom object type too, but
> that would be less convenient.)
>
> So the special commit could look like:
>
>   Authorization
>
>   (commit-authorizations
>     (authorization-commit (KEY1 KEY2 …))
>     (files ("hydra.gnu.org.pub") (KEY1 KEY2 …))
>     (files _ (KEY1 KEY2 …))) ;all other files
>
> That way, to authenticate a commit, we first fetch the latest
> authorization commit, read the authorization rules from there, and make
> sure that the changes it makes match the rules.
>
> Thoughts?

Does this *have* to be baked into git?  Or are we like the carpenter
apprentice who just learned how to use a hammer and considers everything
to be a kind of nail…?

I see the appeal of having everything in git as that’s where the commits
are that should be authenticated, but using special commit messages
seems to me like shoehorning update authorization into a code revision
tool.

You mentioned that checking signatures on commits is also kinda slow
because it’s sequential and not cached.  I don’t know what I really
want, but is there perhaps a way to aggregate signatures on past commits
so that the client’s work is reduced…?

(I’m very glad you’re thinking about this problem and that you’ve come up
with practical steps forward!  I don’t know if my thoughts on this topic
are useful.)

--
Ricardo

  reply	other threads:[~2019-12-27 19:49 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-02 18:03 bug#22883: Trustable "guix pull" Christopher Allan Webber
2016-03-02 19:26 ` Leo Famulari
2016-03-02 21:07   ` Christopher Allan Webber
2016-04-25 22:25 ` Ludovic Courtès
2016-04-26  0:13   ` Leo Famulari
2016-04-26  0:17     ` Thompson, David
2016-04-26  7:12       ` Ludovic Courtès
2016-04-30  4:43     ` Mike Gerwitz
2016-06-03 16:12       ` bug#22883: Authenticating a Git checkout Ludovic Courtès
2016-06-03 20:17         ` Leo Famulari
2016-06-04 11:04           ` Ludovic Courtès
2016-06-04  4:24         ` Mike Gerwitz
2016-06-04 11:17           ` Ludovic Courtès
2016-06-04 12:45             ` ng0
2016-06-06 12:20               ` ng0
2016-06-04 16:14             ` Mike Gerwitz
2016-06-05 20:39             ` Christopher Allan Webber
2016-06-05 21:15               ` Leo Famulari
2016-06-06  2:41               ` Mike Gerwitz
2016-06-06  7:01                 ` Ludovic Courtès
2016-07-22  8:22         ` Ludovic Courtès
2016-07-22 12:58           ` Thompson, David
2016-07-22 13:58             ` Ludovic Courtès
2017-10-24 23:30           ` Ludovic Courtès
2019-12-27 19:48             ` Ricardo Wurmus [this message]
2019-12-28 14:47               ` Ludovic Courtès
2019-12-28 16:05                 ` Ricardo Wurmus
2019-12-28 17:45                   ` Ludovic Courtès
2020-04-30 15:32                 ` Ludovic Courtès
2020-05-01 15:46                   ` Justus Winter
2020-05-01 16:50                     ` Ludovic Courtès
2020-05-01 17:04                   ` Ludovic Courtès
2020-05-19 20:23                     ` Ludovic Courtès
2020-06-01 14:07                       ` bug#22883: Channel introductions Ludovic Courtès
2020-06-02 23:45                         ` zimoun
2020-06-03  9:50                           ` Ludovic Courtès
2020-06-03 16:20                             ` zimoun
2020-06-04  9:55                               ` Ludovic Courtès
2020-05-01 17:20                   ` bug#22883: Authenticating a Git checkout Ludovic Courtès
2020-05-02 22:02                   ` Ludovic Courtès
2020-05-04  8:03                     ` Ludovic Courtès
2016-06-01 16:47   ` bug#22883: Discussion of TUF in the context of Git checkout authentication Ludovic Courtès
2016-05-15 12:40 ` bug#22883: Trustable "guix pull" fluxboks
2016-05-16 17:55   ` Thompson, David
2016-05-17 21:19   ` Ludovic Courtès
2016-06-04 16:19 ` Werner Koch
2016-06-04 22:27   ` Ludovic Courtès
2016-06-05  7:51     ` Werner Koch
2016-06-06 21:01       ` Leo Famulari
2016-06-07  8:08         ` bug#22883: gpg2 vs. gpg Ludovic Courtès
2016-06-07 11:25           ` Werner Koch
2016-06-07 12:58             ` ng0
2016-06-05  1:43   ` bug#22883: Trustable "guix pull" Mike Gerwitz
2018-08-28 19:56 ` Vagrant Cascadian
2018-09-02 16:05   ` Ludovic Courtès
2018-09-02 17:15     ` Vagrant Cascadian
2018-09-02 20:07       ` Ludovic Courtès
2019-12-20 22:11         ` bug#22883: Authenticating Git checkouts: step #1 Ludovic Courtès
     [not found]         ` <87mubmodfb.fsf_-_@gnu.org>
2019-12-21  1:33           ` zimoun
2019-12-27 12:58           ` Ludovic Courtès
     [not found]           ` <87eewqgc1v.fsf@gnu.org>
2019-12-27 20:47             ` Ricardo Wurmus
     [not found]             ` <87o8vto5rl.fsf@elephly.net>
2019-12-29  2:45               ` Vagrant Cascadian
     [not found]               ` <87a77bzw6p.fsf@yucca>
2019-12-29  7:34                 ` Efraim Flashner
2019-12-30 21:29                 ` Ludovic Courtès
2019-12-31 19:16 ` Jakub Kądziołka
2020-01-08 13:30   ` Ludovic Courtès
2020-06-02 13:49 ` bug#22883: Authenticating a Git checkout John Soo
2020-06-03  9:33   ` Ludovic Courtès
2020-06-08 21:54 ` bug#22883: [PATCH 1/9] git-authenticate: Cache takes a key parameter Ludovic Courtès
2020-06-08 21:54   ` bug#22883: [PATCH 2/9] git-authenticate: 'authenticate-commits' takes a #:keyring parameter Ludovic Courtès
2020-06-08 21:54   ` bug#22883: [PATCH 3/9] tests: Move OpenPGP helpers to (guix tests gnupg) Ludovic Courtès
2020-06-08 21:54   ` bug#22883: [PATCH 4/9] channels: 'latest-channel-instance' authenticates Git checkouts Ludovic Courtès
2020-06-08 21:54   ` bug#22883: [PATCH 5/9] channels: Make 'validate-pull' call right after clone/pull Ludovic Courtès
2020-06-08 21:54   ` bug#22883: [PATCH 6/9] .guix-channel: Add 'keyring-reference' Ludovic Courtès
2020-06-08 21:54   ` bug#22883: [PATCH 7/9] channels: Automatically add introduction for the official 'guix' channel Ludovic Courtès
2020-06-08 21:54   ` bug#22883: [PATCH 8/9] pull: Add '--disable-authentication' Ludovic Courtès
2020-06-08 21:54   ` bug#22883: [PATCH 9/9] DROP? channels: Add prehistorical authorizations to <channel-introduction> Ludovic Courtès
2020-06-08 22:04   ` bug#22883: [PATCH 1/9] git-authenticate: Cache takes a key parameter Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87png9o8i2.fsf@elephly.net \
    --to=rekado@elephly.net \
    --cc=22883@debbugs.gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).