Re: [LCFC] wml://security/faq.wml
Bonsoir,
une relecture.
J'envoie un diff et le fichier faq.wml que j'ai construit avant
correction avec les corrections de Baptiste et Jean-Paul.
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 place, la modification doit ê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 qui
outrepasseraient 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 les fichiers
disponibles par le réseau comme les courriers électroniques et
leurs pièces jointes 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, pour certaines architectures c'est plus lent que pour d'autres
et il peut arriver que les constructions pour la plupart des
architectures soient prêtes pendant 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é.
Lâ??équipe chargée de la sécurité pourrait tout de même 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 pourraient 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. Il arrive parfois qu'entre temps, le mainteneur du
paquet ait mis à disposition 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 œ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 vous êtes responsable d'un paquet et voulez contacter l'équipe chargée de
la sécurité au sujet d'un problème de sécurité dans votre paquet, veuillez <a
href="http://wiki.debian.org/rt.debian.org#Security_Team";>remplir un ticket
dans notre système de suivi des requêtes (<q>Request Tracker</q>)</a>.
Si vous voulez utiliser un chiffrement PGP, il est tout de
même préférable d'envoyer un courrier électronique classique.
</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&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 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>
<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é, 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é, de préférence en remplissant un ticket dans notre
système de suivi des requêtes (<q>Request Tracker</q>), mais vous
pouvez aussi les contacter par courrier électronique à 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 d'elle-même, 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/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 contenu 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é intervient sur un paquet de security.debian.org,
il y a de grandes chances que l'ancien paquet soit
supprimé, avec pour conséquence ce genre 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 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 sources corrects à l'équipe en charge de la
sécurité, en remplissant un ticket dans le système de suivi des
requêtes (<q>Request Tracker</q>) ou à 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 sources (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à —
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 ?</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>
--- faqcorrige.wml 2013-12-15 23:27:32.173965495 +0100
+++ faqcorrigejpg.wml 2013-12-16 00:26:48.623065118 +0100
@@ -71,8 +71,8 @@
<p>
Cela signifie que passer à une version amont plus récente n'est pas une
bonne solution.
-� la place, la modification doit être rétroportée.
-En règle générale les mainteneurs amont donnent un coup de main, sinon l'équipe
+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>
@@ -107,8 +107,8 @@
<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 qui
-outrepasseraient la procédure de mise à jour de publication.
+ 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
@@ -125,9 +125,9 @@
<p>
Ce genre de vulnérabilité est en quelque sorte en partie
-locale et distante, et concerne souvent les fichiers
-disponibles par le réseau comme les courriers électroniques et
-leurs pièces jointes ou depuis une page de téléchargement.
+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>
<toc-add-entry name=version>
@@ -139,7 +139,7 @@
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.
+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
@@ -153,9 +153,9 @@
une annonce avec les constructions des paquets mis à jour
pour toutes les architectures prises en charge par Debian.
-Néanmoins, pour certaines architectures c'est plus lent que pour d'autres
+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 pendant qu'il en manque d'autres.
+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.
@@ -177,9 +177,9 @@
<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é.
-Lâ??équipe chargée de la sécurité pourrait tout de même envoyer des
-correctifs de sécurité urgents quand les responsables ont lâ??air inactifs.
-La prise en charge de stable sera toujours la priorité.
+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.
@@ -195,7 +195,7 @@
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 pourraient survenir.
+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.
@@ -224,8 +224,8 @@
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. Il arrive parfois qu'entre temps, le mainteneur du
-paquet ait mis à disposition une version plus récente. Comparez la version qui se
+le problème dans unstable. Il arrive parfois que, entre temps, le mainteneur du
+paquet a mis à disposition 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>
@@ -319,7 +319,7 @@
pouvez aussi les contacter par courrier électronique à 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 d'elle-même, est
+ 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>
@@ -334,15 +334,15 @@
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 contenu dans un
+<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é intervient sur un paquet de security.debian.org,
+sécurité remplace un paquet plus ancien de security.debian.org,
il y a de grandes chances que l'ancien paquet soit
-supprimé, avec pour conséquence ce genre d'erreur.
-Nous ne voulons pas distribuer des
+supprimé, lorsque le nouveau est installé. En conséquence, vous aurez ce genre
+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>
@@ -362,7 +362,7 @@
<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 sources corrects à l'équipe en charge de la
+ correctifs ou des paquets source corrects à l'équipe en charge de la
sécurité, en remplissant un ticket dans le système de suivi des
requêtes (<q>Request Tracker</q>) ou à l'adresse team@security.debian.org.
Ils seront revus par
@@ -389,7 +389,7 @@
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 sources (c'est-à -dire 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">\
Reply to: