Commits und Tags mit einem SSH-Schlüssel oder GPG signieren

Ziel

Commits und Release-Tags mit einer prüfbaren Signatur versehen, sodass ein Reviewer oder ein Build nachvollziehen kann, dass eine Änderung von einer Inhaberin oder einem Inhaber eines bekannten Schlüssels stammt und nicht nur von jemandem, der einen Namen in user.email eingetippt hat.

Voraussetzungen

Git mit Unterstützung für gpg.format (die git-config-Dokumentation listet die Werte openpgp (Standard), x509 und ssh auf). Für SSH-Signaturen: ein SSH-Schlüsselpaar und ssh-keygen aus OpenSSH, das die Signatur erstellt. Für GPG: ein Schlüsselpaar mit einer Schlüssel-ID. Ein Ort, um öffentliche Schlüssel zu veröffentlichen, etwa die Kontoeinstellungen der Hosting-Plattform.

Schritte

1. Das Format wählen. SSH nutzt den Schlüssel weiter, den Entwickelnde bereits haben, und braucht keinen Keyserver; GPG bringt ein Web-of-Trust-Modell und Ablaufdaten mit. git config --global gpg.format ssh setzen (oder für GPG den Standard belassen).
2. Den Schlüssel benennen: git config --global user.signingKey ~/.ssh/id_ed25519.pub für SSH (die GitHub-Anleitung zeigt dieselben Befehle) oder die GPG-Schlüssel-ID.
3. Signieren standardmässig einschalten: git config --global commit.gpgSign true und git config --global tag.gpgSign true. Die Dokumentation weist darauf hin, dass Rebases dann viele Commits signieren, weshalb ein Agent verwendet werden sollte, um wiederholte Passphrase-Abfragen zu vermeiden.
4. Lokal prüfen. Bei SSH eine Allowed-Signers-Datei mit Zeilen der Form principal ssh-ed25519 AAAA... anlegen und gpg.ssh.allowedSignersFile darauf verweisen lassen; die Dokumentation hält fest, dass SSH keine Vertrauensstufen kennt: Ein in dieser Datei gelisteter Schlüssel erhält die Vertrauensstufe „fully“, andernfalls schlagen git verify-commit und git verify-tag fehl – diese Datei ist also die gesamte Vertrauensentscheidung. Anschliessend git verify-commit HEAD und git verify-tag v1.2.0 oder git log --show-signature ausführen.
5. Den öffentlichen Schlüssel als Signing-Schlüssel auf die Hosting-Plattform hochladen, damit deren Oberfläche Commits als verifiziert kennzeichnet.
6. Release-Tags mit git tag -s v1.2.0 -m "..." signieren; nur annotierte Tag-Objekte können eine Signatur tragen.
7. Bei einer Schlüsselrotation den alten öffentlichen Schlüssel mit den Optionen valid-after und valid-before in der Allowed-Signers-Datei belassen (laut Dokumentation OpenSSH 8.8 oder neuer); Git akzeptiert dann Signaturen, die erstellt wurden, solange der Schlüssel gültig war. Widerrufene Schlüssel gehören in gpg.ssh.revocationFile, eine KRL oder eine einfache Schlüsselliste, deren Einträge stets als ungültig gemeldet werden.

Erwartetes Ergebnis

git verify-commit meldet für signierte Commits eine gültige Signatur, die Plattform zeigt sie als verifiziert an, und ein unsignierter oder falsch signierter Commit ist im Review als solcher sichtbar und kann durch Branch-Regeln abgelehnt werden.

Grenzen und Prüfbasis

Eine Signatur belegt den Besitz eines Schlüssels zum Zeitpunkt der Signierung, nicht dass die Änderung korrekt ist oder dass die Schlüsselinhaberin oder der Schlüsselinhaber tatsächlich die im Namen genannte Person ist. Squash- oder Rebase-Merges, die die Hosting-Plattform durchführt, erzeugen neue Commits, die entweder keine Signatur tragen oder die eigene Signatur der Plattform. Das Verhalten folgt der zitierten Dokumentation; es wird keine Messung von Verbreitung oder Aufwand behauptet.