Apt : ajout correct d'une clé GPG

Informations

Depuis 2020, ajouter une clé GPG pour les dépôts utilisés par apt ne doit plus se faire par le biais de la commande apt-key ; celle-ci est déclaré obsolète ET ne doit plus être utilisée !

Lire le manpage : man 8 apt-key et tout particulièrement la section « DEPRECATION ».

Then you can directly replace this with (though note the recommendation below):

   wget -qO- https://myrepo.example/myrepo.asc | sudo tee /etc/apt/trusted.gpg.d/myrepo.asc

   Make sure to use the "asc" extension for ASCII armored keys and the "gpg" extension for the binary OpenPGP format (also known as "GPG key public ring"). The binary OpenPGP format works for all apt versions, while the ASCII
   armored format works for apt version >= 1.4.

   Recommended: Instead of placing keys into the /etc/apt/trusted.gpg.d directory, you can place them anywhere on your filesystem by using the Signed-By option in your sources.list and pointing to the filename of the key. See
   sources.list(5) for details. Since APT 2.4, /etc/apt/keyrings is provided as the recommended location for keys not managed by packages. When using a deb822-style sources.list, and with apt version >= 2.4, the Signed-By option
   can also be used to include the full ASCII armored keyring directly in the sources.list without an additional file.

Pour information, avec Debian 11, apt est en version 2.2.4 ! La version de Test - actuellement nommée « bookworm » et Sid, sont en version 2.5.
La recommandation de placer les clés non officielles dans le répertoire ‹ /etc/apt/keyrings/ › est valable donc pour la version de Test, pour Sid, et le sera dans la future version 12, puisque l’outil apt est en version 2.4 et l’utilisation de fichiers *.sources (donc au format Deb822).


Explications pratiques

En francais, en pratique, cela nous donne quoi ?!

  1. En ligne de commande, je récupère la clé GPG (ou le fichier .asc) du projet concerné :
wget -qO- https://url-projet.tld/fichier-cle.gpg | gpg --dearmor | sudo tee /répertoire/nom-projet.fichier.gpg

/répertoire/ peut-être :

  • le répertoire personnel $HOME
  • officiellement /etc/apt/keyrings/
  • /usr/local/keyrings/ : répertoire par défaut des clés GPG « embarquées » officiellement dans Debian
  • /usr/local/share/keyrings/ : le choix que nous recommandons, nécessitant d’abord la création de ce répertoire inexistant par défaut.
  1. édition « historique » du sources.list :
# apt edit-sources nom-projet

On y ajoute l’information correcte relative à l’URL du dépôt du projet, tel que :

deb [signed-by=/usr/local/share/keyrings/nom-projet.fichier.gpg] url-depot-projet nom-suite composantes

Exemple pour le projet « Element » :

deb [signed-by=/usr/local/share/keyrings/element.gpg] https://packages.riot.im/debian/ default main
  1. je mets à jour mon système puis j’installe le binaire :
# apt update
# apt install nom-binaire-relatif-projet

Voilà pour les informations pratiques nécessaires, ni plus, ni moins.

Retrouvez ci-dessous un script pour faciliter l’installation et des explications complémentaires :


Script de Gestion des clés

Voici une manière pour ajouter la clé GPG de tout projet tiers, qui ne fournit pas correctement ces clés :

  1. Créer le script suivant ayant pour nom « add-apt-key.sh » :
#!/bin/sh

dir_keys="/usr/local/share/keyrings"
name=""
url=""

read -p "Quel est le nom du projet ? " name
read -p "Où est l'URL de la clé GPG (à ajouter pour l'outil apt) ? " url

# creation du repertoire local de clés
[ ! -d "${dir_keyrs}" ] && mkdir -p "${dir_keys}"

# recupération de la clé du projet 
curl -fsSL "${url}" | gpg --dearmor | tee "${dir_keys}/${name}.gpg" > /dev/null

status="$?"

if [ "${status}" -eq 0 ]; then 
	printf '%s : %s\n' "OK" "La clé GPG pour le projet '${name}' a bien été ajoutée."
else
	printf '%s : %s\n' "KO" "Il semble y avoir un soucis pour ajouter la clé GPG du projet '${name}' !"

fi

  1. lien vers le répertoire personnel ~/bin :
$ chmod 0700 $HOME/repertoire/add-apt-key.sh
$ ln $HOME/repertoire/add-apt-key.sh $HOME/bin 

  1. appel du script :
# add-apt-key.sh

Il vous demandera le nom du projet, puis l’URL du dépôt du projet et vous confirmera ou non la bonne installation de la clé GPG dans le répertoire adéquat.


  1. Gestion du fichier sources

Il y a deux manières possibles de gérer le fichier sources nécessaire pour apt. L’une « historique », l’autre à partir du format de contrôle des données RFC822. Essayez d’utiliser en premier le format deb822, et si vraiment impossible, revenez à la version historique ; ne faites pas les deux, ça ne sert à rien.

édition au format deb822

La RFC822 définit le format deb822. Nous ne rentrerons pas ici dans les détails, pour plus d’informations, merci de lire les liens de documentations ci-dessous.

Ce qui semble fonctionner actuellement :

  • Création d’un fichier ‹ /etc/apt/sources.list.d/nom-projet.sources › - à ne pas créer avec l’option ‹ edit-sources › d’apt, car il suffixera automatiquement le nom du fichier de l’extension ‹ .list › ; résultat lors de l’utilisation de l’option ‹ update ›, apt ne comprendra pas le formatage et émettra une erreur à ce propos.
Types: deb
URIs: URL-web-du-depôt-du-projet
Suites: version-debian
Architectures: nom-architecture-cible
Components: cible-depôt
Signed-By: /usr/local/share/keyrings/nom-cle.gpg

Explications :

  • URIs est l’URL du dépôt du projet.
  • Suites est le nom de la version de Debian utilisée ou la valeur du dépôt selon le projet. Par exemple : stable ; dans le cas du projet « Element », c’est default.
  • Components est la cible du dépôt, tel main, contrib et/ou non-free.
  • Signed-By devrait normalement contenir la chaîne textuelle correspondante à la clé GPG - mais comme l’a fait remonter @anon70622873, le support en cours est bogué - donc, dans l’immédiat, c’est le chemin absolu vers le fichier de clé GPG précédemment téléchargé et installé dans le répertoire local /usr/local/share/keyrings/.

Pour exemples, voici les fichiers sources construits par nos soins pour différents projets :

Maintenant, il faut passer à l’étape suivante, celle de la màj et de l’installation du binaire. Si l’update échoue, soit vous vérifiez l’écriture du fichier, soit vous le supprimez puis vous passez à l’édition de manière « historique ».


Passons à l’étape suivante :


  1. update et installation.
# apt update
# apt install nom-binaire-relatif-projet

Voilà !

(normalement l’installation du binaire, tant désiré, devrait être… il ne reste plus qu’à utiliser votre « précieux »).


⇒ Informations supplémentaires :

Il peut parfois être nécessaire d’ajouter la clé GPG par le biais de l’outil gpg, tel que :

# gpg --no-default-keyring --keyring /usr/local/share/keyrings/nom-projet.gpg --keyserver hkps://keys.openpgp.org --recv-keys clé-à-ajouter

L’identifiant de clé « clé-à-ajouter » est généralement fourni dans le message d’erreur que retourne l’outil apt, par exemple, pour le projet Lutris :

W: Une erreur s'est produite lors du contrôle de la signature. Le dépôt n'est pas mis à jour et les fichiers d'index précédents seront utilisés. Erreur de GPG : http://download.opensuse.org/repositories/home:/strycore/Debian_Unstable  InRelease : Les signatures suivantes n'ont pas pu être vérifiées car la clé publique n'est pas disponible : NO_PUBKEY 2F7F0DA5FD5B64B9
W: Impossible de récupérer http://download.opensuse.org/repositories/home:/strycore/Debian_Unstable/InRelease  Les signatures suivantes n'ont pas pu être vérifiées car la clé publique n'est pas disponible : NO_PUBKEY 2F7F0DA5FD5B64B9

