[Fixed] “apt-key est obsolète. Gérez les fichiers de trousseau de clés danstrusted.gpg.d”


  • FrançaisFrançais


  • L’installation d’un package à partir d’un référentiel externe dans Ubuntu consiste en trois étapes :

    • Ajout de la clé GPG du référentiel au système
    • Ajout du référentiel externe au système
    • Installation du package à partir de ce référentiel externe

    Mais dernièrement, vous remarquerez un message indiquant que “apt-key est obsolète” lorsque vous essayez d’installer des packages à partir de référentiels tiers.

    Prenez l’installation de Spotify sur Ubuntu par exemple. Lorsque j’ajoute la clé GPG au système, il se plaint.

    curl -sS https://download.spotify.com/debian/pubkey_5E3C45D7B312C643.gpg | sudo apt-key add -
    [sudo] password for abhishek: 
    Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
    OK

    C’est un avertissement, pas une erreur. Cela n’arrête pas le processus. La clé GPG est ajoutée à votre système et vous pouvez continuer à ajouter le référentiel externe.

    Cependant, cela créera d’autres avertissements (encore une fois, pas d’erreurs). Dans l’exemple ici, si je continue à ajouter le référentiel externe, il m’affiche ce message.

    Reading package lists... Done
    Building dependency tree... Done
    Reading state information... Done
    All packages are up to date.
    W: http://repository.spotify.com/dists/stable/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.

    Cependant, cela n’arrête pas l’installation du paquet. Dans l’exemple, j’ai pu installer le package spotify-client par la suite.

    Si ce n’est pas une erreur, faut-il s’en inquiéter ? Probablement pas. Pas maintenant, du moins. Cependant, il serait préférable de comprendre les changements futurs apportés à ce mécanisme de repo externe.

    Comprendre la dépréciation d’apt-key et le problème trusted.gpg

    Il y a deux parties dans ce message :

    • apt-key est obsolète
    • Gérer les fichiers de trousseau de clés dans trusted.gpg.d

    J’aborderai les deux points dans un instant.

    Lorsque vous ajoutez les clés (.gpg ou .asc) d’un référentiel, votre système fait confiance aux packages (signés avec cette clé) provenant du référentiel. Si vous n’ajoutez pas la clé d’un référentiel, votre système n’autorisera pas l’installation de packages à partir de celui-ci.

    Pendant longtemps, l’outil de ligne de commande apt-key a été utilisé pour gérer les clés de référentiel de Debian et d’autres distributions à l’aide de la gestion de paquets apt. Vous pouvez ajouter, répertorier, mettre à jour et supprimer les clés avec cette commande.

    Problème avec le fonctionnement d’apt-key

    Cela fonctionne en ajoutant les clés au fichier /etc/apt/trusted.gpg. Le gestionnaire de paquets apt fait confiance aux clés à l’intérieur de ce fichier.

    Ça sonne bien, non ? Cependant, il a été découvert qu’il s’agissait d’un problème de sécurité potentiel. Votre système fait entièrement confiance à ces clés, pas seulement aux packages pour lesquels vous les avez ajoutées.

    Imaginez que vous avez ajouté des clés au référentiel A pour obtenir le package AA et au référentiel B pour obtenir le package BB. Votre système acceptera volontiers le package BB signé par la clé du référentiel A. Il ne peut pas associer les clés à leurs packages respectifs.

    Maintenant, c’est plus facile à dire qu’à faire car il y a d’autres facteurs en jeu comme la politique et les préférences appropriées, mais cela ouvre une surface d’attaque.

    C’est la raison pour laquelle apt-key est obsolète. C’est la première partie du message d’avertissement.

    Ubuntu veut que vous sépariez les clés GPG

    Venir à la deuxième partie du message d’avertissement ; “Gérer les fichiers de trousseau de clés dans trusted.gpg.d”.

    Ubuntu ne veut pas que vous ajoutiez toutes les clés de signature dans le seul fichier /etc/apt/trusted.gpg. Il suggère d’utiliser un fichier séparé situé dans le répertoire /etc/apt/trusted.gpg.d.

    C’est le même mécanisme qu’il utilise pour la liste des sources où les sources du référentiel externe sont répertoriées dans leur propre fichier sous /etc/apt/sources.list.d au lieu de tout conserver sous le fichier /etc/apt/sources.list. Cela facilite un peu la gestion des dépôts externes.

    Cela signifie qu’au lieu d’utiliser la clé apt de cette manière :

    curl -sS https://download.spotify.com/debian/pubkey_5E3C45D7B312C643.gpg | sudo apt-key add -

    Vous devriez l’utiliser comme ceci :

    curl -sS https://download.spotify.com/debian/pubkey_5E3C45D7B312C643.gpg | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/spotify.gpg

    Ce qui consiste essentiellement à ajouter la clé à son fichier dédié sous le répertoire /etc/apt/trusted.d. Ubuntu ne se plaindra plus.

    Bien que cela ne résolve pas le problème initial de la signature croisée des packages. La bonne façon à corriger consiste à ajouter l’emplacement de la clé au fichier de liste des sources du référentiel. Je discuterai des deux méthodes dans la section suivante.

    Solution 1 : Ajouter les clés GPG au système pour garder Ubuntu heureux (manière relativement plus simple mais pas appropriée)

    Malheureusement, il n’y a pas de moyen facile de contourner cela. Vous devrez utiliser la ligne de commande et déterminer les paramètres corrects. Il n’y a pas de “lancez ceci et vous avez terminé” ici.

    L’idée ici est d’ajouter la clé GPG sous son fichier dédié dans /etc/apt/trusted.gpg.d.

    Il y a quelques scénarios ici.

    Vous avez déjà ajouté la clé dans le fichier /etc/apt/trusted.gpg

    Dans ce cas, listez les clés avec cette commande :

    sudo apt-key list

    Il devrait y avoir un moyen d’identifier le référentiel. Vous devriez avoir son nom ou le nom du développeur.

    Dans mon cas, je gère le référentiel Spotify :

    [email protected]:~$ sudo apt-key list
    [sudo] password for abhishek: 
    Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
    /etc/apt/trusted.gpg
    --------------------
    pub   rsa4096 2021-10-27 [SC] [expires: 2023-01-20]
          F9A2 1197 6ED6 62F0 0E59  361E 5E3C 45D7 B312 C643
    uid           [ unknown] Spotify Public Repository Signing Key <[email protected]>
    

    Copiez les 8 derniers caractères de la deuxième ligne sous pub. Dans mon cas, c’est B312 C643. Vous devrez supprimer l’espace entre les chiffres et l’utiliser comme ceci :

    sudo apt-key export B312C643 | sudo gpg --dearmour -o /etc/apt/trusted.gpg.d/spotify.gpg

    Le fichier de sortie peut porter n’importe quel nom, mais il est préférable d’utiliser un nom associé au package ou au référentiel.

    La gpg --dearmour partie est importante car le mécanisme s’attend à ce que vous disposiez des clés au format binaire.

    Vous n’avez pas encore ajouté les clés externes

    Eh bien, dans ce cas, récupérez les clés et ajoutez-les à votre répertoire trsuted.gpg.d.

    Si seulement c’était si simple. Les clés peuvent être dans plusieurs formats de fichiers comme .asc, .gpg etc. Et puis ces clés peuvent être blindé.

    Un fichier GPG blindé est crypté mais affiche du texte aléatoire au lieu d’être au format binaire. Une clé GPG blindée commence par :

    -----BEGIN PGP PUBLIC KEY BLOCK-----

    Mais votre clé GPG ne doit pas être “blindée”. Il doit être au format binaire (si vous essayez de le lire, il affiche du charabia).

    ay`�����?o;���Lh����҇�^j?�,4�@8�Xh�]�j�F��Q��W�ă|,%C�n��nG�t���׺���b%/Ka����i���

    C’est pourquoi il est important d’utiliser sudo gpg --dearmour lors de la manipulation des clés. Si les clés ajoutées ne sont pas au format binaire, vous commencerez à voir ce message dans la sortie de la commande apt update :

    The key(s) in the keyring /etc/apt/trusted.gpg.d/spotify.gpg are ignored as the file has an unsupported filetype.

    Vous pouvez également utilisez la commande de fichier pour vérifier si la clé est blindée ou non.

    file repo-key.gpg

    et si la sortie est comme ‘PGP public key block’, il s’agit d’un fichier blindé et doit être converti en binaire.

    [email protected]:~$ file /etc/apt/trusted.gpg.d/spotify.gpg 
    /etc/apt/trusted.gpg.d/spotify.gpg: PGP public key block Public-Key (old)

    Ainsi, les étapes ici impliquent:

    • Télécharger les clés et vérifier s’il est blindé ou non
    • Si le fichier est blindé, il doit être désarmé au format binaire
    • Et puis la clé désarmée est ajoutée à son propre fichier sous le répertoire /etc/apt/trusted.gpg.d

    Vous pouvez combiner tout en une seule commande comme celle-ci étant donné que vous savez qu’il s’agit d’une clé blindée.

    curl -sS https://download.spotify.com/debian/pubkey_5E3C45D7B312C643.gpg | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/spotify.gpg

    Comme je l’ai mentionné plus tôt, c’est relativement plus facile mais pas la bonne façon. Quelle est la bonne manière ? Discutons-en.

    Solution 2 : ajouter les clés GPG au système de la bonne manière

    Ceci est similaire à ce que vous avez vu dans la section précédente, mais il comporte une étape supplémentaire consistant à ajouter l’emplacement de la clé au fichier de liste des sources du référentiel.

    • Télécharger les clés et vérifier s’il est blindé ou non
    • Si le fichier est blindé, il doit être désarmé au format binaire
    • Et puis la clé désarmée est ajoutée à son propre fichier sous le répertoire /usr/share/keyrings
    • L’emplacement du fichier clé est ajouté au fichier de liste des sources du référentiel

    Dans le même exemple, ajoutons la clé du dépôt Spotify dans le répertoire /usr/share/keyrings.

    curl -sS https://download.spotify.com/debian/pubkey_5E3C45D7B312C643.gpg | gpg --dearmor | sudo tee /usr/share/keyrings/spotify.gpg

    Maintenant, vient la partie suivante. Normalement, le contenu du fichier de liste des sources ressemble à ceci :

    deb URL_of_the_repo stable non-free

    Vous devez le modifier et ajouter l’emplacement du fichier clé comme ceci :

    deb [signed-by=/usr/share/keyrings/key-file.gpg] URL_of_the_repo stable non-free

    De cette façon, vous liez le package à une clé spécifique. Maintenant, cette clé ne peut pas être utilisée pour télécharger un autre package. Plus de signature croisée.

    Dans l’exemple Spotify, j’ai modifié la commande de cette manière afin que la liste des sources contienne également les informations signées par.

    echo "deb [signed-by=/usr/share/keyrings/spotify.gpg] http://repository.spotify.com stable non-free" | sudo tee /etc/apt/sources.list.d/spotify.list

    Et ensuite ?

    Comme vous pouvez le voir, il n’y a pas de mécanisme facile à utiliser pour remplacer la commande apt-key. Cela demande beaucoup d’efforts manuels et cela ne devrait pas être comme ça.

    Puisqu’il s’agit de la phase de transition, le message “apt-key is deprecated” est un avertissement, mais les choses pourraient être plus strictes dans les futures versions d’Ubuntu.

    Pour l’instant, même si vous ignorez cet avertissement, vous pouvez continuer à utiliser le référentiel externe.

    À mon avis, la responsabilité incombe au fournisseur de référentiel externe. Ils devraient être ceux qui fournissent la bonne manière d’ajouter leur référentiel.

    je vois ça Le navigateur Brave fournit le moder correctn des instructions mais beaucoup d’autres, comme Spotify, ne le font pas. Le changement devrait venir du côté du développeur. L’utilisateur ne doit pas manipuler les messages d’avertissement et d’erreur.

    Ce n’est pas l’un de mes meilleurs articles car il contient trop de points mobiles et il vous laisse beaucoup de choses à comprendre. J’ai l’impression que l’article n’éclaire peut-être pas tout. Si tel est le cas, veuillez laisser vos questions et suggestions dans la section des commentaires et j’essaierai de l’expliquer davantage.


    Source

    N'oubliez pas de voter pour cet article !
    1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
    Loading...

    La Rédaction

    L'équipe rédactionnnelle du site

    Pour contacter personnellement le taulier :

    Laisser un commentaire

    Votre adresse e-mail ne sera pas publiée.