Signierte Git-Commits — Was „Verified“ tatsächlich bedeutet
Signierte Git-Commits — Was „Verified“ tatsächlich bedeutet
Ein Commit auf einer Hosting-Plattform kann das beruhigende Label „Verified“ tragen. Es ist verständlich, dieses Label als „Diese Änderung stammt von der genannten Person, wurde geprüft und ist sicher“ zu lesen. Diese Interpretation geht jedoch weit über das hinaus, was eine digitale Signatur belegen kann.
Ein signierter Git-Commit ist nützlich, aber sein Nutzen ist begrenzt. Eine Signatur kann es ermöglichen zu prüfen, ob ein kryptografischer Schlüssel eine bestimmte Commit-Signatur erzeugt hat, und zwar nach den Regeln von Git und der Hosting-Plattform. Sie sagt nicht von selbst, ob die Änderung gut ist, ob die erwartete Person den Schlüssel zu diesem Zeitpunkt kontrollierte oder ob die daraus entstandene Software sicher gebaut wurde.
Was ein signierter Commit verbindet
Git speichert einen Commit als Object mit Informationen wie dem aufgezeichneten Tree, den Eltern-Commits, den Author- und Committer-Metadaten sowie der Commit-Nachricht. Eine Signatur wird an diesen Commit angehängt. Bei der Prüfung verwendet Git den zugehörigen Public Key, um festzustellen, ob die Signatur zu den signierten Daten passt.
Das liefert eine wichtige Aussage über die Integrität: Die signierten Daten wurden nicht auf eine Weise verändert, durch die die Signatur ungültig würde. Außerdem erhalten wir eine Schlüsselidentität, die wir untersuchen können. Das wichtige Wort ist untersuchen. Ein Name oder eine E-Mail-Adresse neben einem Schlüssel ist Metadaten und eine Grundlage für eine Richtlinie, aber kein unabhängiger Beweis dafür, dass eine bestimmte Person genau diese Änderung beabsichtigt hat.
Das ähnelt der Prüfung eines Siegels auf einem Umschlag. Ein Siegel kann zeigen, dass der Umschlag nach dem Versiegeln geöffnet oder verändert wurde. Es sagt nicht, ob der Inhalt richtig ist, ob die versiegelnde Person dazu berechtigt war oder ob die darin enthaltenen Anweisungen sinnvoll sind.
Wie Git Commits signiert und prüft
Die Git-Dokumentation beschreibt das Signieren von Commits und Tags mit einem konfigurierten Signing Key. Für einen einzelnen Commit kann die Signatur mit -S angefordert werden:
git commit -S -m "Describe the change"
Der verwendete Schlüssel und das Signaturprogramm hängen von der lokalen Konfiguration ab. Die Git-Referenz dokumentiert Einstellungen wie das Signaturformat und den ausgewählten Schlüssel. Ein Projekt kann Signaturen auch standardmäßig anfordern, zum Beispiel mit:
git config commit.gpgsign true
Diese Einstellung ändert das Standardverhalten für Commits im jeweiligen Konfigurationsbereich. Sie legt keine Vertrauensrichtlinie für jeden Schlüssel im Repository fest und macht historische, unsignierte Commits nicht nachträglich zu signierten Commits.
Git kann Signaturinformationen beim Anzeigen der Historie ausgeben. Das offizielle Git Book dokumentiert git log --show-signature und den Pretty-Format-Platzhalter %G? zur Prüfung des Signaturstatus. Das Ergebnis sollte als eine Eingabe für eine Entscheidung verstanden werden, nicht als vollständige Sicherheitsprüfung.
Was eine Hosting-Plattform hinzufügt
Eine Hosting-Plattform kann einen Public Key einem Konto zuordnen, prüfen, ob die E-Mail-Adresse für dieses Konto zugelassen ist, und einen Status wie „Verified“ anzeigen. GitHub dokumentiert drei Signaturfamilien für Commits: GPG, SSH und S/MIME. Die Oberfläche ermöglicht außerdem, die Details hinter dem Status-Label anzusehen.
Diese Richtlinie auf Plattformebene ist nützlich, weil eine rohe Signatur normalerweise nicht den gesamten Kontext enthält, den ein Leser benötigt. Welches Konto darf den Schlüssel verwenden? Ist die E-Mail-Adresse bestätigt? Wird der Schlüssel noch akzeptiert? Wie behandelt die Plattform einen widerrufenen oder entfernten Schlüssel? Diese Fragen gehören zur Richtlinie der Plattform und des Prüfers, nicht allein zum Git-Object-Format.
Es gibt einen praktischen Unterschied zwischen „Die Signatur ist mathematisch gültig“ und „Dieser Host erkennt sie derzeit an“. Eine lokale Git-Installation kann den Public Key besitzen und die Signatur validieren, während die Hosting-Plattform keine passende Kontorichtlinie hat. Umgekehrt spiegelt ein Plattform-Badge die aktuellen Verifikationsregeln dieser Plattform wider; es ist kein universelles Zertifikat für jeden, der das Repository verwenden könnte.
Was „Verified“ nicht beweist
Eine gültige Signatur ist kein Code-Review. Der Commit kann einen Bug, einen unsicheren Standardwert, eine verwundbare Dependency oder eine Änderung enthalten, die die Anforderungen des Projekts nicht erfüllt. Der Reviewstatus muss aus dem Reviewprozess, geschützten Branches, Tests und den eigenen Annahmeregeln des Projekts hervorgehen.
Sie ist auch kein Beweis dafür, dass die angezeigte Person jede Zeile persönlich geschrieben hat. Git besitzt getrennte Felder für Author und Committer, und Workflows können Rebases, Cherry-Picks, Automatisierung oder Maintainer einschließen, die den Patch einer anderen Person anwenden. Eine Signatur kann zeigen, dass ein Schlüssel einen Commit signiert hat; die Deutung als persönliche Urheberschaft erfordert zusätzlichen Kontext.
Eine Signatur beweist außerdem nicht, dass der Schlüssel niemals kompromittiert wurde. Wenn ein Angreifer Zugriff auf einen privaten Schlüssel erhält, kann er möglicherweise gültige Signaturen erzeugen, bis die Kompromittierung entdeckt und der Schlüssel ersetzt oder widerrufen wird. Schutz, Wiederherstellung, Rotation und Kontosicherheit bleiben wichtig.
Schließlich beweist eine Commit-Signatur nicht, wie ein Release-Artefakt erzeugt wurde. Ein Package kann aus einem anderen Commit, mit anderen Dependencies, auf einem nicht vertrauenswürdigen oder schlecht kontrollierten Build-System erstellt worden sein. Der Weg vom Quelltext zum Artefakt braucht eigene Nachweise.
Drei leicht zu verwechselnde Kontrollen
Commit-Signatur
Sie beantwortet eine enge Frage: Kann die Signatur des Commits mit dem Public Key validiert werden, und erfüllt dieser Schlüssel die Vertrauensrichtlinie des Prüfers? Sie hilft, die Verbindung zwischen einem Schlüssel und einem bestimmten Git-Object zu schützen.
Developer Sign-off
Die Dokumentation für Beiträge zum Linux-Kernel beschreibt eine Zeile Signed-off-by: als Erklärung, dass der Beitragende die Arbeit erstellt hat, das Recht zur Einreichung besaß oder sie unter den genannten Bedingungen erhalten hat. Das ist eine Aussage im Projektprozess. Es ist nicht derselbe Mechanismus wie eine kryptografische Commit-Signatur, auch wenn beide das Wort „signed“ verwenden.
Build-Provenance
SLSA beschreibt Provenance als Informationen darüber, wie ein Artefakt erzeugt wurde. Die Anforderungen behandeln unter anderem die Authentizität der Provenance, die Identität der Build-Plattform und die Isolation zwischen Builds. Das ist eine andere Grenze als der Source-Commit. Ein vertrauenswürdiger Release-Prozess kann eine geprüfte Source-Revision mit einem bestimmten Artefakt verbinden, aber eine Commit-Signatur allein stellt diese Verbindung nicht her.
Ein angemessener Workflow für ein kleines Projekt
Ein kleines Projekt muss nicht sofort alle Kontrollen eines großen Softwareanbieters nachahmen. Es kann damit beginnen, die Fragen ausdrücklich zu machen:
- Festlegen, welche Schlüssel und Konten Änderungen signieren sollen.
- Signaturstatus und Schlüsselidentität prüfen, statt sich nur auf ein Badge zu verlassen.
- Den tatsächlichen Diff, Tests, Dependency-Änderungen und Release Notes prüfen.
- Wichtige Branches schützen, damit eine Signatur nicht die einzige Kontrolle rund um einen Merge ist.
- Für Releases die Source-Revision festhalten, aus der das Artefakt entstand, sowie den Ort des Builds.
- Planen, was bei Verlust, Kompromittierung oder Austausch eines Schlüssels geschieht.
Diese Schritte wirken weniger eindrucksvoll als ein grünes Label. Sie beantworten aber nützlichere Fragen: Wer war berechtigt, diese Änderung vorzunehmen? Was genau wurde geändert? Wurde sie geprüft? Kann die Datei, die Nutzer herunterladen, mit dem geprüften Source-Code verbunden werden? Eine Signatur hilft bei einigen dieser Fragen, aber nicht bei allen.
Fazit
Signierte Git-Commits sollte man am besten als Belege verstehen, nicht als Urteil. Sie können Integrität und Nachvollziehbarkeit einer Source-Historie stärken, wenn Schlüssel und Verifikationsrichtlinie sorgfältig verwaltet werden. Sie ersetzen kein Code-Review, keine Dependency-Analyse, keine Kontosicherheit, keinen Branch-Schutz und keine Build-Provenance.
Wenn ein Commit „Verified“ anzeigt, ist weder blindes Vertrauen noch vollständige Ablehnung die sinnvollste Reaktion. Frage, was verifiziert wurde, von wem, gegen welchen Schlüssel und was außerhalb dieser Aussage bleibt. Sicherheit wird klarer, wenn ein kleines Label nicht das Gewicht eines ganzen Prozesses tragen soll.