Salut, Le 08/05/2012 00:25, David Prévot a écrit : > […] duplicata de www.d.o/security/faq dont > je vais bientôt proposer une relecture et fusion des deux versions Doucement, mais sûrement, j'ai modifié pas mal de choses (le diff est aussi long que la page complète), et n'ai pas gardé l'indentation du texte dans les lignes que j'ai édité (ce qui permet de voir, sans regarder le diff, la plupart des lignes vraiment modifiées). Par avance merci pour vos relectures de cette relecture. Amicalement David
Index: french/security/faq.wml
===================================================================
RCS file: /cvs/webwml/webwml/french/security/faq.wml,v
retrieving revision 1.74
diff -u -r1.74 faq.wml
--- french/security/faq.wml 27 Dec 2011 19:12:07 -0000 1.74
+++ french/security/faq.wml 18 Jun 2012 21:39:38 -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.77" maintainer="David Prévot"
+#use wml::debian::translation-check translation="1.78" maintainer="David Prévot"
#include "$(ENGLISHDIR)/security/faq.inc"
# Translators:
@@ -8,7 +8,7 @@
# Thomas Marteau, 2004
# Simon Paillard, 2005-2009
# Jean-Ã?douard Babin, 2008
-# David Prévot, 2011
+# David Prévot, 2011, 2012.
<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
@@ -16,105 +16,132 @@
<maketoc>
-<toc-add-entry name=signature>La signature sur vos avis de sécurité ne semble pas authentique !</toc-add-entry>
-<p>Réponse : Il s'agit très certainement d'un problème de votre part. La liste
+<toc-add-entry name=signature>
+La signature des avis de sécurité ne semble pas authentique !
+</toc-add-entry>
+<p>
+Réponse : C'est sous 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 valide d'un des membres 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 que vos logiciels ne font pas
- d'encodage/décodage sur les types 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 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>
-
-<p>R. : Une fois que l'équipe en charge de la sécurité reçoit
- notification d'un incident, un ou plusieurs de ses membres examinent
- la situation et en mesurent l'impact sur la version stable de Debian
- (c.-à -d. si elle est vulnérable ou non). Si notre système est
- vulnérable, nous élaborons une correction au problème. Le
+<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 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 ?</toc-add-entry>
+compilés sur toutes les architectures stables puis envoyés.
+Après toutes ces étapes, une annonce est publiée.
+</p>
-<p>R. : 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
+<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, 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
+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 du programme (API) ou l'interface binaire de l'application
- (ABI : <i>Application Binary Interface</i>), aussi petite soit la
- modification.</p>
+(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>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>
+<p>
+Dans certains cas, rétroporter un correctif
+de sécurité n'est pas possible, par exemple si 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 politique pour qu'un paquet stable
-apparaisse dans security.debian.org ?</toc-add-entry>
+<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. : Un trou de sécurité dans la distribution stable justifie un
- paquet sur security.debian.org. Le reste non. L'importance de ce trou
+<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 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,
+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 si le problème de sécurité est
- trivial à corriger, la correction est placée sur
+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 une rustine pour
+<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 les règles normales qui composent la procédure de
- publication.</p>
+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. : Certains bulletins couvrent des vulnérabilités qui ne peuvent pas
- être classifiées suivant la distinction habituelle d'une exploitation locale ou
+<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 on peut les
- exploiter <em>via</em> des fichiers spéciaux issus du réseau alors que le
+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>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 courrier électroniques et leurs pièces jointes.</p>
+<p>
+Ce genre de vulnérabilités est en quelque sorte en partie
+locale et distante, et concerne souvent les fichiers
+disponibles par le réseau comme les courrier é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 m'indique que
-j'utilise toujours une version vulnérable !</toc-add-entry>
+<toc-add-entry name=version>
+Le numéro de version d'un paquet indique toujours 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>) 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 ;
- 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
+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>
@@ -147,19 +174,24 @@
<toc-add-entry name=unstable>Comment est gérée la sécurité pour
<tt>unstable</tt> ?</toc-add-entry>
-<p>R. : La réponse courte est : elle ne l'est pas. Unstable
+<p>
+R. : La réponse courte est : elle ne l'est pas.
+<tt>unstable</tt>
é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>
+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. : Si vous souhaitez un serveur sûr (et stable), vous êtes fortement
- encouragé à rester sur la distribution stable. Cependant, il existe un
+<p>
+R. : Si vous souhaitez un serveur sûr (et stable), vous devriez
+garder la distribution stable.
+Cependant, il existe un
suivi de la sécurité pour <tt>testing</tt> : l'équipe de
- sécurité de Debian s'occupe pour <tt>testing</tt> des problèmes de sécurité.
+sécurité de Debian s'occupe des problèmes de sécurité pour <tt>testing</tt>.
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
@@ -169,7 +201,8 @@
<p><code>deb http://security.debian.org <nom_de_code>/updates main</code></p>
<p>et exécutez <code>apt-get update && 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é
+<p>
+Remarquez que cela ne garantit pas que tous les bogues de sécurité
connus sont corrigés dans <tt>testing</tt> ! Certains paquets mis Ã
jour peuvent être en attente de transition vers <tt>testing</tt>.
Plus d'informations sur l'infrastructure de sécurité
@@ -179,20 +212,22 @@
<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. <i>contrib</i> et
- <i>non-free</i> ne sont pas des parties officielles de la distribution
+<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 <i>non-free</i>
+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 à jour conformes, alors l'équipe en
+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
+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
@@ -205,8 +240,10 @@
security.debian.org ?</toc-add-entry>
<p>R. : En fait, il y a plusieurs miroirs officiels, mis en œ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>
+Ã 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
@@ -229,8 +266,9 @@
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é ?</toc-add-entry>
+<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
@@ -247,10 +285,10 @@
</p>
<p>Si nécessaire, le message peut-être chiffré avec la clé publique du contact
- sécurité Debian (ID <a
+sécurité Debian (identifiant de clef<a
href="http://pgp.surfnet.nl/pks/lookup?search=0x68B64E0D&op=vindex";>\
0x68B64E0D</a>).
- Les clés PGP/GPG individuelles des membres de l'équipe chargée de la sécurité,
+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>
@@ -262,10 +300,12 @@
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>
+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,
@@ -293,59 +333,69 @@
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
+<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 comme quoi le fichier n'est pas
+bulletin d'alerte, mais j'ai eu une erreur de 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, les
- chances sont grandes que l'ancien paquet soit supprimé, ce qui
- entraîne ce message d'erreur. Nous ne voulons pas distribuer des
+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 à travers 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>. Il vaut mieux lancer simplement
- <code>apt-get update</code> avant de mettre à jour le paquet.</p>
+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 une rustine, puis-je la mettre en ligne
-sur security.debian.org directement ?</toc-add-entry>
+<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 notre système de suivi des
+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 modifications.</p>
+ou sans modification.
+</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,
+<p>
+Si vous n'êtes pas habitué aux mises à jour de sécurité, et que vous
+n'êtes pas certain que le 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
+L'équipe en charge de la sécurité dispose de moyens limités 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 la messagerie électronique et
- aidez-nous en ne rajoutant pas des problèmes supplémentaires sur les bras
+veuillez ne pas ajouter de 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> ?</toc-add-entry>
+<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
@@ -368,16 +418,17 @@
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é quelque chose, que le
+<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/unstable), que vous n'avez pas modifié
+testing et 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
+que le paquet contient 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 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
@@ -419,7 +470,7 @@
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 » (p.e. 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>
@@ -432,7 +483,7 @@
de la sécurité ?</toc-add-entry>
<p>R. : L'équipe en charge de la sécurité comporte
- <a href="../intro/organization">plusieurs officiers et des secrétaires</a>.
+<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>
@@ -448,12 +499,14 @@
<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/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
+contient les sommes de contrôle MD5 des fichiers <i>Packages</i> et <i>Sources</i> qui
+contiennent respectivement les sommes de contrôle MD5 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 la sécurisation Debian</a>.</p>
+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
#use wml::debian::template title="FAQ de l'équipe Debian sur la sécurité" #use wml::debian::translation-check translation="1.78" 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, 2012. <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 sous 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 du programme (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 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 ici. 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és est en quelque sorte en partie locale et distante, et concerne souvent les fichiers disponibles par le réseau comme les courrier é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 toujours 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, 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 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 réponse courte est : elle ne l'est pas. <tt>unstable</tt> é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 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. : Si vous souhaitez un serveur sûr (et stable), vous devriez garder la distribution stable. Cependant, il existe un suivi de la sécurité pour <tt>testing</tt> : l'équipe de sécurité de Debian s'occupe des problèmes de sécurité pour <tt>testing</tt>. 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 :</p> <p><code>deb http://security.debian.org <nom_de_code>/updates main</code></p> <p>et exécutez <code>apt-get update && apt-get upgrade</code> commme vous en avez l'habitude</p> <p> Remarquez que cela ne garantit pas que tous les bogues de sécurité connus sont corrigés dans <tt>testing</tt> ! 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> ?</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 le 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é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 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?search=0x68B64E0D&op=vindex";>\ 0x68B64E0D</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 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 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 de 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> Si vous n'êtes pas habitué aux mises à jour de sécurité, et que vous n'êtes pas certain que le 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 moyens limités 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 la messagerie électronique et veuillez ne pas ajouter de 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 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 à votre courrier électronique les fichiers sources (c'est-à -dire 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 ?</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é 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 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 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é ?</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/archive-key-4.0.asc";>\ clef publique</a> utilisée pour l'archive. Le fichier <i>Release</i> contient les sommes de contrôle MD5 des fichiers <i>Packages</i> et <i>Sources</i> qui contiennent respectivement les sommes de contrôle MD5 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 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>
Attachment:
signature.asc
Description: OpenPGP digital signature