From: "Frank Ch. Eigler" <fche@elastic.org>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: Overseers mailing list <overseers@sourceware.org>,
Mark Wielaard <mark@klomp.org>
Subject: Re: gitsigur for protecting git repo integrity
Date: Fri, 14 Jul 2023 10:00:17 -0400 [thread overview]
Message-ID: <ZLFU8eGYTgyatGwN@elastic.org> (raw)
In-Reply-To: <874jm6y6kv.fsf@gnu.org>
Hi -
> > You're talking about retrospectively verifying old commit signatures,
> > rather than verifying eligilibity at the time of a push.
>
> Both.
OK but you're talking exclusively about the former:
> 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.
One can pull the git repo containing the authorized pubkeys. (At this
point, this would be manual; gitsigur should learn to do a git clone
if given remote URL.)
> This is what ‘guix git authenticate’ addresses.
OK.
> > 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”?
("small matter of programming")
> 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),
If the pubkeys are in the same repo but in another branch, the
timestamp unreliability problem still exists, such as it is.
(gitsigur can be configured for this layout already.)
If the pubkeys are stored within the same branch as the payload source
files, then this requires a change to the project source management.
Even this configuration would work with gitsigur, just a bit ugly.
> and it doesn’t work once you have multiple branches.
I don't understand this concern.
> I think you should take a look at Sections 4 and 5 of
> <https://arxiv.org/pdf/2206.14606v1.pdf>. [...]
Will read, thanks.
- FChE
prev parent reply other threads:[~2023-07-14 14:00 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
2023-07-14 14:00 ` Frank Ch. Eigler [this message]
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=ZLFU8eGYTgyatGwN@elastic.org \
--to=fche@elastic.org \
--cc=ludo@gnu.org \
--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).