Drücke "Enter", um den Text zu überspringen.

Github Commits in Visual Studio automatisch signieren

Eine gute Idee bei der Arbeit mit Git ist es generell immer, seine eigenen Commits zu signieren. Solche signierten Commits werden anschließend auf Github als Verified angezeigt. Wer sich damit bisher nicht beschäftigt hatte, kann das zumindest dann sehen, wenn er ein Repository direkt auf Github erzeugt.

Anzeige eines verifizierten Commits auf Github

Sinn einer Commit-Signatur

Natürlich geht der Sinn einer Signierung über das bloße Github-Eyecandy hinaus. Die digitale Signatur dient hauptsächlich zwei wichtigen Zwecken:

  • Sicherstellung der Entwickler-Identität
    Theoretisch ist es bei einem Commit möglich, für den Autor einen beliebigen Namen des Entwicklers und eine beliebige E-Mail-Adresse anzugeben. Die digitale Signatur eines Nutzers lässt sich hingegen kaum fälschen.
  • Sicherstellung der Commit-Integrität
    Ebenfalls lässt sich über die Signierung eines Commits sicherstellen, dass dieser nach der Signierung – in der Regel also während der Übertragung an ein Repository – nicht bösartig verändert wurde.

Funktionsweise einer Commit-Signatur in Git

Git verwendet für die Signierung von Commits das Tool GPG, das plattformübergreifend zur Verfügung steht. GPG nutzt ein asymmetrisches Public-Key-Verfahren (OpenPGP) zur Erzeugung einer Signatur. Bei diesem Verfahren besitzt der Entwickler einen privaten (also nur dem Entwickler bekannten) und einen öffentlichen (Theoretisch jedermann bekannten) Schlüssel für die Verschlüsselung.

Soll ein Commit nun signiert werden, so wird für den Git-Commit ein Hash erzeugt. Unter Verwendung des privaten Schlüssels des Entwicklers wird dieser Hash verschlüsselt und so eine eindeutige Signatur dieses Commits erzeugt.

Um die Gültigkeit der Signatur zu prüfen kann nun eine beliebige andere Stelle diese Signatur unter Verwendung des öffentlichen Schlüssels des Entwicklers diese Signatur entschlüsseln und prüfen, ob der so entschlüsselte Hash mit dem Hash des Commits übereinstimmt.

Erstellen des GPG-Schlüsselpaars für die Signierung der Commits

Obigem Kochrezept folgend benötigen wir logischerweise zunächst einen privaten und einen öffentlichen Schlüssel. Glücklicherweise gibt es mit Gpg4win bereits eine Lösung für Windows, die den Großteil der Arbeit abnehmen kann. Zunächst muss dieses Tool also installiert werden.

Mitinstalliert wird der Zertifikatsmanager Kleopatra, über den sich einfach neue Schlüsselpaare erstellen und in der Folge auch verwalten lassen. So behält man auch gleich den Überblick, falls man mehrere Schlüselpaare verwenden möchte.

Für die Erzeugung eines Schlüsselpaars wird also Kleopatra gestartet. Mittels STRG+N (Oder Datei > Neues Schlüsselpaar…) kann man sich nun ein Schlüsselpaar erzeugen. Es startet der Erstellungs-Assistent von Kleopatra, der sogleich zur Auswahl eines Formats auffordert. Für die Signierung der Commits benötigen wir ein GPG-Schlüsselpaar und wählen also die Option Persönliches OpenPGP-Schlüsselpaar erstellen.

Kleopatra wird nun nach Namen und E-Mail-Adresse fragen, die wir hier entsprechend eintragen sollten. Bevor es weitergeht, öffnen wir zudem die Erweiterten Einstellungen über den entsprechenden Button. Laut Github benötigen wir mindestens eine Schlüssellänge von 4096 Bit. Dementsprechend stellen wir dies also in Kleopatra ein. Wichtig ist zudem, dass unter Verwendung des Zertifikats ein Haken bei Signieren gesetzt ist.

Einstellungen für das Erstellen eines GPG-Schlüsselpaars mit Kleopatra

Nach einem Klick auf Weiter können wir dann nochmal eine Prüfung der Einstellungen vornehmen und per weiterem Klick auf Erstellen mit der Erstellung des Schlüsselpaars loslegen. Kleopatra verlangt nun eine sichere Passphrase, also ein Passwort, das zum Schutz des privaten Schlüssels dient. Hier sollte ein sehr sicheres Passwort verwendet werden – Mindestanforderung sollte also eine bis zum 100% gefüllte Sicherheits-Statusanzeige sein. Da diese Passphrase bald beim Commit benötigt wird, sollte sie auch gut merkbar oder in einem Passwort-Manager sicher gespeichert werden. Anschließend wird das Schlüsselpaar erstellt und ist ab da bereit zur Verwendung. Ein Klick auf Abschließen bringt uns wieder zurück zur Hauptoberfläche von Kleopatra, in der nun das neu erzeugte Schlüsselpaar aufgelistet ist.

