public inbox for overseers@sourceware.org
 help / color / mirror / Atom feed
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

  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).