Bislang nutzte ich das Commit-Signing mit PGP/GPG eher widerwillig, insofern war mein persönliches Highlight der neuen Git Version 2.34 das Signieren von Commits mit SSH Schlüsseln, was natürlich sofort ausprobiert werden musste…
Setup: Signieren von Commits mit SSH Keys
Das Setup ist sehr einfach - im aktiven Git Repository das Format auf SSH einstellen und das Signieren von Commits und Tags aktivieren. Zuletzt wird der Public Key vom jeweiligen SSH Schlüssel konfiguriert.
git config gpg.format ssh
git config commit.gpgsign true
git config tag.gpgsign true
git config user.signingKey 'ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFpYkw64SlGKg8fk8wnNSkrrVOeKcGljvvR0OT5bKf0e'
Soweit das Setup - das Signieren mit den SSH Keys ist eingerichtet und kann wie gewohnt mit der Option -S aktiviert werden.
git commit -S -m 'this a signed commit'
Verifizieren der SSH signierten Commits
Was nützt einem die Signatur wenn sie nicht überprüft wird. Mit --show-signature können wir beim git log die Signatur-Daten prüfen, und da gibts dann schon den ersten Fehler…
git log --show-signature
error: gpg.ssh.allowedSignersFile needs to be configured and exist for ssh signature verification
commit 34340cebdcd5b06186a1e9154800b0e337d96682 (HEAD -> main)
No signature
Author: mplx <developer@mplx.eu>
Date: Thu Nov 18 10:02:08 2021 +0100
Es muss ein allowedSignersFile konfiguriert werden. Dies ist schnell mit einem git config erledigt, zur Sicherheit erstellen wir noch eine leere Datei die wir im Homeverzeichnis anlegen.
mkdir -p ~/.config/git/ && touch ~/.config/git/allowed_signers
git config gpg.ssh.allowedSignersFile "$HOME/.config/git/allowed_signers"
Eine erneute Prüfung teilt uns zwar mit dass die Signatur OK ausschaut, sie aber nicht gegen die Liste vertrauenswürdiger Entwickler verifziert werden konnte (klar, wir haben oben ja eine leere Datei angelegt).
git log --show-signature
echo "developer@mplx.eu ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFpYkw64SlGKg8fk8wnNSkrrVOeKcGljvvR0OT5bKf0e" | tee -a ~/.config/git/allowed_signers
Nachdem ich mir selber am meisten vertraue ;) schreibe ich meinen eigenen Key in das allowed_signers und eine neue Überprüfung bestätigt dass nun alles OK ist.
git log --show-signature
commit 34340cebdcd5b06186a1e9154800b0e337d96682 (HEAD -> main)
Good "git" signature for developer@mplx.eu with ED25519 key SHA256:Qe3mzo3B0wtMwaucAnECdexx4jqSdbZMpsGVnzHLcD4
Author: mplx <developer@mplx.eu>
Date: Thu Nov 18 10:02:08 2021 +0100
allowed_signers: wem wie vertrauen?
Spanned wird, welcher Weg sich als der Beste erweisen wird, die allowed_signers-Datei zu pflegen. Den Job den bei PGP/GPG die Key-Server übernommen haben muss man nun selbst erledigen. Für’s erste Pflege ich lokal meine Liste händisch - notfalls lade ich mir die ohnehin öffentlichen Keys händisch (bzw. mit einem kleinem Frickel-Skript) von den jeweiligen Github- oder Gitlab-Usern herunter, aber für größere Projekte gerade im Unternehmensumfeld scheint das nicht so ganz praktikabel zu sein. Und für die gute Usability fehlt zudem noch die Integration im GUI-Bereich - Gitlab 14.4 zeigt in der Repository-Oberfläche noch keine Daten für SSH Signaturen an - man sieht aktuell nicht einmal das hier ein Commit signiert wurde.
Der erste Blick zeigt das es grundsätzlich sehr interessant ausschaut, aber die Nahe Zukunft erst zeigen wird wie praktikabel die ganze Sache dann sein wird.