Suivant: URL primaire, Précédent: Déclarer des dépendances de canaux, Monter: Canaux [Table des matières][Index]
Comme nous l’avons vu plus haut, Guix garantit le code source qu’il récupère depuis les canaux venant de développeur·euses autorisé·es. En tant qu’auteur·e, vous devez spécifiez la liste des développeur·euses autorisé·es dans le fichier .guix-authorizations dans le dépôt Git des canaux. Le rôle de l’authentification est simple : chaque commit doit être signé par une clé listée dans le fichier .guix-authorizations de son (ses) commit(s) parent(s)13 Le fichier .guix-authorizations ressemble à ceci :
;; Fichier d'exemple '.guix-authorizations'. (authorizations (version 0) ;version actuelle du format de fichier (("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"))))
Chaque empreinte digitale est suivie de paires de clés/valeurs facultatives, comme dans l’exemple ci-dessus. Actuellement, ces paires clé/valeur sont ignorées.
Ce rôle d’authentification crée un problème de poule et d’œuf : comment authentifions-nous le premier commit ? Par rapport à cela : comment traiter les canaux dont l’historique du dépôt contient des commits non signés et qui n’ont pas de.guix-authorisations ? Et comment bifurquer des canaux existants ?
L’introduction des canaux répondent à ces questions en décrivant le premier
commit d’un canal qui doit être authentifiée. La première fois qu’un canal
est récupéré avec guix pull
ou guix time-machine
, la
commande recherche le commit d’introduction et vérifie qu’il est signé par
la clé OpenPGP spécifiée. Elle authentifie ensuite les commits selon la
règle ci-dessus. L’authentification échoue si le commit cible n’est ni un
descendant ni un ancêtre du commit d’introduction.
De plus, votre canal doit fournir toutes les clés OpenPGP qui ont été
mentionnées dans les fichiers .guix-authorizations, stockés dans les
fichiers .key, qui peuvent être soit binaires soit "blindés ASCII".
Par défaut, ces fichiers .key sont recherchés dans la branche nommée
keyring
, mais vous pouvez spécifier un nom de branche différent dans
.guix-channel
de cette façon :
(channel
(version 0)
(keyring-reference "my-keyring-branch"))
En résumé, en tant qu’auteur.e d’une chaîne, il y a trois choses que vous devez faire pour permettre aux utilisateur·rice·s d’authentifier votre code :
gpg -export
et les stocker dans des fichiers .key, par
défaut dans une branche nommée keyring
(nous recommandons d’en faire
une branche orpheline).
Before pushing to your public Git repository, you can run guix git
authenticate
to verify that you did sign all the commits you are about to
push with an authorized key:
guix git authenticate commit signer
où commit et signer sont votre présentation de canal.
Voir Invoquer guix git authenticate
, pour plus de détails.
Publier un canal signé demande de la discipline : toute faute, comme un commit non signé ou un commit signée par une clé non autorisée, vont empêcher les utilisateur·rice·s de récupérer depuis votre canal—bref, c’est tout l’intérêt de l’authentification ! Faites particulièrement attention aux merges : les merge commits sont considérés comme authentiques si et seulement s’ils sont signés par une clé présente dans le fichier .guix-authorizations des branches both.
Les commits de Git forment un graphe acyclique orienté (DAG en anglais). Chaque commit peut avoir zéro ou plusieurs parents ; les commits « usuels » ont un seul parent et les commits de fusion ont deux parents. Lisez Git for Computer Scientists pour une bonne vue d’ensemble.
Suivant: URL primaire, Précédent: Déclarer des dépendances de canaux, Monter: Canaux [Table des matières][Index]