La « clé-à-ajouter » dans ce cas-là est : 2F7F0DA5FD5B64B9


Documentations :

3 J'aime

Ah, cool, ça veut dire qu’on a une nouvelle façon plus facile d’utilisation pour effectuer cette opération, comme on a laissé tomber les affreuses commandes ifconfig, route et arp pour ip.

Ah ! Ben non.

2 J'aime

apt-key nous dit

Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).

D’ailleurs le paquet debian-archive-keyring y mets ses clés

root@debian:/etc/apt/trusted.gpg.d# ls -alrt
total 88
-rw-r--r-- 1 root root 2263  3 sept.  2017 debian-archive-stretch-stable.gpg
-rw-r--r-- 1 root root 7452  3 sept.  2017 debian-archive-stretch-security-automatic.gpg
-rw-r--r-- 1 root root 7443  3 sept.  2017 debian-archive-stretch-automatic.gpg
-rw-r--r-- 1 root root 2332 23 avril  2019 debian-archive-buster-stable.gpg
-rw-r--r-- 1 root root 8141 23 avril  2019 debian-archive-buster-security-automatic.gpg
-rw-r--r-- 1 root root 8132 23 avril  2019 debian-archive-buster-automatic.gpg
-rw-r--r-- 1 root root 7521 18 févr.  2021 google.gpg
-rw-r--r-- 1 root root 2453 25 févr.  2021 debian-archive-bullseye-stable.gpg
-rw-r--r-- 1 root root 8709 25 févr.  2021 debian-archive-bullseye-security-automatic.gpg
-rw-r--r-- 1 root root 8700 25 févr.  2021 debian-archive-bullseye-automatic.gpg
-rw-r--r-- 1 root root 1184  4 sept. 08:05 spotify.gpg

Pourquoi n’utilises tu pas le répertoire d’apt, /etc/apt/trusted.gpg.d ?

En fait ce répertoire est pour ceux qui sont « dignes de confiances » !
C’est à dire qu’ils fournissent correctement leurs clés… donc, à-priori, au-travers des dépôts officiels.

Il semble que pour les autres la recommandation soit l’utilisation du répertoire /usr/share/keyrings, dixit la page DebianRepository/UseThirdParty - Debian Wiki (en anglais)

À noter aussi que les clés « dignes de confiance » sont aussi déposés dans ce répertoire.


Tiens, voici un projet qui restitue des informations « à-jour » :


⇒ Par exemple, pour le projet « Element » :

Types: deb
URIs: https://packages.riot.im/debian/
Suites: default
Architectures: amd64
Components: main
Signed-By: /usr/local/share/keyrings/element.gpg

PS : le premier post est basculé en mode wiki !

1 J'aime
echo "deb [signed-by=/usr/share/keyrings/riot-im-archive-keyring.gpg] https://packages.riot.im/debian/ default main" | sudo tee /etc/apt/sources.list.d/riot-im.list

Mettre la référence de la clé dans le fichier sources.list c’est vraiment la ceinture et les bretelles :rofl:

Ça fonctionne ce truc ?

Oui !
(mais tu n’es pas obligé de le mettre, ça fonctionne aussi sans ; j’ai testé les deux)

Voici ce qui est écrit dans le man sources.list :

Signed-By (signed-by) est une option pour demander la vérification d’un dépot par apt-secure(8) avec un certain jeu de clés plutôt qu’avec la totalité des clés de confiance
configurées par apt. Elle est définie comme une liste de chemins absolus vers des fichiers de trousseau de clés (qui doivent être accessibles en lecture pour l’utilisateur
_apt, et donc, il faut s’assurer que tout le monde a le droit de lecture sur le fichier) et des empreintes de clés à sélectionner dans ces trousseaux. Si aucun fichier de
clés n’est défini, le trousseau trusted.gpg et tous les trousseaux du répertoire trusted.gpg.d/ sont sélectionnés par défaut (voir apt-key fingerprint). Si aucune empreinte
n’est définie, toutes les clés des trousseaux sont sélectionnées. Une empreinte acceptera aussi toutes les signatures de sous clés de cette clé, et si ce n’est pas désiré, un
point d’exclamation (!) peut être ajouté à l’empreinte pour désactiver ce comportement. Elle possède la valeur par défaut de l’option du même nom si elle a été définie dans
le fichier Release de ce dépôt récupéré auparavant (seules des empreintes peuvent être définies par ce biais). Autrement, toutes les clés des trousseaux de confiance sont
considérées comme des signatures valables pour ce dépôt.

Donc, c’est la manière de lui dire d’aller chercher à tel endroit la signature, plutôt que d’aller la chercher dans le répertoire de signatures de confiances, tel trusted.gpg(.d) :wink:

Attention, cela ne fait que de s’assurer de la signature, soit la correspondance du dépôt avec la clé GPG, mais ne la définit pas comme étant sûre et digne de confiance ; un peu comme quand tu utilises gpg avec le mode signed, où tu émets à l’autre que ton message est « signé » par ta clé, donc qu’il vient normalement bien de toi…


Oh, tu peux te moquer… et faire comme tu veux. Là, je « construis »/restitue les informations de la manière la plus recommandée ; après il est toujours possible de moduler.

En effet la vraie question c’est quel sens on donne au mot confiance

Celui utilisé dans le contexte de sécurité, tout comme pour GPG. Tu sais très bien que la confiance est très relative.

Exemple :
⇒ si c’est dans les dépôts officiels, on peut estimer à juste titre avoir confiance car cela a du être « analysé » par une équipe Debian ou l’autre, s’il y a un risque ou quelque chose qui cloche, l’équipe fait le nécessaire pour que le tir soit rectifié, jusqu’à refuser l’inclusion du projet… ;
⇒ en dehors de ça, c’est la « confiance » personnelle que tu offres au projet X, Y, Z, sachant qu’il y a toujours un risque ; personnellement, je n’ai pas ou prou confiance en des projets tiers, d’autant si en plus les informations affichées sont incorrectes, pas mises-à-jour, etc

si je me souviens bien le manpage apt-secure en parle assez bien…

Un peu de lecture :

Et aussi cet article bien fait :

Et il est préférable de mettre les clés dans /usr/local/share pour respecter la FSH.

1 J'aime

???


Quand je lis dans le premier lien, sudoedit pour éditer les sources apt… suis un peu sceptique.
Y’a quand même l’option native à apt. Soit.

Oui, l’intérêt étant de déclarer qu’une clé donnée n’est considérée comme « de confiance » que pour un dépôt donné. Comme souvent, c’est beaucoup moins moche si on utilise des fichiers .sources au format deb822 :

Types: deb
URIs: http://www.bchemnet.com/suldr
Suites: debian
Architectures: amd64
Components: extra
Signed-By: /etc/apt/trusted.gpg.d/suldr-keyring.gpg

(bon, ici c’est un mauvais exemple parce que la clé est dans un répertoire où elle est déjà considérée globablement comme valide pour tout dépôt, mais c’est l’exemple que j’avais sous la main sur cette machine)


Sur le sujet de /usr/share/keyrings, je ne suis pas d’accord avec la doc du wiki Debian (qui mérite probablement d’être corrigé).

/usr/share est censé être le territoire exclusif de dpkg, on ne devrait pas avoir à y ajouter/modifier des fichiers à la main. Pour ce genre d’utilisation, je privilégierais sans hésitation /usr/local/share/keyrings.

Sans la typo, ça donne FHS :wink:

3 J'aime

Quelque soit l’endroit où on pose sa clé…

A bon entendeur…

Tu es le deuxième ici à référer à cette idée.
Je n’ai aucun soucis avec… si ce n’est que par défaut ce répertoire semble ne pas exister ; il faut donc le créer.
Je peux rajouter l’instruction correspondante et modifier le premier post.

