As I hinted in the summary, I think the solution to this problem, for both GitLab and Gitolite, is to use cryptographic signatures using preciously protected keys. We already use OpenPGP extensively in the Tor infrastructure, and it's well integrated in git, so it's an obvious candidate. Various projects have different approaches regarding this:
## Guix: sign all commits
[Guix uses OpenPGP to sign commits](https://guix.gnu.org/blog/2020/securing-updates/), using an approach that is basically like this:
> 1. The repository contains a .guix-authorizations file that lists the OpenPGP key fingerprints of authorized committers.
> 2. A commit is considered authentic if and only if it is signed by one of the keys listed in the .guix-authorizations file of each of its parents. This is the authorization invariant.
>
> \[...\] Since .guix-authorizations is a regular file under version control, granting or revoking commit authorization does not require special support.
Note the big caveat:
> It has one downside: it prevents pull-request-style workflows. Indeed, merging the branch of a contributor not listed in .guix-authorizations would break the authorization invariant. It’s a good tradeoff for Guix because our workflow relies on patches carved into stone tablets (patch tracker), but it’s not suitable for every project out there.
Also note there's a bootstrapping problem in their design:
> which commit do we pick as the first one where we can start verifying the authorization invariant?
They solve this with an out of band "*channel introduction*" mechanism which declares a good hash and a signing key.
This also requires a custom client. But it serves as a good example of an extreme approach (validate everything) one could take.
## Arista: sign all commits in Gerrit
Arista wrote a blog post called [Commit Signing with Git at Enterprise Scale](https://eos.arista.com/commit-signing-with-git-at-enterprise-scale/)([archive](https://web.archive.org/web/20201020180304/https://eos.arista.com/commit-signing-with-git-at-enterprise-scale/)) which takes a radically different approach.
* all OpenPGP keys are centrally managed (which solves the "web of trust" mess) in a [Vault](https://www.vaultproject.io/)
* Gerrit is the gatekeeper: for patches to be merged, they must be signed by a trusted key
It is a rather obtuse system: because the final patches are rebased on top of the history, the git signatures are actually lost so they have a system to keep a reference to the Gerrit change id in the git history, which does have a copy of the OpenPGP signature.
## Gerwitz: sign all commits or at least merge commits
Mike Gerwitz wrote an [article in 2012](https://mikegerwitz.com/2012/05/a-git-horror-story-repository-integrity-with-signed-commits)(which he warns is out of date) but which already correctly identified the issues with merge and rebase workflows. He argues there is a way to implement the desired workflow by signing *merges*: because maintainers are the one committing merge requests to the tree, they are in a position to actually sign the code provided by third-parties. Therefore it can be assume that if a merge commit is signed, then the code it imported is also signed.
The article also provides a crude checking script for such a scenario.
Obviously, in the case of GitLab, it would make the "merge" button less useful, as it would break the trust chain.
## Torwalds: signed tags
Linus Torwalds, the (current) maintainer of the Linux kernel, simply signs the release tags. In an article called "[what does a pgp signature on a git commit prove?](https://people.kernel.org/monsieuricon/what-does-a-pgp-signature-on-a-git-commit-prove)", Konstantin Ryabitsev (the kernel.org sysadmin), provides a good primer on OpenPGP signing in git. It also shows how to validate Linux releases by checking the tag and argues this is sufficient to ensure trust.
## Vick: git signatures AKA git notes
The [git-signatures](https://github.com/hashbang/git-signatures/) project, authored by [Lance R. Vick](https://github.com/lrvick), makes it possible to "*attach an arbitrary number of GPG signatures to a given commit or tag.*":
> Git already supports commit signing. These tools are intended to compliment that support by allowing a code reviewer and/or release engineer attach their signatures as well.
Downside: third-party tool not distributed with git and not packaged in Debian.
The idea of using git-notes was also [proposed by Owen Jacobsen](https://grimoire.ca/git/detached-sigs/).
## Walters: extended validation tags
The [git-evtag](https://github.com/cgwalters/git-evtag) projects from Colin Walters tries to address the perceived vulnerability of the SHA-1 hash by implementing a new signing procedure for tags, based on SHA-512 and OpenPGP.
## Ryabitsev: b4 and patch attestations
Konstantin Ryabitsev (the kernel.org sysadmin, again) proposed a new cryptographic scheme to sign patches in Linux, he called "[patch attestation](https://people.kernel.org/monsieuricon/introducing-b4-and-patch-attestation)". The protocol is designed to survive mailing list transports, rebases and all sorts of mangling. It does not use GnuPG and is based on a Trust On First Use (TOFU) model.
The model is not [without critics](https://lwn.net/Articles/813646/#Comments).
## Ryabitsev: Secure Scuttlebutt
A more exotic proposal is to [use the Secure Scuttlebutt (SSB) protocol](https://people.kernel.org/monsieuricon/patches-carved-into-developer-sigchains) instead of emails to exchange (and also, implicitly) sign git commits. There is even a [git-ssb](https://github.com/clehner/git-ssb) implementation, although it's hard to see because it's been migrated to .... SSB!
Obviously, this is not quite practical and is shown only as a more radical example, as a stand-in for the other end of the decentralization spectrum.
## Other caveats
Also note that git has limited security guarantees regarding checksums, since it uses SHA-1, but [that is about to change](https://lwn.net/Articles/823352/). Most Git implementations also have protections against collisions, see for example [this article from GitHub](https://github.com/blog/2338-sha-1-collision-detection-on-github-com).
There are, of course, a large number of usability (and some would say security) issues with OpenPGP (or, more specifically, the main implementation, GnuPG). There has even been [security issues with signed Git commits](https://mgorny.pl/articles/attack-on-git-signature-verification.html), specifically.
So I would also be open to [alternative signature verification schemes](https://blog.gtank.cc/modern-alternatives-to-pgp/). Unfortunately, none of those are implemented in git, as far as I can tell.
There are, however, alternatives to GnuPG itself. [This article from Saoirse Shipwreckt](https://boats.gitlab.io/blog/post/signing-commits-without-gpg/) shows how to verify commits without GnuPG, for example. That still relies on OpenPGP keys of course...
... which brings us to the web of trust and key distribution problems. The OpenPGP community is in this problematic situation right now where the traditional key distribution mechanisms (the old keyserver network) has been under attack and is not as reliable as it should be. This brings the question of keyring management, but that is already being discussed in tpo/tpa/team#29671.
Finally, note that OpenPGP keys are not permanent: they can be revoked, or expired. Dealing with this problem has its specific [set of solutions](https://karl.kornel.us/2017/10/welp-there-go-my-git-signatures/) as well.
## Related
*[gitid](https://github.com/Luiserebii/gitid): easier identity management for git
