Update head to match stable 1.0

4 files changed, 2083 insertions, 0 deletions

diff --git a/doc/fr/ChangeLog b/doc/fr/ChangeLog
new file mode 100644
index 000000000..167093dcc
--- /dev/null
+++ b/doc/fr/ChangeLog
@@ -0,0 +1,17 @@
+2001-09-10 Gilbert Fernandes <[email protected]>
+
+	* Traduction en français des documents doc/*
+
+
+Copyright 2001 Free Software Foundation, Inc.
+
+Ce fichier est un logiciel libre ; l'auteur vous donne une autorisation
+spéciale de copies illimitées et/ou distribution illimitée avec ou sans
+modifications attendu que cette notice de copyright et note associée
+se trouve conservée dans le document.
+
+This file is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY, to the extent permitted by law; without even the
+implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+
+
diff --git a/doc/fr/DETAILS b/doc/fr/DETAILS
new file mode 100644
index 000000000..5c7246c9d
--- /dev/null
+++ b/doc/fr/DETAILS
@@ -0,0 +1,945 @@
+
+Format des listings "---with-colons"
+====================================
+
+sec::1024:17:6C7EE1B8621CC013:1998-07-07:0:::Werner Koch <[email protected]>:
+ssb::1536:20:5CE086B5B5A18FF4:1998-07-07:0:::
+
+ 1. Champ:  Type d'enregistrement
+	    pub = clef publique
+	    sub = sous-clef (clef secondaire)
+	    sec = clef secrète
+	    ssb = sous-clef secrète (clef secondaire)
+	    uid = id d'utilisateur (seul le champ 10 est utilisé)
+            sig = signature
+	    fpr = fingerprint: (le champ 10 est le fingerprint)
+	    pkd = données publiques de la clef
+		(champ au format spécial, voir ci-dessous)
+
+ 2. Champ:  Une lettre décrivant la confiance calculée. Ce n'est qu'une
+	seule lettre, mais elle fera peut-être l'objet d'une information
+	supplémentaire pour les versions futures, comme décrit ici
+	(ceci ne sera pas utilisé pour les clefs privées)
+		o = Inconnu (cette clef est nouvelle au système)
+                i = La clef est invalide (eg. il manque sa propre signature)
+		d = La clef a été désactivée
+		r = La clef a été révoquée
+		e = La clef a expiré
+		q = Non-défini (pas de valeur attribuée)
+		n = Ne jamais faire confiance à cette clef
+		m = Cette clef dispose d'une confiance marginale
+		f = Cette clef dispose d'une confiance totale
+		u = Cette clef dispose d'une confiance ultime. Cette valeur
+			n'est utilisée que pour les clefs où la clef secrète est
+			également disponibles.
+ 3. Champ:  taille de la clef en bits.
+ 4. Champ:  Algorithme utilisé:	1 = RSA
+		       16 = ElGamal (chiffrement uniquement)
+		       17 = DSA (parfois appellé DH, signature seulement)
+		       20 = ElGamal (signe et chiffre)
+	    (pour d'autres is, consultez include/cipher.h)
+ 5. Champ:  ID de clef (KeyID)
+ 6. Champ:  Date de création (en UTC)
+ 7. Champ:  Date d'expiration de la clef, vide si aucune.
+ 8. Champ:  ID local : numéro d'enregistrement du répertoire dans la
+			trustdb. Cette valeur n'est valide que tant que la
+			trustdb n'est pas effacée. Vous pouvez utiliser
+			"#<local-id>" comme id d'utilisateur lorsque vous spécifiez
+			la clef. Ceci est requis puisque les id de clef ne sont pas
+			toujours uniques - un programme peut donc utiliser ce numéro
+			pour accéder aux clefs ultérieurement.
+ 9. Champ:  Confiance propre (clef publiques primaires uniquement)
+	    C'est une simple lettre, mais une information supplémentaire pourrait
+		se voir ajoutée dans les versions futures.
+10. Champ:  ID utilisateur. La valeur est placée entre guillemets comme une
+		chaîne en C, par exemple : "\x3a".
+11. Champ:  Classe de signature. C'est un nombre hexadécimal à deux chiffres
+		suivi par la lettre "x" si la signature peut être exportée ou la
+		lettre "l" si la signature est uniquement locale.
+12. Champ:  Capacités de la clef :
+                e = chiffrement
+                s = signature
+                c = certification
+            Une clef peut disposer de toute combinaison de ces caractéristiques.
+		La clef primaire dispose, en plus de ces lettres, une version en
+		majuscule des lettres pour marquer les capacités "d'utilisation"
+		de la totalité de la clef.
+
+Toutes les dates sont affichées dans le format :
+
+yyyy-mm-dd
+
+Sauf si vous utilisez l'option --fixed-list-mode où dans ce cas précis les
+dates sont affichées en secondes depuis Epoch. Plus de champs feront l'objet
+d'additions dans les futures versions et les parsers doivent y être préparés.
+Lorsque le parser traitera ces données, il devra s'arrêter au premier
+caractère non-numérique afin que des informations supplémentaires soient
+ajoutées à l'avenir.
+
+Le champ 1 dispose d'un tag "pkd" dont le listing ressemble à ceci :
+
+pkd:0:1024:B665B1435F4C2 .... FF26ABB:
+    !  !   !-- la valeur
+    !  !------ indicateur du nombre de bits de la valeur
+    !--------- index (eg. DSA va de 0 à 3 : p,q,g,y)
+
+
+
+Format de la sortie "--status-fd"
+=================================
+
+Chaque ligne dispose d'un préfixe :
+
+"[GNUPG:] "
+
+Suivie par un mot clef indiquant le type de la ligne de statut,
+et quelques arguments selon le type (probablement aucun) ; une application
+devrait toujours assumer que des arguments supplémentaires seront
+présents dans les versions futures.
+
+    GOODSIG	<long keyid>  <username>
+	La signature keyid est valide.
+	Pour chaque signature seul l'un des trois codes GOODSIG, BADSIG ou
+	ERRSIG seront produits et ils pourront être utilisés comme
+	marqueurs pour les nouvelles signatures.
+
+    BADSIG	<long keyid>  <username>
+	La signature keyid n'a pas été vérifiée correctement.
+
+    ERRSIG  <long keyid>  <pubkey_algo> <hash_algo> \
+	    <sig_class> <timestamp> <rc>
+	Il n'a pas été possible de vérifier la signature. Ceci peut provenir
+	d'une clef publique manquante, ou bien à cause d'un algorithme non-
+	supporté. Un RC de 4 indique un algorithme inconnu, un 9 indique
+	une clef publique manquante. Les autres champs donnent plus d'information
+	sur la signature. sig_class est une valeur hexadécimale de 2 octets.
+
+    VALIDSIG	<fingerprint in hex> <sig_creation_date> <sig-timestamp>
+	La signature keyid est valide. C'est ici la même chose que GOODSIG
+	mais avec le fingerprint comme argument. Les lignes de statut seront
+	émises pour une bonne signature.
+	sig-timestamp est la date de création de la signature en secondes
+	depuis Epoch.
+
+    SIG_ID  <radix64_string>  <sig_creation_date>  <sig-timestamp>
+	N'est émis que pour les signatures de classe 0 ou 1 qui ont été
+	vérifiées comme valides. Le chaîne est un identifiant d'utilisateur
+	et peut être utilisée dans les applications pour détecter les
+	attaques par rejeu de messages signés. Notez que seuls les
+	algorithmes DLP offrent des identifiants uniques ; les autres peuvent
+	produire des id dupliqués lorsqu'ils furent créés à la même seconde.
+
+    ENC_TO  <long keyid>  <keytype>  <keylength>
+	Le message est chiffré avec ce keyid.
+	keytype est une valeur numérique de l'algorithme à clef publique,
+	keylength est la taille de la clef ou 0 si elle n'est pas connue
+	(ce qui est toujours le cas).
+
+    NODATA  <what>
+	Aucune donnée n'a été trouvée. Les codes suivants sont utilisés :
+	    1 - Pas de données sous ARMOR.
+	    2 - Un paquet attendu n'a pas été trouvé.
+	    3 - Paquet invalide trouvé ; ceci peut indiquer un message
+		non-OpenPGP. Vous devez vous attendre à une extension
+		de ces lignes de statu à l'avenir.
+
+    UNEXPECTED <what>
+        Des données innatendues ont été rencontrées
+            0 - pas de détail supplémentaire
+
+    TRUST_UNDEFINED
+    TRUST_NEVER
+    TRUST_MARGINAL
+    TRUST_FULLY
+    TRUST_ULTIMATE
+	Pour les signatures valides, l'une de ces lignes de statut sera produite
+	pour indiquer le niveau de confiance attribué à la clef. Pas d'arguments
+	pour l'instant.
+
+    SIGEXPIRED
+	La clef de signature a expiré. Pas d'arguments pour l'instant.
+
+    KEYREVOKED
+	L'utilisateur a révoqué sa clef. Pas d'arguments pour l'instant.
+
+    BADARMOR
+	L'ARMOR ASCII est corrompu. Pas d'arguments pour l'instant.
+
+    RSA_OR_IDEA
+	Les algorithmes IDEA ont été utilisés sur les données. Un programme
+	pourra basculer sur un autre programme de traitement si GnuPG échoue.
+	Ce message de statut sera affiché pour le RSA aussi, mais ceci a été
+	abandonné puisque le brevêt sur le RSA a expiré.
+	Toutefois, nous ne pouvons modifier le nom du message.
+
+    SHM_INFO
+    SHM_GET
+    SHM_GET_BOOL
+    SHM_GET_HIDDEN
+
+    GET_BOOL
+    GET_LINE
+    GET_HIDDEN
+    GOT_IT
+
+    NEED_PASSPHRASE <long main keyid> <long keyid> <keytype> <keylength>
+	Sera affiché à chaque fois qu'une phrase passe sera requise.
+	keytype est la valeur numérique de l'algorithme à clef publique
+	ou bien 0 si cela n'est pas applicable. keylength est la taille de la
+	clef ou 0 si la taille n'est pas connue (ceci est actuellement
+	toujours le cas).
+
+    NEED_PASSPHRASE_SYM <cipher_algo> <s2k_mode> <s2k_hash>
+	Affiché à chaque fois qu'une phrase passe pour un chiffrement
+	symétrique sera requise.
+
+    MISSING_PASSPHRASE
+	Aucune phrase passe n'a été fournie. Une application qui rencontre
+	ce message devrait stopper immédiatement le parsing car le prochain
+	message sera probablement BAD_PASSPHRASE. Toutefois, si l'application
+	n'est qu'un wrapper autour de la fonctionnalité d'édition de clefs,
+	ceci pourrait avoir un autre sens et stopper le parsing pourrait
+	être incorrect, et il faudra ignorer le BAD_PASSPHRASE.
+
+    BAD_PASSPHRASE <long keyid>
+	La phrase passe fournie est soit invalide, soit n'a pas été fournie.
+	Dans le seconde cas vous devriez voir un MISSING_PASSPHRASE.
+
+    GOOD_PASSPHRASE
+	La phrase passe fournie est valide et le matériel de clefs secrète
+	est utilisable.
+
+    DECRYPTION_FAILED
+	La déchiffrement symétrique a échoué. Il s'agit généralement d'une
+	mauvaise phrase passe ne correspondant pas au message chiffré.
+
+    DECRYPTION_OKAY
+	Succès du déchiffrement. Ceci signifie que soit la clef secrète
+	adaptée a été utilisée avec succès, soit que la phrase passe
+	valide pour un chiffrement symétrique aura conduit au déchiffrement.
+	Le programme pourait toutefois renvoyer un message d'erreur s'il
+	n'a pas été possible de vérifier la signature.
+
+    NO_PUBKEY  <long keyid>
+    NO_SECKEY  <long keyid>
+	La clef n'est pas utilisable.
+
+    IMPORTED   <long keyid>  <username>
+	Le keyid et la signature ont été importés.
+
+    IMPORTED_RES <count> <no_user_id> <imported> <imported_rsa> <unchanged>
+	<n_uids> <n_subk> <n_sigs> <n_revoc> <sec_read> <sec_imported> <sec_dups>
+	Statistiques finales sur le processus d'importation (cette ligne est longue!)
+
+    FILE_START <what> <filename>
+	Début de traitement du fichier <filename>. <what> indique l'opération
+	réalisée :
+	    1 - vérifier
+
+    FILE_DONE
+	Marque la fin de traitement d'un fichier, ayant débuté avec FILE_START.
+
+    BEGIN_DECRYPTION
+    END_DECRYPTION
+	Marque le début et la fin du processus de déchiffrement. Ces messages
+	seront également produits lors de l'utilisation du mode --list-only.
+
+    BEGIN_ENCRYPTION
+    END_ENCRYPTION
+	Marque le début et la fin du processus de chiffrement.
+
+    DELETE_PROBLEM reason_code
+	L'effacement d'une clef a échoué. Un code indique la raison de l'erreur :
+	    1 - La clef spécifiée n'existe pas
+	    2 - La clef privée doit être détruite avant !
+
+    PROGRESS what char cur total
+	Utilisé par les fonctions primegen et de clef publique pour indiquer
+	la progression de l'opération. "char" est le caractère affiché sans
+	--status-fd avec les retours à la ligne marqués par "X". "cur" indique
+	la quantitité de traitement terminée et "total" indique la valeur
+	finale à atteindre. Un total de 0 indique que le total n'est pas
+	connu. 100/100 peut être utilisé pour détecter la fin de l'opération.
+
+    SIG_CREATED <type> <pubkey algo> <hash algo> <class> <timestamp> <key fpr>
+	Une signature a été créée à l'aide de ces paramètres.
+	    type:  'D' = détachée
+		   'C' = en texte clair
+		   'S' = standard
+		   (seul le premier caractère doit être vérifié)
+	    class: 2 chiffres hexadécimaux avec la classe de signature
+        
+    KEY_CREATED <type>
+        Une clef a été créée
+            type: 'B' = primaire et sous-clef
+                  'P' = primaire
+                  'S' = sous-clef
+
+    SESSION_KEY  <algo>:<hexdigits>
+	La clef de session utilisée pour déchiffrer le message. Ce message
+	sera seulement affiché si l'option --show-session est utilisée.
+	Le format est utilisable pour un passage direct à la fonction
+	--override-session-key.
+
+    NOTATION_NAME <name> 
+    NOTATION_DATA <string>
+	Le nom et la chaîne sont "escaped" à l'aide de %XX et les données
+	peuvent être découpées sur plusieurs lignes notation_data.
+
+    USERID_HINT <long main keyid> <string>
+	Donne un indice sur l'ID utilisateur pour un keyID donné.
+
+    POLICY_URL <string>
+	La chaîne est "escaped" en %XX
+
+    BEGIN_STREAM
+    END_STREAM
+	Produit par pipemode.
+
+
+Génération de clef
+==================
+
+La génération de clef marque sa progression à l'aide de différents caractères, dont
+voici la signification :
+
+"." : les 10 derniers tests Miller-Rabin ont échoué.
+"+" : réussite du test Miller-Rabin.
+"!" : Rechargement du pool avec des nombres premiers frais.
+"^" : Vérification d'une nouvelle valeur pour le générateur.
+"<" : La taille d'un facteur a été réduite.
+">" : La taille d'un facteur a été augmentée.
+
+Le nombre premier pour l'ElGamal est généré de la manière suivante :
+
+1. On crée un nombre premier q de 160, 200 ou 240 bits (selon la taille
+	de la clef).
+2. On sélectionne la taille de l'autre facteur premier, afin qu'elle soit
+	au moins de la taille de q et on calcule le nombre de facteurs premiers
+	requis.
+3. On crée un pool de nombres premiers, chacun dont la longueur fut déterminée
+	à l'étape 2.
+4. On obtient une nouvelle permutation du pool et nous continuons avec
+	l'étape 3 une fois toutes les permutations testées.
+5. Le premier cancidat est calculé par p = 2 * q * p[1] * ... * p[n] + 1
+6. On vérifie que ce premier dispose de la taille désirée (ceci peut changer
+	q s'il ne semble pas possible de produire un premier de la taille voulue)
+7. On vérifie si ce nombre est premier à l'aide de divisions d'essai et par
+	le test de Miller-Rabin.
+8. On continue à l'étape 4 si on n'a pas trouvé de premier à l'étape 7.
+9. On trouve un générateur pour ce premier.
+
+Cet algorithme se base sur la suggestion de Lim et Lee du Crypto' 97 (p. 260).
+
+Génération de clef innatendue
+=============================
+
+Cette fonction est actuellement expérimentale et permet la production de
+clefs innatendues avec un contrôle depuis un fichier de paramètres.
+Cette fonctionnalité n'a pas fait l'objet de tests poussés ! Veuillez ne
+PAS vous plaindre si nous décidons d'apporter des modifications importantes
+à cette commande.
+
+Pour utiliser cette fonctionnalité, vous devez utiliser --gen-key en
+combinaison avec --batch et fournir les paramètres soit depuis stdin,
+soit depuis un fichier dont le nom est fourni en ligne de commande.
+
+Ce fichier devra utiliser le format suivant :
+
+ o En texte uniquement, chaque ligne étant limitée à environ 1000 caractères.
+ o Vous devez utiliser un codage UTF-8 pour marquer les caractères non ASCII.
+ o Les lignes vides seront ignorées.
+ o Les espaces en début et fin de ligne seront ignorés.
+ o Un signe "-" en tant que premier caractère "non white space" marque
+	une ligne de commentaire.
+ o Les commandes sont marquées par un signe "%" en début de ligne,
+	suivi par la commande et ses arguments sont séparés par des espaces.
+ o Les paramètres sont indiqués par un mot clef, suivi par un ":". Les
+	arguments sont séparés par des espaces.
+ o Le premier paramètre doit être "Key-Type" et ses contrôles peuvent
+	être placés à votre discrétion.
+ o La génération de clef aura lieu soit à la fin du fichier de paramètres,
+	soit lorsque le premier "Key-Type" est rencontré au sein du fichier,
+	dans un ensenble de contrôle "%commit".
+ o Les ensembles de contrôle sont :
+	%echo <texte>
+	Affiche <texte>
+
+	%dry-run
+	Ne réalise pas la production de clef (pratique pour vérifier la
+	syntaxe).
+
+	%commit
+	Réalise la production de clef. Un commit implicite est produit
+	à chaque rencontre de "Key-Type".
+
+    %pubring <filename>
+    %secring <filename>
+	Ne renvoie pas la clef vers le sortie par défaut ou dans le keyring
+	indiqué en ligne de commande, mais vers le fichier <filename>. Ce
+	contrôle doit être utilisé avant que le commit ne soit rencontré.	
+	Toute double mention sera ignorée et le dernier nom de fichier
+	rencontré sera celui utilisé. Le fichier sera utilisé jusqu'à ce
+	qu'un nouveau fichier soit spécifié (au points de commit) sinon
+	toutes les clefs seront placées dans le même fichier. Si un nouveau
+	nom de fichier est indiqué, le fichier sera créé (et tout ancien
+	fichier sera alors écrasé). Les deux indications doivent être
+	fournies au contrôle.
+
+ o L'ordre des paramètres n'a pas d'importance, sauf pour "Key-Type" qui
+	doit être le premier paramètre rencontré. Les paramètres ne sont
+	destinés qu'au bloc keybloc généré et les paramètres des productions
+	précédentes de clefs ne seront pas pris en compte. Certaines
+	vérifications syntaxiques seront mises en place et peuvent être
+	ou non actives. Les paramètres actuellement définis sont :
+
+     Key-Type: <algo-number>|<algo-string>
+	Débute un nouveau bloc de paramètres indiquant le type de la clef
+	primaire à produire. L'algorithme doit être capable de produire
+	des signatures. Ce paramètre est indispensable !
+
+     Key-Length: <length-in-bits>
+	Indique la taille de la clef, en bits. La valeur par défaut est
+	1024.
+
+     Subkey-Type: <algo-number>|<algo-string>
+	Permet de produire une clef secondaire. Actuellement, seule une
+	sous-clef peut être gérée.
+
+     Subkey-Length: <length-in-bits>
+	Taille de la sous-clef en bits. La valeur par défaut est
+	1024.
+
+     Passphrase: <string>
+	Si vous souhaitez spécifier une phrase passe pour la clef
+	secrète vous pouvez utiliser cette commande. Par défaut,
+	aucune phrase passe ne sera associée aux clefs privées.
+
+     Name-Real: <string>
+     Name-Comment: <string>
+     Name-Email: <string>
+	Voici les trois composantes d'une clef. Vous devez ici
+	n'utiliser que de l'UTF-8. Si vous ne fournissez aucune
+	de ces indications, aucun ID d'utilisateur ne sera créé.
+
+     Expire-Date: <iso-date>|(<number>[d|w|m|y])
+	Spécifie la date d'expiration de la clef (et de sa sous-clef)
+	La date doit être entrée sous la forme d'une date au format
+	ISO (année-mois-jour) ou bien sous forme d'un nombre de
+	jours, de semaines, de mois ou d'années. Si vous n'utilisez
+	pas de lettre pour indiquer la durée, des "jours" sont
+	assumés par défaut.
+
+Voici un exemple :
+$ cat >foo <<EOF
+     %echo Génération d'une clef standard
+     Key-Type: DSA
+     Key-Length: 1024
+     Subkey-Type: ELG-E
+     Subkey-Length: 1024
+     Name-Real: Joe le testeur
+     Name-Comment: ma phrase passe est stupide
+     Name-Email: [email protected]
+     Expire-Date: 0
+     Passphrase: abc
+     %pubring foo.pub
+     %secring foo.sec
+     # Un commit est requis ici, pour pouvoir afficher un "done" :-)
+     %commit
+     %echo done
+EOF
+$ gpg --batch --gen-key -a foo
+ [...]
+$ gpg --no-default-keyring --secret-keyring foo.sec \
+				  --keyring foo.pub --list-secret-keys
+/home/wk/work/gnupg-stable/scratch/foo.sec
+------------------------------------------
+sec  1024D/915A878D 2000-03-09 Joe le testeur (ma phrase passe est stupide) <[email protected]>
+ssb  1024g/8F70E2C0 2000-03-09
+
+
+
+Composition de la TrustDB
+=========================
+
+La TrustDB est construire à partir d'enregistrements à taille fixe, où le premier
+octet décrit le type d'enregistrement. Toutes les valeurs numériques sont
+conservées dans un réseau d'ordre d'octets. La longueur de chaque enregistrement
+est de 40 octets. Le premier enregistrement de la TrustDB est toujours de type 1
+et c'est le seul enregistrement de ce type.
+
+  Record type 0:
+  --------------
+
+	Cet enregistrement n'est pas utilisé. Il peut être utilisé
+	à votre discrétion.
+
+  Record type 1:
+  --------------
+
+	Indique la version de la TrustDB. Cet enregistrement doit toujours être
+	le premier enregistrement de la base de données et c'est le seul
+	enregistrement de type 1.
+
+     1 octet valeur : 1
+     3 octets 'gpg'  valeur "magic"
+     1 octet Version de la TrustDB (2)
+     1 octet marginales requises
+     1 octet complètes requises
+     1 octet max_cert_depth
+
+	Ces trois éléments sont utilisés pour vérifier si la valeur de validité
+	mise en cache dans l'enregistrement du répertoire peut être utilisée :
+
+     1 u32  locked flags
+     1 u32  datation de la création de la trustdb
+     1 u32  datation de la dernière modification
+
+	Cette datation pourrait affecter la validité des clefs dans la base de
+	données. Cette valeur sera comparée à celle de la datation de validité
+	des enregistrements dir :
+
+     1 u32  datation de la dernière validation
+
+	Cette valeur sera utilisée pour stocker le passage du temps, lorsque
+	cette TrustDB sera comparée au trousseau de clefs publiques :
+
+     1 u32  numéro de l'enregistrement du keyhashtable
+     1 u32  premier enregistrement libre
+     1 u32  numéro de l'enregistrement répertoire shadow de la table de hachage
+
+	Cette table ne devrait pas être combinée avec la table de clefs car le
+	keyid n'est pas dans chaque cas un élément du fingerprint.
+
+     4 bytes réservés pour l'enregistrement d'extension de version
+
+
+  Record type 2: (enregistrement répertoire)
+  --------------
+
+	Regroupe les informations sur un certificat de clef publique.
+	Ces valeur sont statiques et ne sont jamais modifiées sans une
+	interaction avec l'utilisateur :
+
+     1 octet valeur : 2
+     1 octet  réservé
+     1 u32   LID     .	(numéro d'enregistrement de cet enregistrement)
+     1 u32   Liste de key-records (le premier est la clef primaire)
+     1 u32   Liste de uid-records
+     1 u32   cache record
+     1 octet  ownertrust
+     1 octet  dirflag
+     1 octet  validité maximale de tous les id utilisateurs
+     1 u32   datation de la dernière vérification de validité
+     1 u32   Vérification requise lorsque cette datation sera atteinte
+	     (0 = pas de vérification requise)
+
+
+  Record type 3:  (enregistrement de clef)
+  --------------
+
+	Regroupe les informations sur une clef publique primaire.
+	(ces informations sont principalement utilisées pour réaliser les lookup
+	dans l'enregistrement trust)
+
+     1 octet valeur : 3
+     1 octet  réservé
+     1 u32   LID
+     1 u32   next   - prochain enregistrement
+     7 octets réservés
+     1 octet  keyflags
+     1 octet  algorithme de la clef publique
+     1 octet  taille du fingerprint (en octets)
+     20 octets fingerprint de la clef publique
+	      (Cette valeur est utilisée pour identifier toute clef)
+
+  Record type 4: (enregistrement uid)
+  --------------
+
+	Regroupe les informations sur un id utilisateur (un "uid").
+	Nous ne stockons par l'uid mais un hachage de l'uid : cela semble suffire.
+
+     1 octet valeur : 4
+     1 octet réservé
+     1 u32  LID  pointe vers l'enregistrement directory
+     1 u32  next   le userid suivant
+     1 u32  pointeur vers l'enregistrement preference
+     1 u32  siglist  liste de signatures valides
+     1 octet uidflags
+     1 octet validité de la clef calculée pour cet userid
+     20 bytes ripemd160 hachage du nom de l'utilisateur
+
+
+  Record type 5: (enregistrement pref)
+  --------------
+
+	Regroupe les informations formant les préférences.
+
+     1 octet valeur : 5
+     1 octet   réservé
+     1 u32  LID; pointe vers l'enregistrement directory (et PAS vers le uid !!!)
+	    (égal à 0 pour un enregistrement de préférences standard)
+     1 u32  suivant
+     30 byte données de préférences
+
+  Record type 6  (sigrec)
+  -------------
+
+	Cet enregistrement est utilisé pour traquer les signatures de clefs. Les
+	auto-signatures ne sont pas conservées. Si une clef publique ne se trouve
+	pas dans la TrustDB, la signature pointe vers un enregistrement dir fantôme,
+	lequel contient une liste des enregistrements qui seraient intéressés
+	par cette clef (et l'enregistrement signature en fait partie).
+
+     1 octet   valeur : 6
+     1 octet   réservé
+     1 u32    LID	    pointe en retour vers l'enregistrment dir
+     1 u32    next   prochain sigrec de cet uid ou bien 0 pour indiquer que ce
+					sigrec est le dernier.
+     6 times
+	1 u32  Local_id des dir signatures ou de l'enregistrement dir fantôme
+	1 octet Flag: Bit 0 = vérifié: Bit 1 est valide (nous avons un
+				véritable enregistrement directory)
+			 1 = valide est vrai (mais pourrait être révoqué)
+
+
+
+  Record type 8: (enregistrement répertoire (dir) fantôme)
+  --------------
+
+	Cet enregistrement est utilisé pour réserver un LID pour une clef publique.
+	Nous avons besoin de cet enregistrement pour créer les enregistrements sigs
+	des autres clefs, même si nous ne disposons pas d'une signature de la clef
+	publique.
+	Cet enregistrement (le numéro d'enregistrement pour être plus précis)
+	sera réutilisé dans l'enregistrement dir lorsque nous importerons la
+	véritable clef publique.
+
+     1 octet valeur : 8
+     1 octet  réservé
+     1 u32   LID      (Ceci est simplement le numéro d'enregistrement de ce record.)
+     2 u32   keyid
+     1 octet  algorithme de la clef publique
+     3 octets réservé
+     1 u32   hintlist
+
+	hintlist contient la liste des enregistrements qui ont des références qui pointent
+	vers cette clef. Nous utilisons cet élément pour augmenter la vitesse d'accès
+	des enregistrements de signature qui ne sont pas encore vérifiés. Notez que ces
+	données ne sont qu'un indice, une indication ("hint") mais les enregistrements actuels	
+	pourraient ne pas détenir d'enregistrement de signature pour la clef, mais le
+	code du programme saura prendre soin de tout cela.
+
+    18 octets réservés
+
+
+
+  Record Type 10 (table de hachage)
+  --------------
+
+	Comme nous utilisons les fingerprint pour accéder aux clefs, nous devons
+	implémenter un accès rapide en utilisant des méthodes de hachages simples,
+	afin d'éviter une surcharge de gdbm. La propriété des fingerprint
+	est qu'ils permettent un usage direct en tant que valeurs hachées (ils
+	peuvent être considérés comme des nombres aléatoires cryptographiquement
+	forts).
+	Nous utilisons une architecture à multiples niveaux dynamique, qui combine
+	les tables de hachage, les listes d'enregistrements et les listes
+	chaînées.
+
+	Cet enregistrement est une table de hachages de 256 entrées ; une propriété
+	spéciale est que tous les enregistrements sont stockés consécutivement
+	pour produire une grande table. La valeur hachée est simplement le 1er,
+	2nd.. octet du fingerprint (selon le niveau d'indirection).
+
+	Lorsque nous les utilisons pour hacher les enregistrements de répertoires
+	shadow, une différente table est utilisée, et elle se trouve indexée
+	par le keyid.
+
+     1 octet valeur : 10
+     1 octet réservé
+     n u32  recnum; n dépend de la taille de l'enregistrement :
+	    n = (reclen-2)/4  ce qui donne 9 pour la taille actuelle
+		d'enregistrement de 40 octets.
+
+	Le nombre total de ces enregistrements constituant la table est :
+
+	 m = (256+n-1) / n
+
+	ce qui donne 29 pour une taille d'enregistrement de 40.
+
+	Pour rechercher une clef, nous utilisons le premier octet du fingerprint
+	pour obtenir le recnum de la table de hachage et nous étudions l'enregistrement
+	adressé :
+
+	o Si cet enregistrement est une autre table de hachage, nous pouvons
+	utiliser le second octet pour indexer cette table de hachage et continuer.
+
+	o Si cet enregistrement est une liste de hachages, nous pouvons parcourir
+	toutes les entrées jusqu'à trouver la bonne.
+
+	o Si cet enregistrement est un enregistrement de clef, nous comparons
+	le fingerprint avec celui recherché et nous déterminons s'il s'agit
+	de la clef recherchée.
+
+
+
+  Record type 11 (liste hachée)
+  --------------
+
+	Consultez la table hachée pour une explication.
+	Ceci sera également utilisé à d'autres fins.
+
+    1 octet valeur : 11
+    1 octet réservé
+    1 u32  next 	 enregistrement de liste hachée suivant
+    n times		 n = (reclen-5)/5
+	1 u32  recnum
+
+	Pour la taille actuelle utilisée par les enregistrements (taille 40) nous avons n = 7.
+
+
+
+
+  Record type 254 (enregistrement libre)
+  ---------------
+
+Tous ces enregistrements forment une liste chaînée d'enregistrements non-utilisés.
+
+     1 octet  valeur 254
+     1 octet  réservé (0)
+     1 u32   next_free
+
+
+
+En-têtes de paquets
+===================
+
+GnuPG utilise des en-têtes PGP 2 et il est aussi capable de comprendre
+les en-têtes de type OpenPGP. C'est une amélioration utilisée sur les anciens
+en-têtes de paquets :
+
+Les CTB bits 10, les "packet-length length bits" ont leurs valeurs listées
+dans la table suivante :
+
+      00 - 1-octet champ packet-length
+      01 - 2-octets champ packet-length
+      10 - 4-octets champ packet-length
+      11 - pas de taille de paquet fournie, taille inconnue
+
+Comme indiqué dans cette table, selon la taille du packet-length les
+octets restants (1, 2, 4 ou 0) du champ de structure de paquets sont
+un "champ packet-length". Ce champ est une valeur numérique à part entière.
+La valeur du champ packet-length est définie par la valeur de la
+totalité du champ numérique.
+
+La valeur 11 est actuellement utilisée dans un cas : les données
+compressées. C''est à dire qu'un bloc de données compressées
+ressemble à : <A3 01 .. .. > où A3 est le binaire "10 1000 11" et
+produit ici un paquet de taille non-définie. L'interprétation
+correcte en est : "jusqu'à la fin de la structure englobante"
+bien qu'en fait la structure englobante soit généralement
+le fichier.
+
++ Ceci sera modifié dans une future version, où la signification de la
++ valeur 11 (voir ci-dessous) aura aussi sa place.
++
++ Une valeur de 11 pour d'autres paquets active un codage spécial
++ de la taille, où la taille du paquet suivant ne pourra pas être
++ déterminée avant l'écriture du paquet, en particulier ceci sera
++ utilisé si de grande quantités de données sont à traiter dans
++ un mode filtre.
++
++ Ceci fonctionne de la manière suivante : après le CTB (qui est un
++ champ de longueur de 11) un champ marqueur sera utilisé, il indiquera
++ alors la taille du bloc de données suivant. C'est un simple champ
++ de deux octets (MSB en premier) contenant la quantité de données qui
++ suivent le champ, sans inclure le champ de taille toutefois. Après
++ ce bloc de données un autre champ de taille suivra, qui donnera la taille
++ du bloc de données suivant. Une valeur de 0 indique une fin de paquet.
++ La taille maximale d'un bloc de données est limitée à 65534, ce qui
++ réserve la valeur 0xffff pour des extensions futures. Ces marqueurs de
++ taille devront être insérés dans le flux de données avant que les
++ données ne soient envoyées en sortie.
++
++ Ce champ de deux octets est largement suffisant, car l'application
++ doit placer en tampon cette quantité de données pour précéder le
++ marqueur de taille avant de produire une sortie. Les blocs de données
++ d'une taille supérieure à 32 Ko n'ont aucun sens. Notez que ceci pourra
++ également être utilisé pour les flux de données compressées, mais
++ nous devrons alors utiliser une autre version de paquet afin de dire à
++ l'application qu'elle ne peut assumer qu'il s'agit du dernier paquet.
+
+
+Extensions GNU à l'algorithme S2K
+=================================
+
+Le S2K mode 101 est utilisé pour identifier ces extensions.
+Après l'algorithme de hachage les trois octets "GNU" sont utilisés
+pour indiquer clairement qu'il s'agit d'extensions GNU et les octets
+qui suivent donnent le mode de protection GNU utilisé : 1000. Les
+modes définis sont :
+
+  1001 - ne pas conserver du tout de partie secrète
+
+
+
+Usage des fichiers gdbm pour les trousseaux de clefs
+====================================================
+
+La clef utilisé pour stocker le keyblock est son propre fingerprint,
+les autres enregistrements sont utilisés pour les clefs secondaires.
+Les fingerprint font toujours 20 octets où 16 bits de fingerprint
+sont suivis par 0. Le premier octet de chaque clef indique une
+information sur le type de clef :
+
+      1 = la clef est un fingerprint de 20 octets (16 octets fpr "paddés" de 0)
+	  les données sont le keyblock
+      2 = la clef est un keyid complet de 8 octets
+	  les données sont une liste de 20 octets fingerprints
+      3 = la clef est un keyid court de 4 octets
+	  les données sont une liste de 20 octets fingerprints
+      4 = la clef est une adresse email
+	  les données sont une liste de 20 octets fingerprints
+
+	Les données sont pre-appended (précédées) par un octet de type :
+
+      1 = keyblock
+      2 = liste de 20 octets fingerprints "paddés"
+      3 = liste de liste de fingerprints ("but how to we key them?")
+
+
+
+Pipemode
+========
+
+Ce mode est utilisé pour réaliser des opérations multiples avec un
+unique appel à gpg. C'est assez pratique lorsqu'il faut pouvoir vérifier
+un grand nombre de signatures. Actuellement nous n'avons qu'un support
+des signatures détachées. Ce mode est une astuce qui permet d'éviter
+de faire fonctionner gpg n en daemon mode et d'utiliser les Unix Domain
+Sockets pour lui faire passer les données. Il n'existe aucun moyen
+pratique de portabilité de ce concept sous Windows, alors nous utilisons
+des pipes simples pour faire fonctionner ce mode sous Windows. Comme nous
+n'avons aucun moyen de signaler des EOF multiples dans un pipe nous
+devons laisser le contrôle s'insérer dans le flux de données lui-même.
+Nous réalisons alors une distinction entre les données du flux et un
+état de contrôle. A son lancement, le système se trouve dans un état
+de données mais n'acceptera aucune donnée. Il attend en fait une
+transition vers un mode de contrôle qui s'obtient en envoyant un simple
+caractère '@'. Une fois dans le mode de contrôle, des commandes sont
+attendues et ces commandes sont à un octet après lequel le système
+revient au mode de données (mais cela n'implique pas qu'il acceptera
+des données immédiatement). La commande de contrôle la plus simple
+est '@' qui permet d'insérer ce caractère dans le flux de données.
+
+Voici le format que nous utilisons pour les signatures détachées :
+
+"@<"  - Début d'un nouveau flux
+"@B"  - La signature détachée suit.
+        Ceci émet le paquet de contrôle (1,'B')
+<detached_signature>
+"@t"  - Le texte signé suit. 
+        Ceci émet le paquet de contrôle (2, 'B')
+<signed_text>
+"@."  - Fin de l'opération. Le paquet de contrôle final force la
+	vérification de la signature.
+"@>"  - Fin du flux.
+
+
+
+Autres notes
+============
+
+Dans la version* 3 de version de paquet nous calculons les keyid de cette manière :
+
+RSA : les 64 bits de poids faible de n
+ELGAMAL : nous construisons un paquet de clef publique v3 (avec CTB 0x99)
+	et nous calculons une valeur hachée rmd160 à partir de ce paquet.
+	Il est utilisé comme fingerprint avec les 64 bits de poids faible
+	qui produisent le keyid.
+
+* Les certificats de révocation ne comportent qu'un paquet de signature ;
+"import" sait comment traiter ces paquets. L'idée derrière ce principe
+est de conserver une petite taille de paquet.
+
+
+
+Format des messages Keyserver
+=============================
+
+Le serveur de clef peut être contacté par un Unix Domain Socket ou via TCP.
+
+Le format des requêtes est :
+
+====
+command-tag
+"Content-length:" digits
+CRLF
+=======
+
+Où le command-tag est :
+
+NOOP
+GET <user-name>
+PUT
+DELETE <user-name>
+
+
+Le format de réponse utilisé est :
+
+======
+"GNUPG/1.0" status-code status-text
+"Content-length:" digits
+CRLF
+============
+
+suivi par <digits> octets de données.
+
+
+Les codes de statut utilisés sont :
+
+     o	1xx: Information: requête reçue, traitement en cours.
+
+     o	2xx: Succès - L'action a été reçue, comprise et acceptée.
+
+     o	4xx: Erreur client : la requête contient une erreur, mauvaise syntaxe
+		ou demande irréalisable.
+
+     o	5xx: Erreur serveur - Le serveur n'a pu traiter une demande
+		qui semble valide.
+
+
+Documentation sur HKP (le protocol de serveurs de clefs http)
+=============================================================
+
+Un serveur HTTP minimal sur port 11371 reconnaît les requêtes GET
+pour /pks/lookup. Les paramètres standard encodés URL de la requête
+sont toujours ceux-ci : (toujours key=valeur)
+
+- op=index (comme pgp -kv), op=vindex (comme pgp -kvv) and op=get (comme
+  pgp -kxa)
+
+- search=<stringlist>. Nous avons ici une liste de mots qui doivent
+	apparaître dans la clef. Ces mots sont séparés par des espaces,
+	points, @, etc. Les délimiteurs ne feront pas partie de la
+	recherche et l'ordre des mots n'a aucune importance (mais consultez
+	l'option suivante).
+
+- exact=on. Ce switch permet d'indiquer au serveur hkp qu'il ne doit
+	rechercher que les correspondances exactes. Dans ce cas, les
+	délimiteurs et l'ordre des mots sera considéré.
+
+- fingerprint=on. Renvoie également les fingerprint, lorsque utilisé
+	avec 'index' ou 'vindex'
+
+Les serveurs de clefs savent aussi reconnaître le format http-POST vers /pks/add.
+Vous utilisez ceci pour envoyer des clefs au serveur.
+
+Le mieux pour produire une requête reste :
+
+   /pks/lookup/<gnupg_formatierte_user_id>?op=<operation>
+
+Ceci peut être implémenté en utilisant le mécanisme de traduction Hurd.
+Toutefois, nous pensons que les traitements du serveur de clef doivent
+faire l'objet d'une refonte.
diff --git a/doc/fr/FAQ b/doc/fr/FAQ
new file mode 100644
index 000000000..48c28ae76
--- /dev/null
+++ b/doc/fr/FAQ
@@ -0,0 +1,1111 @@
+
+GNUPG : FOIRE AUX QUESTIONS
+
+Version : 1.2
+Dernière modification : 10 septembre 2001
+Maintenu par : Nils Ellmenreich <nils 'at' gnupg.org>
+Traduction : Gilbert Fernandes <gilbertf 'at' posse-press.com>
+
+Ce document est la FAQ de GnuPG. La dernière version HTML est
+disponble ici : <http://www.gnupg.org/faq.html>
+
+L'index est produit automatiquement. Des erreurs peuvent donc
+s'y trouver. Toutes les questions ne seront pas situées dans leurs
+sections afférentes. Les suggestions quand à l'amélioration de cette
+FAQ seront les bienvenues.
+
+Veuilez envoyer vos additions et corrections au mainteneur de la FAQ.
+Il serait plus pratique si vous pouviez fournir une réponse à inclure
+directement dans la FAQ. Toute aide sera fortement appréciée.
+
+Veuillez ne pas nous envoyer de message du type : "Ceci devrait
+être une FAQ, quelle est la réponse ?". Si la réponse ne se trouve
+pas dans la FAQ c'est que la question n'a pas été considérée.
+Dans ce cas, recherchez dans les archives de la liste de
+distribution par email.
+
+
+
+
+ 1. GENERAL
+   1.1) Qu'est-ce que GnuPG ?
+   1.2) GnuPG est-il compatible avec PGP ?
+
+ 2. SOURCES D'INFORMATION
+   2.1) Où puis-je trouver plus d'informations ?
+   2.2) Où puis-je obtenir GnuPG ?
+
+ 3. INSTALLATION 
+   3.1) Sur quels systèmes fonctionne GnuPG ?
+   3.2) Quel collecteur d'entropie dois-je utiliser ?
+   3.3) Comment puis-je inclure le support du RSA et de l'IDEA ?
+
+ 4. UTILISATION
+   4.1) Quelle est la taille de clef recommandée ?
+   4.2) Pourquoi la création de clefs est-elle aussi longue ?
+   4.3) Pourquoi tout est si lent quand je travaille sur un système distant ?
+   4.4) Quelle est la différence entre options et commandes ?
+   4.5) Je ne peux pas effacer un userid car il a déjà été effacé dans mon
+	trousseau de clefs publiques ?
+   4.6) Que sont la confiance, la validité et l'ownertrust ?
+   4.7) Comment puis-je signer un fichier de patch ?
+   4.8) Où se trouve l'option "encrypt-to-self" ?
+   4.9) Comment puis-je me débarasser de la version et du champ de commentaire
+	dans la version "armor" des messages ?
+   4.10) Que signifie le message "You are using the xxxx character set" ?
+   4.11) Comment puis-je obtenir la liste des keyid ayant servi à
+	chiffrer un message ?
+   4.12) Je ne peux plus déchiffrer mon message chiffré symétriquement (-c) avec la nouvelle
+version de GnuPG ?
+   4.13) Comment puis-je utiliser GnuPG en environnement automatisé ?
+   4.14) Quel client email puis-je utiliser avec GnuPG ?
+   4.15) On ne peut pas avoir une librairie gpg ?
+   4.16) J'ai produit avec succès un certificat de révocation, mais comment dois-je
+	le transmettre aux serveurs de clefs ?
+
+ 5. QUESTIONS SUR LA COMPATIBILITE
+   5.1) Comment puis-je chiffrer un message avec GnuPG pour que PGP soit capable de le déchiffrer ?
+   5.2) Comment migrer de PGP 2.x vers GnuPG ?
+   5.3) (supprimé)
+   5.4) Pourquoi PGP 5.x n'est pas capable de déchiffrer les messages pour certaines clefs ?
+   5.5) Pourquoi PGP 5.x ne peut vérifier mes messages ?
+   5.6) Comment puis-je transférer mes valeurs de confiance de PGP vers GnuPG ?
+   5.7) PGP n'aime pas ma clef privée.
+
+ 6. PROBLEMES ET MESSAGES D'ERREUR
+   6.1) Pourquoi GnupG me dit sans cesse "Warning  : using insecure memory!" ?
+   6.2) Le support des fichiers de grande taille ne fonctionne pas ..
+   6.3) Dans le menu d'édition les valeurs de confiance ne sont pas affichées
+	correctement après la signature des uid : pourquoi ?
+   6.4) Que signifie "skipping pubkey 1: already loaded" ?
+   6.5) GnuPG 1.0.4 ne tient pas compte de ~/.gnupg ...
+   6.6) Une signature ElGamal ne vérifie plus rien depuis la 1.0.2 ..
+   6.7) Les anciennes versions de GnuPG ne vérifient pas les anciennes
+	signatures ElGamal
+   6.8) Lorsque j'utilise --clearsign le texte en clair comporte parfois des
+	tirets supplémentaires : pourquoi ?
+   6.9) Que signifie "can't handle multiple signatures" ?
+   6.10) Si je soumet une clef au serveur de clefs, rien ne survient !
+   6.11) J'obtiens un "gpg: waiting for lock ..."
+   6.12) Les anciennes versions de GnuPG (e.g. 1.0) ont des problèmes
+	avec les clefs de GnuPG récents ..
+   6.13) Avec GnuPG 1.0.4 j'obtiens un "this cipher algorithm is deprecated ..."
+   6.14) Les dates sont affichées par ????-??-??, pourquoi ?
+   6.15) J'ai encore un problème, dois-je produire un message de bogue ?
+   6.16) Pourquoi GnuPG ne supporte pas les certificats X.509 ?
+
+ 7. SUJETS AVANCES
+   7.1) Comment tout cela fonctionne-t-il ?
+   7.2) Pourquoi certaines signatures avec une clef ELG-E sont valides ?
+   7.3) Comment tout le système de confiance fonctionne au juste ?
+   7.4) Quel est ce genre de sortie : "key C26EE891.298, uid 09FB: ...."?
+   7.5) Comment interpréter certaines sorties informatives ?
+   7.6) Les lignes d'en-tête des messages font-elles parties des éléments signés ?
+   7.7) Quelle est la liste des algorithmes préférés ?
+   7.8) Comment puis-je changer la liste des algorithmes préférés ?
+
+ 8. REMERCIEMENTS
+
+
+
+1. GENERAL
+
+1.1) Qu'est-ce que GnuPG ?
+
+GnuPG signifie GNU Privacy Guard et <http://www.gnupg.org> est
+l'outil GNU destiné aux communications protégées par chiffrement,
+ainsi que le stockage protégé d'informations. Ce programme peut
+être utilisé pour chiffrer des données et produire des signatures
+numériques. Il comprend une gestion avancée des clefs et respecte
+le standard Internet proposé OpenPGP comme décrit dans le
+RFC 2440 : <http://www.gnupg.org/rfc2440.html> et il se destine
+à une parfaite compatibilité avec le PGP produit par NAI Inc.
+
+1.2) GnuPG est-il compatible avec PGP ?
+
+En règle générale, oui. GnuPG et les distributions récentes de PGP
+devraient respecter le standard OpenPGP et fonctionner de concert.
+Il existe toutefois quelques problèmes d'interopérabilité. Consultez
+les questions 5.1ff pour plus de détails.
+
+2. SOURCES D'INFORMATION
+
+2.1) Où puis-je trouver plus d'informations ?
+
+Voici une liste de ressources en ligne :
+
+<http://www.gnupg.org/docs.html>
+
+Cette page regroupe la page de documentation GnuPG. Vous pouvez consulter
+les HOWTO ainsi que le manuel de GnuPG :  le GNU Privacy Handbook
+actuellement disponible en anglais, espagnol et russe. Ce dernier offre par
+ailleurs une présentation étendue de GnuPG. Vous trouverez aussi des
+documentations expliquant la conversion de PGP 2.x vers GnuPG.
+
+<http://lists.gnupg.org> 
+
+Vous trouverez ici une archive en ligne des listes de distribution par
+courrier électronique de GnuPG. La liste la plus intéressante sera
+probablement gnupg-users où toutes les questions en rapport avec
+l'utilisation de GnuPG se trouvent rassemblées. Si le développement
+vous intéresse vous consulterez avec joie la liste gnupg-devel et
+vous pourrez également prendre contact avec les développeurs.
+
+S'IL-VOUS-PLAIT !
+
+Avant de poster sur une liste, veuillez lire avec attention la FAQ et
+toutes les documentations disponibles. D'autre part, vous devez ensuite
+consulter les archives afin de découvrir si votre question n'a pas été
+déjà posée et résolue. Vous épargnerez des pertes de temps et la
+liste pourra se concentrer sur les problèmes qui n'ont pas encore
+été résolus.
+
+La distribution des sources de GnuPG comprend également un
+sous-répertoire /doc qui contient des documentations supplémentaires
+et ces informations seront précieuses aux hackers (pas beaucoup aux
+utilisateurs habituels, sauf les plus curieux).
+
+2.2) Où puis-je obtenir GnuPG ?
+
+Vous pouvez télécharger GNU Privacy Guard depuis son FTP primaire :
+
+<ftp.gnupg.org>
+
+Ou depuis l'un des mirroirs :
+
+<http://www.gnupg.org/mirror.html>
+
+La version actuelle est la version 1.0.6 et nous vous encourageons à migrer
+vers cette version rapidement : elle corrige des bogues et améliore le
+fonctionnement du programme, ainsi que votre sécurité de fait.
+
+
+3. INSTALLATION 
+
+3.1) Sur quels systèmes fonctionne GnuPG ?
+
+GnuPG devrait fonctionner sur tous les Unices ainsi que Windows (95, 98..) et les variantes
+NT. Une liste de systèmes d'exploitation fonctionnels se trouve à :
+
+<http://www.gnupg.org/gnupg.html#supsys>
+
+3.2) Quel collecteur d'entropie dois-je utiliser ?
+
+Les "bons" générateurs de nombres aléatoires sont cruciaux pour la sécurité de vos
+chiffrements. Les différents systèmes d'exploitation proposent des valeurs
+aléatoires de qualité variable. Linux et les systèmes *BSD produisent généralement
+de bonnes valeurs grâce au /dev/random et cette méthode devrait rester la
+méthode de choix pour ces systèmes. Les utilisateurs de Solaris devraient opter
+pour pe paquetage SUNWski afin de disposer d'un /dev/random. Dans ces cas,
+vous devriez utiliser l'option --enable-static-rnd=linux. D'autre part, il existe également
+un dispositif au niveau kernel pour la production de valeurs aléatoires développé
+par Andi Maier :
+
+< http://www.cosy.sbg.ac.at/~andi>
+
+Ce logiciel est au stade de beta : vous ne l'utilisez que sous votre seule
+responsabilité !
+
+Sur les autres systèmes, l'utilisation de l'EGC ou "Entropy Gathering Daemon"
+se montre un bon choix. C'est un daemon écrit en Perl qui surveille l'activité du
+système et produit des hachages permettant d'obtenir des valeurs aléatoires.
+Vous devriez en consulter la page de téléchargement depuis :
+
+<http://www.gnupg.org/download.html>
+
+Pour l'utiliser vous devrez utiliser l'option --enable-static-rnd=egd
+
+Si les options ci-dessus ne fonctionne pas, vous pourrez utiliser le producteur
+d'entropie "unix". Il est *TRES* lent et il devrait être évité lorsque possible.
+Sa qualité d'entropie laisse vraiment à désirer et vous ne devrez jamais
+l'utiliser dans la protection de données sensibles.
+
+3.3) Comment puis-je inclure le support du RSA et de l'IDEA ?
+
+RSA se trouve inclus dans GnuPG depuis la version 1.0.3 et supérieures.
+
+La distribution officielle de GnuPG ne comprend pas l'IDEA à cause
+d'une restriction par brevêt. Le brevêt devrait expirer en 2007 et nous
+attendons cette date pour l'inclure dans GnuPG.
+
+Toutefois, il existe des modules officieux qui permettent de l'inclure
+même dans les versions de GnuPG avant cette date. Ces modules
+sont disponibles depuis :
+
+<ftp://ftp.gnupg.org/pub/gcrypt/contrib/>
+
+Recherchez 'idea.c'
+
+Les directives de compilation se trouvent dans les fichiers "headers" de
+ces fichiers. Vous pourrez ensuite ajouter la ligne suivante à votre
+fichier ~/.gnupg/options :
+
+    load-extension idea 
+
+4. USAGE
+
+4.1) Quelle est la taille de clef recommandée ?
+
+Nous vous recommandons un minimum de 1024 bits pour les clefs de type
+DSA et également pour les signatures simples de type ElGamal. La taille
+du hachage est probablement le lien le plus faible si la taille de la clef
+augmente à plus de 1024 bits. Les clefs de chiffrement peuvent avoir
+des tailles supérieures, mais vous devriez alors vérifier le fingerprint
+de la clef de cette manière :
+
+gpg --fingerprint --fingerprint <user ID>
+
+Comme pour les algorithmes de clef, vous devriez vous en tenir aux
+valeurs par défaut (i.e. les chiffrements ElGamal avec signature
+DSA). Une clef de signature ElGamal comporte les désavantages
+suivants : si la signature est grosse, il est difficile de créer une
+clef correspondante utile pour les signatures et capable de résister
+aux attaques réelles, et vous n'obtiendrez pas de sécurité
+supplémentaire face au DSA. Il pourrait y avoir des problèmes
+de compatibilité avec certaines versions de PGP. Il n'aura été
+introduit que parce à l'époque, il n'était pas clair de savoir si
+un brevêt s'appliquait ou non au DSA.
+
+4.2) Pourquoi la création de clefs est-elle aussi longue ?
+
+Le problème est ici que nous avons besoin d'une grande quantité d'octets aléatoires et que
+nous devons pour ce faire collecter une certaine quantité d'entropie depuis, sous Linux,
+le /dev/random. Il n'est pas vraiment facile de remplir l'entropie de Linux ; nous en avons
+discuté avec Ted Ts'o et il a expliqué que la meilleure méthode pour remplir le buffer
+n'est autre que de jouer avec votre clavier. Une bonne sécurité implique un coût.
+Vous pouvez utiliser les touches Shift, Control, Alt en appuyant dessus de manière aléatoire,
+d'autant que ces touches ne produisent aucune sortie à l'écran et vous pourrez accélérer
+la production des clefs.
+
+Un autre programme pourrait également consommer une partie de l'entropie du système
+dont vous avez besoin (jettez un oeil à vos daemons actifs).
+
+4.3) Pourquoi tout est si lent quand je travaille sur un système distant ?
+
+Vous ne devez SURTOUT pas faire cela ! Vous ne devez jamais créer de
+clef GnuPG sur un système distant car vous n'aurez alors aucun contrôle
+physique sur votre clef privée, ni même votre trousseau de clefs privées.
+Ces clefs seront alors suspectibles de subir une attaque par dictionnaire.
+Nous vous encourageons vivement à ne produire vos clefs que sur une
+machine personnelle (un portable déconnecté de toute alimentation
+et connexion réseau est le meilleur choix) et si vous devez conserver
+votre clef privée sur une machine fixe, assurez-vous qu'une phrase
+passe solide en protège le contenu et que vous pouvez faire confiance
+à votre administrateur système.
+
+Lorsque nous devons utiliser GnuPG à distance c'est au-travers de SSH
+et nous rencontrons le même problème. Il faut *beaucoup* de temps
+pour produire des clefs de toute manière. Il ne faut pas créer de clefs
+à distance. Si vous avez juste besoin de clefs à fins de tests, vous
+pouvez utiliser l'optoin --quick-random pour produire rapidement des
+clefs *faibles* qui permettent de vérifier quelques tests.
+
+4.4) Quelle est la différence entre options et commandes ?
+
+Si vous tapez 'gpg --help' vous obtiendrez deux listes séparées. La première
+liste vous répertorie les commandes. La seconde liste regroupe elle les
+options. A chaque fois que vous utiliserez GnuPG vous devrez utiliser
+*UNE* commande (avec une exception, voir ci-dessous) et vous pourrez
+utiliser une ou *plusieurs* options en combinaison avec la commande.
+
+Par convention, la commande doit se trouver à la fin de la liste d'arguments
+après toutes les options. Si la commande requiert un nom de fichier,
+ce dernier sera donné à GnuPG en *dernier* sur la ligne de commande.
+
+L'usage basique de GnuPG est donc :
+
+    gpg [--option something] [--option2] [--option3 something] --command file 
+
+Certaines options demandent des arguments. Par exemple, l'option
+--output (que l'on peut raccourcir par -o) requiert un nom de fichier
+en argument. L'argument de l'option doit suivre celle-ci immédiatement !
+GnuPG ne sera sinon pas capable de différencier le nom de fichier comme
+option. Comme option, --output et son nom de fichier doivent se trouver
+avant la commande donnée à GnuPG. L'option --recipient (ou -r) demande
+un nom ou un keyID pour chiffrer le message et ces informations devront
+imméditamenet suivre l'option --recipient/-r. La commande --encrypt ou
+-e sera fournie après ces options, avec en final le nom du fichier à
+chiffrer. En voici un exemple :
+
+    gpg -r alice -o secret.txt -e test.txt 
+
+Mais l'utilisation des options sous leur forme longue permet de simplifier
+la compréhension des lignes de commande :
+
+    gpg --recipient alice --output secret.txt --encrypt test.txt 
+
+Si vous sauvez dans un fichier nommé ".txt" alors vous devriez probablement
+utiliser l'option ARMOR en ajoutant l'option --armor ou -a qui ne prend aucun
+argument :
+
+    gpg --armor --recipient alice --output secret.txt --encrypt test.txt
+
+Si nous plaçons des crochets autour des parties optionnelles, les choses
+deviennent plus claires :
+
+    gpg [--armor] [--recipient alice] [--output secret.txt] --encrypt test.txt 
+
+Les parties entre crochets peuvent être placées dans l'ordre de votre
+choix :
+
+    gpg --output secret.txt --recipient alice --armor --encrypt test.txt
+
+Si votre nom de fichier commence par un tiret, GnuPG risque de penser
+qu'il s'agit d'un paramètre et pour éviter cette situation vous pouvez
+soit utiliser un "./-a.txt" soit utiliser un double-tiret comme ceci :
+
+-- -a.txt
+
+* L'exception concerne le chiffrement ET la signature au même moment.
+On utilise alors gpg [--options] --sign --encrypt foo.txt
+
+4.5) Je ne peux pas effacer un userid car il a déjà été effacé dans mon
+	trousseau de clefs publiques ?
+
+Comme vous ne pouvez sélectionner que depuis le trousseau de clefs
+publiques, vous ne pouvez pas directement effacer le userid. Toutefois,
+ce n'est pas très compliqué à faire. Vous devez créer un nouvel
+utilisateur, disposant du même userid ce qui vous permet d'obtenir deux
+utilisateurs identiques avec un seul disposant d'une correspondance
+dans la clef privée. Vous pouvez désormais sélectionner cet utilisateur
+et l'effacer. Les deux identifiants seront affacés du trousseau de clefs
+privées.
+
+4.6) Que sont la confiance, la validité et l'ownertrust ?
+
+Le terme "ownertrust" est utilisé en remplacement de "trust" lorsqu'il
+s'agit de la valeur que vous avez attribuée à une clef en fonction
+du degré de confiance que vous accordez à son propriétaire, et si
+vous l'autorisez à introduire de nouvelles clefs avec votre signature
+jointe. La "validité" est un terme de confiance calculée, une valeur
+numérique calculée par GnuPG en fonction des paramètres de
+confiance des clefs et vous donne une idée de la confiance que
+GnuPG attribue ou n'attribue pas à une clef et s'il estime que la clef
+est valide pour un usage de chiffrement. Pour plus de détails consultez
+le chapître "The web of trust"
+
+4.7) Comment puis-je signer un fichier de patch ?
+
+Vous pouvez utiliser :
+
+gpg --clearsign --not-dash-espaced ...
+
+Le problème avec --clearsign c'est que toutes les lignes qui
+commençent par un tiret sont "quotées" avec "- " et comme diff
+produit beaucoup de lignes de ce type, le patch risque d'être
+détruit par la signature. Pour utiliser un fichier patch en le signant
+et sans perdre la signature claire, l'option spéciale :
+
+--not-dash-escaped
+
+Permet de supprimer la production de ces séquences d'échappement.
+Vous ne devriez pas transmettre par courrier électronique un patch
+de ce type car les espaces et les fins de ligne font également
+partie de la signature et un logiciel de messagerie risque de modifier
+l'espacement et/ou les tailles de lignes, invalidant la signature. Si vous
+souhaitez transmettre le fichier, le plus simple reste de le signer à l'aide
+de votre MUA.
+
+4.8) Où se trouve l'option "encrypt-to-self" ?
+
+Utilisez l'option :
+
+--encrypt-to <votre_keyID>
+
+Vous pouvez utiliser une combinaison de cette option pour spécifier
+plus d'un keyID. Pour désactiver temporairement l'utilisation de clefs
+additionnelles, vous pouvez utiliser l'option : --no-encrypt-to.
+
+4.9) Comment puis-je me débarasser de la version et du champ de commentaire
+	dans la version "armor" des messages ?
+
+Utilisez l'option --no-version --comment ""
+
+Veuillez noter que la ligne vide laissée en place est *requise* par le format
+et le protocole.
+
+4.10) Que signifie le message "You are using the xxxx character set" ?
+
+Cette note est affichée lorsque une conversion UTF-8 a été réalisée.
+Veuillez vous assurer que le jeu de caractères utilisé pour l'affichage
+correspond bien à celui du système. Le plus utilisé reste "iso-8859-1" et
+c'est le jeu de caractères par défaut. Vous pouvez modifier ce jeu
+de caractères à l'aide de l'option "--charset". Il faut que le jeu de
+caractères utilisé corresponde à celui de votre affichage ou des
+caractères pourraient ne plus correspondre dans le message une
+fois transmis. Sinon, n'utilisez que de l'ASCII 7 bits pour qu'aucune
+conversion ne puisse survenir.
+
+4.11) Comment puis-je obtenir la liste des keyid ayant servi à
+	chiffrer un message ?
+
+     gpg --batch --decrypt --list-only --status-fd 1 2>/dev/null | \
+    awk '/^\[GNUPG:\] ENC_TO / { print $3 }' 
+
+4.12) Je ne peux plus déchiffrer mon message chiffré symétriquement
+	(-c) avec la nouvelle version de GnuPG ?
+
+Il existait un bogue dans les versions 1.0.1 et antérieures de GnuPG
+qui surveniait lorsque 3DES ou Twofish avaient été utilisé pour des
+chiffrements symétriques (ce qui n'a jamais été le cas par défaut).
+Ce bogue a été corrigé afin de permettre le déchiffrement des anciens
+messages, en utilisant l'option :
+
+---emulate-3des-s2k-bug
+
+Vous devriez déchiffrer puis rechiffrer (correctement) le ou les
+messages concernés. Cette option sera retirée dans la version 1.1
+de GnuPG : n'attendez pas pour convertir vos messages !
+
+4.13) Comment puis-je utiliser GnuPG en environnement automatisé ?
+
+Vous devriez utiliser l'option --batch et ne pas utiliser de phrase
+passe car il n'existe alors aucun moyen de conserver cette
+information de manière plus secrète que le trousseau de clefs
+lui-même. Nous vous suggérons de créer vos clefs, en environnement
+automatisé, de la manière suivante :
+
+Sur une machine protégée :
+
+Créez une sous-clef de signature pour votre clef, en utilisant le menu
+edit et en utilisant l'option "addkeu" puis DSA. Vous devez ensuite
+vous assurer que vous utilisez une phrase passe (requise par
+l'implémentation actuelle) puis utiliser :
+
+gpg --export-secret-subkeys --no-comment foo
+    >secring.auto
+
+Copiez secring.auto et le trousseau de clefs publiques dans un
+répertoire test. Entrez dans le répertoire, puis :
+
+gpg --homedir . --edit foo
+
+Et utilisez "passwd" pour retirer la phrase passe des sous-clefs.
+Vous devriez également retirer toutes les sous-clefs qui ne sont
+pas utilisées et copier secring.auto sur une disquette et la
+porter jusqu'à la machine cible.
+
+Sur celle-ci, installez secring.auto comme trousseau de clefs
+secrètes. Vous pouvez maintenant faire démarrer votre
+nouveau service. C'est aussi une bonne idée que d'installer
+un système de détection d'intrusions afin de pouvoir repérer
+les intrusions ce qui vous permettra alors de révoquer toutes
+les sous-clefs installées sur cette machine et de procéder à une
+nouvelle installation de sous-clefs.
+
+4.14) Quel client email puis-je utiliser avec GnuPG ?
+
+Utiliser GnuPG pour le chiffrement de courrier électronique est
+probablement l'usage le plus répandu. De nombreux logiciels de
+messagerie (les "MUA") supportent GnuPG à divers degrés. Pour simplifier,
+il existe deux moyens de chiffrer les emails avec GnuPG : l'ancien style
+qui repose sur l'utilisation de l'ASCII Armor (un chiffrement classique
+suivi par une conversion selon le RFC2015) ce qu'on appellait le
+PGP/MIME et qui s'appelle désormais l'OpenPGP. Ce dernier supporte
+d'autre part le MIME. Certains MUA ne supportent qu'un seul de ces
+formats et vous devrez utiliser ce qui correspond aux capacités
+de votre client de messagerie.
+
+La liste suivante n'est probablement pas exhaustive :
+
+    OpenPGP: Mutt (Unix), Emacs/Mew, Becky2 (Windows avec plugin),
+	TkRat (Unix). Il y a un effort pour disposer d'un plug-in
+	Mozilla et Emacs/GNUS dispose d'un support en CVS.
+
+    ASCII:   Emacs/{VM,GNUS}/MailCrypt, Mutt(Unix), Pine(Unix), et
+	probablement beaucoup d'autres.
+
+Un bon aperçu du support de PGP se trouve à l'adresse :
+
+http://cryptorights.org/pgp-users/pgp-mail-clients.html
+
+Le support direct de GnuPG n'est pas indiqué, toutefois dans certains
+cas il doit être possible d'utiliser un "wrapper".
+
+4.15) On ne peut pas avoir une librairie gpg ?
+
+Cette question aura souvent été posée. Toutefois, le point de vue
+actuel est que GnuPG en tant que librairie risque de conduire à des
+problèmes de sécurité. Dans un futur proche, GnuPG ne sera pas
+implémenté sous forme de librairie. Toutefois, pour quelques domaines
+d'application le programme gpgme doit pouvoir assurer ces questions.
+Vous pouvez obtenir ce programme depuis :
+
+ftp://ftp.guug.de/pub/gcrypt/alpha/gpgme
+
+
+4.16) J'ai produit avec succès un certificat de révocation, mais comment
+	dois-je le transmettre aux serveurs de clefs ?
+
+La plupart des serveurs de clefs n'accepteront pas une simple et "dure"
+révocation. Vous devez d'abord importer le certificat dans GnuPG :
+
+    gpg --import my-revocation.asc
+
+Puis transmettre la révocation au serveurs de clefs :
+
+    gpg --keyserver certserver.pgp.com --send-keys mykeyid
+
+5. COMPATIBILITY ISSUES 
+
+5.1) Comment puis-je chiffrer un message avec GnuPG pour que PGP
+	soit capable de le déchiffrer ?
+
+Tout ceci dépend de la version de PGP.
+
+     PGP 2.x 
+
+Vous ne pourrez pas dans ce cas, car PGP 2.x utilise l'IDEA qui n'est
+pas un algorithme supporté par GnuPG à cause de son brevêt (voir
+la section 3.3) mais si vous disposez d'une version modifiée de PGP
+vous pouvez essayer ceci :
+
+     gpg --rfc1991 --cipher-algo 3des ...  
+
+Attention ! N'utlisez pas de pipe des données à chiffrer vers gpg,
+mais donnez à gpg un nom de fichier sinon PGP 2 ne sera pas
+capable de le prendre en charge.
+
+Quand à ce qui concerne le chiffrement conventionnel, vous ne
+pouvez l'obtenir avec PGP 2.
+
+
+     PGP 5.x et ultérieurs
+
+Vous devrez utiliser deux options additionnelles :
+
+    --compress-algo 1 --cipher-algo cast5  
+
+Vous devrez parfois utiliser "3des" au lieu de "cast5". PGP 5 ne
+supporte pas l'algorithme "blowfish". Vous devrez aussi insérer
+un "compress-algo 1" au sein de votre fichier ~/.gnupg/options
+et ceci n'affectera pas le fonctionnement général de GnuPG.
+
+Ceci s'applique également au chiffrement conventionnel.
+
+5.2) Comment migrer de PGP 2.x vers GnuPG ?
+
+PGP 2 utilise les algorithmes RSA et IDEA pour le chiffrement. Depuis que le
+brevêt sur le RSA a expiré GnuPG incorpore ce dernier, depuis la version
+1.0.3 et ultérieures. L'algorithme IDEA reste sous brevêt jusqu'en 2007.
+Sous certaines conditions vous pouvez utiliser l'IDEA, même aujourd'hui.
+Dans ce cas, vous devriez consulter la réponse à la question 3.3 qui
+explique l'ajout du support de l'IDEA à GnuPG et également lire ce
+document :
+
+http://www.gnupg.org/gph/en/pgp2x.html
+
+Pour procéder à la migration.
+
+5.3) (supprimé)
+
+    (vide)
+
+5.4) Pourquoi PGP 5.x n'est pas capable de déchiffrer les messages
+	pour certaines clefs ?
+
+PGP Inc refuse d'accepter les clefs ElGamal de type 20 même pour
+le chiffrement. Ils ne supportent que le type 16 (qui est identifique en tout
+cas en ce qui concerne le déchiffrement). Pour être plus inter-opérable,
+GnuPG (depuis la version 0.3.3) utilise également le type 16 pour la sous-
+clef ElGamal qui est créée par l'algorithme par défaut. Vous pouvez
+aussi ajouter une clef de type 16 à votre trousseau de clefs publiques
+tout en assurant que vos signatures sont valides.
+
+5.5) Pourquoi PGP 5.x ne peut vérifier mes messages ?
+
+PGP 5.x n'accepte pas les signatures en version 4 pour les données
+mais OpenPGP demande la production de clefs V4 pour tous les types
+de données et c'est pourquoi GnuPG les utilise... Vous devrez utiliser
+l'option --force-v3-sigs pour produir'e des signatures V3 sur les
+données.
+
+5.6) Comment puis-je transférer mes valeurs de confiance de
+	PGP vers GnuPG ?
+
+Il existe un script au sein du répertoire tools qui pourra vous aider. Après
+avoir importé le trousseau de clefs publiques PGP vous pouvez utiliser
+cette commande :
+
+    $ lspgpot pgpkeyring | gpg --import-ownertrust 
+
+où "pgpkeyring" est le trousseau de clefs originels et NON celui de GnuPG
+que vous avez produit à la première étape.
+
+5.7) PGP n'aime pas ma clef privée.
+
+Les anciens PGP échouent parfois au traitement des commentaires privés
+sur les paquets utilisés par GnuPG. Ces paquets sont en *totale* conformité
+avec OpenPGP mais vous l'aurez compris, PGP n'est pas vraiment soucieux
+d'OpenPGP. Pour contourner ce problème il faut exporter les clefs privées
+à l'aide de cette commande :
+
+     $ gpg --export-secret-keys --no-comment -a your-key-id 
+
+Une autre possibilité : par défaut, GnuPG chiffre votre clef privée à l'aide
+de l'algorithme symétrique Blowfish. Les anciennes versions de PGP
+ne peuvent comprendre que le 3DES, CAST5 ou l'IDEA sous leurs formes
+symétriques. L'utilisation de la méthode suivante permet de rechiffrer
+vos clefs privées à l'aide d'un algorithme différent :
+
+     $ gpg --s2k-cipher-algo=CAST5 --s2k-digest-algo=SHA1 \
+          --compress-algo=1  --edit-key <username>
+
+Vous utiliserez alors l'option passwd pour modifier le mot de passe ; il suffit
+de choisir la même phrase passe mais cette fois la clef sera chiffrée
+symétriquement par du CAST5.
+
+Vous pouvez maintenant exporter la clef et PGP devrait pouvoir la gérer.
+
+Pour PGP 6.x les options suivantes permettent d'exporter une clef :
+
+     $ gpg --s2k-cipher-algo 3des --compress-algo 1 --rfc1991 \
+           --export-secret-keys <Key-ID>
+
+6. PROBLEMS and ERROR MESSAGES
+
+6.1) Pourquoi GnupG me dit sans cesse "Warning  : using insecure memory!" ?
+
+Sur beaucoup de systèmes, ce programme doit être installé en tant que
+setuid(root). Ceci est requis afin de pouvoir produire un blocage en mémoire
+des pages utilisées (et d'éviter tout transfert en swap ou sur disque). Ce "lock"
+permet de verrouiller dans la pratique les informations sensibles en RAM
+afin de conserver ces données comme secrètes. Si vous n'obtenez aucun
+message d'erreur c'est que votre système supporte le verrouillage de pages
+mémoire depuis l'accès root (le programme s'exécute en tant que root grâce
+à son setuid). Le programme quitte le mode d'exécution "root" dès que les
+pages sont verrouillées en mémoire qui plus est.
+
+Sur Unixware 2.x et 7.x vous devriez installer GnuPG avec le privilège
+"plock" pour obtenir le même effet :
+
+	filepriv -f plock /path/to/gpg
+
+Si vous ne pouvez pas installer GnuPG en tant que setuid(root) ou si vous
+ne voulez pas, vous pouvez utiliser l'option :
+
+--no-secmem-warning
+
+Ou bien le placer en tant qu'option (sans les deux tirets) dans votre
+fichier ~/.gnupg/options ce qui permet de désactiver le warning.
+
+Sur quelques systèmes (e.g; Windows) GnuPG ne verrouille pas les
+pages en mémoire (ce n'est pas toujours possible selon les systèmes)
+et les anciennes versions de GnuPG (1.0.4 et antérieures) produisent
+sur ces systèmes le message d'erreur suivant :
+
+    gpg: Please note that you don't have secure memory
+
+Cet avertissement ne peut être désactivé en utilisant l'option décrite
+ci-dessus car nous considérons que cet avertissement forme une
+faille de sécurité importante. Toutefois, comme il provoquait une trop
+forte confusion auprès des utilisateurs de ces systèmes, le message
+d'avertissement a été retiré.
+
+6.2) Le support des fichiers de grande taille ne fonctionne pas ..
+
+Le LFS fonctionne correctement depuis les versions 1.0.4 et ultérieures.
+Si le configure ne le détecte pas correctement, essayez un autre
+compilateur : egcs 1.1.2 fonctionne parfaitement mais d'autres
+versions semblent poser problème. D'autre part, certains problèmes
+de compilation rencontrés dans GnuPG 1.0.3 et 1.0.4 sur HP-UX et
+Solaris étaient provoqués par un support "cassé" du LFS dans les
+sources ...
+
+6.3) Dans le menu d'édition les valeurs de confiance ne sont pas affichées
+	correctement après la signature des uid : pourquoi ?
+
+Ceci survient car certaines informations sont stockées immédiatement
+dans la TrustDB, mais le calcul ne se réalisé qu'au moment de la
+sauvegarde effective. Ce n'est pas un bogue vraiment facile à corriger
+mais nous pensons régler ce problème dans une future version.
+
+6.4) Que signifie "skipping pubkey 1: already loaded" ?
+
+Depuis la version 1.0.3 de GnuPG l'algorithme RSA est inclus. Si vous
+avez toujours l'option :
+
+load-extension rsa
+
+Dans votre fichier .options le message en question apparaîtra.
+Il vous suffira de retirer la commande qui n'est plus requise
+du fichier .options pour que le message cesse.
+
+6.5) GnuPG 1.0.4 ne tient pas compte de ~/.gnupg ...
+
+Ce bogue est connu et il a été corrigé dans les versions ultérieures.
+
+6.6) Une signature ElGamal ne vérifie plus rien depuis la 1.0.2 ..
+
+Utilisez l'option :
+
+--emulate-md-encode-bug
+
+    Use the option --emulate-md-encode-bug.
+
+6.7) Les anciennes versions de GnuPG ne vérifient pas les anciennes
+	signatures ElGamal
+
+Veuillez migrer vers la version 1.0.2 au minimum, et de préférence
+une version ultérieure (1.0.6 par exemple).
+
+6.8) Lorsque j'utilise --clearsign le texte en clair comporte parfois des
+	tirets supplémentaires : pourquoi ?
+
+Ceci s'appelle le "dash-escaped" et il est requis par le format
+OpenPGP. A chaque fois qu'une ligne commence par un tiret, ceci
+risque de survenir. Cela permet aux programmes de retrouver
+sans difficulté les lignes de marquage du format, comme :
+
+-----BEGIN PGP SIGNATURE-----
+
+Seules ces lignes doivent pouvoir commencer par deux tirets. Si vous
+utilisez GnuPG pour traiter ces messages, les tirets supplémentaires
+seront retirés et les clients de messagerie "corrects" devraient
+également retirer ces tirets lorsqu'ils affichent le message.
+ 
+6.9) Que signifie "can't handle multiple signatures" ?
+
+A cause des différents formats de messages, GnuPG n'est pas toujours
+capable de découper un fichier contenant des signatures multiples.
+Ce message d'erreur vous informe que les données en entrée
+comportent un problème. Le seul moyen pour disposer correctement
+de signatures multiples revient à utiliser le standard : le format
+OpenPGP avec les paquets "one-pass-signature" qui sont utilisés
+par défaut par GnuPG ou bien de recourir au format de texte en clair.
+
+6.10) Si je soumet une clef au serveur de clefs, rien ne survient !
+
+Vous utilisez probablement GnuPG sur Windows en version 1.0.2 ou
+antérieure. Cette fonctionnalité n'était alors pas encore disponible,
+et il ne s'agit pas d'un bogue. Vous devriez adopter une version
+plus récente, qui dispose de toutes les fonctionnalités :-)
+
+6.11) J'obtiens un "gpg: waiting for lock ..."
+
+Les anciennes versions de GnuPG ne quittaient pas correctement
+et laissaient un fichier "lock". Allez dans le répertoire ~/.gnupg et
+effacez les fichiers *.lock qui s'y trouvent pour continuer.
+
+6.12) Les anciennes versions de GnuPG (e.g. 1.0) ont des problèmes
+	avec les clefs de GnuPG récents ..
+
+Depuis la version 1.0.3 les clefs produites par GnuPG sont créées avec
+une préférence pour Twofish (et l'AES depuis la version 1.0.4 à savoir,
+l'algorithme Rijndael) et ceci signifie également qu'elles disposent de la
+capacité d'utilisation de la nouvelle méthode de chiffrement MDC. Ceci
+sera disponible dans OpenPGP très rapidement et sera supporté en
+tout logique par PGP 7. Cette nouvelle méthode de chiffrement permet
+de se protéger votre des attaques (des anciennes attaques en fait)
+contre les systèmes de chiffrement du courrier électronique.
+
+Ceci signifie également que les versions 1.0.3 et antérieures de GnuPG
+auront des problèmes avec les clefs plus récentes. A cause des
+correctifs de sécurité, vous devriez conserver votre installation
+de GnuPG à jour de toute manière. Comme manière de régler le
+problème vous devriez demander à GnuPG de n'utiliser que l'ancien
+algorithme de chiffrement en utilisant la ligne :
+
+cipher-algo cast5
+
+dans votre fichiers d'options.
+
+6.13) Avec GnuPG 1.0.4 j'obtiens un "this cipher algorithm is deprecated ..."
+
+Si vous venez de produire une nouvelle clef et que vous obtenez ce message
+pendant un chiffrement, il s'agit d'un bogue de la version 1.0.4 ; le nouvel
+algorithme AES Rijndael est utilisé mais il n'est pas enregistré sous le bon
+numéro d'algorithme ce qui produit ce message d'erreur "deprecated".
+Vous pouvez ignorer cet avertissement et les versions plus récentes
+de GnuPG sont corrigées sur ce point.
+
+6.14) Les dates sont affichées par ????-??-??, pourquoi ?
+
+A cause de contraintes dans la plupart des implémentations de la libc,
+les dates au-delà de 2038-01-19 ne seront pas affichées correctement.
+Les systèmes 64-bit ne sont pas affectés par ce problème. Pour éviter
+d'afficher les dates de manière incorrecte, GnuPG utilise des signes
+"?" au lieu des chiffres. Pour obtenir la valeur correcte vous devrez
+utiliser l'option :
+
+--with-colons --fixed-list-mode
+
+6.15) J'ai encore un problème, dois-je produire un message de bogue ?
+
+Si vous êtes sûr(e) que le problème n'est mentionné nulle part, ni dans
+cette FAQ ni dans aucune liste de distribution GnuPG, commencez
+par consulter la liste de bogues qui sont en cours de traitement (la page
+de documentation dispose d'un lien vers la page de bogues). Si vous
+ne savez pas trop s'il s'agit d'un bogue, envoyez un courrier
+électronique à la liste : gnupg-devel. Sinon, vous pouvez utiliser
+le système de suivi de bogues GUUG à l'adresse :
+
+http://bugs.guug.de/Reporting.html.   
+
+6.16) Pourquoi GnuPG ne supporte pas les certificats X.509 ?
+
+GnuPG est avant tout une implémentation du standard OpenPGP,
+défini dans le RFC 2440. Ce standard propose une infrastructure
+complète et différente du X.509
+
+Ces deux systèmes sont des cryptosystèmes à clef publique, mais
+la manière dont les clefs sont traitées diffèrent.
+
+7. SUJETS AVANCES
+
+7.1) Comment tout cela fonctionne-t-il ?
+
+Pour produire une paire de clefs publique/privée, utilisez la commande
+
+gpg --gen-key
+
+Puis répondez aux questions en adoptant de préférence les valeurs
+par défaut.
+
+Les données qui sont chiffrées par une clef publique ne peuvent être
+déchiffrées que par la clef privée correspondante. La clef secrète
+est d'autre part protégée par une phrase-passe ce qui n'est pas le cas
+de la clef publique, librement distribuable.
+
+Pour transmettre à vos amis un message, il vous suffit de le chiffrer
+à l'aide de leurs clefs publiques. Seules leurs clefs privées seront
+capables de déchiffrer le message.
+
+GnuPG est pratique pour signer de manière numérique les choses.
+Les éléments qui sont chiffrés à l'aide de la clef publique ne peuvent
+être déchiffrés que par la clef publique, ce qui permet de signer
+des documents. On commence par produire un hachage, une sorte
+d'empreinte à taille fixe d'un document (de taille variable). Ensuite,
+votre clef privée est utilisée pour chiffrer ce hachage. Par la suite,
+toute personne disposant de votre clef publique et du document
+peut vérifier si le hachage du document correspond bien au
+déchiffrement du hachage, obtenu par votre clef publique dont
+disposent vos destinataires.
+
+Un trousseau de clefs n'est qu'un gros fichier (selon le nombre de
+clefs qu'il contient). Vous avez un trousseau de clefs publiques
+qui contient vos clefs publiques et celles de vos amis. Vous avez
+également un trousseau de clefs privées qui ne contient que vos
+clefs privées (chiffrées et protégées par votre phrase-passe). Vous
+devez faire très *attention* à ce fichier. Personne ne devra jamais
+y avoir accès et la phrase-passe qui le protège devra être
+complexe, et longue afin de bien protéger le secret.
+
+Vous pouvez aussi chiffrer des données de manière conventionnelle,
+en utilisant l'option "-c" de GnuPG. Dans ce cas, la phrase-passe
+utilisée servira de clef pour protéger le message. Aucun usage
+de clef publique ou de clef privée ici : il s'agit d'un chiffrement
+classique où il n'existe qu'une seule clef, utilisée pour chiffrer et
+déchiffrer les données. Généralement, on utilise cette méthode
+pour chiffrer ses propres documents à l'aide d'une phrase-passe
+secrète qui vous est propre. Cette méthode de chiffrement ne
+doit être utilisée pour des communications que si vous avez
+physiquement rencontré vos destinataires et que vous partagez
+dans le plus grand secret la phrase-passe (votre propre époux ou
+épouse, ou un ami de confiance). L'avantage est que vous pouvez
+changer de temps en temps la phrase-passe et en réduire le
+risque afin qu'en cas de découverte de la phrase-passe toutes
+vos données ne soient pas lisibles ;-)
+
+Vous pouvez ajouter et copier des clefs depuis votre trousseau
+de clefs publiques à l'aide des commandes "gpg --import" et
+"gpg --export". Vous pouvez également (ATTENTION !!) exporter
+vos clefs privées à l'aide de la commande : "gpg --export-secret-keys"
+mais ce n'est généralement pas utile sauf si vous devez déplacer
+vos clefs privées d'une machine à l'autre.
+
+Les clefs peuvent être signées à l'aide de l'option "gpg --edit-key". Lorsque
+vous signez une clef, vous certifiez que la clef appartient selon vous
+à la personne dont l'identité se trouve mentionnée dans la clef. Vous
+devez absolument être sûr(e) que la clef appartient bien à cette
+personne, sans le moindre doute. Vous devez vérifier son fingerprint
+à l'aide de la commande :
+
+gpg --fingerprint userid
+
+Et recevoir le même finger par téléphone ou de visu par la personne
+concernée. Généralement, on procède à des "fêtes" où chaque personne
+amène sa pièce d'identité, une carte de visite comprenant le fingerprint
+et l'on procède à un échange des fingerprint, ou directement des clefs.
+
+Vous pouvez également utiliser l'option "-o filename" pour forcer
+la sortie vers le fichier "filename". Pour forcer une sortie en console
+par défaut on utilise un tiret. La commande "-r" permet de spécifier
+le destinataire (avec quelle clef publique vous allez chiffrer) en ligne
+de commande au lieu d'avoir à taper le nom du destinataire dans
+le mode interactif.
+
+Autre chose d'importance. Par défaut, TOUTES les données sont chiffrées
+dans un format binaire particulier; Si vous souhaitez transmettre les données
+par courrier électronique (par exemple) vous devez les protéger dans
+un format d'amure qu'on appelle ASCII ARMOR. Ce format sera obtenu
+en utilisant l'option "-a" mais la méthode préférée reste d'utiliser
+un client de messagerie respectueux du format MIME comme Mutt, Pine
+et bien d'autres.
+
+Enfin, il existe une petite faille de sécurité dans OpenPGP (et donc dans PGP)
+et vous devriez TOUJOURS chiffrer PUIS signer un message. Il ne faut
+pas seulement chiffrer afin d'être totalement protégé. N'oubliez jamais.
+
+7.2) Pourquoi certaines signatures avec une clef ELG-E sont valides ?
+
+Ces clefs ElGamal furent produites par GnuPG en version 3 de paquets
+(selon le RFC 1991). Le brouillon OpenPGP a été modifié par la suite
+afin de modifier l'identifiant d'algorithme pour les clefs ElGamal qui est
+utilisable pour les signatures et le chiffrement des modes 16 à 20.
+GnuPG utilise le mode 20 quand il produit ses nouvelles clefs ElGamal
+mais il accepte toujours les clefs de type 16 qui selon le standard
+OpenPGP ne peuvent servir qu'au chiffrement, si la clef se trouve
+dans un paquet en version 3 du format. GnuPG est le seul programme
+ayant jamais utilisé les clefs au sein de paquets v3 - vous ne risquez
+donc pas grand chose.
+
+7.3) Comment tout le système de confiance fonctionne au juste ?
+
+Il fonctionne d'une manière proche de PGP. La différence c'est que
+la confiance est calculée uniquement lorsqu'elle est requise. C'est
+pourquoi la TrustDB contient une liste des signatures de clefs
+valides. Si vous ne fonctionnez pas en mode batch, vous devrez
+assigner un paramètre de confiance aux clefs (un ownertrust).
+
+Vous pouvez consulter la validité (la valeur de confiance
+calculée) en utilisant cette commande :
+
+     gpg --list-keys --with-colons  
+
+Si le premier champ est "pub" ou "uid" le second champ vous
+indiquera le niveau de confiance :
+
+o = Inconnu (cette clef est nouvelle au système)
+i = La clef est invalide (eg. il manque sa propre signature)
+d = La clef a été désactivée
+r = La clef a été révoquée
+e = La clef a expiré
+q = Non-défini (pas de valeur attribuée)
+n = Ne jamais faire confiance à cette clef
+m = Cette clef dispose d'une confiance marginale
+f = Cette clef dispose d'une confiance totale
+u = Cette clef dispose d'une confiance ultime. Cette valeur
+	n'est utilisée que pour les clefs où la clef secrète est
+	également disponibles.
+
+La valeur dans l'enregistrement "pub" est la meilleure valeur
+obtenue depuis les enregistrements "uid".
+
+Vous pouvez obtenir la liste des valeurs de confiance attribuées ;
+i.e. la confiance que vous accordez aux autres lorsqu'il s'agit
+de signer la clef d'un autre individu) :
+
+     gpg --list-ownertrust
+
+Le premier champ est le fingerprint de la clef primaire, le second
+champ est la valeur assignée :
+
+_ = Aucune valeur d'ownertrust assignée
+n = Ne jamais faire confiance au propriétaire de cette clef
+	lorsqu'il s'agit de vérifier d'autres signatures.
+m = Une confiance marginale est accordée au détenteur de cette clef
+	lorsqu'il s'agit de signer d'autres clefs.
+f = Assumer que le détenteur de cette clef est une personne de confiance
+	lorsqu'il s'agit de signer des clefs.
+u = Nous n'avons pas besoin de nous faire confiance à nous-même puisque
+	nous détenons notre propre clef privée.
+
+Vous devez conserver ces valeurs confidentielles, car elles représentent
+la confiance que vous accordez ou non à d'autres individus. PGP stocke
+cette information au sein de trousseau de clefs et le publier n'est PAS
+une bonne idée. Vous devez utiliser la commande d'exportation pour
+transmettre des clefs. Quoi qu'il en soit, GnuPG
+évite ces problèmes en ne conservant ces valeurs qu'aun sein de sa
+TrustDB donc vous pouvez copier un trousseau de clefs publiques
+si vous utilisez GnuPG (et nous disposons aussi de la commande
+d'exportation).
+
+7.4) Quel est ce genre de sortie : "key C26EE891.298, uid 09FB: ...."?
+
+Cette sortie est la représentation interne d'un userid au sein
+de la TrustDB. Le keyid est "C26EE891" et le "298" est le keyid local,
+un simple numéro d'enregistrement dans la TrustDB. Enfin, le "09FB"
+sont les deux derniers octets d'un ripe-md-160 de l'identifiant de
+l'utilisateur pour cette clef.
+
+7.5) Comment interpréter certaines sorties informatives ?
+
+Lorsque vous vérifiez la validité d'une clef, GnuPG affiche
+parfois une information préfixée par l'information en rapport
+avec le sujet vérifié. Par exemple : "key 12345678.3456" indique
+que la clef disposant de l'ID 12345678, et du numéro interne 3456
+est considérée au sein de la TrustDB au sein de ce qu'on
+appelle un enregistrement "directory". Un "uid 12345678.3456/ACDE"
+indique quel est l'identifiant d'utilisateur qui correspond
+à cette clef. Il s'agit d'une information sur la signature de la
+clef 9A8B7C6D disposant de cet ID et s'il s'agit d'une signature
+directe sur la clef, la partie User ID sera vide :
+
+(..//..)
+
+7.6) Les lignes d'en-tête des messages font-elles parties des
+	éléments signés ?
+
+Non. Par exemple, vous pouvez retirer les lignes "Comment:"
+Elles n'ont pas vraiment d'objet comme les lignes "header" des
+courriers électroniques. Toutefois, une ligne qui débute par
+"Hash: ..." est requise par les signatures OpenPGP afin de permettre
+au parser de déterminer quel algorithme de hachage utiliser.
+
+7.7) Quelle est la liste des algorithmes préférés ?
+
+La liste des algorithmes préférés est une liste d'algorithmes
+de chiffrement, de hachage et de compression stockés dans
+la signature propre de la clef durant sa production. Lorsque
+vous chiffrez un document, GnuPG utilise cette liste (elle fait
+partie de la clef publique) pour déterminer quels algorithmes
+doivent être utilisés. De manière basique, ces indications
+expliquent aux autres utilisateurs quels algorithmes vous
+acceptez en entrée avec un ordre de préférence.
+
+7.8) Comment puis-je changer la liste des algorithmes préférés ?
+
+Actuellement la liste et les préférences sont directement intégrées
+dans les codes sources de GnuPG. Vous devrez modifier le fichier
+g10/keygen afin de modifier cette liste et procéder à une
+nouvelle compilation. La fonction que vous devrez modifier est
+keygen_add_std_prefs. Le code est d'ailleurs assez simple à
+comprendre. Les constantes utilisées pour différencier les
+algorithmes sont définies au sein du fichier include/cipher.h
+
+Après avoir modifié ces fichiers, générez une nouvelle paire
+de clefs (ou une nouvelle sous-clef de chiffrement) avec
+la version modifiée de l'exécutable. La nouvelle clef disposera
+des nouvelles préférences et pourra être utilisée depuis des
+exécutables non modifiés.
+
+Pour modifier les préférénces d'une clef existante, vous devrez
+utiliser un exécutable modifié (voir ci-dessus) afin de modifier
+la date d'expiration puis sauvegardez les changements. Les
+préférences seront automatiquement modifiées lors de la
+sauvegarde et vous pouvez désormais utiliser la clef modifiée
+avec tout exécutable, modifié ou non.
+
+La modification de la liste de préférences à l'aide d'une
+version non-modifiée de GnuPG (probablement depuis le menu
+d'édition) fait partie de la liste TODO (A FAIRE) prévue
+pour les prochaines versions de GnuPG.
+
+
+8. REMERCIEMENTS
+
+Nous souhaitons remercier Werker Kosh pour la rédaction de la
+première FAQ originelle et pour tous les participants aux listes
+de discussion gnupg-users et gnupg-devel. La quasi-totalité
+des réponses de ce document proviennent de leurs efforts.
+
+Nous souhaitons également remercier Casper Dik pour nous
+avoir fourni le script permettant de générer cette FAQ,
+qu'il utilise d'autre part pour son excellente FAQ Solaris2 ;-)
+
+Copyright (C) 2000 Free Software Foundation, Inc. , 
+59 Temple Place - Suite 330, Boston, MA 02111, USA 
+
+Verbatim copying and distribution of this entire article is permitted in
+any medium, provided this notice is preserved.
diff --git a/doc/fr/README.fr b/doc/fr/README.fr
new file mode 100644
index 000000000..3a5d8485e
--- /dev/null
+++ b/doc/fr/README.fr
@@ -0,0 +1,10 @@
+You find here translations to French of some of the documents in
+../doc.  Those translations are not necessary up-to-date and should
+not be used as reference without checking the original English
+versions.
+
+Gilbert Fernandes kindly contributed thses translatons.
+
+
+
+