security/faq.wml
Bonjour,
Voici une toute petite correction...
--
Migrec
#use wml::debian::template title="FAQ de l'équipe Debian sur la sécurité"
#use wml::debian::translation-check translation="1.29" maintainer="DFS Task Force"
#include "$(ENGLISHDIR)/security/faq.inc"
<p>Ces derniers jours, nous avons reçu un peu trop souvent des questions
identiques, et avons donc décidé d'écrire cette page pour y répondre
globalement.</p>
<maketoc>
<toc-add-entry name=signature>La signature sur vos avis de sécurité ne semble pas authentique !</toc-add-entry>
<p>Réponse : Il s'agit très certainement d'un problème de votre part. La liste
<a href="http://lists.debian.org/debian-security-announce/">\
debian-security-announce</a> a un filtre qui n'autorise que les messages
avec une signature valide d'un des membres de l'équipe chargée de la
sécurité.</p>
<p>Un de vos outils de messagerie doit légèrement modifier le message,
ce qui corrompt la signature. Vérifiez que vos logiciels ne font pas
d'encodage/décodage sur les types MIME, ou de substitutions entre
espaces et tabulations.</p>
<p>Les coupables habituels sont fetchmail (avec l'option mimedecode
activée), formail (venant de procmail 3.14 seulement) et evolution.</p>
<toc-add-entry name="handling">Comment s'occupe-t-on de la sécurité dans
Debian ?</toc-add-entry>
<p>R. : Une fois que l'équipe en charge de la sécurité reçoit
notification d'un incident, un ou plusieurs de ses membres examinent
la situation et en mesurent l'impact sur la version stable de Debian
(<i>i.e.</i> si elle est vulnérable ou non). Si notre système est
vulnérable, nous élaborons une correction au problème. Le
responsable du paquet est lui aussi contacté, s'il n'a pas déjà
contacté l'équipe en charge de la sécurité. Enfin, la correction est
testée et de nouveaux paquets sont préparés ; ces paquets sont
compilés sur toutes les architectures stables et ensuite mis en
téléchargement. Après toutes ces étapes, un rapport est publié.</p>
<toc-add-entry name=oldversion>Pourquoi vous cassez vous la tête avec une
vieille version de ce paquet ?</toc-add-entry>
<p>La règle la plus importante lorsque l'on construit un nouveau paquet qui
corrige un problème de sécurité est de faire le moins de changements
possibles. Nos utilisateurs et nos développeurs s'attendent à ce que la
distribution conserve son comportement d'origine, aussi n'importe
quel changement que nous faisons peut éventuellement casser
le système de quelqu'un. C'est particulièrement vrai dans le cadre
des bibliothèques : assurez-vous de ne jamais changer l'interface de
programmation du programme (API) ou l'interface binaire de l'application
(ABI : <i>Application Binary Interface</i>), aussi petite soit la
modification.</p>
<p>Cela signifie que changer pour une version plus récente n'est pas une
bonne solution, au lieu de cela la modification doit être rétro-portée.
En règle générale les auteurs donnent un coup de main, sinon l'équipe
en charge de la sécurité devrait être capable de s'en charger.</p>
<p>Dans des cas particuliers il n'est pas possible de rétro-porter une rustine
de sécurité, par exemple lorsqu'une grande partie du code source doit
être modifiée ou ré-écrite. Si cela survient, il sera nécessaire de passer
à une nouvelle version des fichiers sources, mais cela devra se faire
avec la participation de l'équipe en charge de la sécurité.</p>
<toc-add-entry name=policy>Quelle est la politique pour qu'un paquet stable
apparaisse dans security.debian.org ?</toc-add-entry>
<p>R. : Un trou de sécurité dans la distribution stable justifie un
paquet sur security.debian.org. Le reste non. La taille de ce trou
n'est pas un réel critère ici. Habituellement, l'équipe chargée de la
sécurité prépare les paquets en lien étroit avec le responsable du
paquet. L'un d'eux (de confiance) indique les causes du problème,
corrige et compile tous les paquets incriminés, puis les envoie à
l'équipe chargée de la sécurité. Même si le problème de sécurité est
trivial à corriger, la correction est placée sur
security.debian.org. Veuillez lire ci-dessous.</p>
<p>Les mises à jour de sécurité ont un objectif : fournir une rustine pour
une faille de sécurité. Ces mises à jour n'ont pas vocation à
intégrer d'autres modifications dans la version stable stable qui
outrepasseraient les règles normales qui composent la procédure de
publication.</p>
<toc-add-entry name=version>Le numéro de version d'un paquet m'indique que
j'utilise toujours une version vulnérable !</toc-add-entry>
<p>R. : Au lieu de passer à une nouvelle version, nous réalisons un
rétro-portage (« <i>backport</i> ») de la rustine de
sécurité vers la version fournie dans la distribution stable. La
raison pour laquelle nous faisons cela est qu'une version publiée
(« <i>release</i> ») change aussi peu que possible ;
ainsi les rustines de sécurité ne seront pas la cause de problèmes
annexes. Vous pouvez savoir si vous utilisez une version sécurisée
d'un paquet en examinant le ChangeLog du paquet, ou en comparant son
numéro exact de version et celui indiqué par le bulletin d'alerte de
l'équipe Debian chargée de la sécurité.</p>
<toc-add-entry name=testing>Comment est gérée la sécurité pour <tt>testing</tt>
et <tt>unstable</tt> ?</toc-add-entry>
<p>R. : La réponse courte est : elle ne l'est pas. Testing et unstable
évoluent rapidement et l'équipe chargée de la sécurité n'a pas les
ressources nécessaires pour faire ce travail correctement. Si vous
souhaitez un serveur sûr (et stable), vous êtes fortement encouragés
à rester sur la distribution stable. Cependant, les membres de l'équipe
en charge de la sécurité essayeront de corriger les problèmes dans
<i>testing</i> et <i>unstable</i> une fois qu'ils auront été corrigés dans
la version stable.</p>
<toc-add-entry name=mirror>Pourquoi n'y a-t-il pas de miroirs officiels de
security.debian.org ?</toc-add-entry>
<p>R. : Le but de security.debian.org est de rendre les mises à jour pour
raisons de sécurité disponibles aussi rapidement que possible.
<p>Encourager l'utilisation des sites miroirs ne ferait qu'ajouter de
la complexité là où elle n'est pas nécessaire, et pourrait causer des
problèmes s'ils n'étaient pas à jour. Cependant, nous prévoyons d'utiliser
de tels miroirs dans le futur.</p>
<toc-add-entry name=missing>J'ai vu les DSA 100 et DSA 102,
mais où est le DSA 101 ?</toc-add-entry>
<p>R. : plusieurs distributeurs (la plupart de GNU/Linux, mais aussi des
dérivés BSD) coordonnent leurs avis de sécurité pour certains
incidents et se mettent d'accord sur une date de parution, afin de
permettre aux distributeurs de sortir l'avis en même temps. Cela a
été décidé afin de ne pas faire de tort à certains distributeurs qui
ont besoin de plus de temps (par exemple lorsque le distributeur doit
passer par de longues phases de tests imposées par son assurance
qualité, ou doit fournir des solutions sur une multitude
d'architectures). Notre propre équipe en charge de la sécurité
prépare ainsi ses avis à l'avance. De temps en temps, d'autres
problèmes de sécurité doivent être traités avant que l'avis en
attente ne soit rendu public, et ainsi la continuité de la
numérotation est temporairement rompue.</p>
<toc-add-entry name=contact>Comment puis-je contacter l'équipe chargée de la
sécurité ?</toc-add-entry>
<p>R. : Les informations relatives à la sécurité peuvent être envoyées à
security@debian.org, qui est censée être lue par tous les développeurs
Debian. Si vous avez des informations sensibles, veuillez les envoyer à
team@security.debian.org qui n'est lue que par les membres de l'équipe
chargée de la sécurité. Si nécessaire, le message peut-être crypté
avec la clé publique du contact sécurité Debian (ID <a
href="http://blackhole.pca.dfn.de:11371/pks/lookup?op=get&exact=on&search=0x363CCD95">\
0x363CCD95)</a>.</p>
<toc-add-entry name=discover>Je pense avoir trouvé un problème de sécurité,
que suis-je censé faire ?</toc-add-entry>
<p>R. : Si vous êtes informé de l'existence d'un problème de sécurité,
soit dans un de vos paquets, soit dans le paquet de quelqu'un d'autre,
prenez systématiquement contact avec l'équipe en charge de la sécurité.
Si l'équipe en charge de la sécurité confirme la faille et que les autres
distributeurs sont également concernés, ils prennent également contact avec
les autres revendeurs. Si la vulnérabilité ne peut pas être publiée,
ils essaient de coordonner les annonces de sécurité avec les autres
revendeurs, ainsi les principales distributions sont synchronisées.</p>
<p>Si vous êtes un développeur Debian, <a href="#care">regardez
ci-dessous</a>.</p>
<toc-add-entry name=care>Que suis-je censé faire si l'un de mes paquets
présente un problème de sécurité ?</toc-add-entry>
<p>R. : Si vous entendez parler d'un problème de sécurité, soit
dans votre paquet soit dans le paquet de quelqu'un d'autre, vous
devez toujours prendre contact avec l'équipe en charge de la
sécurité. Vous pouvez les contacter par courriel à l'adresse
team@security.debian.org. Cette équipe s'occupe du suivi des
problèmes de sécurité, peut aider les responsables de paquets à
corriger les problèmes de sécurité ou les corrigent eux-mêmes, est
responsable de l'envoi des bulletins d'alerte de sécurité et est
responsable du site security.debian.org.</p>
<p>La <a href="$(DOC)/developers-reference/ch-pkgs#s-bug-security">\
référence du développeur</a> contient les instructions complètes sur
la démarche à suivre.</p>
<p>Il est très important que vous ne mettiez pas en ligne vos paquets ailleurs
que dans la distribution <i>unstable</i> sans y avoir été préalablement
invité par l'équipe en charge de la sécurité. Si vous ne respectez pas
cette règle, cela entrainera de la confusion et nécessitera plus de
travail.</p>
<toc-add-entry name=enofile>J'ai essayé de télécharger un paquet contenu dans un
bulletin d'alerte, mais j'ai eu une erreur comme quoi le fichier n'est pas
trouvé.</toc-add-entry>
<p>R. : À chaque fois qu'une nouvelle correction de bogue de
sécurité intervient sur un paquet de security.debian.org, les
chances sont grandes que l'ancien paquet soit supprimé, ce qui
entraine ce message d'erreur. Nous ne voulons pas distribuer des
paquets avec des bogues de sécurité connus plus longtemps qu'il n'est
nécessaire.</p>
<p>Veuillez utiliser les paquets des bulletins d'alerte les plus
récents, qui sont distribués à travers la liste de diffusion
<a href="http://lists.debian.org/debian-security-announce/">\
debian-security-announce</a>. Il vaut mieux lancer simplement
<code>apt-get update</code> avant de mettre à jour le paquet.</p>
<toc-add-entry name=upload>Je possède une rustine, puis-je la mettre en ligne
sur security.debian.org directement ?</toc-add-entry>
<p>R. : Non, vous ne pouvez pas. Les archives de
security.debian.org sont entretenues par l'équipe en charge de la
sécurité, qui doit approuver tous les paquets. Vous devez envoyer vos
rustines ou des paquets sources propres à l'équipe en charge de la
sécurité a l'adresse team@security.debian.org. Ils seront revus par
l'équipe en charge de la sécurité et éventuellement mis en ligne, avec
ou sans modifications.</p>
<p>Si vous n'êtes pas habitué des mises à jour de sécurité, et que vous
n'êtes pas certain que votre paquet est sain, lisez bien ce qui suit,
ne mettez pas vos paquets en ligne dans le répertoire <i>incoming</i>.
L'équipe en charge de la sécurité dispose de possibilités réduites pour
traiter un paquet mal-formé, particulièrement dans le cas où le numéro
de version n'est pas bon. Les paquets ne pourront pas être rejetés
et le démon de construction <i>buildd</i> sera perturbé si cela doit
se produire. Pour traiter ces problèmes, utilisez le courriel et
aidez-nous en ne rajoutant pas des problèmes supplémentaires sur les bras
de l'équipe en charge de la sécurité.</p>
<p>La <a href="$(DOC)/developers-reference/ch-pkgs#s-bug-security">\
Référence du Développeur</a> contient les instructions complètes
sur la démarche à suivre.</p>
<toc-add-entry name=ppu>Je possède une rustine, puis-je la mettre en ligne
dans <i>proposed-updates</i> ?</toc-add-entry>
<p>R : Techniquement parlant, vous pouvez. Cependant, vous ne devriez pas.
En effet, cela interfère de façon néfaste avec le travail de l'équipe
en charge de la sécurité. Les paquets situés dans security.debian.org
seront automatiquement copiés dans <i>proposed-updates</i>. Si un paquet
avec un numéro de version identique ou supérieur est d'ores et déjà installé
dans l'archive, la mise à jour de sécurité sera rejetée par le système
d'archive. En définitive, la distribution stable se retrouvera dépourvue
de la mise à jour de sécurité, à moins que les « mauvais »
paquets du répertoire <i>proposed-updates</i> ne soient rejetés. Veuillez
prendre contact avec l'équipe en charge de la sécurité et ajoutez tous les
détails de la faille et joignez à votre courriel les fichiers sources (i.e.
les fichiers diff.gz et dsc).</p>
<p>La <a href="$(DOC)/developers-reference/ch-pkgs#s-bug-security">\
Référence du Développeur</a> contient les instructions complètes sur
la démarche à suivre.</p>
<toc-add-entry name=SecurityUploadQueue>Je suis presque persuadé que mes
paquets sont correctement construits, comment puis-je les mettre en
ligne ?</toc-add-entry>
<p>R : Si vous êtes certain de ne pas avoir cassé quelque chose, que le
numéro de version est le bon (i.e. supérieur à celui dans la version
qui se trouve dans stable et inférieur à celui qui se trouve dans
testing/unstable), que vous n'avez pas modifié
le comportement du paquet, et que vous avez pallié au problème de
sécurité, que vous l'avez compilé pour la bonne distribution (qui
est <code>oldstable-security</code> ou <code>stable-security</code>),
que le paquet contiennent les sources originales si le paquet
est nouveau sur security.debian.org, que vous pouvez confirmer que
la rustine pour la plus récente version est propre et concerne uniquement
le problème de sécurité dont il est question (vérifiez le avec la commande
<code>interdiff -z</code> et également les fichiers <code>.diff.gz</code>),
que vous avez relu la rustine au moins trois fois, et que
<code>debdiff</code> n'affiche aucun changement, vous pouvez mettre en
ligne les fichiers dans le répertoire
<a href="/org/ftp.root/pub/SecurityUploadQueue/">incoming</a> qui se trouve
sur security.debian.org directement. Veillez également à notifier l'équipe
en charge de la sécurité sur team@security.debian.org de tous les détails
et des liens.</p>
<toc-add-entry name=help>Comment puis-je fournir de l'aide sur la
sécurité ?</toc-add-entry>
<p>R. : S'il vous plaît, réexaminez chaque problème avant de le
rapporter. Si vous en avez la possibilité, fournissez des correctifs,
ce qui accélérera le processus. Ne renvoyez pas simplement des
messages en provenance du bugtraq, car nous les recevons déjà —
mais fournissez-nous des informations complémentaires à celles
fournies par bugtraq.</p>
<toc-add-entry name=proposed-updates>Quel est le contenu de
« proposed-updates » ?</toc-add-entry>
<p>R. : Ce répertoire contient les paquets qui ont été proposés dans
le but d'être incorporés dans la prochaine version stable de Debian.
Chaque fois que des paquets sont mis en téléchargement (uploadés) par
des responsables pour la version stable, ils atterrissent dans ce
répertoire. Comme la distribution « stable » est supposée
être stable, aucune mise à jour automatique n'est réalisée. De même,
lorsque l'équipe chargée de la sécurité met à disposition les paquets
mentionnés dans ses bulletins d'alerte pour les incorporer dans
stable, ils sont placés en premier lieu dans
« proposed-updates ». Tous les deux mois, les responsables
de la version stable vérifient la liste des paquets de
« proposed-updates » et décident si un paquet est approprié
ou non pour stable. Ces modifications sont rassemblées dans une
nouvelle version (<i>revision</i>) de « stable » (p.e. 2.2r3
ou 2.2r4). Les paquets qui ne correspondent pas seront probablement
rejetés et seront aussi retirés de <i>proposed-updates</i>.</p>
<p>Veuillez noter que les paquets mis en ligne par les responsables
de paquets (et non par l'équipe en charge de la sécurité) dans
le répertoire proposed-updates/ ne sont pas maintenus par
l'équipe en charge de la sécurité.</p>
<toc-add-entry name=composing>De quelle façon est constituée l'équipe chargée
de la sécurité ?</toc-add-entry>
<p>R. : L'équipe en charge de la sécurité comporte
<a href="../intro/organization">plusieurs officiers et des secrétaires</a>.
L'équipe chargée de la sécurité nomme elle-même ses membres.</p>
Reply to: