Skip to main content

Informationen zur Verifizierung einer Commit-Signatur

Mithilfe von GPG, SSH oder S/MIME können Sie Tags und Commits lokal signieren. Diese Tags oder Commits werden auf GitHub Enterprise Cloud als überprüft gekennzeichnet, sodass andere Personen darauf vertrauen können, dass die Änderungen aus einer vertrauenswürdigen Quelle stammen.

Informationen zur Verifizierung einer Commit-Signatur

Du kannst Commits und Tags lokal signieren, um anderen Personen Sicherheit in Bezug auf den Ursprung einer vorgenommenen Änderung zu geben. Wenn ein Commit oder Tag eine GPG-, SSH- oder S/MIME-Signatur aufweist, die kryptografisch verifizierbar ist, markiert GitHub Enterprise Cloud den Commit oder das Tag als „Überprüft“ oder „Teilweise überprüft“.

Screenshot eines Commits in der Commitliste für ein Repository. „Überprüft“ ist orange umrandet.

Für die meisten Einzelbenutzer ist GPG oder SSH die beste Wahl, um Commits zu signieren. S/MIME-Signaturen werden normalerweise im Kontext einer größeren Organisation benötigt. SSH-Signaturen sind am einfachsten zu generieren. Du kannst sogar deinen vorhandenen Authentifizierungsschlüssel in GitHub Enterprise Cloud hochladen, um ihn auch als Signaturschlüssel zu verwenden. Das Generieren eines GPG Signaturschlüssels ist aufwändiger als das Generieren eines SSH-Schlüssels, aber GPG bietet Funktionen, die SSH nicht bereitstellt. Ein GPG-Schlüssel kann ablaufen oder widerrufen werden, wenn er nicht mehr verwendet wird. Die GPG-Signatur kann Informationen über das Ablaufen oder Widerrufen enthalten.

Je nachdem, ob du den wachsamen Modus aktiviert hast, weisen Commits und Tags die folgenden Überprüfungsstatus auf. Standardmäßig ist der wachsame Modus nicht aktiviert. Informationen zum Aktivieren des wachsamen Modus findest du unter Anzeigen von Überprüfungsstatus für alle deine Commits.

Das Signieren von Commits unterscheidet sich vom Abzeichnen eines Commits. Weitere Informationen zum Genehmigen von Commits findest du unter Verwalten der Richtlinie für das Abzeichnen von Commits für dein Repository.

Standardstatus

StatusBESCHREIBUNG
ÜberprüftDer Commit ist signiert, und die Signatur wurde erfolgreich überprüft.
Nicht überprüftDer Commit ist signiert, aber die Signatur konnte nicht überprüft werden.
Kein ÜberprüfungsstatusDer Commit ist nicht signiert.

Verifizieren einer persistenten Commitsignatur

Unabhängig von der Signaturauswahl – GPG, SSH oder S/MIME – bleibt diese nach dem Überprüfen einer Commitsignatur im Netzwerk des Repositorys in diesem Status. Weitere Informationen findest du unter Zusammenhänge zwischen Repositorys verstehen.

Beim Überprüfen einer Commitsignatur beim Pushen an GitHub Enterprise Cloud wird zusammen mit dem Commit ein Überprüfungseintrag gespeichert. Dieser Datensatz kann nicht bearbeitet werden und bleibt erhalten, sodass Signaturen überprüft bleiben, auch wenn Signaturschlüssel rotiert oder widerrufen werden oder wenn Mitwirkende die Organisation verlassen.

Im Überprüfungseintrag ist der Abschluss der Überprüfung mit einem Zeitstempel markiert. Dieser persistente Eintrag stellt einen konsistenten überprüften Zustand und einen durchgängigen Verlauf von Beiträgen innerhalb des Repositorys sicher. Du kannst diesen Zeitstempel anzeigen, indem zu mit dem Mauszeiger auf den Badge „Verified“ in GitHub Enterprise Cloud zeigst oder den Commit über die REST-API aufrufst, die das Feld verified_at enthält. Weitere Informationen findest du unter REST-API-Endpunkte für Commits.

Das Überprüfen der persistenten Commitsignatur gilt für neue Commits, die an GitHub Enterprise Cloud gepusht werden. Für alle dem Feature vorangegangenen Commits wird beim nächsten Überprüfen der Commitsignatur in GitHub Enterprise Cloud ein persistenter Eintrag erstellt. So kann sichergestellt werden, dass überprüfte Status im Repositoryverlauf stabil und verlässlich sind.

Einträge bleiben auch nach Widerrufen und Ablaufen erhalten.

