Re: gitsigur for protecting git repo integrity

[Mark Wielaard <mark@klomp.org>]

Hi Frank,

CC, FoxBoron and Sam who we were discussing some of this on irc, but
who I believe are not on overseers@.

On Fri, Jun 16, 2023 at 08:03:00PM -0400, Frank Ch. Eigler via Overseers wrote:
> 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.  "properly" means signed with keys that are designated as
> valid for the particular committer, so as to further protect repos -
> from impersonation.  Those keys are held in an auxiliary git repo.
> 
> It's a small, self-contained python3 script (plus a man page), already
> deployed to gitsigur's own git repo (in enforcing mode!), and onto
> elfutils & bunsen master branches in permissive mode (so it only
> tests, but accepts anyway).  Having a project gradually opt-in is
> trivial for a shell-capable project admin:
> 
>  - add a +x .git/hooks/update file containing something like like:
> 
>    #! /bin/sh
>    set -e
>    /sourceware/projects/gitsigur-home/install/bin/gitsigur "$1" "$2" "$3"
> 
>  - add a few configuration parameters to .git/config
>  
>    [gitsigur]
>        keygitrepo = /sourceware/projects/gitsigur-home/keygitrepo
>        checkref = refs/heads/master
> 
>  - and gradually send me/us participating folks' gpg public keys to
>    add to the new git://sourceware.org/git/keygitrepo.git keyring
> 
> 
> That's it!  If in enforcing mode, this is what a push attempt would
> see on an unsigned commit:
> 
> remote: gitsigur checking (enforcing) against keygitrepo /git/keygitrepo.git branch keymaster
> remote: ⨯ commit 3a3c69aafa549aad042ed2210bae36fa7fe0ced8 not signed
> remote: gitsigur result: ⨯ failure
> remote: error: hook declined to update refs/heads/master
> To ssh://sourceware.org/git/gitsigur.git
>  ! [remote rejected]           master -> master (hook declined)
>   error: failed to push some refs to 'ssh://sourceware.org/git/gitsigur.git'
>   
> On the other hand, a happier outcome looks like this:
> 
> remote: gitsigur checking (enforcing) against keygitrepo /sourceware/projects/gitsigur-home/keygitrepo branch keymaster
> remote: ✓ commit d4bad9409204c887e7786427caf0b1919fd3f09d signed by authorized key for fche@redhat.com
> remote: gitsigur result: ✓ success
> To ssh://sourceware.org/git/gitsigur.git
>    9fa6f36a615f..d4bad9409204  master -> master
> 
> In the default permissive mode, even failure gets a trophy.
> 
> 
> From the developer side, signing git commits with gpg is not too bad.
> With tools like gpg-agent mediating one's credentials, one's not stuck
> typing passphrases all day.
> 
> https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work
> 
> 
> Future:
> 
> The gadget scratches my itch already.
> 
> Depending on interest etc. and time availability, one can envision
> some self-serve management of the repo that stores gpg public keys,
> maybe interoperation with public gpg key servers, maybe dabbling in
> web-of-trust type things.  Maybe gamification so projects and people
> who commit signed things, thereby contributing to a secure supply
> chain, get rewarded with electronic tchotchkes.  Maybe allow
> per-branch keyring configuration.  Maybe toolshed some jargon?  What
> do you think?

I like the general idea of (optionally) signing commits. And having an
associated store of known keys.

As long as there are also unsigned or unknown signed commits it makes
sense to also introduce some kind of transparancy log so people can
check commits came in through a (ssh authenticated) receive-pack (and
were not to result of direct manipulation of a repo on the server).

I don't think enforcing mode will be very popular on normal
development branches. But I can see it being something you might want
for release branches. So a configuration where only release
maintainers may create and push to release branches and you can check
that all commits are signed up to the branch point.

Also you might want to have a mode between permissive and enforcing,
that simply checks all commits are signed? But maybe not having the
public key for a signed commit doesn't really make sense?

Does it make sense for there to be a mode that requires (just) tags to
be signed?

> Sauce:
> 
> https://sourceware.org/git/gitsigur.git
> https://sourceware.org/git/keygitrepo.git
> 
> Similarish:
> 
> https://gitweb.gentoo.org/infra/githooks.git/tree/local/update-02-gpg
> [and probably a bunch of others]
> 
> 
> - FChE