[relu] security/faq.wml
Merci à Martine, Nico et Joël pour leur relecture.
Denis
#use wml::debian::template title="FAQ de l'équipe Debian sur la sécurité"
#use wml::debian::translation-check translation="1.11" maintainer="Denis Barbier"
<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>
<p><em>Question : La signature sur vos avis de sécurité ne semble pas authentique !</em></p>
<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) et formail (venant de procmail 3.14 seulement).</p>
<p><em>Q. : Comment s'occupe-t-on de la sécurité dans Debian ?</em></p>
<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>
<p><em>Q. : Quelle est la politique pour qu'un paquet stable apparaisse
dans security.debian.org ?</em></p>
<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</p>
<p><em>Q. : Le numéro de version d'un paquet m'indique que j'utilise
toujours une version vulnérable !</em></p>
<p>R. : Au lieu de passer à une nouvelle version, nous réalisons un
rétroportage (« <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>
<p><em>Q. : Comment est gérée la sécurité pour <tt>testing</tt> et
<tt>unstable</tt> ?</em></p>
<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.</p>
<p><em>Q. : Pourquoi n'y a-t-il pas de miroirs officiels de security.debian.org ?</em></p>
<p>R. : Le but de security.debian.org est de rendre les mises à jour pour
raisons de sécurité disponibles aussi rapidement que possible. Des
sites miroirs ne feraient qu'ajouter de la complexité là où elle
n'est pas nécessaire, et pourraient causer des problèmes s'ils
n'étaient pas à jour.</p>
<p><em>Q. : J'ai vu les DSA 100 et DSA 102, mais où est le DSA 101 ?</em></p>
<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>
<p><em>Q. : Comment puis-je contacter l'équipe chargée de la sécurité ?</em></p>
<p>R. : Les informations relatives à la sécurité peuvent être envoyées à
security@debian.org, qui est 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 363CCD95).</p>
<p><em>Q. : Comment puis-je fournir de l'aide sur la sécurité ?</em></p>
<p>R. : S'il vous plait, 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
supplémentaires à celles fournies par bugtraq.</p>
<p><em>Q. : Quel est le contenu de « proposed-updates » ?</em></p>
<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 parcourent 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 publique (<i>release</i>) (ex. 2.2r3 ou 2.2r4).</p>
<p><em>Q. : De quelle façon est constituée l'équipe chargée de la
sécurité ?</em></p>
<p>R. : L'équipe en charge de la sécurité comporte actuellement cinq officiers
et de deux secrétaires. L'équipe chargée de la sécurité nomme elle-même ses
membres.</p>
Reply to: