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.
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).
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.
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.
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
, 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
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.
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
.
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
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.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.
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.