NOM

       apt-secure - Gestion de l'authentification d'archive avec APT

DESCRIPTION

       Depuis sa version 0.6, apt sait vérifier la signature du fichier Release de chaque dépôt. On s'assure
       ainsi que les paquets dans l'archive ne peuvent pas être modifiés par quelqu'un qui ne possède pas la clé
       de la signature du fichier Release. À partir de la version 1.1, apt exige que les dépôts fournissent des
       informations récentes d'authentification pour une utilisation libre du dépôt. Depuis la version 1.5, les
       modifications dans les informations contenues dans le fichier Release sur le dépôt, doivent être
       confirmées avant qu'APT continue à appliquer les mises à jour depuis ce dépôt.

       Attention : toutes les interfaces de gestion de paquets comme apt-get(8), aptitude(8) et synaptic(8)
       possèdent cette fonction de certification, aussi cette page de manuel utilise APT pour se référer à
       l'ensemble d'entre elles, pour des raisons de simplicité.

CONFIGURATION UTILISATEUR

       Keys should usually be included inside their corresponding .sources by embedding the ASCII-armored key in
       the Signed-By option. To do so, replace the empty line with a dot, and then indent all lines by two
       spaces. See sources.list(5) for more information.

       Alternatively, keys may be placed in /etc/apt/keyrings for local keys, or /usr/share/keyrings for keys
       managed by packages, and then referenced by Signed-By: /etc/apt/keyrings/example-archive-keyring.asc
       option in a .sources file or using deb [signed-by=/etc/apt/keyrings/example-archive-keyring.asc] ... in
       the legacy .list format. This may be useful for APT versions prior to 2.4, which do not support embedded
       keys. ASCII-armored keys must use an extension of .asc, and unarmored keys an extension of .gpg.

       To generate keys suitable for use in APT using GnuPG, you will need to use the gpg --export-options
       export-minimal [--armor] --export command. Earlier solutions involving --keyring file --import no longer
       work with recent GnuPG versions as they use a new internal format ("GPG keybox database").

       Note that a default installation already contains all keys to securely acquire packages from the default
       repositories, so managing keys is only needed if third-party repositories are added. The extrepo package
       can be used to manage several external repositories with ease.

DÉPÔTS NON SIGNÉS

       Si une archive possède un fichier Release non signé ou pas de fichier Release du tout, les versions
       actuelles d'APT refuseront par défaut d'en télécharger des données dans les opérations update. Même si un
       frontal tel que apt-get(8) est forcé de télécharger, il demandera une confirmation explicite si une
       installation inclut un paquet d'une archive non authentifiée.

       Vous pouvez contraindre les clients APT à n'émettre que des avertissements en configurant l'option
       Acquire::AllowInsecureRepositories à true. L'option allow-insecure=yes de sources.list(5) peut aussi
       permettre à des dépôts individuels d'être non sécurisés. Veuillez noter que les dépôts non sécurisés sont
       fortement déconseillés et toutes les options pour contraindre APT à continuer à les prendre en charge
       devront être éventuellement supprimées. Les utilisateurs disposent aussi de l'option Trusted pour
       désactiver même les avertissements, mais il faut être sûr de comprendre ses implications détaillées dans
       sources.list(5).

       Un dépôt qui auparavant était authentifié, mais qui perdrait cet état lors d'une opération update envoie
       un message d'erreur à tous les clients d'APT quelle que soit l'option d'autoriser ou d'interdire
       l'utilisation de dépôts non sécurisés. L'erreur peut être contournée par le réglage supplémentaire de
       Acquire::AllowDowngradeToInsecureRepositories à true, ou, pour des dépôts individuels avec l'option
       allow-downgrade-to-insecure=yes de sources.list(5).

