[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [RFR]wml://security/faq.wml

Bonjour,

Le 14/02/2014 14:49, JP Guillonneau a écrit :
> Re,
> Erreur de diff.
> Merci Baptiste.
> 
Juste une paire de corrections et suggestion. Je joins le fichier
complet et le diff parce que je n'ai pas pu m'empêcher d'ajuster la
longueur des lignes et d'unifier la gestion des balises (même si ne cela
sert à pas grand chose, c'est un peu maniaque).
Amicalement
jipege

#use wml::debian::template title="FAQ de l'équipe Debian sur la sécurité"
#use wml::debian::translation-check translation="1.82" maintainer="David Prévot"
#include "$(ENGLISHDIR)/security/faq.inc"

# Translators:
# Denis Barbier, 2001-2004
# Pierre Machard, 2001-2004
# Thomas Marteau, 2004
# Simon Paillard, 2005-2009
# Jean-Ã?douard Babin, 2008
# David Prévot, 2011-2013.

<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 des avis de sécurité ne semble pas authentique !
</toc-add-entry>
<p>
Réponse : C'est sans doute dû à un problème de votre côté. 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 valable d'un membre 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 qu'aucun logiciel ne fait
   d'encodage ou de décodage 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 la sécurité est-elle gérée dans Debian ?
</toc-add-entry>
<p>
R. : Dès que l'équipe en charge de la sécurité reçoit une
   notification d'incident, un ou plusieurs de ses membres examinent
   la situation et évaluent l'impact sur la version stable de Debian
   (c'est-à-dire si elle est vulnérable ou non). Si notre système est
   vulnérable, nous préparons une correction du 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 puis envoyés.
   Après toutes ces étapes, une annonce est publiée.</p>

<toc-add-entry name=oldversion>
Pourquoi vous embêtez-vous avec une vieille version de ce paquet ?
</toc-add-entry>
<p>
R. : La règle la plus importante lors de la construction d'un nouveau
   paquet qui corrige un problème de sécurité est de faire le moins de
   modifications possibles. Nos utilisateurs et nos développeurs s'attendent
   à ce que la distribution conserve son comportement d'origine.
   Ainsi, toute modification, aussi petite soit-elle, peut éventuellement
   casser le système de quelqu'un. C'est particulièrement vrai avec des
   bibliothèques : assurez-vous de ne jamais modifier l'interface de 
   programmation d'applications (API) ou l'interface binaire de l'application
  (ABI : <i>Application Binary Interface</i>).</p>

<p>Cela signifie que passer à une version amont plus récente n'est pas une 
   bonne solution. La modification doit plutôt être rétroportée. 
   En règle générale, les mainteneurs amont donnent un coup de main, sinon
   l'équipe en charge de la sécurité pourrait aider.</p>

<p>Dans certains cas, rétroporter un correctif de sécurité n'est pas possible,
   par exemple si une grande partie du code source doit être modifiée ou
   réécrite. Dans ce cas, il sera peut-être nécessaire de passer à une
   nouvelle version amont, mais cela devra se faire en coordination avec
   l'équipe en charge de la sécurité.</p>

<toc-add-entry name=policy>
Quelle est la règle pour qu'un paquet corrigé apparaisse sur security.debian.org ?
</toc-add-entry>
<p>
R. : Une faille de sécurité dans la distribution stable justifie un 
   paquet sur security.debian.org. Rien d'autre. L'importance de cette faille
   n'est pas un réel critère pour cela. Habituellement, l'équipe chargée de la
   sécurité prépare les paquets en lien étroit avec le responsable du paquet.
   Si quelqu'un (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 un problème de sécurité trivial sera corrigé sur
   security.debian.org. Veuillez lire ci-dessous.</p>

<p>Les mises à jour de sécurité ont un objectif : fournir un correctif pour
   une faille de sécurité. Ces mises à jour n'ont pas vocation à intégrer 
   d'autres modifications dans la version stable en outrepassant la procédure
   de mise à jour de publication.</p>

<toc-add-entry name=localremote>Que signifie <q>local (remote)</q> ?
  </toc-add-entry>
<p>
R. : Certaines annonces couvrent des vulnérabilités qui ne peuvent pas
   être classées suivant la distinction habituelle d'une exploitation locale
   ou distante. Certaines vulnérabilités ne peuvent pas être exploitées à
   distance, c'est-à-dire sans démon à l'écoute d'un port réseau. Si elles
   peuvent être exploitées avec des fichiers spéciaux issus du réseau alors
   que le service vulnérable n'est pas connecté de manière permanente au
   réseau, nous écrivons alors <q>local (remote)</q>.</p>

<p>Ce genre de vulnérabilité est en quelque sorte en partie locale et distante,
   et concerne souvent des fichiers disponibles par le réseau, comme les
   les pièces jointes des courriers électroniques, ou depuis une page de
   téléchargement.</p>

<toc-add-entry name=version>
Le numéro de version d'un paquet indique-t-il une version vulnérable ?
</toc-add-entry>
<p>
R. : Au lieu de passer à une nouvelle version, nous réalisons un 
   rétroportage (<q>backport</q>) du correctif de sécurité dans la version
   de la distribution stable. La raison d'agir ainsi est simple : une version
   publiée (<q>release</q>) doit changer le moins possible ; ainsi, les
   correctifs de sécurité ne seront pas la cause de problèmes annexes. Vous
   pouvez vérifier si une version d'un paquet est sécurisée en examinant son
   journal de modifications, 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=archismissing>J'ai reçu une annonce, mais la construction
   pour une architecture de processeur semble manquer.</toc-add-entry>
<p>
R. : Normalement, l'équipe chargée de la sécurité publie une annonce avec les
   constructions des paquets mis à jour pour toutes les architectures prises en
   charge par Debian. Néanmoins, c'est plus lent pour certaines architectures
   que pour d'autres et il peut arriver que les constructions pour la plupart
   des architectures soient prêtes alors qu'il en manque d'autres. Ces
   architectures plus petites représentent une petite partie de notre base
   d'utilisateurs. En fonction de l'urgence du problème, il peut être décidé
   de publier l'annonce sans délai. Les constructions manquantes seront
   ajoutées à l'archive dès qu'elles seront disponibles, mais aucun avis ne
   sera publié à ce sujet. �videmment, il ne sera jamais publié d'annonce
   sans les constructions pour i386 ou amd64.</p>

<toc-add-entry name=unstable>Comment est gérée la sécurité pour
<tt>unstable</tt> ?</toc-add-entry>
<p>
R. : La sécurité pour <tt>unstable</tt> est dâ??abord gérée par les responsables
   de paquets et non par lâ??équipe chargée de la sécurité. Bien que lâ??équipe
   chargée de la sécurité puisse envoyer des correctifs de sécurité urgents
   quand les responsables ont lâ??air inactifs, la prise en charge de stable sera
   toujours la priorité. Si vous souhaitez un serveur sûr (et stable), vous
   devriez garder la distribution stable.</p>

<toc-add-entry name=testing>Comment est gérée la sécurité pour <tt>testing</tt>
 ?</toc-add-entry>
<p>
R. : La sécurité pour <tt>testing</tt> bénéficie des efforts sur la sécurité
   réalisés par tout le projet pour <tt>unstable</tt>. Cependant, un délai
   minimal de deux jours existe pour la migration, et les correctifs de
   sécurité peuvent parfois être retenus par les transitions. Lâ??équipe chargée
   de la sécurité aide à faire avancer ces transitions qui retiennent les
   envois de sécurité importants, mais ce nâ??est pas toujours possible et des
   contretemps peuvent survenir. En particulier, les mois qui suivent une
   nouvelle publication de stable, quand de nombreuses nouvelles versions sont
   envoyées dans <tt>unstable</tt>, les correctifs de sécurité pourraient être
   mis en attente. Si vous souhaitez un serveur sûr (et stable), vous devriez
   garder la distribution stable.</p>

<toc-add-entry name=contrib>Comment est gérée la sécurité pour <tt>contrib</tt>
  et <tt>non-free</tt> ?</toc-add-entry>
<p>
R. : La réponse courte est : elle ne l'est pas. <tt>contrib</tt> et
   <tt>non-free</tt> ne font pas officiellement partie de la distribution
   Debian et ne sont pas publiées, c'est pourquoi elles ne sont pas prises en
   charge par l'équipe en charge de la sécurité. Certains paquets de 
   <tt>non-free</tt>sont distribués sans les sources ou avec une licence ne
   permettant pas la distribution de versions modifiées. Dans ces deux derniers
   cas, les corrections de sécurité sont simplement impossibles à faire. S'il
   est possible de corriger le problème, et que le responsable du paquet ou
   quelqu'un d'autre fournit des paquets correctement mis à jour, alors
   l'équipe en charge de la sécurité, dans la plupart des cas, intégrera ces
   paquets et publiera une annonce de sécurité.</p>

<toc-add-entry name=sidversionisold>L'annonce dit que la distribution unstable
  est corrigée dans la version 1.2.3-1, mais unstable a la version 1.2.5-1, que
  se passe-t-il ?</toc-add-entry>
<p>R. : Nous essayons de donner le numéro de la première version qui a résolu
   le problème dans unstable. Parfois, le mainteneur du paquet a pu mettre à
   disposition entre temps une version plus récente. Comparez la version qui se
   trouve dans unstable avec la version que nous indiquons dans l'annonce, si
   la version dans unstable est égale ou supérieure vous devriez être à l'abri
   de la vulnérabilité.</p>

<toc-add-entry name=mirror>Pourquoi n'y a-t-il pas de miroir officiel de 
security.debian.org ?</toc-add-entry>
<p>
R. : En fait, il y a plusieurs miroirs officiels, mis en &oelig;uvre
   à l'aide d'alias DNS. Le but de security.debian.org est de mettre à
   disposition les mises à jour de sécurité aussi rapidement et facilement que
   possible.</p>

<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.</p>

<toc-add-entry name=missing>J'ai vu les DSA 100 et DSA 102, 
mais où est la DSA 101 ?</toc-add-entry>
<p>
R. : Plusieurs distributeurs (la plupart de GNU/Linux, mais aussi des
   dérivés BSD) coordonnent leurs alertes 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és 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 joindre 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 ou à team@security.debian.org, chacune de ces adresses
   est lue par l'équipe chargée de la sécurité.</p>

<p>Si nécessaire, le message peut-être chiffré avec la clé publique du contact
   sécurité Debian (identifiant de clef<a 
   href="http://pgp.surfnet.nl/pks/lookup?op=vindex&amp;search=0xBACB4B5C30AC38F319EE961E2702CAEB90F8EEC5";>\
   0x90F8EEC5</a>). Pour les clés PGP/GPG individuelles des membres de
   l'équipe chargée de la sécurité, veuillez consulter le serveur de clés
   <a href="http://keyring.debian.org/";>keyring.debian.org</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 celle-ci confirme la faille et que d'autres distributeurs sont
   également concernés, elle prendra également contact avec eux. Si la
   vulnérabilité n'est pas encore publique, l'équipe essayera de coordonner
   l'annonce avec les autres distributeurs, de telle sorte que les
   distributions principales soient synchronisées.</p>

<p>Si la vulnérabilité a déjà été rendue publique, assurez-vous de remplir un
   rapport de bogue dans le système de suivi des bogues (<em>BTS</em>) de
   Debian, avec la marque <q>security</q>.</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é, dans votre
   paquet, vous devez toujours prendre contact avec l'équipe en charge de la
   sécurité 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
   corrige elle-même. Elle est responsable de l'envoi des bulletins d'alerte
   de sécurité et de l'entretien du site security.debian.org.</p>

<p>La <a href="$(DOC)/developers-reference/pkgs.html#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 de ne pas envoyer de 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 entraînera de la confusion et nécessitera plus de 
   travail.</p>

<toc-add-entry name=enofile>J'ai essayé de télécharger un paquet mentionné dans
un bulletin d'alerte, mais j'ai eu une erreur « fichier non trouvé ».
</toc-add-entry>
<p>
R. : � chaque fois qu'une nouvelle correction de bogue de
   sécurité remplace un paquet plus ancien de security.debian.org, il y a de
   grandes chances que l'ancien paquet soit supprimé, lorsque le nouveau est
   installé. Par conséquent, ce genre d'erreur peut survenir. 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 sur la liste de diffusion
   <a href="http://lists.debian.org/debian-security-announce/";>\
   debian-security-announce</a>. Mieux vaut lancer simplement 
   <code>apt-get update</code> avant de mettre à niveau le paquet.</p>

<toc-add-entry name=upload>Je possède un correctif, puis-je le 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
   correctifs ou des paquets source corrects à l'équipe en charge de la
   sécurité par courriel à 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 modification.</p>

<p>La <a href="$(DOC)/developers-reference/pkgs.html#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 un correctif, puis-je le 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 <q>mauvais</q>
   paquets du répertoire <i>proposed-updates</i> ne soient rejetés. Veuillez
   prendre contact avec l'équipe en charge de la sécurité, ajoutez tous les
   détails de la faille et joignez les fichiers source (c'est-à-dire les 
   fichiers diff.gz et dsc) à votre courrier électronique.</p>

<p>La <a href="$(DOC)/developers-reference/pkgs.html#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é quoi que ce soit, que le
   numéro de version est le bon (c'est-à-dire supérieur à celui de la version
   qui se trouve dans stable et inférieur à celui qui se trouve dans 
   testing et unstable), que vous n'avez pas modifié
   le comportement du paquet, et que vous avez pallié le 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 contient les sources originales si le paquet
   est nouveau sur security.debian.org, que vous pouvez confirmer que 
   le correctif pour la plus récente version est propre et ne concerne que
   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 incoming 
   <code>ftp://security-master.debian.org/pub/SecurityUploadQueue</code> qui se
   trouve sur security.debian.org directement. Veillez également à notifier à
   l'équipe en charge de la sécurité sur team@security.debian.org tous les
   détails et 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
   signaler. 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à &mdash;
   mais fournissez-nous des informations complémentaires à celles
   fournies par bugtraq.</p>

<p>Une bonne façon de commencer à contribuer est d'apporter votre aide sur le
   « Debian Security Tracker » en suivant les <a
   href="http://security-tracker.debian.org/tracker/data/report";>
   instructions</a>).</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 envoyé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 » (par exemple 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 membres et assistants</a>. 
   L'équipe chargée de la sécurité nomme elle-même ses membres.</p>

<toc-add-entry name=lifespan>Pendant combien de temps les mises à jour de
sécurité seront-elles fournies&nbsp;?</toc-add-entry>
<p>
R. : L'équipe en charge de la sécurité essaye de prendre en charge la
   distribution stable environ une année après que la version stable suivante
   a été publiée, sauf lorsqu'une autre distribution stable est publiée
   la même année. Il n'est pas possible de prendre en charge trois
   distributions, c'est déjà bien assez difficile avec deux.</p>

<toc-add-entry name=check>Comment puis-je contrôler l'intégrité des paquets ?
</toc-add-entry>
<p>
R. : Ce processus consiste à contrôler la signature du fichier <i>Release</i>
   à l'aide de la <a href="http://ftp-master.debian.org/keys.html";>\
   clef publique</a> utilisée pour l'archive. Le fichier <i>Release</i>
   contient les sommes de contrôle des fichiers <i>Packages</i> et <i>
   Sources</i> qui contiennent respectivement les sommes de contrôle des
   paquets binaires et des paquets source. Des instructions détaillées sur la
   façon de contrôler l'intégrité des paquets peuvent être obtenues dans le
   <a href="$(HOME)/doc/manuals/securing-debian-howto/ch7#s-deb-pack-sign">\
   manuel de sécurisation Debian</a>.</p>

<toc-add-entry name=break>Que faire si un paquet est cassé suite à une mise à
jour de sécurité ?</toc-add-entry>
<p>
R. : Premièrement, vous devez essayer de comprendre pourquoi le paquet
   est défaillant et comment il interagit avec la mise à jour de sécurité.
   Ensuite, prenez contact avec l'équipe en charge de la sécurité s'il s'agit
   de quelque chose de sérieux ou bien avec le responsable de la distribution
   stable s'il s'agit de quelque chose de moins grave. Nous parlons ici de
   paquets quelconques qui cessent de fonctionner après une mise à jour de
   sécurité d'un autre paquet. Si vous ne parvenez pas à identifier la cause
   du problème, mais que vous connaissez le correctif, parlez-en également à
   l'équipe en charge de la sécurité. Il est toutefois possible qu'on vous
   renvoie vers le responsable de la distribution stable.</p>

<toc-add-entry name=cvewhat>Quâ??est-ce quâ??un identifiant CVE ?</toc-add-entry>
<p>R. : Le projet Common Vulnerabilities and Exposures (CVE) assigne des noms
   uniques, appelés identifiants CVE, pour les vulnérabilités spécifiques à la
   sécurité, afin de faciliter la référence unique à un problème spécifique.
   Des renseignements supplémentaires sont disponibles sur <a
   href="https://fr.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures";>\
   Wikipédia</a>.</p>

<toc-add-entry name=cvedsa>Est-ce que Debian réalise une annonce de sécurité
(DSA) pour chaque identifiant CVE ?</toc-add-entry>
<p>
R. : Lâ??équipe de sécurité Debian suit tous les identifiants CVE publiés, les
   connecte aux paquets Debian correspondants et évalue leur impact dans le
   contexte de Debian â?? le fait quâ??un identifiant CVE soit attribué nâ??implique 
   pas forcément que le problème représente une menace sévère pour un système
   Debian.Ces renseignements sont suivis dans le <a
   href="http://security-tracker.debian.org";>Debian Security Tracker</a> et une
   annonce de sécurité Debian sera envoyée pour les problèmes considérés
   sérieux.</p>

<p>Les problèmes ayant un faible impact pour lesquels aucune DSA ne sera
   publiée peuvent être corrigés dans la publication de Debian suivante, lors
   dâ??une mise à jour intermédiaire des distributions stable ou oldstable
   actuelles. Un correctif pour ces problèmes peut aussi être inclus dans une
   DSA publiée pour une vulnérabilité plus sérieuse.</p>

<toc-add-entry name=cveget>Debian peut-elle assigner des identifiants CVE ?
</toc-add-entry>
<p>
R. : Debian est une autorité de numération CVE et peut assigner des
   identifiants CVE, mais conformément à la politique de CVE, uniquement pour
   des problèmes non encore publics. Si vous avez une vulnérabilité de sécurité
   non publique pour un logiciel dans Debian et que vous voudriez obtenir un
   identifiant pour ce problème, contactez lâ??équipe de sécurité Debian. Dans 
   le cas où la vulnérabilité est déjà publique, veuillez suivre la procédure
   détaillée dans le <a
   href="http://people.redhat.com/kseifrie/CVE-OpenSource-Request-HOWTO.html";>\
   CVE OpenSource Request HOWTO</a>.</p>

--- Documents/traductions/l10n/faq/security/faq.wml	2014-02-15 23:29:28.676975522 +0100
+++ l10n/faq/security/faqjpg.wml	2014-02-16 12:23:44.990738001 +0100
@@ -20,241 +20,195 @@
 La signature des avis de sécurité ne semble pas authentique !
 </toc-add-entry>
 <p>
-Réponse&nbsp;: C'est sans doute dû à un problème de votre côté.
-La liste
+Réponse : C'est sans doute dû à un problème de votre côté. 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 valable d'un membre de l'équipe chargée de la
+   avec une signature valable d'un membre 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 qu'aucun logiciel ne fait
-d'encodage ou de décodage MIME, ou de substitutions entre
+   ce qui corrompt la signature. Vérifiez qu'aucun logiciel ne fait
+   d'encodage ou de décodage 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&nbsp;3.14 seulement) et evolution.</p>
+   activée), formail (venant de procmail 3.14 seulement) et evolution.</p>
 
 <toc-add-entry name="handling">
 Comment la sécurité est-elle gérée dans Debian ?
 </toc-add-entry>
 <p>
-R.&nbsp;: Dès que l'équipe en charge de la sécurité reçoit une
-notification d'incident, un ou plusieurs de ses membres examinent
-la situation et évaluent l'impact sur la version stable de Debian
-(c'est-à-dire si elle est vulnérable ou non).
-Si notre système est vulnérable, nous préparons une correction du problème.
-Le
+R. : Dès que l'équipe en charge de la sécurité reçoit une
+   notification d'incident, un ou plusieurs de ses membres examinent
+   la situation et évaluent l'impact sur la version stable de Debian
+   (c'est-à-dire si elle est vulnérable ou non). Si notre système est
+   vulnérable, nous préparons une correction du 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&nbsp;; ces paquets sont
-compilés sur toutes les architectures stables puis envoyés.
-Après toutes ces étapes, une annonce est publiée.
-</p>
+   testée et de nouveaux paquets sont préparés ; ces paquets sont
+   compilés sur toutes les architectures stables puis envoyés.
+   Après toutes ces étapes, une annonce est publiée.</p>
 
 <toc-add-entry name=oldversion>
 Pourquoi vous embêtez-vous avec une vieille version de ce paquet ?
 </toc-add-entry>
 <p>
-R.&nbsp;: La règle la plus importante lors de la construction d'un nouveau paquet qui
-corrige un problème de sécurité est de faire le moins de modifications
-   possibles. Nos utilisateurs et nos développeurs s'attendent à ce que la
-distribution conserve son comportement d'origine.
-Ainsi, toute modification, aussi petite soit-elle, peut éventuellement casser
-le système de quelqu'un. C'est particulièrement vrai avec
-des bibliothèques&nbsp;: assurez-vous de ne jamais modifier l'interface de 
-programmation d'applications (API) ou l'interface binaire de l'application
-(ABI&nbsp;: <i>Application Binary Interface</i>). 
-</p>
-
-<p>
-Cela signifie que passer à une version amont plus récente n'est pas une 
-bonne solution.
-La modification doit plutôt être rétroportée. 
-En règle générale, les mainteneurs amont donnent un coup de main, sinon l'équipe
-en charge de la sécurité pourrait aider.
-</p>
+R. : La règle la plus importante lors de la construction d'un nouveau
+   paquet qui corrige un problème de sécurité est de faire le moins de
+   modifications possibles. Nos utilisateurs et nos développeurs s'attendent
+   à ce que la distribution conserve son comportement d'origine.
+   Ainsi, toute modification, aussi petite soit-elle, peut éventuellement
+   casser le système de quelqu'un. C'est particulièrement vrai avec des
+   bibliothèques : assurez-vous de ne jamais modifier l'interface de 
+   programmation d'applications (API) ou l'interface binaire de l'application
+  (ABI : <i>Application Binary Interface</i>).</p>
 
-<p>
-Dans certains cas, rétroporter un correctif
-de sécurité n'est pas possible, par exemple si une grande partie du code source doit
-être modifiée ou réécrite.
-Dans ce cas, il sera peut-être nécessaire de passer
-à une nouvelle version amont, mais cela devra se faire
-en coordination avec l'équipe en charge de la sécurité.
-</p>
+<p>Cela signifie que passer à une version amont plus récente n'est pas une 
+   bonne solution. La modification doit plutôt être rétroportée. 
+   En règle générale, les mainteneurs amont donnent un coup de main, sinon
+   l'équipe en charge de la sécurité pourrait aider.</p>
 
+<p>Dans certains cas, rétroporter un correctif de sécurité n'est pas possible,
+   par exemple si une grande partie du code source doit être modifiée ou
+   réécrite. Dans ce cas, il sera peut-être nécessaire de passer à une
+   nouvelle version amont, mais cela devra se faire en coordination avec
+   l'équipe en charge de la sécurité.</p>
 
 <toc-add-entry name=policy>
 Quelle est la règle pour qu'un paquet corrigé apparaisse sur security.debian.org ?
 </toc-add-entry>
-
 <p>
-R.&nbsp;: Une faille de sécurité dans la distribution stable justifie un 
-paquet sur security.debian.org.
-Rien d'autre.
-L'importance de cette faille
-n'est pas un réel critère pour cela. Habituellement, l'équipe chargée de la
-   sécurité prépare les paquets en lien étroit avec le responsable du
-paquet.
-Si quelqu'un (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 un problème de sécurité
-trivial sera corrigé sur
+R. : Une faille de sécurité dans la distribution stable justifie un 
+   paquet sur security.debian.org. Rien d'autre. L'importance de cette faille
+   n'est pas un réel critère pour cela. Habituellement, l'équipe chargée de la
+   sécurité prépare les paquets en lien étroit avec le responsable du paquet.
+   Si quelqu'un (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 un problème de sécurité trivial sera corrigé sur
    security.debian.org. Veuillez lire ci-dessous.</p>
 
-<p>
-Les mises à jour de sécurité ont un objectif&nbsp;: fournir un correctif pour
-   une faille de sécurité. Ces mises à jour n'ont pas vocation à 
-intégrer d'autres modifications dans la version stable en 
-outrepassant la procédure de mise à jour de publication.
-</p>
+<p>Les mises à jour de sécurité ont un objectif : fournir un correctif pour
+   une faille de sécurité. Ces mises à jour n'ont pas vocation à intégrer 
+   d'autres modifications dans la version stable en outrepassant la procédure
+   de mise à jour de publication.</p>
 
-<toc-add-entry name=localremote>Que signifie <q>local
-(remote)</q>&nbsp;?</toc-add-entry>
+<toc-add-entry name=localremote>Que signifie <q>local (remote)</q> ?
+  </toc-add-entry>
 <p>
-R.&nbsp;: Certaines annonces couvrent des vulnérabilités qui ne peuvent pas
-être classées suivant la distinction habituelle d'une exploitation locale ou
-   distante. Certaines vulnérabilités ne peuvent pas être exploitées à distance,
-c'est-à-dire sans démon à l'écoute d'un port réseau.
-Si elles peuvent être
-exploitées avec des fichiers spéciaux issus du réseau alors que le
-   service vulnérable n'est pas connecté de manière permanente au réseau, nous
-   écrivons alors <q>local (remote)</q>.</p>
+R. : Certaines annonces couvrent des vulnérabilités qui ne peuvent pas
+   être classées suivant la distinction habituelle d'une exploitation locale
+   ou distante. Certaines vulnérabilités ne peuvent pas être exploitées à
+   distance, c'est-à-dire sans démon à l'écoute d'un port réseau. Si elles
+   peuvent être exploitées avec des fichiers spéciaux issus du réseau alors
+   que le service vulnérable n'est pas connecté de manière permanente au
+   réseau, nous écrivons alors <q>local (remote)</q>.</p>
 
-<p>
-Ce genre de vulnérabilité est en quelque sorte en partie
-locale et distante, et concerne souvent des fichiers
-disponibles par le réseau, comme les courriers électroniques et
-leurs pièces jointes, ou depuis une page de téléchargement.
-</p>
+<p>Ce genre de vulnérabilité est en quelque sorte en partie locale et distante,
+   et concerne souvent des fichiers disponibles par le réseau, comme les
+   les pièces jointes des courriers électroniques, ou depuis une page de
+   téléchargement.</p>
 
 <toc-add-entry name=version>
 Le numéro de version d'un paquet indique-t-il une version vulnérable ?
 </toc-add-entry>
-
-<p>R.&nbsp;: Au lieu de passer à une nouvelle version, nous réalisons un 
-rétroportage (<q>backport</q>) du correctif de
-sécurité dans la version de la distribution stable.
-La raison d'agir ainsi est simple : une version publiée
-(<q>release</q>) doit changer le moins possible&nbsp;;
-ainsi, les correctifs de sécurité ne seront pas la cause de problèmes annexes.
-Vous pouvez vérifier si une version d'un paquet est sécurisée
-en examinant son journal de modifications, 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>
+R. : Au lieu de passer à une nouvelle version, nous réalisons un 
+   rétroportage (<q>backport</q>) du correctif de sécurité dans la version
+   de la distribution stable. La raison d'agir ainsi est simple : une version
+   publiée (<q>release</q>) doit changer le moins possible ; ainsi, les
+   correctifs de sécurité ne seront pas la cause de problèmes annexes. Vous
+   pouvez vérifier si une version d'un paquet est sécurisée en examinant son
+   journal de modifications, 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=archismissing>J'ai reçu une annonce, mais la construction
-pour une architecture de processeur semble manquer.</toc-add-entry>
+   pour une architecture de processeur semble manquer.</toc-add-entry>
 <p>
-R. : Normalement, l'équipe chargée de la sécurité publie
-une annonce avec les constructions des paquets mis à jour
-pour toutes les architectures prises en charge par Debian. 
-
-Néanmoins, c'est plus lent pour certaines architectures que pour d'autres
-et il peut arriver que les constructions pour la plupart des
-architectures soient prêtes alors qu'il en manque d'autres.
-
-Ces architectures plus petites représentent une
-petite partie de notre base d'utilisateurs.
-
-En fonction de l'urgence du problème, il peut
-être décidé de publier l'annonce sans délai.
-
-Les constructions manquantes seront ajoutées à l'archive dès qu'elles
-seront disponibles, mais aucun avis ne sera publié à ce sujet.
-
-�videmment, il ne sera jamais publié d'annonce
-sans les constructions pour i386 ou amd64.
-</p>
-
+R. : Normalement, l'équipe chargée de la sécurité publie une annonce avec les
+   constructions des paquets mis à jour pour toutes les architectures prises en
+   charge par Debian. Néanmoins, c'est plus lent pour certaines architectures
+   que pour d'autres et il peut arriver que les constructions pour la plupart
+   des architectures soient prêtes alors qu'il en manque d'autres. Ces
+   architectures plus petites représentent une petite partie de notre base
+   d'utilisateurs. En fonction de l'urgence du problème, il peut être décidé
+   de publier l'annonce sans délai. Les constructions manquantes seront
+   ajoutées à l'archive dès qu'elles seront disponibles, mais aucun avis ne
+   sera publié à ce sujet. �videmment, il ne sera jamais publié d'annonce
+   sans les constructions pour i386 ou amd64.</p>
 
 <toc-add-entry name=unstable>Comment est gérée la sécurité pour
-<tt>unstable</tt>&nbsp;?</toc-add-entry>
-
+<tt>unstable</tt> ?</toc-add-entry>
 <p>
-R. : La sécurité pour <tt>unstable</tt> est dâ??abord gérée par les
-responsables de paquets et non par lâ??équipe chargée de la sécurité.
-Bien que lâ??équipe chargée de la sécurité puisse envoyer des
-correctifs de sécurité urgents quand les responsables ont lâ??air inactifs,
-la prise en charge de stable sera toujours la priorité.
-Si vous
-souhaitez un serveur sûr (et stable), vous devriez
-garder la distribution stable.
-</p>
-   
-<toc-add-entry name=testing>Comment est gérée la sécurité pour <tt>testing</tt>
-&nbsp;?</toc-add-entry>
+R. : La sécurité pour <tt>unstable</tt> est dâ??abord gérée par les responsables
+   de paquets et non par lâ??équipe chargée de la sécurité. Bien que lâ??équipe
+   chargée de la sécurité puisse envoyer des correctifs de sécurité urgents
+   quand les responsables ont lâ??air inactifs, la prise en charge de stable sera
+   toujours la priorité. Si vous souhaitez un serveur sûr (et stable), vous
+   devriez garder la distribution stable.</p>
 
+<toc-add-entry name=testing>Comment est gérée la sécurité pour <tt>testing</tt>
+ ?</toc-add-entry>
 <p>
-R. : La sécurité pour <tt>testing</tt> bénéficie des efforts sur la
-sécurité réalisés par tout le projet pour <tt>unstable</tt>.
-Cependant, un délai minimal de deux jours existe pour la migration, et les
-correctifs de sécurité peuvent parfois être retenus par les transitions.
-Lâ??équipe chargée de la sécurité aide à faire avancer ces transitions
-qui retiennent les envois de sécurité importants, mais ce nâ??est
-pas toujours possible et des contretemps peuvent survenir.
-En particulier, les mois qui suivent une nouvelle publication de stable,
-quand de nombreuses nouvelles versions sont envoyées dans <tt>unstable</tt>,
-les correctifs de sécurité pourraient être mis en attente.
-Si vous souhaitez un serveur sûr (et stable), vous devriez
-garder la distribution stable.
-</p>
+R. : La sécurité pour <tt>testing</tt> bénéficie des efforts sur la sécurité
+   réalisés par tout le projet pour <tt>unstable</tt>. Cependant, un délai
+   minimal de deux jours existe pour la migration, et les correctifs de
+   sécurité peuvent parfois être retenus par les transitions. Lâ??équipe chargée
+   de la sécurité aide à faire avancer ces transitions qui retiennent les
+   envois de sécurité importants, mais ce nâ??est pas toujours possible et des
+   contretemps peuvent survenir. En particulier, les mois qui suivent une
+   nouvelle publication de stable, quand de nombreuses nouvelles versions sont
+   envoyées dans <tt>unstable</tt>, les correctifs de sécurité pourraient être
+   mis en attente. Si vous souhaitez un serveur sûr (et stable), vous devriez
+   garder la distribution stable.</p>
 
 <toc-add-entry name=contrib>Comment est gérée la sécurité pour <tt>contrib</tt>
-et <tt>non-free</tt>&nbsp;?</toc-add-entry>
-
+  et <tt>non-free</tt> ?</toc-add-entry>
 <p>
-R.&nbsp;: La réponse courte est&nbsp;: elle ne l'est pas.
-<tt>contrib</tt> et <tt>non-free</tt> ne font pas officiellement partie de la distribution
-   Debian et ne sont pas publiées, c'est pourquoi elles ne sont pas prises en charge 
-par l'équipe en charge de la sécurité.
-Certains paquets de <tt>non-free</tt>
-   sont distribués sans les sources ou avec une licence ne permettant pas la 
-   distribution de versions modifiées. Dans ces deux derniers cas, les 
-   corrections de sécurité sont simplement impossibles à faire. S'il est
-   possible de corriger le problème, et que le responsable du paquet ou 
-quelqu'un d'autre fournit des paquets correctement mis à jour, alors l'équipe en
-   charge de la sécurité, dans la plupart des cas, intégrera ces paquets
-   et publiera une annonce de sécurité.</p>
+R. : La réponse courte est : elle ne l'est pas. <tt>contrib</tt> et
+   <tt>non-free</tt> ne font pas officiellement partie de la distribution
+   Debian et ne sont pas publiées, c'est pourquoi elles ne sont pas prises en
+   charge par l'équipe en charge de la sécurité. Certains paquets de 
+   <tt>non-free</tt>sont distribués sans les sources ou avec une licence ne
+   permettant pas la distribution de versions modifiées. Dans ces deux derniers
+   cas, les corrections de sécurité sont simplement impossibles à faire. S'il
+   est possible de corriger le problème, et que le responsable du paquet ou
+   quelqu'un d'autre fournit des paquets correctement mis à jour, alors
+   l'équipe en charge de la sécurité, dans la plupart des cas, intégrera ces
+   paquets et publiera une annonce de sécurité.</p>
 
 <toc-add-entry name=sidversionisold>L'annonce dit que la distribution unstable
-est corrigée dans la version 1.2.3-1, mais unstable a la version 1.2.5-1, que se
-passe-t-il ?</toc-add-entry>
+  est corrigée dans la version 1.2.3-1, mais unstable a la version 1.2.5-1, que
+  se passe-t-il ?</toc-add-entry>
 <p>R. : Nous essayons de donner le numéro de la première version qui a résolu
-le problème dans unstable.
-Parfois, le mainteneur du paquet a pu mettre à
-disposition entre temps une version plus récente.
-Comparez la version qui se
-trouve dans unstable avec la version que nous indiquons dans l'annonce, si la
-version dans unstable est égale ou supérieure vous devriez être à l'abri de la
-vulnérabilité.</p>
+   le problème dans unstable. Parfois, le mainteneur du paquet a pu mettre à
+   disposition entre temps une version plus récente. Comparez la version qui se
+   trouve dans unstable avec la version que nous indiquons dans l'annonce, si
+   la version dans unstable est égale ou supérieure vous devriez être à l'abri
+   de la vulnérabilité.</p>
 
 <toc-add-entry name=mirror>Pourquoi n'y a-t-il pas de miroir officiel de 
-security.debian.org&nbsp;?</toc-add-entry>
+security.debian.org ?</toc-add-entry>
+<p>
+R. : En fait, il y a plusieurs miroirs officiels, mis en &oelig;uvre
+   à l'aide d'alias DNS. Le but de security.debian.org est de mettre à
+   disposition les mises à jour de sécurité aussi rapidement et facilement que
+   possible.</p>
 
-<p>R.&nbsp;: En fait, il y a plusieurs miroirs officiels, mis en &oelig;uvre
-à l'aide d'alias DNS.
-Le but de security.debian.org est de mettre à disposition les mises
-à jour de sécurité aussi rapidement et facilement que possible.
-</p>
-   
 <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.</p>
 
-<toc-add-entry name=missing>J'ai vu les DSA&nbsp;100 et DSA&nbsp;102, 
-mais où est la DSA&nbsp;101&nbsp;?</toc-add-entry>
-
-<p>R.&nbsp;: Plusieurs distributeurs (la plupart de GNU/Linux, mais aussi des
+<toc-add-entry name=missing>J'ai vu les DSA 100 et DSA 102, 
+mais où est la DSA 101 ?</toc-add-entry>
+<p>
+R. : Plusieurs distributeurs (la plupart de GNU/Linux, mais aussi des
    dérivés BSD) coordonnent leurs alertes 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és par son assurance
+   passer par de longues phases de tests imposés 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
@@ -263,121 +217,106 @@
    numérotation est temporairement rompue.</p>
 
 <toc-add-entry name=contact>
-Comment joindre l'équipe chargée de la sécurité&nbsp;?
+Comment joindre l'équipe chargée de la sécurité ?
 </toc-add-entry>
-
-<p>R.&nbsp;: Les informations relatives à la sécurité peuvent être envoyées à
+<p>
+R. : Les informations relatives à la sécurité peuvent être envoyées à
    security@debian.org ou à team@security.debian.org, chacune de ces adresses
    est lue par l'équipe chargée de la sécurité.</p>
-   
-<p>Si nécessaire, le message peut-être chiffré avec la clé publique du contact 
-sécurité Debian (identifiant de clef<a 
+
+<p>Si nécessaire, le message peut-être chiffré avec la clé publique du contact
+   sécurité Debian (identifiant de clef<a 
    href="http://pgp.surfnet.nl/pks/lookup?op=vindex&amp;search=0xBACB4B5C30AC38F319EE961E2702CAEB90F8EEC5";>\
-   0x90F8EEC5</a>).
-Pour les clés PGP/GPG individuelles des membres de l'équipe chargée de la sécurité,
-   veuillez consulter le serveur de clés <a href="http://keyring.debian.org/";>\
-   keyring.debian.org</a>.
-   </p>
+   0x90F8EEC5</a>). Pour les clés PGP/GPG individuelles des membres de
+   l'équipe chargée de la sécurité, veuillez consulter le serveur de clés
+   <a href="http://keyring.debian.org/";>keyring.debian.org</a>.</p>
 
 <toc-add-entry name=discover>Je pense avoir trouvé un problème de sécurité,
-que suis-je censé faire&nbsp;?</toc-add-entry>
-
-<p>R.&nbsp;: Si vous êtes informé de l'existence d'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 celle-ci confirme la faille et que les autres
-distributeurs sont également concernés,
-elle prendra également contact avec eux.
-Si la vulnérabilité n'est pas encore publique, l'équipe essayera
-de coordonner l'annonce avec les autres distributeurs, de telle
-sorte que les distributions principales soient synchronisées.
-</p>
+   Si celle-ci confirme la faille et que d'autres distributeurs sont
+   également concernés, elle prendra également contact avec eux. Si la
+   vulnérabilité n'est pas encore publique, l'équipe essayera de coordonner
+   l'annonce avec les autres distributeurs, de telle sorte que les
+   distributions principales soient synchronisées.</p>
 
 <p>Si la vulnérabilité a déjà été rendue publique, assurez-vous de remplir un
-rapport de bogue dans le système de suivi des bogues (<em>BTS</em>) de Debian,
-avec la marque <q>security</q>.</p>
+   rapport de bogue dans le système de suivi des bogues (<em>BTS</em>) de
+   Debian, avec la marque <q>security</q>.</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é&nbsp;?</toc-add-entry>
 
-<p>R.&nbsp;: 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
+<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é, dans votre
+   paquet, vous devez toujours prendre contact avec l'équipe en charge de la
    sécurité 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
-   corrige elle-même, est responsable de l'envoi des bulletins d'alerte
-   de sécurité et est responsable du site security.debian.org.</p>
+   corrige elle-même. Elle est responsable de l'envoi des bulletins d'alerte
+   de sécurité et de l'entretien du site security.debian.org.</p>
 
 <p>La <a href="$(DOC)/developers-reference/pkgs.html#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 de ne pas envoyer de paquets ailleurs
+<p>Il est très important de ne pas envoyer de 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 entraînera de la confusion et nécessitera plus de 
    travail.</p>
 
-<toc-add-entry name=enofile>J'ai essayé de télécharger un paquet mentionné dans un
-bulletin d'alerte, mais j'ai eu une erreur « fichier non
-trouvé ».</toc-add-entry>
-
-<p>R.&nbsp;: Ã? chaque fois qu'une nouvelle correction de bogue de
-sécurité remplace un paquet plus ancien de security.debian.org,
-il y a de grandes chances que l'ancien paquet soit
-supprimé, lorsque le nouveau est installé.
-Par conséquent, ce genre d'erreur peut survenir.
-Nous ne voulons pas distribuer des
-   paquets avec des bogues de sécurité connus plus longtemps qu'il n'est
-   nécessaire.</p>
+<toc-add-entry name=enofile>J'ai essayé de télécharger un paquet mentionné dans
+un bulletin d'alerte, mais j'ai eu une erreur « fichier non trouvé ».
+</toc-add-entry>
+<p>
+R. : � chaque fois qu'une nouvelle correction de bogue de
+   sécurité remplace un paquet plus ancien de security.debian.org, il y a de
+   grandes chances que l'ancien paquet soit supprimé, lorsque le nouveau est
+   installé. Par conséquent, ce genre d'erreur peut survenir. 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 sur la liste de diffusion
+   récents, qui sont distribués sur la liste de diffusion
    <a href="http://lists.debian.org/debian-security-announce/";>\
-debian-security-announce</a>.
-Mieux vaut lancer simplement <code>apt-get update</code>
-avant de mettre à niveau le paquet.
-</p>
-
-<toc-add-entry name=upload>
-Je possède un correctif, puis-je le mettre en
-ligne sur security.debian.org directement&nbsp;?
-</toc-add-entry>
+   debian-security-announce</a>. Mieux vaut lancer simplement 
+   <code>apt-get update</code> avant de mettre à niveau le paquet.</p>
 
-<p>R.&nbsp;: Non, vous ne pouvez pas. Les archives de
-   security.debian.org sont entretenues par l'équipe en charge de la
+<toc-add-entry name=upload>Je possède un correctif, puis-je le 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
    correctifs ou des paquets source corrects à l'équipe en charge de la
    sécurité par courriel à 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 modification.
-</p>
-   
+   éventuellement mis en ligne, avec ou sans modification.</p>
+
 <p>La <a href="$(DOC)/developers-reference/pkgs.html#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 un correctif, puis-je le mettre
-en ligne dans <i>proposed-updates</i>&nbsp;?
-</toc-add-entry>
-
-<p>R. : Techniquement parlant, vous pouvez. Cependant, vous ne devriez pas.
+<toc-add-entry name=ppu>Je possède un correctif, puis-je le 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 <q>mauvais</q> 
-   paquets du répertoire <i>proposed-updates</i> ne soient rejetés. Veuillez 
-   prendre contact avec l'équipe en charge de la sécurité, ajoutez tous les 
-détails de la faille et joignez les fichiers source (c'est-à-dire les 
+   de la mise à jour de sécurité, à moins que les <q>mauvais</q>
+   paquets du répertoire <i>proposed-updates</i> ne soient rejetés. Veuillez
+   prendre contact avec l'équipe en charge de la sécurité, ajoutez tous les
+   détails de la faille et joignez les fichiers source (c'est-à-dire les 
    fichiers diff.gz et dsc) à votre courrier électronique.</p>
 
 <p>La <a href="$(DOC)/developers-reference/pkgs.html#bug-security">\
@@ -385,35 +324,33 @@
    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&nbsp;?</toc-add-entry>
-
+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é quoi que ce soit, que le
    numéro de version est le bon (c'est-à-dire supérieur à celui de la version
    qui se trouve dans stable et inférieur à celui qui se trouve dans 
-testing et unstable), que vous n'avez pas modifié
-le comportement du paquet, et que vous avez pallié le problème de
+   testing et unstable), que vous n'avez pas modifié
+   le comportement du paquet, et que vous avez pallié le 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 contient les sources originales si le paquet
+   que le paquet contient les sources originales si le paquet
    est nouveau sur security.debian.org, que vous pouvez confirmer que 
-le correctif pour la plus récente version est propre et ne concerne que
+   le correctif pour la plus récente version est propre et ne concerne que
    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 incoming 
-   <code>ftp://security-master.debian.org/pub/SecurityUploadQueue</code> qui se trouve
-sur security.debian.org directement. Veillez également à notifier à l'équipe 
-en charge de la sécurité sur team@security.debian.org tous les détails
-et liens.
-</p>
+   <code>ftp://security-master.debian.org/pub/SecurityUploadQueue</code> qui se
+   trouve sur security.debian.org directement. Veillez également à notifier à
+   l'équipe en charge de la sécurité sur team@security.debian.org tous les
+   détails et liens.</p>
 
 <toc-add-entry name=help>Comment puis-je fournir de l'aide sur la 
-sécurité&nbsp;?</toc-add-entry>
-
-<p>R.&nbsp;: S'il vous plaît, réexaminez chaque problème avant de le
+sécurité ?</toc-add-entry>
+<p>
+R. : S'il vous plaît, réexaminez chaque problème avant de le
    signaler. 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à &mdash;
@@ -425,23 +362,21 @@
    href="http://security-tracker.debian.org/tracker/data/report";>
    instructions</a>).</p>
 
-<toc-add-entry name=proposed-updates>Quel est le contenu de 
-«&nbsp;proposed-updates&nbsp;»&nbsp;?</toc-add-entry>
-
-<p>R.&nbsp;: Ce répertoire contient les paquets qui ont été proposés dans
+<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 envoyés par
-   des responsables pour la version stable, ils atterrissent dans ce
-   répertoire. Comme la distribution «&nbsp;stable&nbsp;» 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
-   «&nbsp;proposed-updates&nbsp;». Tous les deux mois, les responsables
+   Chaque fois que des paquets sont envoyé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
-   «&nbsp;proposed-updates&nbsp;» et décident si un paquet est approprié
+   « 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 «&nbsp;stable&nbsp;» (par exemple 2.2r3
+   nouvelle version (<i>revision</i>) de « stable » (par exemple 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>
 
@@ -450,87 +385,84 @@
    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é&nbsp;?</toc-add-entry>
-
-<p>R.&nbsp;: L'équipe en charge de la sécurité comporte
+<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 membres et assistants</a>. 
    L'équipe chargée de la sécurité nomme elle-même ses membres.</p>
 
-<toc-add-entry name=lifespan>Pendant combien de temps les mises à jour de sécurité seront-elles fournies&nbsp;?</toc-add-entry>
-
-<p>R.&nbsp;: L'équipe en charge de la sécurité essaye de prendre en charge la
+<toc-add-entry name=lifespan>Pendant combien de temps les mises à jour de
+sécurité seront-elles fournies&nbsp;?</toc-add-entry>
+<p>
+R. : L'équipe en charge de la sécurité essaye de prendre en charge la
    distribution stable environ une année après que la version stable suivante
    a été publiée, sauf lorsqu'une autre distribution stable est publiée
-   la même année. Il n'est pas possible de prendre en charge trois distributions,
-   c'est déjà bien assez difficile avec deux.</p>
-
-<toc-add-entry name=check>Comment puis-je contrôler l'intégrité des paquets&nbsp;?</toc-add-entry>
+   la même année. Il n'est pas possible de prendre en charge trois
+   distributions, c'est déjà bien assez difficile avec deux.</p>
 
-<p>R.&nbsp;: Ce processus consiste à contrôler la signature du fichier <i>Release</i> à
-   l'aide de la <a href="http://ftp-master.debian.org/keys.html";>\
-   clef publique</a> utilisée pour l'archive. Le fichier <i>Release</i> 
-contient les sommes de contrôle des fichiers <i>Packages</i> et <i>Sources</i> qui
-contiennent respectivement les sommes de contrôle des paquets binaires et des 
-paquets source.
-Des instructions détaillées sur la façon de contrôler 
-   l'intégrité des paquets peuvent être obtenues dans le <a
-   href="$(HOME)/doc/manuals/securing-debian-howto/ch7#s-deb-pack-sign">\
-manuel de sécurisation Debian</a>.
-</p>
+<toc-add-entry name=check>Comment puis-je contrôler l'intégrité des paquets ?
+</toc-add-entry>
+<p>
+R. : Ce processus consiste à contrôler la signature du fichier <i>Release</i>
+   à l'aide de la <a href="http://ftp-master.debian.org/keys.html";>\
+   clef publique</a> utilisée pour l'archive. Le fichier <i>Release</i>
+   contient les sommes de contrôle des fichiers <i>Packages</i> et <i>
+   Sources</i> qui contiennent respectivement les sommes de contrôle des
+   paquets binaires et des paquets source. Des instructions détaillées sur la
+   façon de contrôler l'intégrité des paquets peuvent être obtenues dans le
+   <a href="$(HOME)/doc/manuals/securing-debian-howto/ch7#s-deb-pack-sign">\
+   manuel de sécurisation Debian</a>.</p>
 
-<toc-add-entry name=break>Que faire si un paquet est cassé suite à une mise à jour de sécurité&nbsp;?</toc-add-entry>
-<p>R.&nbsp;: Premièrement, vous devez essayer de comprendre pourquoi le paquet
+<toc-add-entry name=break>Que faire si un paquet est cassé suite à une mise à
+jour de sécurité ?</toc-add-entry>
+<p>
+R. : Premièrement, vous devez essayer de comprendre pourquoi le paquet
    est défaillant et comment il interagit avec la mise à jour de sécurité.
    Ensuite, prenez contact avec l'équipe en charge de la sécurité s'il s'agit
-de quelque chose de sérieux ou bien avec le responsable de la distribution stable
-   s'il s'agit de quelque chose de moins grave. Nous parlons ici de paquets
-   quelconques qui cessent de fonctionner après une mise à jour de sécurité
-   d'un autre paquet. Si vous ne parvenez pas à identifier la cause du
-   problème, mais que vous connaissez le correctif, parlez-en également à
+   de quelque chose de sérieux ou bien avec le responsable de la distribution
+   stable s'il s'agit de quelque chose de moins grave. Nous parlons ici de
+   paquets quelconques qui cessent de fonctionner après une mise à jour de
+   sécurité d'un autre paquet. Si vous ne parvenez pas à identifier la cause
+   du problème, mais que vous connaissez le correctif, parlez-en également à
    l'équipe en charge de la sécurité. Il est toutefois possible qu'on vous
    renvoie vers le responsable de la distribution stable.</p>
 
 <toc-add-entry name=cvewhat>Quâ??est-ce quâ??un identifiant CVE ?</toc-add-entry>
-<p>
-R. : Le projet Common Vulnerabilities and Exposures (CVE) assigne des noms
-uniques, appelés identifiants CVE, pour les vulnérabilités spécifiques à la
-sécurité, afin de faciliter la référence unique à un problème spécifique.
-Des renseignements supplémentaires sont disponibles sur <a
-href="https://fr.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures";>\
-Wikipédia</a>.
-</p>
+<p>R. : Le projet Common Vulnerabilities and Exposures (CVE) assigne des noms
+   uniques, appelés identifiants CVE, pour les vulnérabilités spécifiques à la
+   sécurité, afin de faciliter la référence unique à un problème spécifique.
+   Des renseignements supplémentaires sont disponibles sur <a
+   href="https://fr.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures";>\
+   Wikipédia</a>.</p>
 
 <toc-add-entry name=cvedsa>Est-ce que Debian réalise une annonce de sécurité
 (DSA) pour chaque identifiant CVE ?</toc-add-entry>
 <p>
 R. : Lâ??équipe de sécurité Debian suit tous les identifiants CVE publiés, les
-connecte aux paquets Debian correspondants et évalue leur impact dans le
-contexte de Debian â?? le fait quâ??un identifiant CVE soit attribué nâ??implique pas
-forcément que le problème représente une menace sévère pour un système Debian.
-Ces renseignements sont suivis dans le <a
-href="http://security-tracker.debian.org";>Debian Security Tracker</a> et une
-annonce de sécurité Debian sera envoyée pour les problèmes considérés sérieux.
-</p>
+   connecte aux paquets Debian correspondants et évalue leur impact dans le
+   contexte de Debian â?? le fait quâ??un identifiant CVE soit attribué nâ??implique 
+   pas forcément que le problème représente une menace sévère pour un système
+   Debian.Ces renseignements sont suivis dans le <a
+   href="http://security-tracker.debian.org";>Debian Security Tracker</a> et une
+   annonce de sécurité Debian sera envoyée pour les problèmes considérés
+   sérieux.</p>
 
-<p>
-Les problèmes ayant un faible impact pour lesquels aucune DSA ne sera publiée
-peuvent être corrigés dans la publication de Debian suivante, lors dâ??une
-mise à jour intermédiaire des distributions stable ou oldstable actuelles.
-Un correctif pour ces problèmes peut aussi être inclus
-dans une DSA publiée pour une vulnérabilité plus sérieuse.
-</p>
+<p>Les problèmes ayant un faible impact pour lesquels aucune DSA ne sera
+   publiée peuvent être corrigés dans la publication de Debian suivante, lors
+   dâ??une mise à jour intermédiaire des distributions stable ou oldstable
+   actuelles. Un correctif pour ces problèmes peut aussi être inclus dans une
+   DSA publiée pour une vulnérabilité plus sérieuse.</p>
 
-<toc-add-entry name=cveget>Debian peut-elle assigner des identifiants CVE ?</toc-add-entry>
+<toc-add-entry name=cveget>Debian peut-elle assigner des identifiants CVE ?
+</toc-add-entry>
 <p>
-R. : Debian est une autorité de numération CVE et peut
-assigner des identifiants CVE, mais conformément à la politique
-de CVE, uniquement pour des problèmes non encore publics.
-Si vous avez une vulnérabilité de sécurité non publique pour un
-logiciel dans Debian et que vous voudriez obtenir un identifiant
-pour ce problème, contactez lâ??équipe de sécurité Debian.
-Dans le cas où la vulnérabilité est déjà publique,
-veuillez suivre la procédure détaillée dans le <a
-href="http://people.redhat.com/kseifrie/CVE-OpenSource-Request-HOWTO.html";>\
-CVE OpenSource Request HOWTO</a>.
-</p>
+R. : Debian est une autorité de numération CVE et peut assigner des
+   identifiants CVE, mais conformément à la politique de CVE, uniquement pour
+   des problèmes non encore publics. Si vous avez une vulnérabilité de sécurité
+   non publique pour un logiciel dans Debian et que vous voudriez obtenir un
+   identifiant pour ce problème, contactez lâ??équipe de sécurité Debian. Dans 
+   le cas où la vulnérabilité est déjà publique, veuillez suivre la procédure
+   détaillée dans le <a
+   href="http://people.redhat.com/kseifrie/CVE-OpenSource-Request-HOWTO.html";>\
+   CVE OpenSource Request HOWTO</a>.</p>
Reply to: