Product SiteDocumentation Site

7.5. La signature de paquet dans Debian

Ce chapitre pourrait également être intitulé « comment mettre à jour et à niveau un système Debian GNU/Linux en sécurité » et mérite d'avoir son propre chapitre car c'est une partie importante de l'infrastructure de sécurité. La signature des paquets est un point important car elle évite l'altération de paquets distribués sur les miroirs et des téléchargements avec des attaques en homme au milieu (« man-in-the-middle »). Les mises à jour de logiciels automatiques sont une fonctionnalité importante, mais il est également important d'enlever les menaces de sécurité qui pourraient favoriser la propagation de chevaux de Troie et la compromission de systèmes lors des mises à jour[56].
FIXME : la faille d'Internet Explorer sur la gestion des chaînes de certificat a probablement eu un impact sur les mises à jour de sécurité de Microsoft Windows.
Debian ne fournit pas de paquets signés, mais fournit un mécanisme disponible depuis Debian 4.0 Etch pour vérifier l'intégrité des paquets téléchargés[57]. Pour obtenir plus de renseignements, consultez Section 7.5.2, « apt sécurisé ».
Ce problème est mieux décrit dans le http://www.cryptnet.net/fdp/crypto/strong_distro.html par V. Alex Brennen.

7.5.1. Le schéma actuel pour la vérification de paquet

Le schéma actuel pour la vérification de signatures de paquet en utilisant apt est :
  • le fichier Release contient la somme de contrôle MD5 de Packages.gz (qui contient les sommes de contrôle MD5 des paquets) et sera signé. La signature est celle d'une source sûre ;
  • ce fichier Release est téléchargé par « apt-get update » et stocké sur le disque dur avec Packages.gz ;
  • quand un paquet est sur le point d'être installé, il est d'abord téléchargé, puis la somme MD5 est calculée ;
  • le fichier Release signé est vérifié (la signature est bonne) et la somme MD5 en est extraite pour le fichier Packages.gz, la somme de contrôle de Packages.gz est calculée et (si elle est bonne) la somme de contrôle MD5 du paquet téléchargé en est extraite ;
  • si la somme de contrôle MD5 du paquet téléchargé est la même que celle contenue dans le fichier Packages.gz, le paquet sera installé sinon l'administrateur sera averti et le paquet sera laissé dans le cache (ainsi l'administrateur décidera de l'installer ou non). Si le paquet n'est pas dans Packages.gz et que l'administrateur a configuré le système pour installer uniquement les paquets vérifiés, il ne sera pas installé non plus.
En suivant la chaîne des sommes MD5, apt est capable de vérifier qu'un paquet est originaire d'une version bien spécifique. C'est moins souple que de signer chaque paquet un par un, mais ce peut être combiné également avec ce schéma (voir ci-dessous).
Ce schéma est htttp://lists.debian.org/debian-devel/2003/debian-devel-200312/msg01986.html dans apt 0.6 et disponible depuis la publication de Debian 4.0. Pour obtenir plus de renseignements, consultez Section 7.5.2, « apt sécurisé ». Les paquets fournissant une interface à apt doivent être modifiés pour s'adapter à cette nouvelle fonctionnalité, c'est le cas d'aptitude qui a été htttp://lists.debian.org/debian-devel/2005/03/msg02641.html pour être adapté à ce schéma. aptitude et synaptic font partie des interfaces déjà connues pour fonctionner correctement avec cette fonctionnalité.
La signature de paquets a été abordée dans Debian depuis pas mal de temps déjà, pour plus d'informations vous pouvez lire : htttp://www.debian.org/News/weekly/2001/8/ et htttp://www.debian.org/News/weekly/2000/11/.

7.5.2. apt sécurisé

La version 0.6 d'apt, disponible depuis Debian 4.0 Etch, et les versions plus récentes, intègrent apt-secure (aussi connu sous le nom d'apt sécurisé) qui est un outil permettant à l'administrateur système de tester l'intégrité des paquets téléchargés conformément au schéma ci-dessus. Cette version contient l'outil apt-key pour ajouter de nouvelles clefs au trousseau d'apt qui ne contient par défaut que la clef actuelle de signature de l'archive Debian.
Ces modifications sont basées sur un correctif pour apt (disponible dans le htttp://bugs.debian.org/cgi-bin/bugreport.cgi?bug=203741) qui fournit cette implémentation.
apt sécurisé fonctionne en vérifiant la distribution à l'aide du fichier Release, conformément à Section 7.5.3, « Vérification par version de distribution ». Typiquement, ce processus sera transparent pour l'administrateur bien qu'il faudra intervenir chaque année [58] pour ajouter la nouvelle clef de l'archive quand elle est modifiée. Pour obtenir plus de renseignements sur les étapes qu'un administrateur doit accomplir, consultez Section 7.5.3.7, « Ajout de clef en sécurité ».
Cette fonctionnalité est encore en développement, donc si vous pensez avoir trouvé des bogues dans ce paquet, veuillez d'abord vérifier que vous utilisez la dernière version (car ce paquet peut évoluer beaucoup avant d'être diffusé) et si vous utilisez la dernière version, soumettez un rapport de bogue sur le paquet apt.
Plus de renseignements sont disponibles sur http://wiki.debian.org/SecureApt et dans la documentation officielle : http://www.enyo.de/fw/software/apt-secure/ et http://www.syntaxpolice.org/apt-secure/.

7.5.3. Vérification par version de distribution

Cette section décrit le mode de fonctionnement du mécanisme de vérification par version de distribution, elle a été écrite par Joey Hess et est également disponible dans le htttp://wiki.debian.org/SecureApt.

7.5.3.1. Concepts de base

Voici quelque concepts de base que vous devrez comprendre pour la suite de cette section.
Une somme de contrôle est une méthode permettant de prendre un fichier et de le réduire en un nombre suffisamment petit qui identifie son contenu de façon unique. C'est beaucoup plus compliqué qu'il n'y parait de faire ça bien, et le type de sommes de contrôle le plus fréquemment utilisé, MD5, est en passe d'être cassé.
La cryptographie à clef publique est basée sur une paire de clefs: une publique et une privée. La clef publique est distribuée partout ; la clef privée doit être gardée secrète. Tous ceux qui possèdent la clef publique peuvent chiffrer un message qui ne pourra être lu que par un possesseur de la clef privée. La clef privée permet elle de signer un fichier, pas de le chiffrer. Si une clef privée est utilisée pour signer un fichier, alors tous ceux qui ont la clef publique peuvent vérifier que le fichier était signé par cette clef. Une personne ne possédant pas la clef privée ne peut pas contrefaire une telle signature.
Ces clefs sont des nombres assez grands (de 1024 à 2048 chiffres, ou plus) et pour les rendre plus facile à utiliser, ils ont un identifiant de clef, plus court (un nombre de 8 ou 16 chiffres), qui peut être utilisé pour y référer.
gpg est l'outil utilisé par apt sécurisé pour signer les fichiers et vérifier leurs signatures.
apt-key est un programme qui permet de gérer un trousseau de clefs GPG pour apt sécurisé. Le trousseau est gardé dans le fichier /etc/apt/trusted.gpg (à ne pas confondre avec le fichier /etc/apt/trustdb.gpg relatif, mais pas très intéressant). apt-key permet de montrer les clefs du trousseau, et d'ajouter ou enlever une clef.

7.5.3.2. Sommes de contrôle de Release

Une archive Debian contient un fichier Release, qui est mis à jour à chaque fois qu'un paquet de l'archive est modifié. Entre autres, le fichier Release contient les sommes MD5 d'autres fichiers de l'archives. Exemple d'extrait de fichier Release :
MD5Sum:
 6b05b392f792ba5a436d590c129de21f            3453 Packages
 1356479a23edda7a69f24eb8d6f4a14b            1131 Packages.gz
 2a5167881adc9ad1a8864f281b1eb959            1715 Sources
 88de3533bf6e054d1799f8e49b6aed8b             658 Sources.gz
Les fichiers Release contiennent aussi des sommes de contrôle SHA-1, ce qui sera utile quand les sommes de contrôle MD5 seront complètement cassées, toutefois, apt ne les utilise pas encore.
Maintenant, à l'intérieur d'un fichier Packages, d'autres sommes de contrôle MD5 sont disponibles : une pour chaque paquet de la liste. Par exemple :
    Package: uqm
    Priority: optional
    ...
    Filename: unstable/uqm_0.4.0-1_i386.deb
    Size: 580558
    MD5sum: 864ec6157c1eea88acfef44d0f34d219
Ces deux sommes de contrôle permettent de vérifier que la copie du fichier Packages téléchargé est correcte, avec une somme de contrôle MD5 qui correspond à celle du fichier Release. Lorsqu'un paquet est téléchargé individuellement, la vérification de la somme de contrôle MD5 avec le contenu du fichier Packages est aussi possible. Si apt échoue à l'une de ces étapes, il abandonnera.
Rien de nouveau pour apt sécurisé, mais cela fournit les bases. Remarquez qu'un seul fichier n'a pas pu être vérifié par apt : le fichier Release. apt sécurisé a justement pour but de faire vérifier Release par apt avant de faire quoi que ce soit d'autre avec, et de combler ce trou, afin de rendre la chaîne de vérification complète, du paquet qui va être installé jusqu'au fournisseur du paquet.

7.5.3.3. Vérification du fichier Release

Pour vérifier le fichier Release, une signature gpg est ajoutée dans le fichier Release.gpg, distribué à ses côtés. Il ressemble à ceci[59], bien que seul gpg accède à son contenu normalement :
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBCqKO1nukh8wJbxY8RAsfHAJ9hu8oGNRAl2MSmP5+z2RZb6FJ8kACfWvEx
UBGPVc7jbHHsg78EhMBlV/U=
=x6og
-----END PGP SIGNATURE-----