Automatisches Signieren von GitHub-Commits

Nun wäre es natürlich am bequemsten, wenn beim Commit automatisch eine Signierung des Commits erfolgen würde. Das haben sich vermutlich auch die Entwickler von GitHub gedacht, denn diese Möglichkeit besteht natürlich. Nötig sind lediglich einige Einstellungen in Git. Beim Arbeiten mit Visual Studio lassen sich diese Einstellungen recht einfach über die Paket-Manager-Konsole treffen (Extras > NuGet-Paket-Manager > Paket-Manager-Konsole).

Die Einstellungen lassen sich sowohl global, als auch lokal für das einzelne Repository treffen. Arbeitet man stets mit demselben GitHub-Nutzer, empfiehlt sich die globale Einstellung – Die Schlüssel werden nicht pro Repository verwaltet, sondern pro Nutzer. Wer lieber nur für ein einzelnes Repository die Einstellungen treffen will, lässt in unten stehenden Befehlen jeweils das –global weg.

Wir legen zunächst den Gpg4win-Client als GPG-Programm in Git fest:

git config --global gpg.program gpg

Dann schalten wir das automatische Signieren von Commits ein:

git config --global commit.gpgsign true

Nun müssen wir in Git nur noch den Fingerabdruck hinterlegen, über den das verwendete GPG-Schlüsselpaar identifiziert wird. Dieser lässt sich in Kleopatra auslesen (Rechtsklick > Details > Fingerabdruck). Für das Kopieren des Fingerabdrucks kann man abgekürzt einfach einen Rechtsklick auf das Schlüsselpaar in Kleopatra ausführen und Exportieren… wählen. Der Dateiname für das Exportieren ist zugleich der Fingerabdruck.

Diesen Fingerabdruck muss man nur noch in Git hinterlegen. Dazu unten im Befehl das [FINGERABDRUCK] durch den echten Fingerabdruck ersetzen und die eckigen Klammern natürlich weg lassen. Kleine Anekdote: Bei meinem ersten Mal habe ich die Option prompt falsch geschrieben und das zweite ‚g‘ in signingkey vergessen… Glücklicherweise war ich nach halbstündiger Recherche nicht der einzige mit Brett vor dem Kopf 😉

git config --global user.signingkey [FINGERABDRUCK]

Das wars auch schon. Führen wir nun einen Commit über Git aus, so werden wir ab sofort zur Eingabe der Passphrase aufgefordert, die für Verwendung des privaten Schlüssels benötigt wird (Diese haben wir oben in Kleopatra bei Erstellung des Schlüsselpaars eingegeben). Hier nochmal eine Übersicht einer beispielhaften Git-Konfiguration:

Beispielkonfiguration von Git für automatisches Signieren von Commits

GPG-Schlüssel in GitHub hinterlegen

Nun werden unsere Commits also ordnungsgemäß signiert und jeder kann prüfen, dass wir wirklich Autor eines solchen Commits sind, wenn er unseren öffentlichen GPG-Schlüssel besitzt. Das trifft natürlich auch auf Github zu. Aber Moment – wie kommt GitHub denn nun zu dem öffentlichen Schlüssel?

Nun, dieser kann direkt mit dem Profil eines GitHub-Benutzers verknüpft werden. Hierzu muss man sich zunächst in Github einloggen. Durch einen Klick auf den persönlichen Avatar ganz oben rechts und einen weiteren Klick auf Settings kommt man in die Profileinstellungen. Hier gibt es nun links einen Punkt SSH and GPG keys, unter dem solche öffentlichen Schlüssel hinterlegt werden können.

An den öffentlichen Schlüssel gelangen wir wiederum über unsere neue Freundin Kleopatra: Einfach per Rechtsklick auf das gewünschte Schlüsselpaar und einen Klick auf Details. Dort gibt es dann einen Button mit der Aufschrift Exportieren… Den dort angezeigten Text kann man komplett kopieren. Anschließend klickt man in GitHub auf den Button New GPG key und fügt im erscheinenden Textfeld den kopierten Text komplett ein und bestätigt mit einem Klick auf Add GPG key. Man wird nun nach seinem GitHub-Passwort gefragt, das man zur Bestätigung eingeben kann. Ab sofort wird GitHub mit diesem Schlüssel signierte Commits als Verified anzeigen!

Auflistung der GPG-Keys in GitHub

Quellen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert