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

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



Salut,

Un paragraphe a été ajouté à la FAQ de sécurité en début de la rencontre
de l'équipe, par avance merci pour vos relectures (j'ai modifié une
paire d'autres détails en passant, mais n'ai pas relu la page
complètement, après tout c'est Simon qui en est responsable ;-).

Amicalement

David

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

<p>Ces derniers jours, nous avons reçu un peu trop souvent des questions
identiques, et avons donc décidé d'écrire cette page pour y répondre
globalement.</p>

<maketoc>

<toc-add-entry name=signature>La signature sur vos avis de sécurité ne semble pas authentique&nbsp;!</toc-add-entry>
<p>Réponse&nbsp;: Il s'agit très certainement d'un problème de votre part. La liste
   <a href="http://lists.debian.org/debian-security-announce/";>\
   debian-security-announce</a> a un filtre qui n'autorise que les messages
   avec une signature valide d'un des membres de l'équipe chargée de la
   sécurité.</p>

<p>Un de vos outils de messagerie doit légèrement modifier le message,
   ce qui corrompt la signature. Vérifiez que vos logiciels ne font pas
   d'encodage/décodage sur les types MIME, ou de substitutions entre
   espaces et tabulations.</p>

<p>Les coupables habituels sont fetchmail (avec l'option mimedecode
   activée), formail (venant de procmail&nbsp;3.14 seulement) et evolution.</p>

<toc-add-entry name="handling">Comment s'occupe-t-on de la sécurité dans 
Debian&nbsp;?</toc-add-entry>

<p>R.&nbsp;: Une fois que l'équipe en charge de la sécurité reçoit
   notification d'un incident, un ou plusieurs de ses membres examinent
   la situation et en mesurent l'impact sur la version stable de Debian
   (c.-à-d. si elle est vulnérable ou non). Si notre système est
   vulnérable, nous élaborons une correction au problème. Le
   responsable du paquet est lui aussi contacté, s'il n'a pas déjà
   contacté l'équipe en charge de la sécurité. Enfin, la correction est
   testée et de nouveaux paquets sont préparés&nbsp;; ces paquets sont
   compilés sur toutes les architectures stables et ensuite mis en
   téléchargement. Après toutes ces étapes, un rapport est publié.</p>

<toc-add-entry name=oldversion>Pourquoi vous cassez-vous la tête avec une
vieille version de ce paquet&nbsp;?</toc-add-entry>

<p>R.&nbsp;: La règle la plus importante lorsque l'on construit un nouveau paquet qui
   corrige un problème de sécurité est de faire le moins de changements 
   possibles. Nos utilisateurs et nos développeurs s'attendent à ce que la
   distribution conserve son comportement d'origine, aussi n'importe
   quel changement que nous faisons peut éventuellement casser 
   le système de quelqu'un. C'est particulièrement vrai dans le cadre
   des bibliothèques&nbsp;: assurez-vous de ne jamais changer l'interface de 
   programmation du programme (API) ou l'interface binaire de l'application
   (ABI&nbsp;: <i>Application Binary Interface</i>), aussi petite soit la 
   modification.</p>

<p>Cela signifie que changer pour une version plus récente n'est pas une 
   bonne solution, au lieu de cela la modification doit être rétroportée. 
   En règle générale les auteurs donnent un coup de main, sinon l'équipe
   en charge de la sécurité devrait être capable de s'en charger.</p>

<p>Dans des cas particuliers il n'est pas possible de rétroporter une rustine
   de sécurité, par exemple lorsqu'une grande partie du code source doit
   être modifiée ou réécrite. Si cela survient, il sera nécessaire de passer
   à une nouvelle version des fichiers sources, mais cela devra se faire
   avec la participation de l'équipe en charge de la sécurité.</p>


<toc-add-entry name=policy>Quelle est la politique pour qu'un paquet stable 
apparaisse dans security.debian.org&nbsp;?</toc-add-entry>

<p>R.&nbsp;: Un trou de sécurité dans la distribution stable justifie un 
   paquet sur security.debian.org. Le reste non. L'importance de ce trou
   n'est pas un réel critère ici. Habituellement, l'équipe chargée de la
   sécurité prépare les paquets en lien étroit avec le responsable du
   paquet. L'un d'eux (de confiance) indique les causes du problème,
   corrige et compile tous les paquets incriminés, puis les envoie à
   l'équipe chargée de la sécurité. Même si le problème de sécurité est
   trivial à corriger, la correction est placée sur
   security.debian.org. Veuillez lire ci-dessous.</p>

<p>Les mises à jour de sécurité ont un objectif&nbsp;: fournir une rustine pour
   une faille de sécurité. Ces mises à jour n'ont pas vocation à 
   intégrer d'autres modifications dans la version stable qui 
   outrepasseraient les règles normales qui composent la procédure de 
   publication.</p>

<toc-add-entry name=localremote>Que signifie <q>local
(remote)</q>&nbsp;?</toc-add-entry>
<p>R.&nbsp;: Certains bulletins couvrent des vulnérabilités qui ne peuvent pas
   être classifié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 on peut les
   exploiter <em>via</em> 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>De telles vulnérabilités sont en quelque sorte entre les vulnérabilités
   locales et les distantes, et concernent souvent les fichiers disponibles par
   le réseau comme les courriels et leurs pièces jointes.</p> 

<toc-add-entry name=version>Le numéro de version d'un paquet m'indique que 
j'utilise toujours une version vulnérable&nbsp;!</toc-add-entry>

<p>R.&nbsp;: Au lieu de passer à une nouvelle version, nous réalisons un 
   rétroportage (<q>backport</q>) de la rustine de
   sécurité vers la version fournie dans la distribution stable. La
   raison pour laquelle nous faisons cela est qu'une version publiée
   (<q>release</q>) change aussi peu que possible&nbsp;;
   ainsi les rustines de sécurité ne seront pas la cause de problèmes
   annexes. Vous pouvez savoir si vous utilisez une version sécurisée
   d'un paquet en examinant le ChangeLog du paquet, ou en comparant son
   numéro exact de version et celui indiqué par le bulletin d'alerte de
   l'équipe Debian chargée de la sécurité.</p>


<toc-add-entry name=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, certaines architectures sont plus lentes que 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 avec
les constructions pour i386 ou amd64 manquantes.
</p>


<toc-add-entry name=unstable>Comment est gérée la sécurité pour
<tt>unstable</tt>&nbsp;?</toc-add-entry>

<p>R.&nbsp;: La réponse courte est&nbsp;: elle ne l'est pas. Unstable
   évolue rapidement et l'équipe chargée de la sécurité n'a pas les
   ressources nécessaires pour faire ce travail correctement. Si vous
   souhaitez un serveur sûr (et stable), vous êtes fortement encouragé
   à rester sur 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>

<p>R.&nbsp;: Si vous souhaitez un serveur sûr (et stable), vous êtes fortement
   encouragé à rester sur la distribution stable. Cependant, il existe un
   suivi de la sécurité pour <tt>testing</tt>&nbsp;: l'équipe de
   sécurité de Debian s'occupe pour <tt>testing</tt> des problèmes de sécurité.
   Ils s'assureront que les paquets corrigés intègrent <tt>testing</tt> par la
   méthode habituelle en migrant depuis <tt>unstable</tt> (avec un délai de
   quarantaine réduit), ou si cela prend trop de temps, les rendront
   accessibles par l'infrastructure <a
   href="http://security.debian.org";>http://security.debian.org</a>.
   Pour l'utiliser, assurez-vous de la présence dans <code>/etc/apt/sources.list</code> de la ligne&nbsp;:</p>
   <p><code>deb http://security.debian.org &lt;nom_de_code&gt;/updates main</code></p>
   <p>et exécutez <code>apt-get update &amp;&amp; apt-get upgrade</code> commme
   vous en avez l'habitude</p>
   <p>Notez bien que cela ne garantit en rien que tous les bugs de sécurité
   connus sont corrigés dans <tt>testing</tt>&nbsp;! Certains paquets mis à
   jour peuvent être en attente de transition vers <tt>testing</tt>.
   Plus d'informations sur l'infrastructure de sécurité
   pour <tt>testing</tt> sont disponibles sur <a
   href="http://secure-testing-master.debian.net/";>http://secure-testing-master.debian.net/</a>.</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>

<p>R.&nbsp;: La réponse courte est&nbsp;: elle ne l'est pas. <i>contrib</i> et
   <i>non-free</i> ne sont pas des parties officielles 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 <i>non-free</i>
   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 à jour conformes, 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&nbsp;?</toc-add-entry>

<p>R.&nbsp;: En fait, il y a plusieurs miroirs officiels, mis en &oelig;uvre
   par des alias DNS. Le but de security.debian.org est de rendre les mises à jour
   pour raisons de sécurité disponibles aussi rapidement 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 le DSA&nbsp;101&nbsp;?</toc-add-entry>

<p>R.&nbsp;: 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ées par son assurance
   qualité, ou doit fournir des solutions sur une multitude
   d'architectures). Notre propre équipe en charge de la sécurité
   prépare ainsi ses avis à l'avance. De temps en temps, d'autres
   problèmes de sécurité doivent être traités avant que l'avis en
   attente ne soit rendu public, et ainsi la continuité de la
   numérotation est temporairement rompue.</p>

<toc-add-entry name=contact>Comment puis-je contacter l'équipe chargée de la 
sécurité&nbsp;?</toc-add-entry>

<p>R.&nbsp;: 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 avez des informations sensibles, veuillez les envoyer uniquement aux
   membres de l'équipe chargée de la sécurité à team@security.debian.org.</p>
   
<p>Si nécessaire, le message peut-être chiffré avec la clé publique du contact 
   sécurité Debian (ID&nbsp;<a 
   href="http://pgpkeys.pca.dfn.de/pks/lookup?search=0x68B64E0D&amp;op=vindex";>\
   0x68B64E0D</a>).
   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é,
   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, ils prennent également contact avec
   les autres revendeurs. Si la vulnérabilité ne peut pas être publiée,
   ils essaient de coordonner les annonces de sécurité avec les autres
   revendeurs, ainsi les principales distributions sont synchronisées.</p>

<p>Si 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é&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
   sécurité. Vous pouvez les contacter par courriel à l'adresse
   team@security.debian.org.  Cette équipe s'occupe du suivi des
   problèmes de sécurité, peut aider les responsables de paquets à
   corriger les problèmes de sécurité ou les corrigent eux-mêmes, est
   responsable de l'envoi des bulletins d'alerte de sécurité et est
   responsable du site security.debian.org.</p>

<p>La <a href="$(DOC)/developers-reference/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 que vous ne mettiez pas en ligne vos paquets ailleurs
   que dans la distribution <i>unstable</i> sans y avoir été préalablement
   invité par l'équipe en charge de la sécurité. Si vous ne respectez pas
   cette règle, cela 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 comme quoi le fichier n'est pas 
trouvé.</toc-add-entry>

<p>R.&nbsp;: Ã? chaque fois qu'une nouvelle correction de bogue de
   sécurité intervient sur un paquet de security.debian.org, les
   chances sont grandes que l'ancien paquet soit supprimé, ce qui
   entraîne ce message d'erreur. Nous ne voulons pas distribuer des
   paquets avec des bogues de sécurité connus plus longtemps qu'il n'est
   nécessaire.</p>

<p>Veuillez utiliser les paquets des bulletins d'alerte les plus
   récents, qui sont distribués à travers la liste de diffusion
   <a href="http://lists.debian.org/debian-security-announce/";>\
   debian-security-announce</a>. Il vaut mieux lancer simplement
   <code>apt-get update</code> avant de mettre à jour le paquet.</p>

<toc-add-entry name=upload>Je possède une rustine, puis-je la mettre en ligne 
sur security.debian.org directement&nbsp;?</toc-add-entry>

<p>R.&nbsp;: Non, vous ne pouvez pas. Les archives de
   security.debian.org sont entretenues par l'équipe en charge de la
   sécurité, qui doit approuver tous les paquets. Vous devez envoyer vos
   rustines ou des paquets sources propres à l'équipe en charge de la
   sécurité a l'adresse team@security.debian.org. Ils seront revus par
   l'équipe en charge de la sécurité et éventuellement mis en ligne, avec
   ou sans modifications.</p>
   
<p>Si vous n'êtes pas habitué des mises à jour de sécurité, et que vous
   n'êtes pas certain que votre paquet est sain, lisez bien ce qui suit,
   ne mettez pas vos paquets en ligne dans le répertoire <i>incoming</i>.
   L'équipe en charge de la sécurité dispose de possibilités réduites pour
   traiter un paquet mal formé, particulièrement dans le cas où le numéro
   de version n'est pas bon. Les paquets ne pourront pas être rejetés
   et le démon de construction <i>buildd</i> sera perturbé si cela doit
   se produire. Pour traiter ces problèmes, utilisez le courriel et 
   aidez-nous en ne rajoutant pas des problèmes supplémentaires sur les bras
   de l'équipe en charge de la sécurité.</p>

<p>La <a href="$(DOC)/developers-reference/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 une rustine, puis-je la mettre en ligne
dans <i>proposed-updates</i>&nbsp;?</toc-add-entry>

<p>R&nbsp;: 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 à votre courriel les fichiers sources (i.e. 
   les fichiers diff.gz et dsc).</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&nbsp;?</toc-add-entry>

<p>R&nbsp;: Si vous êtes certain de ne pas avoir cassé quelque chose, que le
   numéro de version est le bon (i.e. supérieur à celui dans la version
   qui se trouve dans stable et inférieur à celui qui se trouve dans 
   testing/unstable), que vous n'avez pas modifié
   le comportement du paquet, et que vous avez pallié au problème de
   sécurité, que vous l'avez compilé pour la bonne distribution (qui 
   est <code>oldstable-security</code> ou <code>stable-security</code>),
   que le paquet contienne les sources originales si le paquet
   est nouveau sur security.debian.org, que vous pouvez confirmer que 
   la rustine pour la plus récente version est propre et concerne uniquement
   le problème de sécurité dont il est question (vérifiez-le avec la commande
   <code>interdiff -z</code> et également les fichiers <code>.diff.gz</code>),
   que vous avez relu la rustine au moins trois fois, et que 
   <code>debdiff</code> n'affiche aucun changement, vous pouvez mettre en 
   ligne les fichiers dans le répertoire 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 de tous les détails
   et des liens.</p>

<toc-add-entry name=help>Comment puis-je fournir de l'aide sur la 
sécurité&nbsp;?</toc-add-entry>

<p>R.&nbsp;: 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 
«&nbsp;proposed-updates&nbsp;»&nbsp;?</toc-add-entry>

<p>R.&nbsp;: 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
   de la version stable vérifient la liste des paquets de
   «&nbsp;proposed-updates&nbsp;» 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;» (p.e. 2.2r3
   ou 2.2r4). Les paquets qui ne correspondent pas seront probablement
   rejetés et seront aussi retirés de <i>proposed-updates</i>.</p>