7.5.3.4. Vérification du fichier Release.gpg par apt

apt sécurisé télécharge les fichiers Release.gpg en même temps que les fichiers Release, et s'il ne peut pas télécharger Release.gpg, ou si la signature n'est pas correcte, il se plaindra, et fera remarquer que les fichiers Packages pointés par le fichier Release, et tous les paquets contenus dedans, ne proviennent pas d'une source de confiance. Voici à quoi cela ressemble lors d'un apt-get update :
W: Erreur de GPG : http://ftp.us.debian.org testing Release :
Les signatures suivantes n'ont pas pu être vérifiées car la
clé publique n'est pas disponible : NO_PUBKEY 010908312D230C5F
Remarquez que la seconde partie du grand nombre est l'identifiant de la clef qu'apt ne connaît pas, c'est-à-dire 2D230C5F ici.
Si vous ignorez cet avertissement et essayez d'installer un paquet ensuite, apt avertira de nouveau :
ATTENTION : les paquets suivants n'ont pas été authentifiés.
  libglib-perl libgtk2-perl
Faut-il installer ces paquets sans vérification (o/N) ?
Si vous acceptez ici, vous n'avez aucun moyen de savoir si le fichier que vous obtenez est le paquet que vous voulez installer, ou s'il s'agit d'autre chose que quelqu'un pouvant intercepter la communication avec le serveur[60] a préparé pour vous, avec une mauvaise surprise.
Remarquez que vous pouvez désactiver ces vérifications en exécutant apt avec --allow-unauthenticated.
Remarquez également que les nouvelles versions de l'installateur Debian utilisent le même mécanisme de fichier Release lors du debootstrap du système de base Debian, avant qu'apt ne soit disponible, et que l'installateur utilise même ce système pour vérifier ses morceaux qu'il télécharge. Enfin, Debian ne signe pour l'instant pas les fichiers Release de ses CD ; apt peut être configuré pour faire toujours confiance aux fichiers des CD de sorte que ce ne soit pas un gros problème.

7.5.3.5. Comment expliquer à apt en quoi avoir confiance

La sécurité de l'intégralité du système dépend de l'existence d'un fichier Release.gpg, qui signe un fichier Release et de la vérification d'apt à l'aide de gpg. Pour vérifier la signature, il doit connaître la clef publique de la personne qui a signé le fichier. Ces clefs sont gardées dans le trousseau spécifique à apt (/etc/apt/trusted.gpg) et apt sécurisé arrive avec la gestion des clefs.
Par défaut, les systèmes Debian sont fournis préconfigurés avec la clef d'archive Debian du trousseau.
# apt-key list
/etc/apt/trusted.gpg
--------------------
pub   1024D/4F368D5D 2005-01-31 [expire: 2006-01-31]
uid                  Debian Archive Automatic Signing Key (2005) <ftpmaster@debian.org>
Ici 4F368D5D est l'identifiant de clef, et remarquez que la clef n'est valable que pour une période d'un an. Debian permute ces clefs comme dernière ligne de défense contre une quelconque brèche de sécurité de cassage de clef.
apt aura ainsi confiance en l'archive Debian officielle, mais si vous ajoutez d'autres dépôts apt à /etc/apt/sources.list, il vous faudra également donner à apt sa clef si vous voulez qu'il ait confiance en ce dépôt. Une fois que vous possédez la clef et que vous l'avez vérifiée, il suffit d'exécuter apt-key add fichier pour l'ajouter. Obtenir la clef et la vérifier sont les parties les plus délicates.

7.5.3.6. Trouver la clef d'un dépôt

Le paquet debian-archive-keyring est utilisé pour distribuer les clefs à apt. Les mises à niveau de ce paquet peuvent ajouter (ou retirer) des clefs gpg pour l'archive Debian principale.
Pour les autres archives, il n'y a pas encore d'endroit normalisé pour trouver la clef d'un dépôt apt donné. La clef est souvent liée depuis la page web du dépôt ou placée dans le dépôt directement, mais il vous faudra parfois la chercher.
La clef de signature de l'archive Debian est disponible en htttp://ftp-master.debian.org/ziyi_key_2006.asc (remplacez 2006 par l'année en cours). [61]
gpg a lui même un moyen normalisé de distribuer les clefs, utilisant un servent de clefs, d'où gpg peut télécharger une clef pour l'ajouter à son trousseau. Par exemple :
$ gpg --keyserver pgpkeys.mit.edu --recv-key 2D230C5F
gpg: requête de la clé 2D230C5F du serveur hkp pgpkeys.mit.edu
gpg: clé 2D230C5F: clé publique « Debian Archive Automatic Signing Key (2006)
<ftpmaster@debian.org> » importée
gpg:        Quantité totale traitée: 1
gpg:                       importée: 1
Vous pouvez alors exporter cette clef depuis votre propre trousseau et la fournir à apt-key :
$ gpg -a --export 2D230C5F | sudo apt-key add -
gpg: aucune clé de confiance ultime n'a été trouvée
OK
L'avertissement « gpg: aucune clé de confiance ultime n'a été trouvée » signifie que gpg n'était pas configuré pour faire confiance de façon ultime à une clef en particulier. Les réglages de confiance font partie du réseau de confiance d'OpenPGP qui ne s'applique pas ici. Cet avertissement n'est donc pas un problème ici. Dans les configurations typiques, seule la propre clef de l'utilisateur est de confiance ultime.

7.5.3.7. Ajout de clef en sécurité

En ajoutant une clef au trousseau d'apt, vous lui dite de faire confiance à tout ce qui est signé par cette clef, et cela vous permet de savoir avec certitude qu'apt n'installera rien de non signé par la personne qui possède la clef privée. Si vous êtes suffisamment paranoïaque, vous pouvez voir que cela ne fait que déplacer les choses d'un niveau : maintenant au lieu de vous inquiéter de la validité d'un paquet ou d'un fichier Release, il suffit de s'inquiéter d'avoir vraiment la bonne clef ; est-ce que le fichier htttp://ftp-master.debian.org/ziyi_key_2006.asc mentionné ci-dessous est vraiment la clef de signature de l'archive, ou a-t-il été modifié (ou ce document ment-il) ?
Être paranoïaque est une bonne attitude en sécurité, mais vérifier les choses à partir d'ici est plus difficile. gpg connaît le concept de chaîne de confiance, qui peut commencer à partir de quelqu'un dont vous être sûr, qui signe la clef de quelqu'un, qui signe une autre clef, etc. jusqu'à atteindre la clef de l'archive. Si vous êtes suffisamment paranoïaque, vous voudrez vérifier que la clef de l'archive est signée par une clef en laquelle vous pouvez avoir confiance, avec une chaîne de confiance qui remonte jusqu'à quelqu'un que vous connaissez personnellement. Si vous voulez faire cela, rendez vous à une conférence Debian ou peut-être à un groupe (LUG) local pour une signature de clef [62].
Si vous ne pouvez pas vous permettre ce niveau de paranoïa, faites le nécessaire suffisant de votre point de vue quand vous ajoutez une nouvelle source apt et une nouvelle clef. Peut-être voudrez vous échanger un courrier électronique avec la personne fournissant la clef et la vérifier, ou peut-être préférerez vous tenter votre chance en téléchargeant la clef en supposant que c'est la bonne. Ce qui est important est qu'en réduisant le problème au niveau de confiance des clefs de l'archive, apt sécurisé vous laisse être aussi prudent et sécurisé que vous désirez l'être.

7.5.3.8. Vérification de l'intégrité des clefs

Vous pouvez aussi bien vérifier l'empreinte digitale de la clef que ses signatures. La récupération de l'empreinte digitale peut se faire depuis de nombreuses sources : vous pouvez vérifier htttp://debiansystem.info/readers/changes/547-ziyi-key-2006, parler avec des développeurs Debian sur IRC, lire la liste de diffusion où la modification de clef sera annoncée ou n'importe quel moyen supplémentaire pour vérifier l'empreinte digitale. Par exemple en faisant :
$ GET http://ftp-master.debian.org/keys/archive-key-6.0.asc | gpg --import
gpg: clé 473041FA: clé publique « Debian Archive Automatic Signing Key (6.0/squeeze)
  <ftpmaster@debian.org> » importée
gpg:        Quantité totale traitée: 1
gpg:                       importée: 1  (RSA: 1)
gpg: 3 marginale(s) nécessaires, 1 complète(s) nécessaires, modèle
  de confiance PGP
gpg: profondeur: 0  valide:   1  signé:   0
confiance: 0-. 0g. 0n. 0m. 0f. 1u
$ gpg --check-sigs --fingerprint 473041FA
pub   4096R/473041FA 2010-08-27 [expire: 2018-03-05]
    Empreinte de la clé = 9FED 2BCB DCD2 9CDF 7626  78CB AED4 B06F 4730 41FA
uid                  Debian Archive Automatic Signing Key (6.0/squeeze) <ftpmaster@debian.org>
sig!3        473041FA 2010-08-27  Debian Archive Automatic Signing Key (6.0/squeeze)
  <ftpmaster@debian.org>
