Debian possède une équipe de sécurité, composée de cinq membres et deux secrétaires, qui gère la sécurité dans la distribution stable. Gérer la sécurité veut dire qu'ils suivent les failles qui surviennent dans les logiciels (en surveillant des forums comme bugtraq ou vuln-dev) et ils déterminent si la distribution stable est touchée par ces failles.
L'équipe de sécurité Debian est également le point de contact pour les
problèmes qui sont coordonnées par les développeurs amont ou des organisations
comme le CERT
, qui peuvent
toucher de multiples vendeurs. C'est-à-dire, quand les problèmes ne sont pas
spécifiques à Debian. Il existe deux points de contact avec l'équipe de
sécurité :
team@security.debian.org
qui
n'est lu que par les membres de l'équipe de sécurité.
security@debian.org
qui
est lu par tous les développeurs Debian (y compris l'équipe de sécurité). Les
messages envoyés sur cette liste ne sont pas publiés sur l'Internet (ce n'est
pas une liste publique).
Les informations secrètes devraient être envoyées à la première adresse et, dans certains cas, devraient être cryptées avec la clé du contact de l'équipe de sécurité (key ID 363CCD95).
Une fois qu'un problème probable est reçu par l'équipe de sécurit, elle
recherchera si la distribution stable est affectée et si c'est le cas,
un correctif sera créé pour la base de code source. Ce correctif inclura
parfois un rétro-portage du correctif effectué en amont (qui est habituellement
en avance de plusieurs version par rapport à la version distribuée par Debian).
Après qu'un test du correctif ait été effectué, les nouveaux paquets sont
préparés et publiés sur le site security.debian.org
pour pouvoir être
récupéré par apt
(voir Se
mettre à jour au niveau de la sécurité, Section 4.2). En même temps, une
alerte de sécurité Debian (Debian Security Advisory ou DSA) est
publiée sur le site web et envoyée aux listes de diffusion publiques y compris
debian-security-announce
et bugtraq.
D'autres questions souvent posées sur l'équipe de sécurité Debian peuvent être trouvées à Questions concernant l'équipe de sécurité Debian, Section 11.3.
Les alertes de sécurité Debian sont effectuées à chaque fois qu'une faille est découverte affectant un paquet Debian. Ces alertes, signées par l'un des membres de l'équipe de sécurité, incluent des informations sur les versions touchées ainsi que l'emplacement des mises à jour et leurs MD5sums. Ces informations sont :
Les DSA sont publiées sur la page
principale de Debian
et dans les pages de sécurité Debian
.
Ceci ne se produit habituellement pas avant que le site web ne soit reconstruit
(une fois par jour), elles peuvent donc ne pas être immédiatement présentes, le
canal préféré est la liste de diffusion debian-security-announce.
Les utilisateurs intéressées peuvent, cependant (et ceci est fait sur quelques
portails relatifs à Debian) utiliser le canal RDF pour télécharger
automatiquement les DSA sur leur bureau. Certaines applications, comme
Evolution
(un client de messagerie et assistant d'informations
personnelles) et Multiticker
(une applet GNOME) peuvent être
utilisés pour récupérer les alertes automatiquement. Le canal RDF est
disponible à http://www.debian.org/security/dsa.rdf
.
Les DSA publiées sur le site web peuvent être mises à jour après avoir été envoyées sur les listes de diffusion publiques. Une mise à jour courante est d'ajouter des références croisées vers les bases de données des failles de sécurité. Les traductions [39] des DSA ne sont pas envoyées aux listes de diffusion de sécurité, mais elles sont directement incluses sur le site web.
Debian fournit une table de références
croisées
complète comprenant toutes les références disponibles pour
toutes les alertes publiées depuis 1998. Cette table est fournie en
complément de la carte des
références disponible pour le CVE
.
Vous pourrez noter que cette table fournit des références vers des bases de
données de sécurité comme Bugtraq
, les alertes CERT/CC
et la
base de données des notes failles
US-CERT
ainsi que les noms CVE (voir ci-dessous). Ces références
sont fournis pour faciliter l'utilisation, mais seules les références CVE sont
périodiquement vérifiées et incluses. Cette fonctionnalité a été ajoutée au
site web en juin 2002.
L'un des avantages d'ajouter les références croisées vers ces bases de données de failles est que :
Les alertes de sécurité Debian ont été déclarées comme étant
compatibles CVE
[40]
le 24 février 2004.
Les développeurs Debian comprennent la nécessité de fournir une information
précise et à jour de l'état de sécurité de la distribution Debian, permettant
aux utilisateurs de gérer le risque associé aux nouvelles failles de sécurité.
CVE nous permet de fournir des références standardisées qui permettent aux
utilisateurs de développer un processus de gestion
de sécurité avec CVE
.
Le projet Common Vulnerabilities and
Exposures (CVE)
est maintenu par la société MITRE et fournit une
liste des noms standardisés pour les failles et expositions de sécurité.
Debian croit que fournir aux utilisateurs des informations supplémentaires liées aux problèmes de sécurité qui touchent la distribution Debian est extrêmement important. L'inclusion des noms CVE dans les alertes aide les utilisateurs à associer des failles génériques avec les mises à jour spécifiques de Debian, ce qui réduit le temps passé à gérer les failles qui concernent nos utilisateurs. Cela facilite également la gestion du risque dans un environnement où sont déployés des outils de sécurité gérant CVE — comme des systèmes de détection d'intrusion d'hôte ou de réseau ou des outils de vérification de failles — qu'ils soient ou non basés sur la distribution Debian.
Debian a commencé à ajouter les noms CVE aux DSA en juin 2002 et fournit
maintenant les noms CVA pour toutes les DSA publiées depuis septembre 1998
après un processus de vérification commencé en août 2002. Toutes les
alertes peuvent être récupérées sur le site web Debian et les annonces liées
aux nouvelles failles incluent les noms CVS quand ils sont disponibles lors de
leur publication. Les alertes liées à un nom de CVE donné peuvent être
cherchées directement avec le moteur
de rechercher
.
Les utilisateurs désirant chercher un nom particulier de CVE peuvent utiliser
le moteur de recherche disponible sur debian.org pour récupérer les alertes
disponibles (en anglais et traduites dans d'autres langues) associées aux noms
CVE. Une recherche peut être faite avec un nom spécifique (comme alerte
CAN-2002-0001
)
ou pour des noms partiels (comme une recherche de tous les candidats 2002
inclus dans des alertes pour CAN-2002
).
Notez que vous devez entrer lie mot clé alerte (« advisory » en
anglais) avec le nom CVE pour ne récupérer que les alertes de sécurité.
Dans certains cas, vous pouvez ne pas trouver un nom de CVE donné dans les alertes publiées parce que :
bogue de
sécurité
, mais aucune correction n'a encore été testée et envoyée),
Comme Debian supporte actuellement un grand nombre d'architectures, les administrateurs se demandent parfois si une architecture donnée pourrait prendre plus de temps pour recevoir des mises à jour de sécurité qu'une autre. En fait, à l'exception de rares circonstances, les mises à jour sont disponibles pour toutes les architectures en même temps.
Alors que précédemment la tâche de construction des mises à jour de sécurité
était faite à la main, ce n'est plus actuellement le cas (comme le décrit
Anthony Towns dans un
courriel
envoyé à la liste de diffusion debian-devel-announce daté
du 8 juin 2002).
Les paquets envoyés par l'équipe de sécurité (à security.debian.org:/org/security.debian.org/queue/unchecked
ou ftp://security.debian.org/pub/SecurityUploadQueue
)
avec un correctif approprié voient leur signature vérifiée dans les quinze
minutes après l'envoi, une fois ceci fait, ils sont ajoutés à la liste des
autoconstructeurs (qui n'est plus une exécution d'archive journalière). Les
paquets sont donc automatiquement construits pour toutes les
architectures trente minutes ou une heure après leur envoi. Cependant, les
mises à jour de sécurité sont un petit peu différentes que les envois normaux
par les responsables de paquets car, dans certains cas, avant d'être publiées,
elles doivent attendre de pouvoir être plus testées, qu'une alerte soit rédigée
ou attendre une semaine ou plus pour éviter de publier le défaut jusqu'à ce que
tous les vendeurs aient eu une chance raisonnable de le corriger.
L'archive d'envoi de sécurité fonctionner donc de la façon suivante (dénommée "Accepted-Autobuilding") :
dpkg-scanpackages
,
dpkg-scansources
, etc.),
Cette procédure, auparavant fait à la main, a été testé et mise en place pendant l'étape de gel de Debian 3.0 woody (juillet 2002). Grâce à cette architecture, l'équipe de sécurité a pu avoir des paquets mis à jour pour les problèmes d'Apache et d'OpenSSH pour toutes les architectures supportées (presque vingt) en moins d'un jour.
Ce message a été envoyé par Wichert Akkerman à la liste
de diffusion debian-devel-announce
pour décrire le comportement des
développeurs Debian pour la gestion des problèmes de sécurité dans leurs
paquets. Il est publié ici à la fois pour le bénéfice des développeurs ainsi
que pour que les utilisateurs comprennent mieux comment est gérée la sécurité
dans Debian.
Veuillez noter que la référence à jour pour cette information est la référence
du développeur Debian
, cette section sera supprimée dans un avenir
proche.
Si un développeur apprend un problème de sécurité soit dans son paquet ou dans celui de quelqu'un d'autre, il devrait toujours contacter l'équipe de sécurité (à team@security.debian.org). Il suivent les problèmes de sécurité existants, ils peuvent aider les responsables avec des problèmes de sécurité ou les corriger eux-même, ils sont responsables de l'envoi des alertes de sécurité et maintiennent security.debian.org.
Veuillez noter que les alertes de sécurité ne sont effectuées que pour des distributions stables, pas pour testing, unstable (voir Comment est assurée la sécurité pour les versions testing et unstable ?, Section 11.3.7) ou d'anciennes distributions (voir Je possède un ancienne version de Debian, est-elle supportée par l'équipe de sécurité Debian ?, Section 11.3.8).
Il existe plusieurs façons pour un développeur de prendre connaissance d'un problème de sécurité :
Dans les deux premiers cas, l'information est publique et il est important d'avoir une solution le plus vite possible. Dans le dernier cas, cependant, ce n'est peut-être pas une information publique. Dans ce cas, il existe quelques options possibles pour traiter le problème :
Dans tous les cas, si la personne qui indique le problème demande à ce que l'information ne soit pas diffusée, cela devrait être respecté avec l'évidente exception d'informer l'équipe de sécurité (le développeur devrait s'assurer de dire à l'équipe de sécurité que l'information ne peut être dévoilée).
Veuillez noter que si le secret est nécessaire, vous ne pourrez pas envoyer un correctif vers unstable (ou ailleurs) puisque les informations de changelog sont publiques.
Il existe deux raisons pour diffuser l'information même si le secret est demandé : le problème est connu depuis un certain temps ou le problème est devenu public.
La règle la plus important lors de la construction d'un nouveau paquet corrigeant un problème de sécurité est de faire aussi peu de modifications que possible. Les personnes s'attendent à un comportement identique dans une version lorsque celle-ci est diffusée, donc tout changement qui est fait est susceptible de casser le système de quelqu'un. Ceci est spécialement vrai pour les bibliothèques : assurez-vous de ne jamais changer l'API ou l'ABI, quelque minimal que soit le changement.
Cela veut dire que passer à une version amont supérieure n'est pas une bonne solution. À la place, les changements pertinents devraient être rétroportés. Habituellement, les développeurs amont veulent bien aider. Sinon, l'équipe de sécurité Debian peut le faire.
Dans certains cas, il n'est pas possible de rétroporter un correctif de sécurité, par exemple, quand de grandes quantités de code source doivent être modifiées ou réécrites. Si cela se produit, il peut être nécessaire de passer à une nouvelle version amont, mais vous devez toujours coordonner cela avec l'équipe de sécurité au préalable.
Il existe une autre règle de conduite liée à cela : les développeurs doivent toujours tester leurs changements. Si une exploitation du problème existe, essayez-la et vérifiez qu'elle réussit sur le paquet non corrigé et échoue sur le paquet corrigé. Testez aussi les autres actions normales car parfois un correctif de sécurité peut casser de manière subtile des fonctionnalités normales.
Enfin, quelques points techniques que les développeurs doivent garder à l'esprit :
buildd
ne construira pas
ceux-ci.
pbuilder
et debootstrap
peuvent
s'avérer utiles dans ce cas).
Une fois que le développeur a créé et testé le nouveau paquet, il doit être envoyé pour être installé dans l'archive. Pour les envois de sécurité, l'adresse d'envoi est ftp://security.debian.org/pub/SecurityUploadQueue/.
Une fois que l'envoi vers la file d'attente de sécurité a été accepté, le paquet sera automatiquement recompilé pour toutes les architectures et stocké pour vérification par l'équipe de sécurité.
Les envois en attente d'acceptation ou de vérification ne sont accessibles que par l'équipe de sécurité. C'est nécessaire car il pourrait y avoir des correctifs pour des problèmes de sécurité qui ne peuvent pas encore être diffusés.
Si une personne de l'équipe de sécurité accepte un paquet, il sera installé sur security.debian.org ainsi que dans le répertoire <nomdecode>-proposed-updates qui convient sur ftp-master ou dans l'archive non-US.
Les alertes de sécurité sont écrites et envoyées par l'équipe de sécurité. Cependant, ils ne verront aucun inconvénient à qu'un responsable fournisse (une partie) du texte pour eux. Les informations qui devraient être présentes dans une alerte sont décrites dans Alertes de sécurité Debian, Section 7.2.
Ce chapitre pourrait également être intitulé « comment améliorer/actualiser sûrement votre système Debian GNU/Linux » et il 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 sur l'homme-du-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 pourrait favoriser la propagation de chevaux de Troie et la compromission de systèmes lors des mises à jour [41].
À ce jour (mai 2005), Debian ne fournit pas de paquets signés pour la distribution et les versions Woody (3.0) et Sarge (3.1) n'intègrent pas cette fonctionnalité. Il existe une solution pour les paquets signés qui sera, espérons-le, fournie dans la prochaine version (Etch). Cette nouvelle fonctionnalité sera disponible dans apt 0.6 (actuellement disponible dans la distribution experimental, voir Paquets apt expérimentaux, Section 7.4.4).
Ce problème est mieux décrit dans le Strong
Distribution HOWTO
par V. Alex Brennen.
Le schéma actuel pour la vérification de signatures de paquet en utilisant
apt
est :
En suivant la chaîne de sommes MD5, apt
est capable de vérifier
qu'un paquet est originaire d'une version bien spécifique. Ceci est moins
souple que de signer chaque paquet un par un, mais peut être combiné également
avec ce schéma suivant (voir ci-dessous).
Actuellement, ce schéma est complètement
implémenté
dans apt 0.6 ; pour plus d'informations, voir
Paquets apt expérimentaux, Section 7.4.4. 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é
modifié
pour être adapté à ce schéma.
La signature de paquets a été abordée dans Debian depuis pas mal de temps déjà,
pour plus d'informations vous pouvez lire : http://www.debian.org/News/weekly/2001/8/
et http://www.debian.org/News/weekly/2000/11/
.
Au cas où vous voudriez ajouter des vérifications de sécurité supplémentaires et que vous ne vouliez pas utiliser la version d'apt d'experimental (bien que vous apprécierions qu'elle soit testée), vous pouvez utiliser le script ci-dessous fourni par Anthony Thown. 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 instable 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 :
http://ftp-master.debian.org/ziyi_key_2003.asc
,
et les ajouter à ~/.gnupg/trustedkeys.gpg
(ce qui est ce que
gpgv
utilise par défaut).
gpg --no-default-keyring --keyring trustedkeys.gpg --import ziyi_key_2003.asc
/etc/apt/sources.list
qui n'utilisent
pas la structure normale « dists » ou changer le script afin qu'il
fonctionne avec elles.
Ceci est le code exemple pour apt-check-sigs
, la dernière version
peut être récupérée depuis http://people.debian.org/~ajt/apt-check-sigs
.
Ce code est actuellement en bêta, pour plus d'informations, lisez http://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 "OK" return fi echo "$FILE" >>MISSING echo "MISSING $Y" return fi if [ "$Y" = "" ]; then echo "$FILE" >>NOCHECK echo "NOCHECK" 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 "BAD" return fi echo "$FILE" >>OK echo "OK" } echo echo "Checking sources in /etc/apt/sources.list:" echo "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~" echo (echo "You should take care to ensure that the distributions you're downloading " echo "are the ones you think you are downloading, and that they are as up to" echo "date as you would expect (testing and unstable should be no more than" echo "two or three days out of date, stable-updates no more than a few weeks" echo "or a month)." ) | 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 " * NO TOP-LEVEL Release FILE" >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 Origin: $origline/$lablline" echo " o Suite: $suitline/$codeline" echo " o $dateline" echo " o $dscrline" if [ "${dist%%/*}" != "$suitline" -a "${dist%%/*}" != "$codeline" ]; then echo " * WARNING: asked for $dist, got $suitline/$codeline" 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 " * Signed by ${err# } key: ${rest#* }" else echo " o Signed by: ${rest#* }" okay=1 fi err="" elif [ "$gpgcode" = "BADSIG" ]; then echo " * BAD SIGNATURE BY: ${rest#* }" err="" elif [ "$gpgcode" = "ERRSIG" ]; then echo " * COULDN'T CHECK SIGNATURE BY KEYID: ${rest %% *}" err="" elif [ "$gpgcode" = "SIGREVOKED" ]; then err="$err REVOKED" elif [ "$gpgcode" = "SIGEXPIRED" ]; then err="$err EXPIRED" fi done if [ "$okay" != 1 ]; then echo " * NO VALID SIGNATURE" >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 " * PROBLEMS WITH $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 " * PROBLEMS WITH component $comp ($X, $Y)" fi fi done [ "$okaycomps" = "" ] || echo " o Okay:$okaycomps" echo done echo "Results" 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 "The following files in /var/lib/apt/lists have not been validated." echo "This could turn out to be a harmless indication that this script" echo "is buggy or out of date, or it could let trojaned packages get onto" echo "your system." ) | fmt echo sed 's/^/ /' < UNVALIDATED echo fi if grep -q ^ BAD; then allokay=false (echo "The contents of the following files in /var/lib/apt/lists does not" echo "match what was expected. This may mean these sources are out of date," echo "that the archive is having problems, or that someone is actively" echo "using your mirror to distribute trojans." if am_root; then echo "The files have been renamed to have the extension .FAILED and" echo "will be ignored by 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 "The following files from /var/lib/apt/lists were missing. This" echo "may cause you to miss out on updates to some vulnerable packages." ) | fmt echo sed 's/^/ /' < MISSING echo fi if grep -q ^ NOCHECK; then allokay=false (echo "The contents of the following files in /var/lib/apt/lists could not" echo "be validated due to the lack of a signed Release file, or the lack" echo "of an appropriate entry in a signed Release file. This probably" echo "means that the maintainers of these sources are slack, but may mean" echo "these sources are being actively used to distribute trojans." if am_root; then echo "The files have been renamed to have the extension .FAILED and" echo "will be ignored by 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 'Everything seems okay!' echo fi rm -rf /tmp/apt-release-check
Il est possible que vous deviez ajouter le correctif suivant pour Sid
car md5sum
ajoute un '-' après la somme quand l'entrée est
stdin :
@@ -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"
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 quand aucun paquet n'a jamais existé pour ceux-ci qui puisse être utilisé 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 incluses dans le .deb lui-même. Debian a
déjà la capacité de faire cela actuellement, mais l'implémentation de cette
règle et des outils ne commencera pas avant la sortie de Woody.
Les dernières versions de dpkg (à partir de la version 1.9.21) incluent un
correctif
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.
Note2 : 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 des vérifications de version comme décrit précédemment.
La version 0.6 d'apt inclut apt-secure qui est un outil
permettant à l'administrateur système de tester l'intégrité des paquets
téléchargés par le schéma ci-dessus. Cette version inclut l'outil
apt-key
pour ajouter de nouvelles clés au porte-clés d'apt qui
n'inclut par défaut que la clé actuelle de signature de l'archive Debian.
Si vous voulez tester cette fonctionnalité, vous devrez ajouter la distribution
experimental à votre sources.list
et exécuter :
# apt-get -t experimental install apt
Ces changements sont basés sur un correctif pour apt
(disponible
dans le bogue n°\|[nbsp
]\|203741
) qui fournit cette implémentation.
Cette fonctionnalité est encore en développement, donc si vous croyez avoir
trouvé des bogues dans ce paquet, veuillez vérifier en premier que vous
utilisez la dernière version (car ce paquet peut beaucoup changer avant d'être
diffusé) et si vous utilisez la dernière version, créez un bogue sur le paquet
apt
en utilisant l'étiquette experimental.
Notez que, lors de l'utilisation de la version expérimentale d'apt, 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. Ceci 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
Manuel de sécurisation de Debian
Version: 3.2, Mon, 16 May 2005 21:28:01 +0200jfs@debian.org
debian-l10n-french@lists.debian.org