it-swarm.com.de

Signierte Git-Commits überprüfen?

Mit neueren Versionen von git ist es möglich, einzelne Commits (zusätzlich zu Tags) mit einem PGP-Schlüssel zu signieren:

git commit -m "some message" -S

Und Sie können diese Signaturen in der Ausgabe von git log Mit der Option --show-signature Anzeigen:

$ git log --show-signature
commit 93bd0a7529ef347f8dbca7efde43f7e99ab89515
gpg: Signature made Fri 28 Jun 2013 02:28:41 PM EDT using RSA key ID AC1964A8
gpg: Good signature from "Lars Kellogg-Stedman <[email protected]>"
Author: Lars Kellogg-Stedman <[email protected]>
Date:   Fri Jun 28 14:28:41 2013 -0400

    this is a test

Aber gibt es eine andere Möglichkeit, die Signatur eines bestimmten Commits programmgesteuert zu überprüfen, als die Ausgabe von git log Abzufragen? Ich suche nach dem Commit-Äquivalent von git tag -v - etwas, das einen Exit-Code liefert, der angibt, ob für ein bestimmtes Commit eine gültige Signatur vorhanden war oder nicht.

80
larsks

Nur für den Fall, dass jemand über eine Suchmaschine auf diese Seite gelangt, wie ich es getan habe: In den zwei Jahren seit der Veröffentlichung der Frage wurden neue Tools zur Verfügung gestellt: Es gibt jetzt git-Befehle für diese Aufgabe: git verify-commit und git verify-tag kann verwendet werden, um Commits bzw. Tags zu überprüfen.

83
tarleb

Hinweis: bis GIT 2.5 haben git verify-commit und git verify-tag nur eine für Menschen lesbare Nachricht angezeigt.
Wenn Sie die Prüfung automatisieren möchten, fügt Git 2.6+ (Q3 2015) eine weitere Ausgabe hinzu.

Siehe Festschreiben von e18443e , Festschreiben von aeff29d , Festschreiben von ca194d5 , Festschreiben von 434060e , Festschreiben von 8e98e5f , commit a4cc18f , commit d66aeff (21. Juni 2015) von brian m. carlson (bk2204 .
(Zusammengeführt von Junio ​​C Hamano - gitster - in Festschreiben ba12cb2 , 3. August 2015)

verify-tag/verify-commit: Option zum Drucken von Roh-GPG-Statusinformationen hinzufügen

verify-tag/verify-commit Zeigt standardmäßig eine lesbare Ausgabe bei Standardfehlern an.
Es kann jedoch auch nützlich sein, auf die rohen gpg-Statusinformationen zuzugreifen, die maschinenlesbar sind und eine automatisierte Implementierung der Signaturrichtlinie ermöglichen .

Fügen Sie eine --raw - Option hinzu, damit verify-tag Die GPG-Statusinformationen bei Standardfehlern anstelle des von Menschen lesbaren Formats erzeugt .

Plus:

verify-tag Wird erfolgreich beendet, wenn die Signatur korrekt ist, der Schlüssel jedoch nicht vertrauenswürdig ist. verify-commit Wird nicht erfolgreich beendet.
Diese Verhaltensdivergenz ist unerwartet und unerwünscht.
Da verify-tag Früher existierte, fügen Sie einen fehlgeschlagenen Test hinzu, damit verify-commit Das Verhalten von verify-tag Teilt.


git 2.9 (Juni 2016) aktualisiert das git merge doc :

Siehe commit 05a5869 (13. Mai 2016) von Keller Fuchs (``) .
Geholfen von: Junio ​​C Hamano (gitster) .
(Zusammengeführt von Junio ​​C Hamano - gitster - in commit be6ec17 , 17. Mai 2016)

--verify-signatures:
--no-verify-signatures:

Stellen Sie sicher, dass das Tip-Commit des zusammenzuführenden Nebenzweigs mit einem gültigen Schlüssel signiert ist, dh einem Schlüssel mit einer gültigen UID: Im Standardvertrauensmodell bedeutet dies, dass der Signaturschlüssel signiert wurde durch einen vertrauenswürdigen Schlüssel.
Wenn das Tip-Commit des Nebenzweigs nicht mit einem gültigen Schlüssel signiert ist, wird die Zusammenführung abgebrochen
.


Update Git 2.10 (3. Quartal 2016)

Siehe commit b624a3e (16. August 2016) von Linus Torvalds (torvalds) .
(Zusammengeführt von Junio ​​C Hamano - gitster - in commit 83d9eb , 19. August 2016)

gpg-interface: Bevorzugen Sie die Ausgabe im "langen" Schlüsselformat, wenn Sie PGP-Signaturen überprüfen

"git log --show-signature" Und andere Befehle, die den Überprüfungsstatus der PGP-Signatur anzeigen, zeigen jetzt die längere Schlüssel-ID an, da die 32-Bit-Schlüssel-ID das letzte Jahrhundert ist.

Linus 'Original wurde für den Fall, dass Binärdistributoren, die in der Vergangenheit stecken geblieben sind, es auf ihre ältere Codebasis übertragen möchten, neu auf die Wartungsspur angewendet.


Git 2.11+ (Q4 2016) wird noch präziser.

Siehe commit 661a18 (12. Oktober 2016) von Michael J Gruber (mjg) .
(Zusammengeführt von Junio ​​C Hamano - gitster - in Festschreiben 56d268b , 26. Oktober 2016)

Der in der hübschen Formatangabe "%G?" Angezeigte GPG-Überprüfungsstatus war nicht reich genug, um zwischen einer Signatur eines abgelaufenen Schlüssels, einer Signatur eines widerrufenen Schlüssels usw. zu unterscheiden.
Neue Ausgabebuchstaben wurden zugewiesen, um sie auszudrücken .

Nach gpg2's doc/DETAILS :

Für jede Signatur wird nur einer der Codes GOODSIG, BADSIG, EXPSIG, EXPKEYSIG, REVKEYSIG oder ERRSIG verwendet emittiert werden.

Die git pretty-format Dokumentation beinhaltet nun:

  • '%G?': Zeige
    • "G" für eine gute (gültige) Signatur,
    • "B" für eine schlechte Signatur,
    • "U" für eine gute Signatur mit unbekannter Gültigkeit,
    • "X" für eine gute Signatur, die abgelaufen ist,
    • "Y" für eine gute Signatur eines abgelaufenen Schlüssels,
    • "R" für eine gute Signatur durch einen widerrufenen Schlüssel,
    • "E", wenn die Signatur nicht geprüft werden kann (z. B. fehlender Schlüssel), und "N", wenn keine Signatur vorliegt

Git 2.12 (Q1 2017) "git tag" Und "git verify-tag" haben gelernt, den GPG-Überprüfungsstatus in ihr Ausgabeformat "--format=<placeholders>" Zu setzen .

Siehe commit 4fea72f , commit 02c54 , commit ff3c8c8 (17. Januar 2017) von Santiago Torres (SantiagoTorres) .
Siehe Festschreiben 07d347c , Festschreiben 2111aa7 , Festschreiben 94240b9 (17. Januar 2017) von Lukas Pühringer (`` ) .
(Zusammengeführt von Junio ​​C Hamano - gitster - in Commit 237bdd9 , 31. Januar 2017)

Durch Hinzufügen von --format Zu git tag -v Wird die Standardausgabe der GPG-Überprüfung stummgeschaltet und stattdessen das formatierte Tag-Objekt gedruckt.
Auf diese Weise können Anrufer bei der GPG-Überprüfung den Tag-Namen von Verweisen/Tags mit dem Tag-Namen aus dem Tag-Objekt-Header abgleichen.


Mit Git 2.16 (Q1 2018) kann die Überprüfung der Commit-Signatur mit der Konfigurationsvariablen merge.verifySignatures Noch automatisiert werden.

Siehe commit 7f8ca2 , commit ca779e8 (10. Dezember 2017) von Hans Jerry Illikainen (``) .
(Zusammengeführt von Junio ​​C Hamano - gitster - in Festschreiben 0433d5 , 28. Dezember 2017)

merge: Konfigurationsoption für verifySignatures hinzufügen

git merge --verify-signatures Kann verwendet werden, um zu überprüfen, ob das Tip-Commit des Zweigs, in dem das Mergen ausgeführt wird, ordnungsgemäß signiert ist. Es ist jedoch umständlich, dies jedes Mal anzugeben.

Fügen Sie eine Konfigurationsoption hinzu, die dieses Verhalten standardmäßig aktiviert und durch --no-verify-signatures Überschrieben werden kann.

Die Manpage git merge Config lautet nun:

merge.verifySignatures:

Wenn true, entspricht dies der Befehlszeilenoption --verify-signatures.


Git 2.19 (Q3 2018) ist sogar noch hilfreicher, da "git verify-tag" Und "git verify-commit" Gelehrt wurden, den Exit-Status des zugrunde liegenden "gpg --verify" Als Signal für fehlerhaft zu verwenden oder nicht vertrauenswürdige Unterschrift, die sie gefunden haben.

Hinweis: Mit Git 2.19 kann gpg.format Auf "openpgp" oder "x509" Gesetzt werden, und gpg.<format>.program Wird verwendet, um Geben Sie an, welches Programm für das Format verwendet werden soll.) Damit können X.509-Zertifikate mit CMS über "gpgsm" anstelle von openpgp über "gnupg" verwendet werden.

Siehe commit 4e5dc9c (09. August 2018) von Junio ​​C Hamano (gitster) .
Geholfen von: Vojtech Myslivec (VojtechMyslivec) , brian m. Carlson (bk2204) und - Jeff King (peff) .
(Zusammengeführt von Junio ​​C Hamano - gitster - in Commit 4d34122 , 20. August 2018)

gpg-interface: Weitergabe des Exit-Status von gpg an die Anrufer

Als gpg-interface API Mitte 2015 die Unterstützung für Signaturüberprüfungscodepfade für signierte Tags und signierte Commits vereinheitlichte, wurde die GPG-Signaturüberprüfung versehentlich gelockert.

Vor dieser Änderung wurden signierte Commits überprüft, indem in GPG nach einer guten Signatur "G" gesucht und der Beendigungsstatus des Prozesses "gpg --verify" Ignoriert wurde, während signierte Tags durch einfaches Übergeben des Beendigungsprozesses überprüft wurden Status von "gpg --verify "bis.

Der vereinheitlichte Code, den wir derzeit haben, ignoriert den Exit-Status von "gpg --verify" Und gibt eine erfolgreiche Überprüfung zurück, wenn die Signatur mit einem nicht abgelaufenen Schlüssel übereinstimmt, unabhängig von der Vertrauenswürdigkeit des Schlüssels (dh zusätzlich zu "G "ood ones, wir akzeptieren" U "ntrusted ones).

Diese Befehle signalisieren einen Fehler mit ihrem Exit-Status, wenn dies unter "gpg --verify" (Oder dem durch die Konfigurationsvariable "gpg.program" Angegebenen benutzerdefinierten Befehl) der Fall ist.
Dadurch wird ihr Verhalten im Wesentlichen in einer abwärtskompatiblen Weise geändert, sodass Signaturen, die mit nicht vertrauenswürdigen Schlüsseln erstellt wurden, zurückgewiesen werden, auch wenn sie korrekt überprüft wurden. So verhält sich "gpg --verify".

Beachten Sie, dass der Code weiterhin einen Null-Exit-Status überschreibt, der von "gpg" (oder gpg.program) Erhalten wurde, wenn die Ausgabe nicht besagt, dass die Signatur gut ist oder korrekt berechnet wurde, aber mit nicht vertrauenswürdigen Schlüsseln erstellt wurde, um zu fangen Ein schlecht geschriebener Wrapper um "gpg", den der Benutzer uns geben kann.

Wir könnten die "U" - Unterstützung von diesem Fallback-Code ausschließen, aber das würde zwei inkompatible Änderungen in einem einzigen Commit bewirken. Lassen Sie uns dies vorerst vermeiden.
Eine nachträgliche Änderung könnte dies auf Wunsch tun.

26
VonC

Eine flüchtige Überprüfung des Codes legt nahe, dass es keine solche direkte Methode gibt.

Alle Tests in der Git-Quelle basieren auf grepping der Ausgabe von git show (Siehe t/t7510-signed-commit.sh für die Tests).

Sie können die Ausgabe mit etwas wie --pretty "%H %G?%" Anpassen, um das Parsen zu vereinfachen.

Anscheinend können Sie git merge Bitten, eine Signatur zu verifizieren. Die Tests basieren jedoch auf grep (siehe t/t7612-merge-verify-signatures.sh ). Es sieht so aus, als würde eine ungültige Signatur dazu führen, dass git merge Mit einer falschen Signatur beendet wird. Sie könnten sich also heute möglicherweise darum kümmern, indem Sie irgendwo eine Testzusammenführung durchführen und diese Zusammenführung verwerfen, aber das scheint schlimmer, als nur grep aufzurufen.

4
Emil Sit