From: "Frank Ch. Eigler" <fche@elastic.org>
To: overseers@sourceware.org
Subject: Re: gitsigur for protecting git repo integrity
Date: Thu, 29 Jun 2023 14:55:06 -0400 [thread overview]
Message-ID: <ZJ3Tihvu6GbOb8/R@elastic.org> (raw)
In-Reply-To: <ZIz4NB/AqWpSNj5d@elastic.org>
Hi -
> I'd like to share a little gadget I've been working on recently.
>
> It's a prototype git server hook for allowing participating projects
> to check and/or enforce that commits to certain branches of
> shared-access git repos such as those on sourceware are properly
> gpg-signed. [...]
Some questions have arisen offline about the relationship of this
script to systems such as sigstore and b4. Here's a rough comparison
of the three. This is pretty terse point-by-point analysis. I'd be
happy to elaborate on any aspect of it.
tl;dr: Overall, it turns out to be more of a composition situation
rather than competition.
Sources: [lines-of-source language]
* gitsigur: https://sourceware.org/git/gitsigur.git [200 python]
* sigstore: https://github.com/sigstore/gitsign, /rekor, /fulcio [73000 go]
* b4: https://github.com/mricon/b4 [8500 python]
Scope:
* gitsigur: enforcement of gpg-signed git commits at git server;
keyring storage in some git repo
* sigstore: developer-side git signature tooling, via custom
temporary x509 certificates bound to a web openid identity
* b4: signed/secure git commit text transport over email
Scope overlap:
* gitsigur/b4: none, though the signed git commit message can include the
public-inbox url for authenticating the chain of custody
* sigstore/b4: ditto
* gitsigur/sigstore: use of gpg vs custom signatures on git commits
(nb: sigstore upstream development uses github's
server-side gpg signatures, does not eat sigstore
dog-food itself)
* gitsigur/gitlab: signing same, verification analogous
https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/index.html
https://docs.gitlab.com/ee/user/project/repository/push_rules.html
* gitsigur/github: signing same, verification analogous
https://docs.github.com/en/authentication/managing-commit-signature-verification/telling-git-about-your-signing-key
https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches
Infrastructure required:
* gitsigur: a git server
* sigstore: an openid web server, a certificate generator web server,
audit trail web server, timestamp server
* b4: a public-inbox email server
Developer workflow - pushing code:
* gitsigur: create & share gpg key once, use builtin git gpg support
to sign locally; normal git push to pass gitsigur
enforcing/permissive gate hook
* sigstore: install "gitsign" as replacement git signing/crypto
engine; use openid web system to authenticate against
some identity server; public certificate generator system
creates temp certificate; custom git commit signature
scheme includes entire temp certificate abeam the
signature itself; git commit news may be broadcast to
audit trail; normal git push, no server-side gating hook
* b4: developer posts git patches with b4 wrapper to add gpg
signature; maintainer uses b4 wrapper to check integrity of
emailed patch series; normal git commit & push
Developer workflow - verifying commits from git repo:
* gitsigur: download keyring git repo; run gitsigur locally against
range of commits
* sigstore: run gitsign verify on local repo, with the certificate
keyring stored right within the commits; also possibly
connecting with public audit trail servers
* b4: not applicable
Hosting git server workflow:
* gitsigur: one git update hook
* sigstore: not applicable as server-side gating does not appear to be part of sigstore
* b4: not applicable
Composition possibilities:
* gitsigur/b4: use b4 to send/receive patches by email, gpg-sign resulting
commit and enforce at server side via gitsigur
* gitsigur/sigstore: use sigstore to sign commits; teach gitsigur to detect
sigstore flavoured signatures and delegate verification
to sigstore gitsign, then enforce policy similarly
* gitsigur/sigstore 2: teach gitsigur to announce receipt of verified commits
to sigstore (rekor) public audit-trail
* gitsigur/ssh/x509: extend gitsigur to support ssh and x509 standard
git signature styles, let developers choose
their favorite; store keys/certs in same
keygitrepo
- FChE
next prev parent reply other threads:[~2023-06-29 18:55 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 [this message]
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
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=ZJ3Tihvu6GbOb8/R@elastic.org \
--to=fche@elastic.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).