Dans ce cas-là, pourquoi ne pas créer un répertoire ~/keyrings et l’utiliser, ce qui serait moins contraignant pour l’utilisateur !?


le second lien que fournit @anon70622873 semble vouloir dire que :

  • l’usage de /usr/share/keyrings n’est qu’un effet de mode publicitaire,
  • c’est quand même la meilleure approche pour ceux qui fournissent des .deb et qui ont leur propre dépôt
  • qu’il n’y a pas de gain réel à utiliser l’option signed-by.

Si je comprends bien, le mieux serait de fournir un fichier au format deb822 que tu n’as plus qu’à placer dans le répertoire sources.list.d ; à bon entendeur - pour reprendre l’expression ci-dessus…
Un nom-projet.sources suffirait ?!


Ce qui est sûr, c’est que le manpage d’apt-key nous dit clairement qu’après Debian 11, byebye !

apt-key(8) will last be available in Debian 11 and Ubuntu 22.04.

De même, je ne vois aucune mention d’un répertoire à privilégier… sauf dans le man d’apt-key, dont toutes les déclarations sont obsolètes - et donc amener à disparaître.


Ce qui me semble pertinent est que si nous ne voulons pas utiliser, par convention, le répertoire /usr/share/keyrings mais plutôt /usr/local/share/keyrings voire $HOME/keyrings, si l’option signed-by n’est pas utilisé, comment l’outil apt pourrait s’y référer, puisque ce sont des répertoires hors analyse ! ?
(en effet, je rappelle ici la lecture du man sources.list qui explique que par défaut, seuls trusted.gpg{.d} sont sélectionnés pour « lecture »)

Pour remettre 1 € dans le nourin , la commande gpg utilise ses trousseaux dans ~/.gnupg pour un utilisateur lamba ou /root/.gnupg pour l’utilsateur root

ce qui fait que l’utilisation par exemple de la commande

 gpg --keyserver pgpkeys.mit.edu --recv-key D1742AD60D811D58

rempli des trousseaux à l’insu du plein gré de l’utilisateur. Lister par la commande

gpg --list-keys

Donc pour avoir une clé valide pour apt j’utilise mes 3 commandes en passant par /tmp
Exemple pour Spotify:

  • Récupérer la clé du site
wget -O /tmp/0D811D58.gpg https://download.spotify.com/debian/pubkey_0D811D58.gpg
  • Convertir dans un trousseau temporaire
gpg --no-default-keyring --keyring /tmp/spotify-keyring.gpg --import /tmp/0D811D58.gpg
  • Créer une clé valide pour apt
gpg --no-default-keyring --keyring /tmp/spotify-keyring.gpg --export --output /etc/apt/trusted.gpg.d/spotify.gpg
  • Vérification
apt-key list

/etc/apt/trusted.gpg.d/spotify.gpg

----------------------------------

pub rsa4096 2020-09-08 [SC] [expire : 2021-12-02]

8FD3 D9A8 D380 0305 A9FF F259 D174 2AD6 0D81 1D58

uid [ inconnue] Spotify Public Repository Signing Key <[tux@spotify.com](mailto:tux@spotify.com)>*

type de fichier

/etc/apt/trusted.gpg.d$ file spotify.gpg

spotify.gpg: PGP/GPG key public ring (v4) created Tue Sep 8 13:35:47 2020 RSA (Encrypt or Sign) 4096 bits MPI=0xd0ff0bba75deda92…

Car pour moi il s’agit d’utiliser le dépôt spotify pour utiliser spotify

apt policy spotify-client
spotify-client:
  Installé : 1:1.1.55.498.gf9a83c60
  Candidat : 1:1.1.55.498.gf9a83c60
 Table de version :
 *** 1:1.1.55.498.gf9a83c60 500
        500 http://repository.spotify.com stable/non-free amd64 Packages
        100 /var/lib/dpkg/status

Non, pour root, c’est aussi ~/.gnupg. C’est /root/.gnupg seulement si le home de root est /root (ce qui est le cas la majorité du temps).
Sinon, si tu n’es pas root, tu as le chemin avec ~root/.gnupg.