Das Überprüfen einer persistenten Commitsignatur spiegelt den überprüften Status eines Commits zum Zeitpunkt der Überprüfung wider. Dies bedeutet, dass zuvor überprüfte Commits ihren überprüften Status beibehalten, der auf einem bei der ersten Überprüfung erstellten Eintrag basieren, auch wenn ein Signaturschlüssel später widerrufen wird, abläuft oder anderweitig geändert wird. GitHub Enterprise Cloud überprüft zuvor signierte Commits nicht erneut und passt deren Überprüfungsstatus auch nicht nachträglich an Änderungen am Schlüsselstatus an. Organisationen müssen Schlüsselstatus möglicherweise direkt verwalten, um sie an ihre Sicherheitsrichtlinien anzupassen – insbesondere dann, wenn häufige Schlüsselrotation oder häufiger Schlüsselwiderruf geplant sind.

Der Überprüfungseintrag ist auf sein Repositorynetzwerk beschränkt.

Der Überprüfungseintrag ist im Repositorynetzwerk persistent, d. h., wenn derselbe Commit erneut an dasselbe Repository oder an einen seiner Forks gepusht wird, wird der vorhandene Überprüfungseintrag wiederverwendet. Dadurch kann GitHub Enterprise Cloud in zusammenhängenden Repositorys einen konsistenten Überprüfungsstatus beibehalten, ohne den Commit jedes Mal wieder zu überprüfen, wenn er in einem Netzwerk angezeigt wird. Diese Persistenz verstärkt eine einheitliche und zuverlässige Sicht auf die Commitauthentizität in allen Instanzen des Commits innerhalb des Repositorynetzwerks.

Signaturüberprüfung für das Ausführen von Rebases und Mergevorgängen

Wenn du die Option Rebase und Merge für einen Pull Request verwendest, ist es wichtig zu wissen, dass die Commits im Headbranch ohne Überprüfung der Commitsignatur dem Basisbranch hinzugefügt werden. Wenn du diese Option verwendest, erstellt GitHub einen geänderten Commit unter Verwendung der Daten und des Inhalts des ursprünglichen Commits. Das bedeutet, dass GitHub diesen Commit nicht wirklich erstellt hat und ihn daher nicht als generischer Systembenutzer signieren kann. GitHub hat keinen Zugriff auf die privaten Signaturschlüssel des Committers und kann daher den Commit nicht im Auftrag des Benutzers signieren.

Ein Workaround dafür ist, dass du lokal einen Rebase- und Mergevorgang durchführst und die Änderungen dann in den Basisbranch des Pull Requests pushst.

Weitere Informationen finden Sie unter Informationen zu Merge-Methoden auf GitHub.

Status bei aktiviertem wachsamem Modus

StatusBESCHREIBUNG
ÜberprüftDer Commit ist signiert, die Signatur wurde erfolgreich überprüft und der Committer ist der einzige Autor, der den Wächtermodus aktiviert hat.
Teilweise  überprüftDer Commit ist signiert und die Signatur wurde erfolgreich überprüft, aber der Commit hat einen Autor, der a) nicht der Committer ist und b) den Wächtermodus aktiviert hat. In diesem Fall garantiert die Commitsignatur nicht die Zustimmung des Autors, daher wird der Commit nur teilweise verifiziert.
Nicht überprüftEine beliebige der folgenden Aussagen trifft zu:
– Der Commit ist signiert, aber die Signatur konnte nicht überprüft werden.
– Der Commit ist nicht signiert, und der Committer hat den Wächtermodus aktiviert.
– Der Commit ist nicht signiert, und ein Autor hat den Wächtermodus aktiviert.

Repository-Administratoren können die obligatorische Commit-Signatur auf einem Branch erzwingen, um alle Commits zu blockieren, die nicht signiert und verifiziert sind. Weitere Informationen finden Sie unter Informationen zu geschützten Branches.

Du kannst den Verifizierungsstatus deiner signierten Commits oder Tags auf GitHub Enterprise Cloud überprüfen und einsehen, warum deine Commit-Signaturen möglicherweise nicht verifiziert sind. Weitere Informationen findest du unter Verifizierungsstatus der Commit- und Tag-Signaturen.

GitHub verwendet GPG automatisch, um Commits zu signieren, die du über die Webschnittstelle vornimmst. Die von GitHub signierten Commits haben den Status „Überprüft“. Du kannst die Signatur mithilfe des öffentlichen Schlüssels, der unter https://github.com/web-flow.gpg verfügbar ist, lokal überprüfen.

