From: "Ludovic Courtès" <ludo@gnu.org>
To: "Frank Ch. Eigler" <fche@elastic.org>
Cc: "Frank Ch. Eigler" <fche@redhat.com>,
Overseers mailing list <overseers@sourceware.org>,
Mark Wielaard <mark@klomp.org>
Subject: Re: gitsigur for protecting git repo integrity
Date: Fri, 14 Jul 2023 15:18:40 +0200 [thread overview]
Message-ID: <874jm6y6kv.fsf@gnu.org> (raw)
In-Reply-To: <ZKyAwM5x2DKGbeKm@elastic.org> (Frank Ch. Eigler's message of "Mon, 10 Jul 2023 18:05:52 -0400")
Hi Frank and all,
"Frank Ch. Eigler" <fche@elastic.org> skribis:
>> >> My understanding is that gitsigur checks signatures against an
>> >> out-of-band list of authorized keys, which isn’t very useful because
>> >> the set of authorized committers changes over time.
>> >
>> > The list of authorized keys is stored in a selected branch
>>
>> If it’s in another branch than the code it’s about, how can you tell
>> whether a key was authorized at a given point in the commit history?
>
> You're talking about retrospectively verifying old commit signatures,
> rather than verifying eligilibity at the time of a push.
Both. Assume a contributor has a genuine checkout; how do you ensure
that when they eventually run ‘git pull’ they can authenticate their
updated checkout? You need to somehow convey the updated set of
authorized committers to everyone who pulls from the repo.
This is what ‘guix git authenticate’ addresses.
> gitsigur at uses the "current" contents of the keymaster repo/branch
> for the list of public keys. It could also look back in time, relying
> on that repo's commit timeline, to inspect the time-varying mapping.
> There is enough information there, so it's a SMOP.
“SMOP”? I think info about the set of authorized keys should be stored
in-band, in the repo. If you maintain it out-of-band, then you can try
to match timelines as you write, but it’s just an approximation, it’s
unreliable (you cannot rely on timestamps in Git commits, for instance),
and it doesn’t work once you have multiple branches.
I think you should take a look at Sections 4 and 5 of
<https://arxiv.org/pdf/2206.14606v1.pdf>. Maybe you’ll decide that
‘guix git authenticate’ is unsuitable and maybe you’ll end up extending
gitsigur instead, but I think the discussion there is worth a look
because it’s about precisely what we’re discussing.
HTH!
Ludo’.
next prev parent reply other threads:[~2023-07-14 13:18 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-17 0:03 Frank Ch. Eigler
2023-06-18 23:03 ` Mark Wielaard
2023-06-19 20:20 ` Frank Ch. Eigler
2023-06-29 18:55 ` Frank Ch. Eigler
2023-07-04 8:32 ` Mark Wielaard
2023-07-05 18:25 ` Mark Wielaard
2023-07-05 20:01 ` Frank Ch. Eigler
2023-07-10 21:35 ` Ludovic Courtès
2023-07-10 22:05 ` Frank Ch. Eigler
2023-07-14 13:18 ` Ludovic Courtès [this message]
2023-07-14 14:00 ` Frank Ch. Eigler
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874jm6y6kv.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=fche@elastic.org \
--cc=fche@redhat.com \
--cc=mark@klomp.org \
--cc=overseers@sourceware.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.
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).