sig!         7E7B8AC9 2010-08-27  Joerg Jaspert <joerg@debian.org>
sig!    P    B12525C4 2010-08-27  Joerg Jaspert <joerg@debian.org>
sig!         D0EC0723 2010-08-27  Mark Hymers <mhy@debian.org>
sig!         8AEA8FEE 2010-08-27  Stephen Gran <steve@lobefin.net>
sig!         A3AE44A4 2010-08-28  Michael O'Connor (stew) <stew@vireo.org>
sig!         00D8CD16 2010-08-28  Alexander Reichle-Schmehl <alexander@reichle.schmehl.info>
sig!         CD15A883 2010-08-28  Alexander Schmehl (privat) <alexander@schmehl.info>
sig!         672C8B12 2010-08-28  Alexander Reichle-Schmehl <tolimar@debian.org>
sig!2        C4CF8EC3 2010-08-28  Torsten Werner <twerner@debian.org>
sig!2        D628A5CA 2010-08-28  Torsten Werner <mail.twerner@googlemail.com>
puis en vérifiant la chaîne de confiance (consultez Section 7.5, « La signature de paquet dans Debian ») de votre clef (ou d'une clef de confiance) vers au moins une des clefs utilisées pour signer la clef de l'archive. Si vous êtes suffisamment paranoïaque, vous ne direz à apt de ne faire confiance à la clef que si vous êtes satisfait de la chaîne de confiance :
$ gpg --export -a 473041FA | sudo apt-key add -
OK
Remarquez que la clef est signée par la clef de l'archive précédente, donc vous pouvez en théorie vous appuyer simplement sur votre confiance précédente.

7.5.3.9. Rotation annuelle de la clef de l'archive Debian

Comme signalé précédemment, la clef de l'archive Debian est modifiée tous les ans, en janvier. Comme apt sécurisé est encore jeune, nous manquons encore d'expérience pour modifier la clef et des passages sont un peu abrupts.
En janvier 2006, une nouvelle clef à été préparée pour 2006 et le fichier Release a commencé à être signé par cette clef, mais pour éviter de casser les systèmes qui utilisaient encore l'ancienne clef de 2005, le fichier Release était aussi signé par cette dernière. Le but était qu'apt accepte les deux signatures, indépendamment de la clef qu'il possède, mais à cause d'un bogue d'apt, il refusait de faire confiance au fichier s'il n'avait pas les deux clefs et n'était pas capable de vérifier les deux signatures. Cela a été corrigé dans la version 0.6.43.1 d'apt. Une confusion existait aussi sur la façon de distribuer la clef aux utilisateurs qui utilisaient déjà des systèmes avec apt sécurisé ; elle avait été envoyée sur le site web sans annonce et sans réel moyen de la vérifier, et les utilisateurs ont été obligés de la télécharger eux-mêmes.
En janvier 2006, une nouvelle clef à été préparée pour 2006 et le fichier Release a commencé à être signé par cette clef, mais pour éviter de casser les systèmes qui utilisaient encore l'ancienne clef de 2005, le fichier Release était aussi signé par cette dernière. Pour éviter les confusions sur le meilleur mécanisme de distribution pour les utilisateurs qui utilisent déjà des systèmes avec apt sécurisé, le paquet debian-archive-keyring a été introduit, pour gérer les mises à jour du trousseau de clefs d'apt.

7.5.3.10. Problèmes connus de vérification de la publication

Un autre problème évident est que si l'horloge est très décalée, apt sécurisé ne fonctionnera pas. Si la date est configurée dans le passée, comme en 1999, apt échouera avec un message peu compréhensible comme :
W: GPG error: http://ftp.us.debian.org sid Release: Unknown error executing gpg
Pourtant apt-key list expliquera le problème :
gpg: la clé 473041FA a été créée 367773259 secondes dans le futur (rupture
spatio-temporelle ou problème d'horloge)
pub   4096R/473041FA 2010-08-27 [expire: 2018-03-05]
uid                  Debian Archive Automatic Signing Key (6.0/squeeze) <ftpmaster@debian.org>
Si elle est configurée à une date trop dans le futur, apt considérera la clef expirée.
Un autre problème que vous pourriez rencontrer en utilisant testing ou unstable, est que si vous n'avez pas exécuté apt-get update récemment et apt-get install un paquet, apt risque de se plaindre qu'il ne peut pas être authentifié. apt-get update corrigera cela.

7.5.3.11. Vérification manuelle par version de distribution

Au cas où vous voudriez ajouter des vérifications de sécurité supplémentaires et que vous ne vouliez pas ou pouviez pas utiliser la dernière version d'apt[63] vous pouvez utiliser le script ci-dessous fourni par Anthony Towns. Ce script peut automatiquement faire certaines nouvelles vérifications de sécurité qui permettent à l'utilisateur d'être sûr que le logiciel qu'il télécharge correspond à celui de la distribution de logiciels Debian. Cela empêche les développeurs Debian d'intégrer des nouveautés au système de quelqu'un en outrepassant les responsabilités qui incombent au chargement vers l'archive principale, ou encore cela empêche une duplication similaire mais pas exactement identique, ou pour finir cela empêche l'utilisation de miroirs fournissant des copies anciennes de la version unstable ou connaissant des problèmes de sécurité.
Ce code exemple, renommé en apt-release-check, devrait être utilisé de la manière suivante :
# apt-get update
# apt-check-sigs
(...résultats...)
# apt-get dist-upgrade
Avant tout, vous avez besoin de :
  • récupérer les clefs que les logiciels de l'archive utilisent pour signer les fichiers Release, htttp://ftp-master.debian.org/ziyi_key_2006.asc, et les ajouter à ~/.gnupg/trustedkeys.gpg (c'est ce que gpgv utilise par défaut) ;
      gpg --no-default-keyring --keyring trustedkeys.gpg --import ziyi_key_2006.asc
  • retirer toutes les lignes de /etc/apt/sources.list qui n'utilisent pas la structure normale « dists » ou modifier le script afin qu'il fonctionne avec elles ;
  • être prêt à ignorer le fait que les mises à jour de sécurité Debian n'ont pas de fichiers Release signés et que les fichiers Sources n'ont pas (encore) les sommes de contrôle (« checksums ») appropriées dans le fichier Release ;
  • être prêt à vérifier que les sources appropriées soient signées par les clefs appropriées.
C'est le code exemple pour apt-check-sigs, la dernière version peut être récupérée depuis htttp://people.debian.org/~ajt/apt-check-sigs. Ce code est actuellement en bêta, pour de plus amples renseignements, consultez htttp://lists.debian.org/debian-devel/2002/debian-devel-200207/msg00421.html.
#!/bin/bash

# Copyright (c) 2001 Anthony Towns <ajt@debian.org>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.

rm -rf /tmp/apt-release-check
mkdir /tmp/apt-release-check || exit 1
cd /tmp/apt-release-check

>OK
>MISSING
>NOCHECK
>BAD

arch=`dpkg --print-installation-architecture`

am_root () {
        [ `id -u` -eq 0 ]
}

get_md5sumsize () {
        cat "$1" | awk '/^MD5Sum:/,/^SHA1:/' | 
          MYARG="$2" perl -ne '@f = split /\s+/; if ($f[3] eq $ENV{"MYARG"}) { 
print "$f[1] $f[2]\n"; exit(0); }'
}

checkit () {
        local FILE="$1"
        local LOOKUP="$2"

        Y="`get_md5sumsize Release "$LOOKUP"`"
        Y="`echo "$Y" | sed 's/^ *//;s/  */ /g'`"

        if [ ! -e "/var/lib/apt/lists/$FILE" ]; then
                if [ "$Y" = "" ]; then
                        # No file, but not needed anyway
                        echo "Succès"
                        return
                fi
                echo "$FILE" >>MISSING
                echo "$Y manquant"
                return
        fi
        if [ "$Y" = "" ]; then
                echo "$FILE" >>NOCHECK
                echo "Pas de vérification"
                return
        fi
        X="`md5sum < /var/lib/apt/lists/$FILE | cut -d\  -f1` `wc -c < /var/lib
/apt/lists/$FILE`"
        X="`echo "$X" | sed 's/^ *//;s/  */ /g'`"
        if [ "$X" != "$Y" ]; then
                echo "$FILE" >>BAD
                echo "Problème"
                return
        fi
        echo "$FILE" >>OK
        echo "Succès"
}

echo
echo "Vérification des sources dans /etc/apt/sources.list :"
echo "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"
echo
(echo "Vous devriez vous assurer que les distributions que vous téléchargez"
echo "sont bien celles que vous pensez télécharger, et qu'elle sont aussi à"
echo "jour que vous pourriez l'espérer (testing et unstable ne devraient pas"
echo "être désynchronisées de plus d'un jour ou deux, stable-updates pas plus"
echo "de quelques semaines ou un mois)."
) | fmt
echo

cat /etc/apt/sources.list | 
  sed 's/^ *//' | grep '^[^#]' |
  while read ty url dist comps; do
        if [ "${url%%:*}" = "http" -o "${url%%:*}" = "ftp" ]; then
                baseurl="${url#*://}"
        else
                continue
        fi

        echo "Source : ${ty} ${url} ${dist} ${comps}"

        rm -f Release Release.gpg
        lynx -reload -dump "${url}/dists/${dist}/Release" >/dev/null 2>1
        wget -q -O Release "${url}/dists/${dist}/Release"

        if ! grep -q '^' Release; then
                echo "  * Pas de fichier Release au premier niveau"
                >Release
        else
                origline=`sed -n 's/^Origin: *//p' Release | head -1`
                lablline=`sed -n 's/^Label: *//p' Release | head -1`
                suitline=`sed -n 's/^Suite: *//p' Release | head -1`
                codeline=`sed -n 's/^Codename: *//p' Release | head -1`
                dateline=`grep "^Date:" Release | head -1`
                dscrline=`grep "^Description:" Release | head -1`
                echo "  o Origine : $origline/$lablline"
                echo "  o Suite : $suitline/$codeline"
                echo "  o $dateline"
                echo "  o $dscrline"

                if [ "${dist%%/*}" != "$suitline" -a "${dist%%/*}" != "$codeline" ]; then
                        echo "  * Attention : $dist était demandée, $suitline/$codeline a été obtenue"
                fi

                lynx -reload -dump "${url}/dists/${dist}/Release.gpg" > /dev/null 2>&1
                wget -q -O Release.gpg "${url}/dists/${dist}/Release.gpg"

                gpgv --status-fd 3 Release.gpg Release 3>&1 >/dev/null 2>&1 | sed -n "s/^\[GNUPG:\] //p" | (okay=0; err=""; while read gpgcode rest; do
                        if [ "$gpgcode" = "GOODSIG" ]; then
                            if [ "$err" != "" ]; then
                                echo "  * Signé par ${err# } clef : ${rest#* }"
                            else
                                echo "  o Signé par : ${rest#* }"
                                okay=1
                            fi
                            err=""
                        elif [ "$gpgcode" = "BADSIG" ]; then
                            echo "  * Mauvaise signature par : ${rest#* }"
                            err=""
                        elif [ "$gpgcode" = "ERRSIG" ]; then
                            echo "  * Impossible de vérifier la signature par identifiant de clef : ${rest %% *}"
                            err=""
                        elif [ "$gpgcode" = "SIGREVOKED" ]; then
                            err="$err Révoquée"
                        elif [ "$gpgcode" = "SIGEXPIRED" ]; then
                            err="$err Expirée"
                        fi
                    done
                    if [ "$okay" != 1 ]; then
                        echo "  * Pas de signature valable"
                        >Release
                    fi)
        fi
        okaycomps=""
        for comp in $comps; do
                if [ "$ty" = "deb" ]; then
                        X=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/binary-${arch}/Release" | sed 's,//*,_,g'`" "${comp}/binary-${arch}/Release")
                        Y=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/binary-${arch}/Packages" | sed 's,//*,_,g'`" "${comp}/binary-${arch}/Packages")
                        if [ "$X $Y" = "OK OK" ]; then
                                okaycomps="$okaycomps $comp"
                        else
                                echo "  * Problèmes avec $comp ($X, $Y)"
                        fi
                elif [ "$ty" = "deb-src" ]; then
                        X=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/source/Release" | sed 's,//*,_,g'`" "${comp}/source/Release")
                        Y=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/source/Sources" | sed 's,//*,_,g'`" "${comp}/source/Sources")
                        if [ "$X $Y" = "OK OK" ]; then
                                okaycomps="$okaycomps $comp"
                        else
                                echo "  * Problèmes avec le composant $comp ($X, $Y)"
                        fi
                fi
        done
        [ "$okaycomps" = "" ] || echo "  o Okay:$okaycomps"
        echo
  done

echo "Résultat"
echo "~~~~~~~~"
echo

allokay=true

cd /tmp/apt-release-check
diff <(cat BAD MISSING NOCHECK OK | sort) <(cd /var/lib/apt/lists && find . -type f -maxdepth 1 | sed 's,^\./,,g' | grep '_' | sort) | sed -n 's/^> //p' >UNVALIDATED

cd /tmp/apt-release-check
if grep -q ^ UNVALIDATED; then
    allokay=false
    (echo "Les fichiers suivants de /var/lib/apt/lists n'ont pas été validés."
    echo "Cela peut soit être une simple indication inoffensive que ce script"
    echo "est bogué ou pas à jour, soit un indicateur de porte ouverte aux"
    echo "paquets de type chevaux de Troie sur le système."
    ) | fmt
    echo
    sed 's/^/    /' < UNVALIDATED
    echo
fi

if grep -q ^ BAD; then
    allokay=false
    (echo "Les contenus des fichiers suivants de /var/lib/apt/lists ne"
    echo "correspondent pas à ce qui était attendu. Cela peut signifier que"
    echo "ces sources ne sont pas à jour, qu'il y a un problème d'archive,"
    echo "ou que quelqu'un est en train d'utiliser le miroir pour distribuer"
    echo "des chevaux de Troie."
    if am_root; then 
        echo "Les fichiers ont été renommés avec l'extension .FAILED et"
        echo "seront ignorés par apt."
        cat BAD | while read a; do
            mv /var/lib/apt/lists/$a /var/lib/apt/lists/${a}.FAILED
        done
    fi) | fmt
    echo
    sed 's/^/    /' < BAD
    echo
fi

if grep -q ^ MISSING; then
    allokay=false
    (echo "Les fichiers suivants de /var/lib/apt/lists manquaient. Cela"
    echo "pourrait vous faire manquer des mises à jours de paquets vulnérables."
    ) | fmt
    echo
    sed 's/^/    /' < MISSING
    echo
fi

if grep -q ^ NOCHECK; then
    allokay=false
    (echo "Les contenus des fichiers suivants de /var/lib/apt/lists n'ont pas"
    echo "pu être validés à cause d'un manque de fichier Release signé, ou"
    echo "d'un manque d'entrée appropriée dans un fichier Release signé. Cela"
    echo "signifie probablement que les mainteneurs de ces sources sont"
    echo "négligents, mais pourrait signifier que ces sources sont en cours"
    echo "d'utilisation pour distribuer des chevaux de Troie."
    if am_root; then 
        echo "Les fichiers ont été renommés avec l'extension .FAILED et"
        echo "seront ignorés par apt."
        cat NOCHECK | while read a; do
            mv /var/lib/apt/lists/$a /var/lib/apt/lists/${a}.FAILED
        done
    fi) | fmt
    echo
    sed 's/^/    /' < NOCHECK
    echo