<p>Veuillez noter que les paquets mis en ligne par les responsables 
   de paquets (et non par l'équipe en charge de la sécurité) dans 
   le répertoire proposed-updates/ ne sont pas maintenus par 
   l'équipe en charge de la sécurité.</p>

<toc-add-entry name=composing>De quelle façon est constituée l'équipe chargée 
de la sécurité&nbsp;?</toc-add-entry>

<p>R.&nbsp;: L'équipe en charge de la sécurité comporte
   <a href="../intro/organization">plusieurs officiers et des secrétaires</a>. 
   L'équipe chargée de la sécurité nomme elle-même ses membres.</p>

<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
   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>

<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/archive-key-4.0.asc";>\
   clef publique</a> utilisée pour l'archive. Le fichier <i>Release</i> 
   contient les hachés MD5 des fichiers <i>Packages</i> et <i>Sources</i> qui
   contiennent respectivement les hachés MD5 des paquets binaires et des 
   paquets sources. 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 la 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
   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 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>
Index: french/security/faq.wml
===================================================================
RCS file: /cvsroot/webwml/webwml/french/security/faq.wml,v
retrieving revision 1.66
diff -u -r1.66 faq.wml
--- french/security/faq.wml	6 May 2010 23:47:58 -0000	1.66
+++ french/security/faq.wml	15 Jan 2011 16:53:57 -0000
@@ -1,5 +1,5 @@
 #use wml::debian::template title="FAQ de l'équipe Debian sur la sécurité"
-#use wml::debian::translation-check translation="1.70" maintainer="Simon Paillard"
+#use wml::debian::translation-check translation="1.72" maintainer="Simon Paillard"
 #include "$(ENGLISHDIR)/security/faq.inc"
 
 <p>Ces derniers jours, nous avons reçu un peu trop souvent des questions
@@ -109,7 +109,33 @@
    d'un paquet en examinant le ChangeLog du paquet, ou en comparant son
    numéro exact de version et celui indiqué par le bulletin d'alerte de
    l'équipe Debian chargée de la sécurité.</p>
- 
+
+
+<toc-add-entry name=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, certaines architectures sont plus lentes que 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 avec
+les constructions pour i386 ou amd64 manquantes.
+</p>
+
+
 <toc-add-entry name=unstable>Comment est gérée la sécurité pour
 <tt>unstable</tt>&nbsp;?</toc-add-entry>
 
@@ -124,7 +150,7 @@
 
 <p>R.&nbsp;: Si vous souhaitez un serveur sûr (et stable), vous êtes fortement
    encouragé à rester sur la distribution stable. Cependant, il existe un
-   support de la sécurité pour <tt>testing</tt>&nbsp;: l'équipe de
+   suivi de la sécurité pour <tt>testing</tt>&nbsp;: l'équipe de
    sécurité de Debian s'occupe pour <tt>testing</tt> des problèmes de sécurité.
    Ils s'assureront que les paquets corrigés intègrent <tt>testing</tt> par la
    méthode habituelle en migrant depuis <tt>unstable</tt> (avec un délai de
@@ -132,7 +158,7 @@
    accessibles par l'infrastructure <a
    href="http://security.debian.org";>http://security.debian.org</a>.
    Pour l'utiliser, assurez-vous de la présence dans <code>/etc/apt/sources.list</code> de la ligne&nbsp;:</p>
-   <p><code>deb http://security.debian.org testing/updates main</code></p>
+   <p><code>deb http://security.debian.org &lt;nom_de_code&gt;/updates main</code></p>
    <p>et exécutez <code>apt-get update &amp;&amp; apt-get upgrade</code> commme
    vous en avez l'habitude</p>
    <p>Notez bien que cela ne garantit en rien que tous les bugs de sécurité
@@ -145,9 +171,9 @@
 <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>
 
-<p>R.&nbsp;: La réponse courte est&nbsp;: elle ne l'est pas. <i>Contrib</i> et
+<p>R.&nbsp;: La réponse courte est&nbsp;: elle ne l'est pas. <i>contrib</i> et
    <i>non-free</i> ne sont pas des parties officielles de la distribution 
-   Debian et ne sont pas publiées, c'est pourquoi elles ne sont pas supportées 
+   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 <i>non-free</i>
    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 
@@ -392,11 +418,11 @@
 
 <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 supporter la
+<p>R.&nbsp;: 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 supporter trois distributions&nbsp;;
-   en supporter deux est déjà bien assez difficile.</p>
+   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>
 

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: