Nächste: Primäre URL, Vorige: Kanalabhängigkeiten deklarieren, Nach oben: Kanäle [Inhalt][Index]
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:
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).
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.
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]