Nächste: , Vorige: , Nach oben: Kanäle   [Inhalt][Index]


7.9 Weitere Kanalautorisierungen angeben

Wie wir oben gesehen haben, wird durch Guix sichergestellt, dass von Kanälen geladener Code von autorisierten Entwicklern stammt. Als Kanalautor müssen Sie die Liste der autorisierten Entwickler in der Datei .guix-authorizations im Git-Repository des Kanals festlegen. Die Regeln für die Authentifizierung sind einfach: Jeder Commit muss mit einem Schlüssel signiert sein, der in der Datei .guix-authorizations seines bzw. seiner Elterncommits steht13 Die Datei .guix-authorizations sieht so aus:

;; Beispiel für eine '.guix-authorizations'-Datei.

(authorizations
 (version 0)               ;aktuelle Version des Dateiformats

 (("AD17 A21E F8AE D8F1 CC02  DBD9 F8AE D8F1 765C 61E3"
   (name "alice"))
  ("2A39 3FFF 68F4 EF7A 3D29  12AF 68F4 EF7A 22FB B2D5"
   (name "bob"))
  ("CABB A931 C0FF EEC6 900D  0CFB 090B 1199 3D9A EBB5"
   (name "charlie"))))

Auf jeden Fingerabdruck folgen optional Schlüssel-/Wert-Paare wie im obigen Beispiel. Derzeit werden diese Schlüssel-/Wert-Paare ignoriert.

Diese Authentifizierungsregel hat ein Henne-Ei-Problem zur Folge: Wie authentifizieren wir den ersten Commit? Und damit zusammenhängend: Was tun wir, wenn die Historie eines Kanal-Repositorys nicht signierte Commits enthält und eine .guix-authorizations-Datei fehlt? Und wie legen wir eine Abspaltung („Fork“) existierender Kanäle an?

Kanaleinführungen beantworten diese Fragen, indem sie den ersten Commit eines Kanals angeben, der authentifiziert werden soll. Das erste Mal, wenn ein Kanal durch guix pull oder guix time-machine geladen wird, wird nachgeschaut, was der einführende Commit ist und ob er mit dem angegebenen OpenPGP-Schlüssel signiert wurde. Von da an werden Commits gemäß obiger Regel authentifiziert. Damit die Authentifizierung erfolgreich ist, muss der Ziel-Commit entweder Nachkomme oder Vorgänger des einführenden Commits sein.

Außerdem muss Ihr Kanal alle OpenPGP-Schlüssel zur Verfügung stellen, die jemals in .guix-authorizations erwähnt wurden, gespeichert in Form von .key-Dateien, entweder als Binärdateien oder mit „ASCII-Hülle“. Nach Vorgabe wird nach diesen .key-Dateien im Branch namens keyring gesucht, aber Sie können wie hier einen anderen Branchnamen in .guix-channel angeben:

(channel
  (version 0)
  (keyring-reference "my-keyring-branch"))

Zusammenfassen haben Kanalautoren drei Dinge zu tun, damit Nutzer deren Code authentifizieren können:

  1. Exportieren Sie die OpenPGP-Schlüssel früherer und aktueller Committer mittels gpg --export und speichern Sie sie in .key-Dateien, nach Vorgabe gespeichert in einem Branch namens keyring (wir empfehlen, dass Sie diesen als einen verwaisten Branch, d.h. einen „Orphan Branch“, anlegen).
  2. Sie müssen eine anfängliche .guix-authorizations-Datei im Kanalrepository platzieren. Der Commit dazu muss signiert sein (siehe Commit-Zugriff für Informationen, wie Sie Git-Commits signieren).
  3. Sie müssen veröffentlichen, wie die Kanaleinführung aussieht, zum Beispiel auf der Webseite des Kanals. Die Kanaleinführung besteht, wie wir oben gesehen haben, aus einem Paar aus Commit und Schlüssel – für denjenigen Commit, der .guix-authorizations hinzugefügt hat, mit dem Fingerabdruck des OpenPGP-Schlüssels, mit dem er signiert wurde.

Bevor Sie auf Ihr öffentliches Git-Repository pushen, können Sie guix git-authenticate ausführen, um zu überprüfen, dass Sie alle Commits, die Sie pushen würden, mit einem autorisierten Schlüssel signiert haben:

guix git authenticate Commit Unterzeichner

Dabei sind Commit und Unterzeichner Ihre Kanaleinführung. Siehe guix git authenticate aufrufen für die Details.

Um einen signierten Kanal anzubieten, ist Disziplin vonnöten: Jeder Fehler, wie z.B. ein unsignierter Commit oder ein mit einem unautorisierten Schlüssel signierter Commit, verhindert, das Nutzer den Kanal benutzen können – naja, das ist ja auch der Zweck der Authentifizierung! Passen Sie besonders bei Merges auf: Merge-Commits werden dann und nur dann als authentisch angesehen, wenn sie mit einem Schlüssel aus der .guix-authorizations-Datei beider Branches signiert wurden.


Fußnoten

(13)

Git-Commits bilden einen gerichteten azyklischen Graphen (englisch „directed acyclic graph“, kurz DAG). Jeder Commit kann null oder mehr Eltern haben; in der Regel haben Commits einen Elterncommit, Mergecommits haben zwei. Lesen Sie Git for Computer Scientists für eine gelungene Übersicht.


Nächste: Primäre URL, Vorige: Kanalabhängigkeiten deklarieren, Nach oben: Kanäle   [Inhalt][Index]