DÉPÔTS SIGNÉS

       D'une archive APT jusqu'à l'utilisateur, la chaîne de confiance se construit en plusieurs étapes.
       Apt-secure est la dernière étape. Faire confiance à une archive ne signifie pas que les paquets qu'elle
       contient sont exempts de code malveillant, mais signifie que vous faites confiance au responsable de
       l'archive. C'est ensuite au responsable de l'archive de faire en sorte que l'archive soit fiable.

       Apt-secure n'examine pas la signature d'un paquet. Certains programmes peuvent le faire comme
       debsig-verify ou debsign, qu'on peut trouver dans les paquets debsig-verify et devscripts.

       La chaîne de confiance dans Debian commence, par exemple, quand un responsable de paquet envoie un
       nouveau paquet ou une nouvelle version d'un paquet dans l'archive. Cet envoi, pour être effectif, doit
       être signé avec la clé d'un responsable qui se trouve dans un des trousseaux des responsables de paquet
       Debian (disponibles dans le paquet debian-keyring). Les clés des responsables de paquet sont signées par
       d'autres responsables, suivant des procédures préétablies pour s'assurer de l'identité des propriétaires
       de la clé. Des procédures similaires existent dans toutes les distributions basées sur Debian.

       Une fois que le paquet envoyé a été vérifié et inclus dans l'archive, la signature du responsable est
       enlevée, une somme de contrôle du paquet est calculée et mise dans le fichier Packages. Une somme de
       contrôle de tous les paquets est ensuite calculée et mise dans le fichier Release. Ce fichier est signé
       par la clé de l'archive pour la version courante de la distribution et distribuée en même temps que les
       paquets et les fichiers Packages sur les miroirs. Les clés sont dans le trousseau de clés de l'archive
       fournies par le paquet ubuntu-keyring.

       Un utilisateur peut consulter la signature du fichier Release, extraire la somme de contrôle d'un paquet
       et la comparer avec la somme du paquet qu'il a téléchargé, ou tout simplement compter sur APT pour faire
       ces opérations automatiquement.

       Cette façon de faire est différente d'une vérification de la signature d'un paquet. Elle vise à empêcher
       deux types d'attaque possibles :

       •   Attaque réseau de type « homme au milieu ». Sans vérification de signature, quelqu'un de malveillant
           peut s'introduire au milieu du processus de téléchargement et insérer du code soit en contrôlant un
           élément du réseau, routeur, commutateur, etc., soit en détournant le trafic vers un serveur fourbe
           (par usurpation d'adresses).

       •   Attaque par compromission d'un miroir sur le réseau. Sans vérification de signature, quelqu'un de
           malveillant peut compromettre un miroir et modifier les fichiers. Ainsi tous ceux qui téléchargent
           les paquets de ce miroir propagent du code malveillant.

       Cependant cette méthode ne protège pas contre une compromission du serveur principal lui-même (qui signe
       les paquets) ni contre la compromission de la clé qui sert à signer les fichiers Release. Mais elle peut
       compléter la signature des paquets.

MODIFICATIONS DES INFORMATIONS

       Le fichier Release renferme, en plus des sommes de contrôle pour les fichiers du dépôt, des informations
       générales sur le dépôt comme l'origine, le nom de code ou le numéro de la version.

       Ces informations apparaissent à plusieurs endroits, aussi, le propriétaire d'un dépôt devrait toujours
       s'assurer de leur exactitude. Par ailleurs, les configurations de l'utilisateur, comme
       apt_preferences(5), peuvent dépendre de ces informations et les utiliser. Depuis la version 1.5,
       l'utilisateur doit par conséquent confirmer de façon explicite les modifications pour signaler qu'il est
       suffisamment préparé, par exemple, pour la nouvelle version majeure de la distribution fournie dans le
       dépôt (comme indiqué par exemple par le nom de code).

CONFIGURATION DU DÉPÔT

       Si vous voulez signer les archives dont vous avez la responsabilité, vous devez :

       •   créer un fichier Release à la racine de l'archive, s'il n'existe pas déjà. Vous pouvez le créer avec
           la commande apt-ftparchive release (fournie dans le paquet apt-utils).

       •   le signer, avec les commandes gpg --clearsign -o InRelease Release et gpg -abs -o Release.gpg
           Release.

       •   publier l'empreinte de la clé. Ainsi les utilisateurs de votre archive connaîtront la clé qu'ils
           doivent importer pour authentifier les fichiers de l'archive. Le mieux est de diffuser sa clé dans
           son propre paquet de trousseau comme le fait Ubuntu avec ubuntu-keyring pour ensuite distribuer
           automatiquement les mises à jour et les transitions de clés.

       •   fournir les instructions pour ajouter l'archive et la clé. Si les utilisateurs ne peuvent récupérer
           de façon sûre votre clé, la chaîne de confiance décrite plus haut est rompue. La façon d'aider les
           utilisateurs à ajouter votre clé de l'archive dépend de l'archive et de l'audience cible : cela va
           d'un paquet de trousseau inclus dans une autre archive que des utilisateurs ont déjà configurée
           (comme les dépôts par défaut de leur distribution) à la mobilisation du web de confiance.

       Chaque fois que le contenu de l'archive change, (suppression ou ajout de nouveaux paquets) le responsable
       doit refaire les deux premières étapes.

VOIR AUSSI

       apt.conf(5), apt-get(8), sources.list(5), apt-ftparchive(1), debsign(1), debsig-verify(1), gpg(1)

       Pour des informations plus complètes, vous pouvez consulter l'infrastructure Debian pour la sécurité[1]
       un chapitre du manuel Debian sur la sécurité (aussi disponible dans le paquet harden-doc) et le Strong
       Distribution HOWTO[2] par V. Alex Brennen.

BOGUES

       Page des bogues d'APT[3]. Si vous souhaitez signaler un bogue à propos d'APT, veuillez lire
       /usr/share/doc/debian/bug-reporting.txt ou utiliser la commande reportbug(1).

AUTHOR

       APT a été écrit par l'équipe de développement APT <apt@packages.debian.org>.

AUTEURS DES PAGES DE MANUEL

       Cette page a été écrite à partir des travaux de Javier Fernández-Sanguino Peña, Isaac Jones, Colin
       Walters, Florian Weimer et Michael Vogt.

TRADUCTEURS

       Jérôme Marant, Philippe Batailler, Christian Perrier <bubulle@debian.org> (2000, 2005, 2009, 2010), bubu
       et Jean-Pierre Giraud <jean-pierregiraud@neuf.fr> (2004, 2017-2024) et l'équipe de traduction francophone
       de Debian <debian-l10n-french@lists.debian.org>

       Veuillez noter que cette traduction peut contenir des parties non traduites. Cela est volontaire, pour
       éviter de perdre du contenu quand la traduction est légèrement en retard sur le contenu d'origine.

AUTEURS

       Jason Gunthorpe

       Équipe de développement d'APT

NOTES

        1. l'infrastructure Debian pour la sécurité
           https://www.debian.org/doc/manuals/securing-debian-manual/ch07

        2. Strong Distribution HOWTO
           http://www.cryptnet.net/fdp/crypto/strong_distro.html

        3. Page des bogues d'APT
           https://bugs.debian.org/src:apt

APT 3.0.0                                       23 novembre 2024                                   APT-SECURE(8)