7.9 Spécifier les autorisations des canaux

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)¹³ 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 :

1. Exporter les clés OpenPGP des committers passés et présents avec 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).
2. Introduisez un fichier .guix-authorisations initial dans le dépôt du canal. Faites cela dans un commit signé (voir Accès en commit, pour savoir comment signer les commit Git).
3. Annoncez l’introduction du canal, par exemple sur la page web de votre canal. L’introduction du canal, comme nous l’avons vu ci-dessus, est la paire de clés commit—c’est-à-dire le commit qui a introduit .guix-authorizations, et l’empreinte digitale de l’OpenPGP utilisé pour le signer.

Avant de pousser vers votre dépôt Git public, vous pouvez lancer guix git-authenticate pour vérifier que vous avez bien signé tous les commits que vous allez pousser avec une clé autorisée :

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.