Une relecture de l'ensemble du fichier. -- Thomas Huriaux
Index: faq.wml
===================================================================
RCS file: /cvs/webwml/webwml/french/security/faq.wml,v
retrieving revision 1.38
diff -u -r1.38 faq.wml
--- faq.wml 21 Jan 2005 14:27:55 -0000 1.38
+++ faq.wml 21 Jan 2005 14:48:45 -0000
@@ -21,7 +21,7 @@
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>
+ activée), formail (venant de procmail 3.14 seulement) et evolution.</p>
<toc-add-entry name="handling">Comment s'occupe-t-on de la sécurité dans
Debian ?</toc-add-entry>
@@ -37,7 +37,7 @@
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
+<toc-add-entry name=oldversion>Pourquoi vous cassez-vous la tête avec une
vieille version de ce paquet ?</toc-add-entry>
<p>R. : La règle la plus importante lorsque l'on construit un nouveau paquet qui
@@ -46,19 +46,19 @@
distribution conserve son comportement d'origine, aussi n'importe
quel changement que nous faisons peut éventuellement casser
le système de quelqu'un. C'est particulièrement vrai dans le cadre
- des bibliothèques : assurez-vous de ne jamais changer l'interface de
+ des bibliothèques : assurez-vous de ne jamais changer l'interface de
programmation du programme (API) ou l'interface binaire de l'application
- (ABI : <i>Application Binary Interface</i>), aussi petite soit la
+ (ABI : <i>Application Binary Interface</i>), aussi petite soit la
modification.</p>
<p>Cela signifie que changer pour une version plus récente n'est pas une
- bonne solution, au lieu de cela la modification doit être rétro-portée.
+ 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étro-porter une rustine
+<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
+ ê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>
@@ -67,7 +67,7 @@
apparaisse dans security.debian.org ?</toc-add-entry>
<p>R. : Un trou de sécurité dans la distribution stable justifie un
- paquet sur security.debian.org. Le reste non. La taille de ce trou
+ 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,
@@ -78,7 +78,7 @@
<p>Les mises à jour de sécurité ont un objectif : fournir une rustine pour
une faille de sécurité. Ces mises à jour n'ont pas vocation à
- intégrer d'autres modifications dans la version stable stable qui
+ intégrer d'autres modifications dans la version stable qui
outrepasseraient les règles normales qui composent la procédure de
publication.</p>
@@ -86,7 +86,7 @@
j'utilise toujours une version vulnérable !</toc-add-entry>
<p>R. : Au lieu de passer à une nouvelle version, nous réalisons un
- rétro-portage (« <i>backport</i> ») de la rustine de
+ rétroportage (« <i>backport</i> ») de la rustine de
sécurité vers la version fournie dans la distribution stable. La
raison pour laquelle nous faisons cela est qu'une version publiée
(« <i>release</i> ») change aussi peu que possible ;
@@ -102,7 +102,7 @@
<p>R. : La réponse courte est : elle ne l'est pas. Testing et unstable
évoluent rapidement et l'équipe chargée de la sécurité n'a pas les
ressources nécessaires pour faire ce travail correctement. Si vous
- souhaitez un serveur sûr (et stable), vous êtes fortement encouragés
+ souhaitez un serveur sûr (et stable), vous êtes fortement encouragé
à rester sur la distribution stable. Cependant, les membres de l'équipe
en charge de la sécurité essayeront de corriger les problèmes dans
<i>testing</i> et <i>unstable</i> une fois qu'ils auront été corrigés dans
@@ -133,7 +133,7 @@
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=mirror>Pourquoi n'y a-t-il pas de miroirs officiels de
+<toc-add-entry name=mirror>Pourquoi n'y a-t-il pas de miroir officiel de
security.debian.org ?</toc-add-entry>
<p>R. : Le but de security.debian.org est de rendre les mises à jour pour
@@ -144,11 +144,11 @@
problèmes s'ils n'étaient pas à jour. Cependant, nous prévoyons d'utiliser
de tels miroirs dans le futur.</p>
-<toc-add-entry name=missing>J'ai vu les DSA 100 et DSA 102,
+<toc-add-entry name=missing>J'ai vu les DSA 100 et DSA 102,
mais où est le DSA 101 ?</toc-add-entry>
-<p>R. : plusieurs distributeurs (la plupart de GNU/Linux, mais aussi des
- dérivés BSD) coordonnent leurs avis de sécurité pour certains
+<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
@@ -184,7 +184,7 @@
<p>R. : Si vous êtes informé de l'existence d'un problème de sécurité,
soit dans un de vos paquets, soit dans le paquet de quelqu'un d'autre,
prenez systématiquement contact avec l'équipe en charge de la sécurité.
- Si l'équipe en charge de la sécurité confirme la faille et que les autres
+ 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
@@ -248,7 +248,7 @@
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
+ traiter un paquet malformé, 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
@@ -271,7 +271,7 @@
d'archive. En définitive, la distribution stable se retrouvera dépourvue
de la mise à jour de sécurité, à moins que les « mauvais »
paquets du répertoire <i>proposed-updates</i> ne soient rejetés. Veuillez
- prendre contact avec l'équipe en charge de la sécurité et ajoutez tous les
+ 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>
@@ -290,10 +290,10 @@
le comportement du paquet, et que vous avez pallié au problème de
sécurité, que vous l'avez compilé pour la bonne distribution (qui
est <code>oldstable-security</code> ou <code>stable-security</code>),
- que le paquet contiennent les sources originales si le paquet
+ 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
+ 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
@@ -318,7 +318,7 @@
<p>R. : Ce répertoire contient les paquets qui ont été proposés dans
le but d'être incorporés dans la prochaine version stable de Debian.
- Chaque fois que des paquets sont mis en téléchargement (uploadés) par
+ 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,
@@ -349,7 +349,7 @@
<p>R. : L'équipe en charge de la sécurité essaye de supporter la
distribution stable environ une année après que la version stable suivante
- ait été publiée, sauf lorsqu'une autre distribution stable est publiée
+ 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 ;
en supporter deux est déjà bien assez difficile.</p>
Attachment:
signature.asc
Description: Digital signature