Du kannst optional festlegen, dass GitHub in GitHub Codespaces durchgeführte Commits mit GPG signiert. Weitere Informationen zur GPG-Überprüfung für deine Codespaces-Instanz findest du unter Verwalten der GPG-Überprüfung für GitHub Codespaces.

GPG-Verifizierung einer Commit-Signatur

Du kannst GPG verwenden, um Commits mit einem GPG-Schlüssel zu signieren, den du selbst generierst.

GitHub Enterprise Cloud verwendet OpenPGP-Bibliotheken, um zu bestätigen, dass deine lokal signierten Commits und Tags kryptographisch mit einem öffentlichen Schlüssel verifizierbar sind, den du deinem Konto auf GitHub.com hinzugefügt hast.

Um Commits mit GPG zu signieren und diese Commits auf GitHub Enterprise Cloud verifizieren zu lassen, führe die folgenden Schritte aus:

  1. Nach vorhandenen GPG-Schlüsseln suchen
  2. Einen neuen GPG-Schlüssel generieren
  3. Hinzufügen eines GPG-Schlüssels zu deinem GitHub-Konto
  4. Git über den Signaturschlüssel informieren
  5. Commits signieren
  6. Tags signieren

SSH-Verifizierung einer Commitsignatur

Du kannst SSH verwenden, um Commits mit einem SSH-Schlüssel zu signieren, den du selbst generierst. Weitere Informationen findest du in der Git-Referenzdokumentation zu user.Signingkey. Wenn du bereits einen SSH-Schlüssel verwendest, um dich bei GitHub Enterprise Cloud zu authentifizieren, kannst du diesen Schlüssel erneut hochladen, um ihn auch als Signaturschlüssel zu verwenden. Es gibt keine Begrenzung für die Anzahl von Signaturschlüsseln, die du zu deinem Konto hinzufügen kannst.

GitHub Enterprise Cloud verwendet ssh_data, eine Open-Source-Ruby-Bibliothek, um zu bestätigen, dass deine lokal signierten Commits und Tags kryptografisch mit einem öffentlichen Schlüssel verifizierbar sind, den du deinem Konto auf GitHub.com hinzugefügt hast.

Note

Die SSH-Signaturüberprüfung ist in Git 2.34 oder höher verfügbar. Informationen zum Aktualisieren deiner Version von Git findest du auf der Git-Website.

Führe die folgenden Schritte aus, um Commits mit SSH zu signieren und diese Commits auf GitHub Enterprise Cloud zu verifizieren:

  1. Suche nach vorhandenen SSH-Schlüsseln
  2. Generieren eines neuen SSH-Schlüssels
  3. Hinzufügen eines SSH-Schlüssels zu deinem GitHub-Konto
  4. Git über den Signaturschlüssel informieren
  5. Commits signieren
  6. Tags signieren

S/MIME-Verifizierung einer Commit-Signatur

Du kannst S/MIME verwenden, um Commits mit einem von deiner Organisation ausgegebenen X.509-Schlüssel zu signieren.

GitHub Enterprise Cloud verwendet das Debian-CA-Zertifikatpaket, denselben Trust Store, der auch von Mozilla-Browsern verwendet wird, um zu bestätigen, dass deine lokal signierten Commits und Tags kryptographisch mit einem öffentlichen Schlüssel in einem vertrauenswürdigen Stammzertifikat überprüft werden können.

Note

Die S/MIME-Signaturüberprüfung ist in Git 2.19 oder höher verfügbar. Informationen zum Aktualisieren deiner Version von Git findest du auf der Git-Website.

Um Commits mit S/MIME zu signieren und diese Commits auf GitHub Enterprise Cloud verifizieren zu lassen, führe die folgenden Schritte aus:

  1. Git über den Signaturschlüssel informieren
  2. Commits signieren
  3. Tags signieren

Du musst deinen öffentlichen Schlüssel nicht auf GitHub Enterprise Cloud hochladen.

Signaturverifizierung für Bots

Organisationen und GitHub Apps, bei denen Commit-Signaturen vorgeschrieben sind, können Bots für das Signieren von Commits verwenden. Wenn ein Commit oder Tag eine Bot-Signatur hat, die kryptografisch verifiziert werden kann, wird der Commit oder das Tag von GitHub Enterprise Cloud als verifiziert gekennzeichnet.

Die Signaturverifizierung für Bots funktioniert nur, wenn die Anforderung als GitHub App oder Bot verifiziert und authentifiziert ist und keine benutzerdefinierten Informationen zum Autor, zum Beitragenden oder zur Signatur aufweist, also z. B. keine Commits-API.

Weiterführende Themen