La page de manuel Ubuntu pour apt-key comprend la note suivante concernant apt-key add:

Remarque: Au lieu d'utiliser cette commande, un trousseau de clés doit être placé directement dans le répertoire /etc/apt/trusted.gpg.d/ avec un nom descriptif et "gpg" ou "asc" comme extension de fichier.

Je ne pense pas avoir jamais vu ce conseil ailleurs. La plupart des projets qui hébergent leurs propres référentiels disent de télécharger leur fichier de clé et de l'ajouter avec apt-key.

1. Quelle est la motivation derrière ce conseil?
2. Est-ce un Ubuntu-ism, ou s'applique-t-il à une distribution basée sur APT?

Ces projets ont des instructions obsolètes. Je le sais car je publie un référentiel Debian et j'ai mis à jour mes instructions lorsque j'ai découvert les changements dans Debian 9 APT. En effet, cette partie du manuel est désormais obsolète, car il s'agit du mauvais répertoire.

Ce n'est pas vraiment lié aux .drépertoires et plus à la prévention d'une vulnérabilité intersite dans APT. L'ancien système utilisait des fichiers de clés séparés pour plus de commodité, mais c'est maintenant une nécessité pour la sécurité; votre sécurité.

Telle est la vulnérabilité. Considérez deux éditeurs de référentiel, A et B. Dans le monde de Debian 8 et avant, les clés des deux éditeurs se sont retrouvées dans le même trousseau global sur les machines des utilisateurs. Si l'éditeur A pouvait en quelque sorte prendre des dispositions pour supplanter le site WWW du référentiel de l'éditeur B, alors A pourrait publier des packages subversifs, signés avec la propre clé de A , qu'APT accepterait et installerait avec plaisir. La clé de A est, après tout, globalement approuvée pour tous les référentiels.

L'atténuation consiste pour les utilisateurs à utiliser des trousseaux de clés distincts pour les éditeurs individuels et à référencer ces trousseaux avec des Signed-Byparamètres individuels dans leurs définitions de référentiel. Plus précisément, la clé de l'éditeur A est uniquement utilisée dans le Signed-Byréférentiel A et la clé de l'éditeur B est uniquement utilisée dans le Signed-Byréférentiel B. De cette façon, si l'éditeur A remplace le référentiel de l'éditeur B, APT n'acceptera pas les packages subversifs de celui-ci, car ils et le le référentiel est signé par la clé de l'éditeur A et non par l'éditeur B.

Le /etc/apt/trusted.gpg.dmécanisme à portée de main est une maison à mi-chemin quelque peu imparfaite d'un pauvre homme vers cela, depuis 2005 environ, ce qui n'est pas assez bon. Il configure le trousseau de clés dans un fichier séparé, afin qu'il puisse être empaqueté et simplement installé en une seule étape par un gestionnaire de paquets (ou téléchargé avec fetch/ curl/ wget) comme tout autre fichier. (Le gestionnaire de packages gère la prévention de l'installation du package spécial this-is-my-repository-keyring de l'éditeur A sur l'éditeur B, de la manière habituelle pour gérer les conflits de fichiers entre les packages en général.) Mais il l'ajoute toujours au jeu de clés. qui est globalement fiable pour tous les référentiels. Le mécanisme complet qui existe maintenant utilise des fichiers de trousseaux de clés distincts, non approuvés globalement /usr/share/keyrings/.

Mes instructions sont déjà là. ☺ Il y a des mesures à prendre pour déplacer les propres référentiels de Debian vers ce mécanisme, afin qu'ils n'utilisent plus non plus de clés de confiance globales. Vous voudrez peut-être avoir un mot avec ces "la plupart des projets" que vous avez trouvés. Après tout, ils vous demandent actuellement de leur transférer l'accès global à APT sur votre machine.

Lectures complémentaires

• Daniel Kahn Gillmor (2017-05-02). Veuillez envoyer les clés spécifiques à la version séparément à l'extérieur de/etc/apt/trusted.gpg.d/ . Bogue Debian # 861695.
• Daniel Kahn Gillmor (2017-07-27). les sources.listentrées debian devraient avoir des options de signature pointant vers des clés spécifiques . Bogue Debian # 877012.
• Msgstr "Entrée sources.list" . Instructions pour se connecter à un référentiel tiers . Wiki Debian. 2018.
• Pourquoi n'est-ce pas un risque pour la sécurité d'ajouter à sources.list?
• Debian 9, APT et "Erreur GPG: ... InRelease: Les signatures suivantes n'étaient pas valides:"

apt-key delprend le keyid, qui est un hachage dénué de sens de la clé.

C'est plus simple si vous pouvez désinstaller des clés en utilisant un nom significatif ... comme un nom de fichier.

Comme le dit JdeBP, cela fonctionne bien avec les fichiers de clés de confiance installés dans le cadre d'un paquet Debian. Je pense que cela peut aussi être plus agréable lorsque vous avez installé manuellement un fichier clé.

Dans le nouveau mécanisme qui est actuellement en "test initial", cela est encore simplifié. Vous n'avez qu'à supprimer / désactiver une chose: le référentiel (dans sources.list / sources.list.d). Cela cessera automatiquement d'autoriser la clé configurée pour ce dépôt (sauf si elle a également été utilisée par un autre dépôt).

Je ne sais pas comment profiter du nouveau mécanisme de sécurité. Je suppose simplement que je dois faire confiance à quelqu'un si j'utilise son package. Le processus d'installation du package fonctionne toujours sous root:-).