AMHA, les clés GPG des dépôts tiers n’ont rien à faire dans $HOME. $HOME ne doit contenir que les éléments de configuration propres à l’utilisateur.
Elles doivent être soit dans un dossier sous /usr/local/share (/keyrings ou /apt-keys ou ce que vous voulez) et référencées par signed-by (sinon cela ne fonctionne pas), soit directement dans le fichier truc.sources (solution idéale). Et l’usage du dépôt tiers doit être limité avec un fichier de configuration (apt pinning).
Le problème de avec les clés dans/etc/apt/trusted.gpg.d/, c’est qu’elles sont valables pour tous les dépôts comme expliqué dans les liens données et le Wiki Debian.
Les fournisseurs de dépôts tiers devraient donc idéalement fournir un fichiers truc.sources contenant la clé GPG et un fichier de préférences.

2 J'aime

Un vrai travail de bénédictin


Err :7 https://cdn-aws.deb.debian.org/debian bookworm InRelease
  Les signatures suivantes n'ont pas pu être vérifiées car la clé publique n'est pas disponible : NO_PUBKEY 648ACFD622F3D138 NO_PUBKEY 0E98404D386FA1D9
Err :8 https://cdn-aws.deb.debian.org/debian sid InRelease
  Les signatures suivantes n'ont pas pu être vérifiées car la clé publique n'est pas disponible : NO_PUBKEY 648ACFD622F3D138 NO_PUBKEY 0E98404D386FA1D9

c’est la clé de bullseye

gpg --keyserver pgpkeys.mit.edu --search-keys 0E98404D386FA1D9
gpg: data source: http://pgpkeys.mit.edu:11371
(1)	Debian Archive Automatic Signing Key (11/bullseye) <ftpmaster@debian.o
	  4096 bit RSA key 73A4F27B8DD47936, créé : 2021-01-17, expire : 2029-01-15
Keys 1-1 of 1 for "0E98404D386FA1D9".  Entrez le ou les nombres, (S)uivant, ou (Q)uitter > Q

/etc/apt/sources.list:deb [signed-by=/usr/share/keyrings/debian-archive-bullseye-security-automatic.gpg] https://cdn-aws.deb.debian.org/debian-security bullseye-security contrib main non-free
/etc/apt/sources.list:deb [signed-by=/usr/share/keyrings/debian-archive-bullseye-stable.gpg] https://cdn-aws.deb.debian.org/debian/ bullseye contrib main non-free
/etc/apt/sources.list:deb [signed-by=/usr/share/keyrings/debian-archive-bullseye-automatic.gpg] https://cdn-aws.deb.debian.org/debian/ bullseye-proposed-updates contrib main non-free
/etc/apt/sources.list:deb [signed-by=/usr/share/keyrings/debian-archive-bullseye-automatic.gpg] https://cdn-aws.deb.debian.org/debian/ bullseye-updates contrib main non-free
/etc/apt/sources.list:deb  [signed-by=/usr/share/keyrings/debian-archive-bullseye-automatic.gpg] https://cdn-aws.deb.debian.org/debian/ bullseye-backports contrib main non-free
/etc/apt/sources.list:deb [signed-by=/usr/share/keyrings/debian-archive-bullseye-automatic.gpg] https://cdn-aws.deb.debian.org/debian/ bookworm contrib main non-free
/etc/apt/sources.list:deb [signed-by=/usr/share/keyrings/debian-archive-bullseye-automatic.gpg] https://cdn-aws.deb.debian.org/debian/ sid contrib main non-free
/etc/apt/sources.list.d/03-spotify.list:deb [arch=amd64 signed-by=/usr/share/keyrings/spotify.gpg] http://repository.spotify.com stable non-free
etc/apt/preferences.d/spotify 
Package: *
Pin: origin repository.spotify.com
Pin-Priority: 1

Package: spotify-client
Pin: origin repository.spotify.com
Pin-Priority: 500