fi

if $allokay; then
    echo 'Tout semble se passer correctement !'
    echo
fi

rm -rf /tmp/apt-release-check
Vous pourriez devoir ajouter le correctif suivant pour Sid car md5sum ajoute un « - » après la somme quand l'entrée provient de l'entrée standard :
@@ -37,7 +37,7 @@
        local LOOKUP="$2"

        Y="`get_md5sumsize Release "$LOOKUP"`"
-       Y="`echo "$Y" | sed 's/^ *//;s/  */ /g'`"
+       Y="`echo "$Y" | sed 's/-//;s/^ *//;s/  */ /g'`"

        if [ ! -e "/var/lib/apt/lists/$FILE" ]; then
                if [ "$Y" = "" ]; then
@@ -55,7 +55,7 @@
                return
        fi
        X="`md5sum < /var/lib/apt/lists/$FILE` `wc -c < /var/lib/apt/lists/$FILE`"
-       X="`echo "$X" | sed 's/^ *//;s/  */ /g'`"
+       X="`echo "$X" | sed 's/-//;s/^ *//;s/  */ /g'`"
        if [ "$X" != "$Y" ]; then
                echo "$FILE" >>BAD
                echo "BAD"

7.5.4. Vérification de distribution pour les sources non Debian

Notez que, lors de l'utilisation de la dernière version d'apt (avec apt sécurisé), aucun effort supplémentaire ne devrait être nécessaire de votre part sauf si vous utilisez des sources non Debian, auquel cas une étape de confirmation supplémentaire sera imposée par apt-get. C'est évité en fournissant les fichiers Release et Release.gpg dans les sources non Debian. Le fichier Release peut être généré avec apt-ftparchive (disponible dans apt-utils 0.5.0 et ultérieur), le fichier Release.gpg est simplement une signature détachée. Pour générer les deux fichiers, suivez cette procédure simple :
$ rm -f dists/unstable/Release
$ apt-ftparchive release dists/unstable > dists/unstable/Release
$ gpg --sign -ba -o dists/unstable/Release.gpg dists/unstable/Release

7.5.5. Schéma alternatif de signature par paquet

Le schéma supplémentaire de signature de chacun des paquets permet aux paquets d'être vérifiés quand ils ne sont plus référencés par un fichier Packages existant, et également pour les paquets de tierce partie dont aucun Packages n'a jamais existé, pour qu'ils puissent être utilisés dans Debian, mais ce ne sera pas le schéma par défaut.
Ce schéma de signature des paquets peut être implémenté en utilisant debsig-verify et debsigs. Ces deux paquets peuvent signer et vérifier des signatures intégrées au .deb lui-même. Debian a déjà la capacité de faire cela actuellement, mais il n'y a aucun projet de mettre en place une charte ou d'autres outils puisque la signature de l'archive est préférée. Ces outils sont disponibles aux utilisateurs et aux administrateurs d'archive qui pourraient préférer utiliser ce schéma.
Les dernières versions de dpkg (à partir de la version 1.9.21) contiennent un htttp://lists.debian.org/debian-dpkg/2001/debian-dpkg-200103/msg00024.html qui fournit cette fonctionnalité dès que debsig-verify est installé.
Note : actuellement, /etc/dpkg/dpkg.cfg est livré avec « no-debsig » par défaut.
Seconde note : les signatures des développeurs sont actuellement enlevées lors de l'entrée du paquet dans l'archive car la méthode actuellement préférée est par vérification de distribution comme décrit précédemment.


[56] Certains systèmes d'exploitation ont déjà été touchés par des problèmes de mises à jour automatiques comme la htttp://www.cunap.com/~hardingr/projects/osx/exploit.html.
[57] Les versions plus anciennes, comme Debian 3.1 Sarge peuvent utiliser cette fonctionnalité en utilisant les versions rétroportées de cet outil de gestion de paquets.
[58] Jusqu'à ce qu'un mécanisme automatique ne soit développé.
[59] D'un point de vue technique, c'est une signature ASCII-armored détachée.
[60] Ou ayant empoisonné le DNS, ou usurpant le serveur, ou ayant remplacé le fichier sur le miroir utilisé, etc.
[61] « ziyi » est le nom de l'outil utilisé pour signer sur les serveurs Debian, le nom vient du nom d'une htttp://fr.wikipedia.org/wiki/Zhang_Ziyi.
[62] Toutes les clefs de dépôt apt ne sont pas encore signées par une autre clef. Peut-être que la personne qui a mis en place le dépôt n'a pas d'autre clef, ou peut-être que ça ne lui plaît pas de signer une telle clef de rôle avec sa clef principale. Pour des renseignements au sujet de la mise en place d'une clef de dépôt, consultez Section 7.5.4, « Vérification de distribution pour les sources non Debian ».
[63] Soit parce que vous utilisez la version stable Sarge ou une version plus ancienne, soit parce que vous ne voulez pas utiliser la dernière version d'apt, bien que nous apprécierions qu'elle soit testée