From taffit at debian.org Mon Nov 3 03:24:03 2014 From: taffit at debian.org (=?UTF-8?B?RGF2aWQgUHLDqXZvdA==?=) Date: Sun, 02 Nov 2014 22:24:03 -0400 Subject: Translation updates Message-ID: <5456E743.8090804@debian.org> Hi, I?ve submitted a few translation updates over a month ago to gnupg-i18n but none of them seem to have been picked up, even if several releases happened in the mean time. Can someone please point me to some doc about the proper way to submit translations if I did something wrong? http://lists.gnupg.org/pipermail/gnupg-i18n/2014-September/thread.html In case it was just some overlook, please find attached (compressed, since this one didn?t made it to the gnupg-i18n list) an updated French translation update for gnupg master. I?ve also reviewed and updated the other files submitted in September, and will send the according patches as a follow up to this mail unless asked to process another way. Regards David -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-gnupg-master-Update-French-translation.patch.xz Type: application/x-xz Size: 18816 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From taffit at debian.org Mon Nov 3 04:24:29 2014 From: taffit at debian.org (=?UTF-8?q?David=20Pr=C3=A9vot?=) Date: Sun, 2 Nov 2014 23:24:29 -0400 Subject: [PATCH] [gnupg STABLE-BRANCH-1-4] Update French translation In-Reply-To: <5456E743.8090804@debian.org> References: <5456E743.8090804@debian.org> Message-ID: <1414985069-17891-1-git-send-email-taffit@debian.org> --- po/fr.po | 142 +++++++++++++++++++++++++++++++-------------------------------- 1 file changed, 70 insertions(+), 72 deletions(-) diff --git a/po/fr.po b/po/fr.po index c2808d8..6d7be96 100644 --- a/po/fr.po +++ b/po/fr.po @@ -1,13 +1,13 @@ # GnuPG French translation -# Copyright (C) 1998-2009, 2012 Free Software Foundation, Inc. +# Copyright (C) 1998-2009, 2012, 2014 Free Software Foundation, Inc. # # Ga?l Qu?ri , 1998-2009. -# David Pr?vot , 2012. +# David Pr?vot , 2012, 2014. msgid "" msgstr "" -"Project-Id-Version: gnupg 1.4.12\n" +"Project-Id-Version: gnupg 1.4.19\n" "Report-Msgid-Bugs-To: gnupg-i18n at gnupg.org\n" -"PO-Revision-Date: 2012-08-24 16:56+0200\n" +"PO-Revision-Date: 2014-09-06 15:56-0400\n" "Last-Translator: David Pr?vot \n" "Language-Team: French \n" "Language: fr\n" @@ -15,7 +15,7 @@ msgstr "" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8-bit\n" "Plural-Forms: nplurals=2; plural=(n > 1);\n" -"X-Generator: Lokalize 1.4\n" +"X-Generator: Lokalize 1.5\n" #, c-format msgid "can't gen prime with pbits=%u qbits=%u\n" @@ -46,7 +46,7 @@ msgstr "impossible d'acc?der ? ??%s???: %s\n" #, c-format msgid "`%s' is not a regular file - ignored\n" -msgstr "??%s?? n'est pas un fichier r?gulier ? ignor?\n" +msgstr "??%s?? n'est pas un fichier r?gulier ??ignor?\n" msgid "note: random_seed file is empty\n" msgstr "remarque?: le fichier random_seed est vide\n" @@ -87,7 +87,7 @@ msgid "" "\n" msgstr "" "Le g?n?rateur de nombres al?atoires n'est qu'un artifice visant ? ex?cuter\n" -"GnuPG ? ce n'est en aucune mani?re un g?n?rateur (RNG) fort.\n" +"GnuPG ??ce n'est en aucune mani?re un g?n?rateur (RNG) fort.\n" "\n" "N'UTILISEZ PAS LES DONN?ES G?N?R?ES PAR CE PROGRAMME.\n" "\n" @@ -141,7 +141,7 @@ msgstr "utilisation du code personnel par d?faut en tant que %s\n" msgid "failed to use default PIN as %s: %s - disabling further default use\n" msgstr "" "impossible d'utiliser le code personnel par d?faut en tant que %s?:\n" -"%s ? d?sactivation de la prochaine utilisation par d?faut\n" +"%s ??d?sactivation de la prochaine utilisation par d?faut\n" #, c-format msgid "||Please enter the PIN%%0A[sigs done: %lu]" @@ -157,7 +157,7 @@ msgstr "le rappel du code personnel a renvoy? une erreur?: %s\n" #, c-format msgid "PIN for CHV%d is too short; minimum length is %d\n" msgstr "" -"le code personnel pour CHV%d est trop court?; la longueur minimale\n" +"le code personnel pour CHV%d est trop court?; la taille minimale\n" "est %d\n" #, c-format @@ -199,7 +199,7 @@ msgstr "||Veuillez entrer le code de r?initialisation pour la carte" #, c-format msgid "Reset Code is too short; minimum length is %d\n" msgstr "" -"Le code de r?initialisation est trop court?; la longueur minimale\n" +"Le code de r?initialisation est trop court?; la taille minimale\n" "est %d\n" #. TRANSLATORS: Do not translate the "|*|" prefixes but @@ -290,7 +290,7 @@ msgstr "" #, c-format msgid "can't access %s - invalid OpenPGP card?\n" msgstr "" -"impossible d'acc?der ? %s ? la carte OpenPGP n'est peut-?tre pas valable\n" +"impossible d'acc?der ? %s ??la carte OpenPGP n'est peut-?tre pas valable\n" #, c-format msgid "armor: %s\n" @@ -446,7 +446,7 @@ msgid "Language preferences: " msgstr "Pr?f?rences de langue?: " msgid "Error: invalid length of preference string.\n" -msgstr "Erreur?: longueur incorrecte de la cha?ne de pr?f?rences.\n" +msgstr "Erreur?: taille incorrecte de la cha?ne de pr?f?rences.\n" msgid "Error: invalid characters in preference string.\n" msgstr "Erreur?: caract?res incorrects dans la cha?ne de pr?f?rences.\n" @@ -700,7 +700,7 @@ msgid "Delete this key from the keyring? (y/N) " msgstr "Faut-il supprimer cette clef du porte-clefs?? (o/N) " msgid "This is a secret key! - really delete? (y/N) " -msgstr "C'est une clef secr?te ? faut-il vraiment la supprimer?? (o/N) " +msgstr "C'est une clef secr?te ??faut-il vraiment la supprimer?? (o/N) " #, c-format msgid "deleting keyblock failed: %s\n" @@ -719,7 +719,7 @@ msgstr "" #, c-format msgid "error creating passphrase: %s\n" -msgstr "erreur de cr?ation de la phrase de passe?: %s\n" +msgstr "erreur de cr?ation de la phrase secr?te?: %s\n" msgid "can't use a symmetric ESK packet due to the S2K mode\n" msgstr "impossible d'utiliser un paquet ESK sym?trique en mode S2K\n" @@ -859,7 +859,7 @@ msgid "export revocation keys marked as \"sensitive\"" msgstr "exporter les clefs de r?vocation marqu?es comme ??sensibles??" msgid "remove the passphrase from exported subkeys" -msgstr "supprimer la phrase de passe des sous-clefs export?es" +msgstr "supprimer la phrase secr?te des sous-clefs export?es" msgid "remove unusable parts from key during export" msgstr "supprimer les parties inutilisables de la clef pendant l'exportation" @@ -872,15 +872,15 @@ msgstr "il est interdit d'exporter les clefs secr?tes\n" #, c-format msgid "key %s: not protected - skipped\n" -msgstr "clef %s?: non prot?g?e ? ignor?e\n" +msgstr "clef %s?: non prot?g?e ??ignor?e\n" #, c-format msgid "key %s: PGP 2.x style key - skipped\n" -msgstr "clef %s?: clef de type PGP?2.x ? ignor?e\n" +msgstr "clef %s?: clef de type PGP?2.x ??ignor?e\n" #, c-format msgid "key %s: key material on-card - skipped\n" -msgstr "clef %s?: mat?riel de clef sur la carte ? ignor?e\n" +msgstr "clef %s?: mat?riel de clef sur la carte ??ignor?e\n" msgid "about to export an unprotected subkey\n" msgstr "sur le point d'exporter une sous-clef non prot?g?e\n" @@ -1529,7 +1529,7 @@ msgid "the given preferred keyserver URL is invalid\n" msgstr "l'URL du serveur de clefs favori qui a ?t? donn?e est incorrecte\n" msgid "too many entries in pk cache - disabled\n" -msgstr "trop d'entr?es dans le cache de clefs publiques ? d?sactiv?\n" +msgstr "trop d'entr?es dans le cache de clefs publiques ??d?sactiv?\n" msgid "[User ID not found]" msgstr "[identit? introuvable]" @@ -1546,7 +1546,7 @@ msgstr "" #, c-format msgid "no secret subkey for public subkey %s - ignoring\n" -msgstr "pas de sous-clef secr?te pour la sous-clef publique %s ? ignor?e\n" +msgstr "pas de sous-clef secr?te pour la sous-clef publique %s ??ignor?e\n" #, c-format msgid "using subkey %s instead of primary key %s\n" @@ -1556,7 +1556,7 @@ msgstr "" #, c-format msgid "key %s: secret key without public key - skipped\n" -msgstr "clef %s?: clef secr?te sans clef publique ? ignor?e\n" +msgstr "clef %s?: clef secr?te sans clef publique ??ignor?e\n" msgid "be somewhat more quiet" msgstr "devenir beaucoup plus silencieux" @@ -1597,7 +1597,7 @@ msgid "" "ultimately trusted\n" msgstr "" "Pour mettre en place le r?seau de confiance (web-of-trust), GnuPG doit\n" -"savoir en quelles clefs votre confiance est ultime ? ce sont g?n?ralement\n" +"savoir en quelles clefs votre confiance est ultime ??ce sont g?n?ralement\n" "les clefs dont vous poss?dez la clef secr?te. R?pondez ??oui?? pour\n" "indiquer que votre confiance en cette clef est ultime\n" @@ -1656,7 +1656,7 @@ msgid "" msgstr "" "Entrez la valeur demand?e comme indiqu? dans l'invite de commande.\n" "Une date ISO (AAAA-MM-JJ) peut ?tre indiqu?e mais le message d'erreur sera\n" -"inad?quat ? le syst?me essaye alors d'interpr?ter la valeur donn?e comme un\n" +"inad?quat ??le syst?me essaye alors d'interpr?ter la valeur donn?e comme un\n" "intervalle." msgid "Enter the name of the key holder" @@ -1820,7 +1820,7 @@ msgstr "Veuillez entrer la phrase de passe?; c'est une phrase secr?te \n" msgid "Please repeat the last passphrase, so you are sure what you typed in." msgstr "" -"Veuillez r?p?ter la derni?re phrase de passe pour vous assurer d'avoir\n" +"Veuillez r?p?ter la derni?re phrase secr?te pour vous assurer d'avoir\n" "tap? correctement." msgid "Give the name of the file to which the signature applies" @@ -2008,13 +2008,12 @@ msgstr "" msgid "key %s: no user ID\n" msgstr "clef %s?: pas d'identit?\n" -#, fuzzy, c-format -#| msgid "skipped \"%s\": %s\n" +#, c-format msgid "key %s: %s\n" -msgstr "??%s?? a ?t? ignor?e?: %s\n" +msgstr "clef?%s?: %s\n" msgid "rejected by import filter" -msgstr "" +msgstr "rejet?e par le filtre d?importation" #, c-format msgid "key %s: PKS subkey corruption repaired\n" @@ -2037,7 +2036,7 @@ msgstr "clef %s?: clef publique introuvable?: %s\n" #, c-format msgid "key %s: new key - skipped\n" -msgstr "clef %s?: nouvelle clef ? ignor?e\n" +msgstr "clef %s?: nouvelle clef ??ignor?e\n" #, c-format msgid "no writable keyring found: %s\n" @@ -2111,17 +2110,16 @@ msgstr "clef %s?: ??%s?? %d?identit?s nettoy?es\n" msgid "key %s: \"%s\" not changed\n" msgstr "clef %s?: ??%s?? n'est pas modifi?e\n" -#, fuzzy, c-format -#| msgid "secret key \"%s\" not found: %s\n" +#, c-format msgid "secret key %s: %s\n" -msgstr "clef secr?te ??%s?? introuvable?: %s\n" +msgstr "clef secr?te %s?: %s\n" msgid "importing secret keys not allowed\n" msgstr "impossible d'importer des clefs secr?tes\n" #, c-format msgid "key %s: secret key with invalid cipher %d - skipped\n" -msgstr "clef %s?: clef secr?te avec chiffrement %d incorrect ? ignor?e\n" +msgstr "clef %s?: clef secr?te avec chiffrement %d incorrect ??ignor?e\n" #, c-format msgid "no default secret keyring: %s\n" @@ -2142,12 +2140,12 @@ msgstr "clef %s?: clef secr?te introuvable?: %s\n" #, c-format msgid "key %s: no public key - can't apply revocation certificate\n" msgstr "" -"clef %s?: pas de clef publique ? impossible d'appliquer le certificat\n" +"clef %s?: pas de clef publique ??impossible d'appliquer le certificat\n" " de r?vocation\n" #, c-format msgid "key %s: invalid revocation certificate: %s - rejected\n" -msgstr "clef %s?: certificat de r?vocation incorrect?: %s ? rejet?\n" +msgstr "clef %s?: certificat de r?vocation incorrect?: %s ??rejet?\n" #, c-format msgid "key %s: \"%s\" revocation certificate imported\n" @@ -2207,27 +2205,27 @@ msgstr "clef %s?: sous-clef ignor?e\n" #, c-format msgid "key %s: non exportable signature (class 0x%02X) - skipped\n" -msgstr "clef %s?: signature non exportable (classe 0x%02X) ? ignor?e\n" +msgstr "clef %s?: signature non exportable (classe 0x%02X) ??ignor?e\n" #, c-format msgid "key %s: revocation certificate at wrong place - skipped\n" -msgstr "clef %s?: certificat de r?vocation au mauvais endroit ? ignor?\n" +msgstr "clef %s?: certificat de r?vocation au mauvais endroit ??ignor?\n" #, c-format msgid "key %s: invalid revocation certificate: %s - skipped\n" -msgstr "clef %s?: certificat de r?vocation incorrect?: %s ? ignor?\n" +msgstr "clef %s?: certificat de r?vocation incorrect?: %s ??ignor?\n" #, c-format msgid "key %s: subkey signature in wrong place - skipped\n" -msgstr "clef %s?: signature de sous-clef au mauvais endroit ? ignor?e\n" +msgstr "clef %s?: signature de sous-clef au mauvais endroit ??ignor?e\n" #, c-format msgid "key %s: unexpected signature class (0x%02X) - skipped\n" -msgstr "clef %s?: classe de signature inattendue (0x%02X) ? ignor?e\n" +msgstr "clef %s?: classe de signature inattendue (0x%02X) ??ignor?e\n" #, c-format msgid "key %s: duplicated user ID detected - merged\n" -msgstr "clef %s?: identit?s en double d?tect?es ? fusionn?es\n" +msgstr "clef %s?: identit?s en double d?tect?es ??fusionn?es\n" #, c-format msgid "WARNING: key %s may be revoked: fetching revocation key %s\n" @@ -2505,8 +2503,8 @@ msgstr "?chec de la signature?: %s\n" msgid "Key has only stub or on-card key items - no passphrase to change.\n" msgstr "" -"La clef ne poss?de que des items partiels ou stock?s sur carte ?\n" -"pas de phrase de passe ? modifier.\n" +"La clef ne poss?de que des items partiels ou stock?s sur carte\n" +"??pas de phrase secr?te ? modifier.\n" msgid "This key is not protected.\n" msgstr "Cette clef n'est pas prot?g?e.\n" @@ -2529,18 +2527,18 @@ msgid "" "Enter the new passphrase for this secret key.\n" "\n" msgstr "" -"Entrez la nouvelle phrase de passe pour cette clef secr?te.\n" +"Entrez la nouvelle phrase secr?te pour cette clef secr?te.\n" "\n" msgid "passphrase not correctly repeated; try again" msgstr "" -"la phrase de passe n'a pas ?t? correctement r?p?t?e?; veuillez r?essayer." +"la phrase secr?te n'a pas ?t? correctement r?p?t?e?; veuillez r?essayer." msgid "" "You don't want a passphrase - this is probably a *bad* idea!\n" "\n" msgstr "" -"Vous ne voulez pas de phrase de passe ? c'est sans doute une *mauvaise* " +"Vous ne voulez pas de phrase secr?te ??c'est sans doute une *mauvaise* " "id?e.\n" "\n" @@ -2639,7 +2637,7 @@ msgid "set a notation for the selected user IDs" msgstr "d?finir une notation pour les identit?s s?lectionn?es" msgid "change the passphrase" -msgstr "modifier la phrase de passe" +msgstr "modifier la phrase secr?te" msgid "change the ownertrust" msgstr "modifier la confiance du propri?taire" @@ -3233,7 +3231,7 @@ msgstr " (%d) RSA (indiquez vous-m?me les capacit?s)\n" #, c-format msgid "%s keys may be between %u and %u bits long.\n" -msgstr "les clefs %s peuvent faire entre %u et %u?bits de longueur.\n" +msgstr "les clefs %s peuvent faire une taille comprise entre %u et %u?bits.\n" #, c-format msgid "What keysize do you want for the subkey? (%u) " @@ -3401,7 +3399,7 @@ msgid "" "You need a Passphrase to protect your secret key.\n" "\n" msgstr "" -"Une phrase de passe est n?cessaire pour prot?ger votre clef secr?te.\n" +"Une phrase secr?te est n?cessaire pour prot?ger votre clef secr?te.\n" "\n" #, c-format @@ -3414,8 +3412,8 @@ msgid "" "using this program with the option \"--edit-key\".\n" "\n" msgstr "" -"Vous ne voulez pas de phrase de passe ? c'est sans doute une *mauvaise*\n" -"id?e. C'est possible quand m?me. Vous pouvez modifier la phrase de passe\n" +"Vous ne voulez pas de phrase secr?te ??c'est sans doute une *mauvaise*\n" +"id?e. C'est possible quand m?me. Vous pouvez modifier la phrase secr?te\n" "? tout moment en utilisant ce programme avec l'option ??--edit-key??.\n" "\n" @@ -3746,7 +3744,7 @@ msgstr "clef de session chiffr?e %s\n" #, c-format msgid "passphrase generated with unknown digest algorithm %d\n" -msgstr "phrase de passe g?n?r?e avec l'algorithme de hachage %d inconnu\n" +msgstr "phrase secr?te g?n?r?e avec l'algorithme de hachage %d inconnu\n" #, c-format msgid "public key is %s\n" @@ -3775,10 +3773,10 @@ msgstr "?chec du d?chiffrement par clef publique?: %s\n" #, c-format msgid "encrypted with %lu passphrases\n" -msgstr "chiffr? avec %lu?phrases de passe\n" +msgstr "chiffr? avec %lu?phrases secr?tes\n" msgid "encrypted with 1 passphrase\n" -msgstr "chiffr? avec 1?phrase de passe\n" +msgstr "chiffr? avec 1?phrase secr?te\n" #, c-format msgid "assuming %s encrypted data\n" @@ -3814,7 +3812,7 @@ msgid "WARNING: multiple plaintexts seen\n" msgstr "Attention?: plusieurs textes en clair ont ?t? vus\n" msgid "standalone revocation - use \"gpg --import\" to apply\n" -msgstr "r?vocation autonome ? utilisez ??gpg --import?? pour l'appliquer\n" +msgstr "r?vocation autonome ??utilisez ??gpg --import?? pour l'appliquer\n" msgid "no signature found\n" msgstr "aucune signature trouv?e\n" @@ -3960,7 +3958,7 @@ msgstr "veuillez plut?t utiliser ??%s%s??\n" #, c-format msgid "WARNING: \"%s\" is a deprecated command - do not use it\n" -msgstr "Attention?: ??%s?? est une commande d?conseill?e ? ne l'utilisez pas\n" +msgstr "Attention?: ??%s?? est une commande d?conseill?e ??ne l'utilisez pas\n" msgid "Uncompressed" msgstr "Non compress?" @@ -4043,7 +4041,7 @@ msgid "can't connect to `%s': %s\n" msgstr "impossible de se connecter ? ??%s???: %s\n" msgid "problem with the agent - disabling agent use\n" -msgstr "probl?me avec l'agent ? arr?t d'utilisation de l'agent\n" +msgstr "probl?me avec l'agent ??arr?t d'utilisation de l'agent\n" #, c-format msgid " (main key ID %s)" @@ -4055,32 +4053,32 @@ msgid "" "\"%.*s\"\n" "%u-bit %s key, ID %s, created %s%s\n" msgstr "" -"Une phrase de passe est n?cessaire pour d?verrouiller la clef secr?te de\n" +"Une phrase secr?te est n?cessaire pour d?verrouiller la clef secr?te de\n" "l'utilisateur?:\n" "??%2$.*1$s??\n" "clef %4$s de %3$u?bits, identifiant %5$s, cr??e le %6$s%7$s\n" msgid "Repeat passphrase\n" -msgstr "R?p?tez la phrase de passe\n" +msgstr "R?p?tez la phrase secr?te\n" msgid "Enter passphrase\n" -msgstr "Entrez la phrase de passe\n" +msgstr "Entrez la phrase secr?te\n" msgid "cancelled by user\n" msgstr "annul? par l'utilisateur\n" msgid "can't query passphrase in batch mode\n" -msgstr "impossible de demander la phrase de passe en mode automatique\n" +msgstr "impossible de demander la phrase secr?te en mode automatique\n" msgid "Enter passphrase: " -msgstr "Entrez la phrase de passe?: " +msgstr "Entrez la phrase secr?te?: " #, c-format msgid "" "You need a passphrase to unlock the secret key for\n" "user: \"%s\"\n" msgstr "" -"Une phrase de passe est n?cessaire pour d?verrouiller la clef secr?te de\n" +"Une phrase secr?te est n?cessaire pour d?verrouiller la clef secr?te de\n" "l'utilisateur?: ??%s??\n" #, c-format @@ -4092,7 +4090,7 @@ msgid " (subkey on main key ID %s)" msgstr " (sous-clef de la clef principale d'identifiant %s)" msgid "Repeat passphrase: " -msgstr "R?p?tez la phrase de passe?: " +msgstr "R?p?tez la phrase secr?te?: " msgid "" "\n" @@ -4522,7 +4520,7 @@ msgid "protection digest %d is not supported\n" msgstr "le hachage de protection %d n'est pas pris en charge\n" msgid "Invalid passphrase; please try again" -msgstr "Phrase de passe incorrecte?; veuillez r?essayer" +msgstr "Phrase secr?te incorrecte?; veuillez r?essayer" #, c-format msgid "%s ...\n" @@ -4530,7 +4528,7 @@ msgstr "%s?\n" msgid "WARNING: Weak key detected - please change passphrase again.\n" msgstr "" -"Attention?: clef faible d?tect?e ? modifiez encore la phrase de passe.\n" +"Attention?: clef faible d?tect?e ??modifiez encore la phrase secr?te.\n" msgid "generating the deprecated 16-bit checksum for secret key protection\n" msgstr "" @@ -4538,7 +4536,7 @@ msgstr "" "la clef secr?te\n" msgid "weak key created - retrying\n" -msgstr "clef faible g?n?r?e ? nouvel essai\n" +msgstr "clef faible g?n?r?e ??nouvel essai\n" #, c-format msgid "cannot avoid weak key for symmetric cipher; tried %d times!\n" @@ -4547,7 +4545,7 @@ msgstr "" "%d?essais ont eu lieu.\n" msgid "DSA requires the hash length to be a multiple of 8 bits\n" -msgstr "DSA n?cessite que la longueur du hachage soit un multiple de 8?bits\n" +msgstr "DSA n?cessite que la taille du hachage soit un multiple de 8?bits\n" #, c-format msgid "DSA key %s uses an unsafe (%u bit) hash\n" @@ -4670,7 +4668,7 @@ msgstr "le chiffrement %s sera utilis?\n" msgid "key is not flagged as insecure - can't use it with the faked RNG!\n" msgstr "" -"la clef n'est pas marqu?e comme non s?curis?e ? elle ne peut pas ?tre\n" +"la clef n'est pas marqu?e comme non s?curis?e ??elle ne peut pas ?tre\n" "utilis?e avec le soi-disant g?n?rateur de nombres al?atoires.\n" #, c-format @@ -4853,7 +4851,7 @@ msgstr "la clef %s appara?t plusieurs fois dans la base de confiance\n" #, c-format msgid "key %s: no public key for trusted key - skipped\n" -msgstr "clef %s?: pas de clef publique pour la clef de confiance ? ignor?e\n" +msgstr "clef %s?: pas de clef publique pour la clef de confiance ??ignor?e\n" #, c-format msgid "key %s marked as ultimately trusted\n" @@ -5034,7 +5032,7 @@ msgid "checksum error" msgstr "erreur de somme de contr?le" msgid "bad passphrase" -msgstr "mauvaise phrase de passe" +msgstr "mauvaise phrase secr?te" msgid "public key not found" msgstr "clef publique introuvable" @@ -5082,7 +5080,7 @@ msgid "file create error" msgstr "erreur de cr?ation de fichier" msgid "invalid passphrase" -msgstr "phrase de passe incorrecte" +msgstr "phrase secr?te incorrecte" msgid "unimplemented pubkey algorithm" msgstr "algorithme de clef publique non impl?ment?" -- 2.1.1 From taffit at debian.org Mon Nov 3 04:24:09 2014 From: taffit at debian.org (=?UTF-8?q?David=20Pr=C3=A9vot?=) Date: Sun, 2 Nov 2014 23:24:09 -0400 Subject: [PATCH] [gnupg STABLE-BRANCH-2-0] Update French translation In-Reply-To: <5456E743.8090804@debian.org> References: <5456E743.8090804@debian.org> Message-ID: <1414985049-17844-1-git-send-email-taffit@debian.org> --- po/fr.po | 319 ++++++++++++++++++++++++++++++++------------------------------- 1 file changed, 163 insertions(+), 156 deletions(-) diff --git a/po/fr.po b/po/fr.po index 171e300..99a3b8e 100644 --- a/po/fr.po +++ b/po/fr.po @@ -1,13 +1,13 @@ # GnuPG French translation -# Copyright (C) 1998-2009, 2012 Free Software Foundation, Inc. +# Copyright (C) 1998-2009, 2012, 2014 Free Software Foundation, Inc. # # Ga?l Qu?ri , 1998-2009. -# David Pr?vot , 2012. +# David Pr?vot , 2012, 2014. msgid "" msgstr "" -"Project-Id-Version: gnupg 2.0.19\n" +"Project-Id-Version: gnupg 2.0.26\n" "Report-Msgid-Bugs-To: translations at gnupg.org\n" -"PO-Revision-Date: 2013-04-24 09:34+0200\n" +"PO-Revision-Date: 2014-11-01 19:43-0400\n" "Last-Translator: David Pr?vot \n" "Language-Team: French \n" "Language: fr\n" @@ -15,7 +15,7 @@ msgstr "" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8-bit\n" "Plural-Forms: nplurals=2; plural=(n > 1);\n" -"X-Generator: Lokalize 1.4\n" +"X-Generator: Lokalize 1.5\n" #, c-format msgid "failed to acquire the pinentry lock: %s\n" @@ -55,15 +55,15 @@ msgid "" "Please enter your PIN, so that the secret key can be unlocked for this " "session" msgstr "" -"Veuillez entrer votre code personnel, pour pouvoir d?bloquer la clef secr?te " +"Veuillez entrer votre code personnel, afin de d?bloquer la clef secr?te " "pendant cette session" msgid "" "Please enter your passphrase, so that the secret key can be unlocked for " "this session" msgstr "" -"Veuillez entrer votre phrase de passe, pour pouvoir d?bloquer la clef " -"secr?te pendant cette session" +"Veuillez entrer votre phrase secr?te, afin de d?bloquer la clef secr?te " +"pendant cette session" #. TRANSLATORS: The string is appended to an error message in #. the pinentry. The %s is the actual error message, the @@ -76,7 +76,7 @@ msgid "PIN too long" msgstr "Code personnel trop long" msgid "Passphrase too long" -msgstr "Phrase de passe trop longue" +msgstr "Phrase secr?te trop longue" msgid "Invalid characters in PIN" msgstr "Caract?res incorrects dans le code personnel" @@ -88,10 +88,10 @@ msgid "Bad PIN" msgstr "Mauvais code personnel" msgid "Bad Passphrase" -msgstr "Mauvaise phrase de passe" +msgstr "Mauvaise phrase secr?te" msgid "Passphrase" -msgstr "Phrase de passe" +msgstr "Phrase secr?te" #, c-format msgid "ssh keys greater than %d bits are not supported\n" @@ -147,21 +147,21 @@ msgstr "Refuser" #, c-format msgid "Please enter the passphrase for the ssh key%%0A %F%%0A (%c)" -msgstr "Veuillez entrer la phrase de passe pour la clef SSH%%0A %F%%0A (%c)" +msgstr "Veuillez entrer la phrase secr?te pour la clef SSH%%0A %F%%0A (%c)" msgid "Please re-enter this passphrase" -msgstr "Veuillez r?p?ter cette phrase de passe" +msgstr "Veuillez r?p?ter cette phrase secr?te" #, c-format msgid "" "Please enter a passphrase to protect the received secret key%%0A %s%%0A " "%s%%0Awithin gpg-agent's key storage" msgstr "" -"Veuillez entrer une phrase de passe pour prot?ger la clef secr?te%%0A %s" +"Veuillez entrer une phrase secr?te pour prot?ger la clef secr?te%%0A %s" "%%0A %s%%0Are?ue dans l'espace de stockage de clefs de gpg-agent" msgid "does not match - try again" -msgstr "ne correspond pas ? veuillez r?essayer" +msgstr "ne correspond pas ??veuillez r?essayer" #, c-format msgid "failed to create stream from socket: %s\n" @@ -221,7 +221,7 @@ msgid "error writing to temporary file: %s\n" msgstr "erreur d'?criture du fichier temporaire?: %s\n" msgid "Enter new passphrase" -msgstr "Entrez la nouvelle phrase de passe" +msgstr "Entrez la nouvelle phrase secr?te" msgid "Take this one anyway" msgstr "La prendre quand m?me" @@ -234,11 +234,11 @@ msgid_plural "" "Warning: You have entered an insecure passphrase.%%0AA passphrase should be " "at least %u characters long." msgstr[0] "" -"Avertissement?: une phrase de passe non s?curis?e a ?t? entr?e.%%0AUne " -"phrase de passe devrait ?tre longue d'au moins %u?caract?re." +"Avertissement?: une phrase secr?te non s?curis?e a ?t? entr?e.%%0AUne phrase " +"secr?te devrait contenir au moins %u?caract?re." msgstr[1] "" -"Avertissement?: une phrase de passe non s?curis?e a ?t? entr?e.%%0AUne " -"phrase de passe devrait ?tre longue d'au moins %u?caract?res." +"Avertissement?: une phrase secr?te s?curis?e a ?t? entr?e.%%0AUne phrase " +"secr?te devrait contenir au moins %u?caract?res." #, c-format msgid "" @@ -248,27 +248,26 @@ msgid_plural "" "Warning: You have entered an insecure passphrase.%%0AA passphrase should " "contain at least %u digits or%%0Aspecial characters." msgstr[0] "" -"Avertissement?: une phrase de passe non s?curis?e a ?t? entr?e.%%0AUne " -"phrase de passe devrait contenir au moins%%0A%u?chiffre ou caract?re sp?cial." +"Avertissement?: une phrase secr?te non s?curis?e a ?t? entr?e.%%0AUne phrase " +"secr?te devrait contenir au moins %u?chiffre%%0Aou caract?re sp?cial." msgstr[1] "" -"Avertissement?: une phrase de passe non s?curis?e a ?t? entr?e.%%0AUne " -"phrase de passe devrait contenir au moins%%0A%u?chiffres ou caract?res " -"sp?ciaux." +"Avertissement?: une phrase secr?te non s?curis?e a ?t? entr?e.%%0AUne phrase " +"secr?te devrait contenir au moins %u?chiffres%%0Aou caract?res sp?ciaux." #, c-format msgid "" "Warning: You have entered an insecure passphrase.%%0AA passphrase may not be " "a known term or match%%0Acertain pattern." msgstr "" -"Avertissement?: une phrase de passe non s?curis?e a ?t? entr?e.%%0AUne " -"phrase de passe ne devrait ni ?tre un mot commun,%%0Ani correspondre ? un " -"certain sch?ma." +"Avertissement?: une phrase secr?te non s?curis?e a ?t? entr?e.%%0AUne phrase " +"secr?te ne devrait ni ?tre un mot commun,%%0Ani correspondre ? un certain " +"sch?ma." #, c-format msgid "" "You have not entered a passphrase!%0AAn empty passphrase is not allowed." msgstr "" -"Aucune phrase de passe n'a ?t? entr?e.%0AUne phrase de passe vide n'est pas " +"Aucune phrase secr?te n'a ?t? entr?e.%0AUne phrase secr?te vide n'est pas " "autoris?e." #, c-format @@ -276,7 +275,7 @@ msgid "" "You have not entered a passphrase - this is in general a bad idea!%0APlease " "confirm that you do not want to have any protection on your key." msgstr "" -"Aucune phrase de passe n'a ?t? entr?e ? c'est souvent une mauvaise id?e." +"Aucune phrase secr?te n'a ?t? entr?e ??c'est souvent une mauvaise id?e." "%0AVeuillez confirmer que vous ne voulez aucune protection pour la clef." msgid "Yes, protection is not needed" @@ -284,10 +283,10 @@ msgstr "Oui, aucune protection n'est n?cessaire" #, c-format msgid "Please enter the passphrase to%0Aprotect your new key" -msgstr "Veuillez entrer la phrase de passe%0Apour prot?ger la nouvelle clef" +msgstr "Veuillez entrer la phrase secr?te%0Apour prot?ger la nouvelle clef" msgid "Please enter the new passphrase" -msgstr "Veuillez entrer la nouvelle phrase de passe" +msgstr "Veuillez entrer la nouvelle phrase secr?te" msgid "" "@Options:\n" @@ -350,23 +349,17 @@ msgstr "|N|oublier les codes personnels apr?s N?secondes" msgid "do not use the PIN cache when signing" msgstr "ne pas utiliser le cache de code pour signer" -#, fuzzy -#| msgid "allow clients to mark keys as \"trusted\"" msgid "disallow clients to mark keys as \"trusted\"" -msgstr "permettre de marquer la confiance des clefs" +msgstr "ne pas marquer les clefs comme de confiance" msgid "allow presetting passphrase" -msgstr "permettre de pr?configurer la phrase de passe" +msgstr "permettre de pr?configurer la phrase secr?te" -#, fuzzy -#| msgid "enable ssh-agent emulation" msgid "enable ssh support" -msgstr "activer l'?mulation de ssh-agent" +msgstr "activer la prise en charge de SSH" -#, fuzzy -#| msgid "not supported" msgid "enable putty support" -msgstr "non pris en charge" +msgstr "activer la prise en charge de putty" msgid "|FILE|write environment settings also to FILE" msgstr "|FICHIER|?crire aussi les r?glages d'env. dans FICHIER" @@ -483,7 +476,7 @@ msgstr "gestionnaire SSH 0x%lx pour le descripteur?%d termin?\n" #, c-format msgid "pth_select failed: %s - waiting 1s\n" -msgstr "?chec de pth_select?: %s ? attente 1?s\n" +msgstr "?chec de pth_select?: %s ??attente 1?s\n" #, c-format msgid "%s %s stopped\n" @@ -538,35 +531,35 @@ msgstr "" "Outils de maintenance des clefs secr?tes\n" msgid "Please enter the passphrase to unprotect the PKCS#12 object." -msgstr "Veuillez entrer la phrase de passe pour d?prot?ger l'objet PKCS#12." +msgstr "Veuillez entrer la phrase secr?te pour d?prot?ger l'objet PKCS#12." msgid "Please enter the passphrase to protect the new PKCS#12 object." msgstr "" -"Veuillez entrer la phrase de passe pour prot?ger le nouvel objet PKCS#12." +"Veuillez entrer la phrase secr?te pour prot?ger le nouvel objet PKCS#12." msgid "" "Please enter the passphrase to protect the imported object within the GnuPG " "system." msgstr "" -"Veuillez entrer la phrase de passe pour prot?ger l'objet import? dans le " +"Veuillez entrer la phrase secr?te pour prot?ger l'objet import? dans le " "syst?me GnuPG." msgid "" "Please enter the passphrase or the PIN\n" "needed to complete this operation." msgstr "" -"Veuillez entrer la phrase de passe ou le code personnel\n" +"Veuillez entrer la phrase secr?te ou le code personnel\n" "n?cessaires pour terminer cette op?ration." msgid "Passphrase:" -msgstr "Phrase de passe?:" +msgstr "Phrase secr?te?:" msgid "cancelled\n" msgstr "annul?\n" #, c-format msgid "error while asking for the passphrase: %s\n" -msgstr "erreur de demande de la phrase de passe?: %s\n" +msgstr "erreur de demande de la phrase secr?te?: %s\n" #, c-format msgid "error opening `%s': %s\n" @@ -649,7 +642,7 @@ msgstr "Faux" #, c-format msgid "Note: This passphrase has never been changed.%0APlease change it now." msgstr "" -"Remarque?: cette phrase de passe n'a jamais ?t? modifi?e.%0AVeuillez la " +"Remarque?: cette phrase secr?te n'a jamais ?t? modifi?e.%0AVeuillez la " "modifier maintenant." #, c-format @@ -657,11 +650,11 @@ msgid "" "This passphrase has not been changed%%0Asince %.4s-%.2s-%.2s. Please change " "it now." msgstr "" -"Cette phrase de passe n'a pas ?t? modifi?e%%0Adepuis le %.4s-%.2s-%.2s. " +"Cette phrase secr?te n'a pas ?t? modifi?e%%0Adepuis le %.4s-%.2s-%.2s. " "Veuillez la modifier maintenant." msgid "Change passphrase" -msgstr "Modifier la phrase de passe" +msgstr "Modifier la phrase secr?te" msgid "I'll change it later" msgstr "Je la modifierai plus tard" @@ -790,7 +783,7 @@ msgstr "%d?secondes d'attente pour permettre ? l'agent d'arriver\n" msgid "can't connect to the agent - trying fall back\n" msgstr "" -"impossible de se connecter ? l'agent ? essai avec la solution de repli\n" +"impossible de se connecter ? l'agent ??essai avec la solution de repli\n" #. TRANSLATORS: Copy the prefix between the vertical bars #. verbatim. It will not be printed. @@ -905,7 +898,7 @@ msgid "no CRL found for certificate" msgstr "aucune liste de r?vocations trouv?e pour le certificat" msgid "the available CRL is too old" -msgstr "la liste de r?vocations de certificats est trop vieille" +msgstr "la liste de r?vocations de certificat est trop vieille" msgid "CRL/OCSP check of certificates" msgstr "v?rification de liste de r?vocations par OCSP pour le certificat" @@ -1114,7 +1107,7 @@ msgid "Language preferences: " msgstr "Pr?f?rences de langue?: " msgid "Error: invalid length of preference string.\n" -msgstr "Erreur?: longueur incorrecte de la cha?ne de pr?f?rences.\n" +msgstr "Erreur?: taille incorrecte de la cha?ne de pr?f?rences.\n" msgid "Error: invalid characters in preference string.\n" msgstr "Erreur?: caract?res incorrects dans la cha?ne de pr?f?rences.\n" @@ -1327,7 +1320,7 @@ msgid "Delete this key from the keyring? (y/N) " msgstr "Faut-il supprimer cette clef du porte-clefs?? (o/N) " msgid "This is a secret key! - really delete? (y/N) " -msgstr "C'est une clef secr?te ? faut-il vraiment la supprimer?? (o/N) " +msgstr "C'est une clef secr?te ??faut-il vraiment la supprimer?? (o/N) " #, c-format msgid "deleting keyblock failed: %s\n" @@ -1346,7 +1339,7 @@ msgstr "" #, c-format msgid "error creating passphrase: %s\n" -msgstr "erreur de cr?ation de la phrase de passe?: %s\n" +msgstr "erreur de cr?ation de la phrase secr?te?: %s\n" msgid "can't use a symmetric ESK packet due to the S2K mode\n" msgstr "impossible d'utiliser un paquet ESK sym?trique en mode S2K\n" @@ -1482,7 +1475,7 @@ msgid "export revocation keys marked as \"sensitive\"" msgstr "exporter les clefs de r?vocation marqu?es comme ??sensibles??" msgid "remove the passphrase from exported subkeys" -msgstr "supprimer la phrase de passe des sous-clefs export?es" +msgstr "supprimer la phrase secr?te des sous-clefs export?es" msgid "remove unusable parts from key during export" msgstr "supprimer les parties inutilisables de la clef pendant l'exportation" @@ -1498,15 +1491,15 @@ msgstr "il est interdit d'exporter les clefs secr?tes\n" #, c-format msgid "key %s: not protected - skipped\n" -msgstr "clef %s?: non prot?g?e ? ignor?e\n" +msgstr "clef %s?: non prot?g?e ??ignor?e\n" #, c-format msgid "key %s: PGP 2.x style key - skipped\n" -msgstr "clef %s?: clef de type PGP?2.x ? ignor?e\n" +msgstr "clef %s?: clef de type PGP?2.x ??ignor?e\n" #, c-format msgid "key %s: key material on-card - skipped\n" -msgstr "clef %s?: mat?riel de clef sur la carte ? ignor?e\n" +msgstr "clef %s?: mat?riel de clef sur la carte ??ignor?e\n" msgid "about to export an unprotected subkey\n" msgstr "sur le point d'exporter une sous-clef non prot?g?e\n" @@ -1524,7 +1517,7 @@ msgid "WARNING: nothing exported\n" msgstr "Attention?: rien n'a ?t? export?\n" msgid "too many entries in pk cache - disabled\n" -msgstr "trop d'entr?es dans le cache de clefs publiques ? d?sactiv?\n" +msgstr "trop d'entr?es dans le cache de clefs publiques ??d?sactiv?\n" msgid "[User ID not found]" msgstr "[identit? introuvable]" @@ -1548,7 +1541,7 @@ msgstr "" #, c-format msgid "no secret subkey for public subkey %s - ignoring\n" -msgstr "pas de sous-clef secr?te pour la sous-clef publique %s ? ignor?e\n" +msgstr "pas de sous-clef secr?te pour la sous-clef publique %s ??ignor?e\n" #, c-format msgid "using subkey %s instead of primary key %s\n" @@ -1558,7 +1551,7 @@ msgstr "" #, c-format msgid "key %s: secret key without public key - skipped\n" -msgstr "clef %s?: clef secr?te sans clef publique ? ignor?e\n" +msgstr "clef %s?: clef secr?te sans clef publique ??ignor?e\n" msgid "make a signature" msgstr "faire une signature" @@ -1618,7 +1611,7 @@ msgid "sign or edit a key" msgstr "signer ou ?diter une clef" msgid "change a passphrase" -msgstr "modifier une phrase de passe" +msgstr "modifier une phrase secr?te" msgid "export keys" msgstr "exporter les clefs" @@ -1660,10 +1653,10 @@ msgid "create ascii armored output" msgstr "cr?er une sortie ASCII avec armure" msgid "|USER-ID|encrypt for USER-ID" -msgstr "|IDENTIT?|chiffrer pour l'IDENTIT?" +msgstr "|IDENTIT?| chiffrer pour l'IDENTIT?" msgid "|USER-ID|use USER-ID to sign or decrypt" -msgstr "|IDENTIT?|utiliser l'IDENTIT? pour signer ou d?chiffrer" +msgstr "|IDENTIT?| utiliser l'IDENTIT? pour signer ou d?chiffrer" msgid "|N|set compress level to N (0 disables)" msgstr "|N|niveau de compression N (0 d?sactive)" @@ -1672,7 +1665,7 @@ msgid "use canonical text mode" msgstr "utiliser le mode texte canonique" msgid "|FILE|write output to FILE" -msgstr "|FICHIER|?crire la sortie dans le FICHIER" +msgstr "|FICHIER|?crire la sortie dans le FICHIER" msgid "do not make any changes" msgstr "ne rien modifier" @@ -2333,13 +2326,12 @@ msgstr "" msgid "key %s: no user ID\n" msgstr "clef %s?: pas d'identit?\n" -#, fuzzy, c-format -#| msgid "skipped \"%s\": %s\n" +#, c-format msgid "key %s: %s\n" -msgstr "??%s?? a ?t? ignor?e?: %s\n" +msgstr "clef %s?: %s\n" msgid "rejected by import filter" -msgstr "" +msgstr "rejet?e par le filtre d?importation" #, c-format msgid "key %s: PKS subkey corruption repaired\n" @@ -2362,7 +2354,7 @@ msgstr "clef %s?: clef publique introuvable?: %s\n" #, c-format msgid "key %s: new key - skipped\n" -msgstr "clef %s?: nouvelle clef ? ignor?e\n" +msgstr "clef %s?: nouvelle clef ??ignor?e\n" #, c-format msgid "no writable keyring found: %s\n" @@ -2436,17 +2428,16 @@ msgstr "clef %s?: ??%s?? %d?identit?s nettoy?es\n" msgid "key %s: \"%s\" not changed\n" msgstr "clef %s?: ??%s?? n'est pas modifi?e\n" -#, fuzzy, c-format -#| msgid "secret key \"%s\" not found: %s\n" +#, c-format msgid "secret key %s: %s\n" -msgstr "clef secr?te ??%s?? introuvable?: %s\n" +msgstr "clef secr?te %s?: %s\n" msgid "importing secret keys not allowed\n" msgstr "impossible d'importer des clefs secr?tes\n" #, c-format msgid "key %s: secret key with invalid cipher %d - skipped\n" -msgstr "clef %s?: clef secr?te avec chiffrement %d incorrect ? ignor?e\n" +msgstr "clef %s?: clef secr?te avec chiffrement %d incorrect ??ignor?e\n" #, c-format msgid "no default secret keyring: %s\n" @@ -2467,12 +2458,12 @@ msgstr "clef %s?: clef secr?te introuvable?: %s\n" #, c-format msgid "key %s: no public key - can't apply revocation certificate\n" msgstr "" -"clef %s?: pas de clef publique ? impossible d'appliquer le certificat\n" +"clef %s?: pas de clef publique ??impossible d'appliquer le certificat\n" " de r?vocation\n" #, c-format msgid "key %s: invalid revocation certificate: %s - rejected\n" -msgstr "clef %s?: certificat de r?vocation incorrect?: %s ? rejet?\n" +msgstr "clef %s?: certificat de r?vocation incorrect?: %s ??rejet?\n" #, c-format msgid "key %s: \"%s\" revocation certificate imported\n" @@ -2532,27 +2523,27 @@ msgstr "clef %s?: sous-clef ignor?e\n" #, c-format msgid "key %s: non exportable signature (class 0x%02X) - skipped\n" -msgstr "clef %s?: signature non exportable (classe 0x%02X) ? ignor?e\n" +msgstr "clef %s?: signature non exportable (classe 0x%02X) ??ignor?e\n" #, c-format msgid "key %s: revocation certificate at wrong place - skipped\n" -msgstr "clef %s?: certificat de r?vocation au mauvais endroit ? ignor?\n" +msgstr "clef %s?: certificat de r?vocation au mauvais endroit ??ignor?\n" #, c-format msgid "key %s: invalid revocation certificate: %s - skipped\n" -msgstr "clef %s?: certificat de r?vocation incorrect?: %s ? ignor?\n" +msgstr "clef %s?: certificat de r?vocation incorrect?: %s ??ignor?\n" #, c-format msgid "key %s: subkey signature in wrong place - skipped\n" -msgstr "clef %s?: signature de sous-clef au mauvais endroit ? ignor?e\n" +msgstr "clef %s?: signature de sous-clef au mauvais endroit ??ignor?e\n" #, c-format msgid "key %s: unexpected signature class (0x%02X) - skipped\n" -msgstr "clef %s?: classe de signature inattendue (0x%02X) ? ignor?e\n" +msgstr "clef %s?: classe de signature inattendue (0x%02X) ??ignor?e\n" #, c-format msgid "key %s: duplicated user ID detected - merged\n" -msgstr "clef %s?: identit?s en double d?tect?es ? fusionn?es\n" +msgstr "clef %s?: identit?s en double d?tect?es ??fusionn?es\n" #, c-format msgid "WARNING: key %s may be revoked: fetching revocation key %s\n" @@ -2830,8 +2821,8 @@ msgstr "?chec de la signature?: %s\n" msgid "Key has only stub or on-card key items - no passphrase to change.\n" msgstr "" -"La clef ne poss?de que des ?l?ments partiels ou stock?s sur carte ?\n" -"pas de phrase de passe ? modifier.\n" +"La clef ne poss?de que des ?l?ments partiels ou stock?s sur carte\n" +"??pas de phrase secr?te ? modifier.\n" msgid "This key is not protected.\n" msgstr "Cette clef n'est pas prot?g?e.\n" @@ -2854,18 +2845,18 @@ msgid "" "Enter the new passphrase for this secret key.\n" "\n" msgstr "" -"Entrez la nouvelle phrase de passe pour cette clef secr?te.\n" +"Entrez la nouvelle phrase secr?te pour cette clef secr?te.\n" "\n" msgid "passphrase not correctly repeated; try again" msgstr "" -"la phrase de passe n'a pas ?t? correctement r?p?t?e?; veuillez r?essayer" +"la phrase secr?te n'a pas ?t? correctement r?p?t?e?; veuillez r?essayer" msgid "" "You don't want a passphrase - this is probably a *bad* idea!\n" "\n" msgstr "" -"Vous ne voulez pas de phrase de passe ? c'est sans doute une *mauvaise* " +"Vous ne voulez pas de phrase secr?te ??c'est sans doute une *mauvaise* " "id?e.\n" "\n" @@ -2964,7 +2955,7 @@ msgid "set a notation for the selected user IDs" msgstr "d?finir une notation pour les identit?s s?lectionn?es" msgid "change the passphrase" -msgstr "modifier la phrase de passe" +msgstr "modifier la phrase secr?te" msgid "change the ownertrust" msgstr "modifier la confiance du propri?taire" @@ -3567,7 +3558,7 @@ msgstr " (%d) RSA (indiquez vous-m?me les capacit?s)\n" #, c-format msgid "%s keys may be between %u and %u bits long.\n" -msgstr "les clefs %s peuvent faire entre %u et %u?bits de longueur.\n" +msgstr "les clefs %s peuvent faire une taille comprise entre %u et %u?bits.\n" #, c-format msgid "What keysize do you want for the subkey? (%u) " @@ -3751,15 +3742,15 @@ msgid "" "You need a Passphrase to protect your secret key.\n" "\n" msgstr "" -"Une phrase de passe est n?cessaire pour prot?ger votre clef secr?te.\n" +"Une phrase secr?te est n?cessaire pour prot?ger votre clef secr?te.\n" "\n" msgid "" "Please enter a passphrase to protect the off-card backup of the new " "encryption key." msgstr "" -"Veuillez entrer une phrase de passe pour prot?ger la sauvegarde hors carte " -"de la nouvelle clef de chiffrement." +"Veuillez entrer une phrase secr?te pour prot?ger la sauvegarde hors carte de " +"la nouvelle clef de chiffrement." #, c-format msgid "%s.\n" @@ -3771,8 +3762,8 @@ msgid "" "using this program with the option \"--edit-key\".\n" "\n" msgstr "" -"Vous ne voulez pas de phrase de passe ? c'est sans doute une *mauvaise*\n" -"id?e. C'est possible quand m?me. Vous pouvez modifier la phrase de passe\n" +"Vous ne voulez pas de phrase secr?te ??c'est sans doute une *mauvaise*\n" +"id?e. C'est possible quand m?me. Vous pouvez modifier la phrase secr?te\n" "? tout moment en utilisant ce programme avec l'option ??--edit-key??.\n" "\n" @@ -4103,7 +4094,7 @@ msgstr "clef de session chiffr?e %s\n" #, c-format msgid "passphrase generated with unknown digest algorithm %d\n" -msgstr "phrase de passe g?n?r?e avec l'algorithme de hachage %d inconnu\n" +msgstr "phrase secr?te g?n?r?e avec l'algorithme de hachage %d inconnu\n" #, c-format msgid "public key is %s\n" @@ -4132,10 +4123,10 @@ msgstr "?chec du d?chiffrement par clef publique?: %s\n" #, c-format msgid "encrypted with %lu passphrases\n" -msgstr "chiffr? avec %lu?phrases de passe\n" +msgstr "chiffr? avec %lu?phrases secr?tes\n" msgid "encrypted with 1 passphrase\n" -msgstr "chiffr? avec 1?phrase de passe\n" +msgstr "chiffr? avec 1?phrase secr?te\n" #, c-format msgid "assuming %s encrypted data\n" @@ -4158,7 +4149,7 @@ msgstr "Attention?: le message chiffr? a ?t? manipul?.\n" #, c-format msgid "cleared passphrase cached with ID: %s\n" -msgstr "phrase de passe effac?e mise en cache avec l'identifiant?: %s\n" +msgstr "phrase secr?te effac?e mise en cache avec l'identifiant?: %s\n" #, c-format msgid "decryption failed: %s\n" @@ -4175,7 +4166,7 @@ msgid "WARNING: multiple plaintexts seen\n" msgstr "Attention?: plusieurs textes en clair ont ?t? vus\n" msgid "standalone revocation - use \"gpg --import\" to apply\n" -msgstr "r?vocation autonome ? utilisez ??gpg --import?? pour l'appliquer\n" +msgstr "r?vocation autonome ??utilisez ??gpg --import?? pour l'appliquer\n" msgid "no signature found\n" msgstr "aucune signature trouv?e\n" @@ -4295,6 +4286,10 @@ msgstr "Attention?: utilisation de l'algorithme exp?rimental de hachage %s\n" msgid "WARNING: digest algorithm %s is deprecated\n" msgstr "Attention?: l'algorithme de hachage %s est d?conseill?\n" +#, c-format +msgid "Note: signatures using the %s algorithm are rejected\n" +msgstr "Remarque?: les signatures utilisant l?algorithme?%s sont rejet?es\n" + msgid "the IDEA cipher plugin is not present\n" msgstr "le module de chiffrement IDEA n'est pas pr?sent\n" @@ -4316,15 +4311,28 @@ msgstr "veuillez plut?t utiliser ??%s%s??\n" #, c-format msgid "WARNING: \"%s\" is a deprecated command - do not use it\n" -msgstr "Attention?: ??%s?? est une commande d?conseill?e ? ne l'utilisez pas\n" +msgstr "Attention?: ??%s?? est une commande d?conseill?e ??ne l'utilisez pas\n" #, c-format msgid "%s:%u: obsolete option \"%s\" - it has no effect\n" -msgstr "%s?: %u?: option ??%s?? obsol?te ? non prise en compte\n" +msgstr "%s?: %u?: option ??%s?? obsol?te ??non prise en compte\n" #, c-format msgid "WARNING: \"%s\" is an obsolete option - it has no effect\n" -msgstr "Attention?: ??%s?? est une option obsol?te ? non prise en compte\n" +msgstr "Attention?: ??%s?? est une option obsol?te ??non prise en compte\n" + +#, c-format +msgid "%s:%u: \"%s%s\" is obsolete in this file - it only has effect in %s\n" +msgstr "" +"%s?: %u?: ??%s%s?? est obsol?te dans ce fichier ??n?est prise en compte que " +"dans %s\n" + +#, c-format +msgid "" +"WARNING: \"%s%s\" is an obsolete option - it has no effect except on %s\n" +msgstr "" +"Attention?: ??%s%s?? est une option obsol?te ??non prise en compte ? part " +"dans %s\n" msgid "Uncompressed" msgstr "Non compress?" @@ -4404,7 +4412,7 @@ msgid "" "%u-bit %s key, ID %s,\n" "created %s%s.\n" msgstr "" -"Veuillez entrer la phrase de passe pour d?verrouiller la clef secr?te pour " +"Veuillez entrer la phrase secr?te pour d?verrouiller la clef secr?te pour " "le\n" "certificat OpenPGP?:\n" "??%2$.*1$s??\n" @@ -4412,7 +4420,7 @@ msgstr "" "cr??e le %6$s%7$s.\n" msgid "Enter passphrase\n" -msgstr "Entrez la phrase de passe\n" +msgstr "Entrez la phrase secr?te\n" msgid "cancelled by user\n" msgstr "annul? par l'utilisateur\n" @@ -4422,7 +4430,7 @@ msgid "" "You need a passphrase to unlock the secret key for\n" "user: \"%s\"\n" msgstr "" -"Une phrase de passe est n?cessaire pour d?verrouiller la clef secr?te de\n" +"Une phrase secr?te est n?cessaire pour d?verrouiller la clef secr?te de\n" "l'utilisateur?: ??%s??\n" #, c-format @@ -4866,7 +4874,7 @@ msgid "protection digest %d is not supported\n" msgstr "le hachage de protection %d n'est pas pris en charge\n" msgid "Invalid passphrase; please try again" -msgstr "Phrase de passe incorrecte?; veuillez r?essayer" +msgstr "Phrase secr?te incorrecte?; veuillez r?essayer" #, c-format msgid "%s ...\n" @@ -4874,7 +4882,7 @@ msgstr "%s?\n" msgid "WARNING: Weak key detected - please change passphrase again.\n" msgstr "" -"Attention?: clef faible d?tect?e ? modifiez encore la phrase de passe.\n" +"Attention?: clef faible d?tect?e ??modifiez encore la phrase secr?te.\n" msgid "generating the deprecated 16-bit checksum for secret key protection\n" msgstr "" @@ -4882,7 +4890,7 @@ msgstr "" "la clef secr?te\n" msgid "weak key created - retrying\n" -msgstr "clef faible g?n?r?e ? nouvel essai\n" +msgstr "clef faible g?n?r?e ??nouvel essai\n" #, c-format msgid "cannot avoid weak key for symmetric cipher; tried %d times!\n" @@ -4891,7 +4899,7 @@ msgstr "" "%d?essais ont eu lieu.\n" msgid "DSA requires the hash length to be a multiple of 8 bits\n" -msgstr "DSA n?cessite que la longueur du hachage soit un multiple de 8?bits\n" +msgstr "DSA n?cessite que la taille du hachage soit un multiple de 8?bits\n" #, c-format msgid "DSA key %s uses an unsafe (%u bit) hash\n" @@ -4945,11 +4953,6 @@ msgstr "Remarque?: la clef de signature %s a expir? le %s\n" msgid "NOTE: signature key %s has been revoked\n" msgstr "Remarque?: la clef de signature %s a ?t? r?voqu?e\n" -#, fuzzy, c-format -#| msgid "%s signature, digest algorithm %s\n" -msgid "Note: signatures using the %s algorithm are rejected\n" -msgstr "signature %s, algorithme de hachage %s\n" - #, c-format msgid "assuming bad signature from key %s due to an unknown critical bit\n" msgstr "" @@ -5023,7 +5026,7 @@ msgstr "le chiffrement %s sera utilis?\n" msgid "key is not flagged as insecure - can't use it with the faked RNG!\n" msgstr "" -"la clef n'est pas marqu?e comme non s?curis?e ? elle ne peut pas ?tre\n" +"la clef n'est pas marqu?e comme non s?curis?e ??elle ne peut pas ?tre\n" "utilis?e avec le soi-disant g?n?rateur de nombres al?atoires.\n" #, c-format @@ -5206,7 +5209,7 @@ msgstr "la clef %s appara?t plusieurs fois dans la base de confiance\n" #, c-format msgid "key %s: no public key for trusted key - skipped\n" -msgstr "clef %s?: pas de clef publique pour la clef de confiance ? ignor?e\n" +msgstr "clef %s?: pas de clef publique pour la clef de confiance ??ignor?e\n" #, c-format msgid "key %s marked as ultimately trusted\n" @@ -5564,7 +5567,7 @@ msgstr "utilisation du code personnel par d?faut en tant que %s\n" msgid "failed to use default PIN as %s: %s - disabling further default use\n" msgstr "" "impossible d'utiliser le code personnel par d?faut en tant que %s?:\n" -"%s ? d?sactivation de la prochaine utilisation par d?faut\n" +"%s ??d?sactivation de la prochaine utilisation par d?faut\n" #, c-format msgid "||Please enter the PIN%%0A[sigs done: %lu]" @@ -5576,7 +5579,7 @@ msgstr "||Veuillez entrer le code personnel" #, c-format msgid "PIN for CHV%d is too short; minimum length is %d\n" msgstr "" -"le code personnel pour CHV%d est trop court?; la longueur minimale\n" +"le code personnel pour CHV%d est trop court?; la taille minimale\n" "est %d\n" #, c-format @@ -5615,7 +5618,7 @@ msgstr "||Veuillez entrer le code de r?initialisation pour la carte" #, c-format msgid "Reset Code is too short; minimum length is %d\n" msgstr "" -"Le code de r?initialisation est trop court?; la longueur minimale\n" +"Le code de r?initialisation est trop court?; la taille minimale\n" "est %d\n" #. TRANSLATORS: Do not translate the "|*|" prefixes but @@ -5702,7 +5705,7 @@ msgstr "" #, c-format msgid "can't access %s - invalid OpenPGP card?\n" msgstr "" -"impossible d'acc?der ? %s ? la carte OpenPGP n'est peut-?tre pas valable\n" +"impossible d'acc?der ? %s ??la carte OpenPGP n'est peut-?tre pas valable\n" msgid "||Please enter your PIN at the reader's pinpad" msgstr "" @@ -5745,7 +5748,7 @@ msgid "deny the use of admin card commands" msgstr "refus d'utiliser les commandes d'administration de la carte" msgid "use variable length input for pinpad" -msgstr "" +msgstr "utiliser une entr?e de taille variable pour le pav? num?rique" msgid "Usage: scdaemon [options] (-h for help)" msgstr "Utilisation?: scdaemon [options] (-h pour l'aide)" @@ -5780,7 +5783,7 @@ msgstr "?chec de transfert de la demande %s au client\n" #, c-format msgid "no running dirmngr - starting `%s'\n" -msgstr "pas d'instance de dirmngr en cours d'ex?cution ? d?marrage de ??%s??\n" +msgstr "pas d'instance de dirmngr en cours d'ex?cution ??d?marrage de ??%s??\n" msgid "malformed DIRMNGR_INFO environment variable\n" msgstr "la variable d'environnement DIRMNGR_INFO est mal d?finie\n" @@ -5791,7 +5794,7 @@ msgstr "le protocole dirmngr version?%d n'est pas pris en charge\n" msgid "can't connect to the dirmngr - trying fall back\n" msgstr "" -"impossible de se connecter au dirmngr ? essai avec la solution de repli\n" +"impossible de se connecter au dirmngr ??essai avec la solution de repli\n" #, c-format msgid "validation model requested by certificate: %s" @@ -5856,7 +5859,7 @@ msgstr "veuillez vous assurer que le ??dirmngr?? est correctement install?\ #, c-format msgid "checking the CRL failed: %s" -msgstr "?chec de v?rification de la liste de r?vocations de certificats?: %s" +msgstr "?chec de v?rification de la liste de r?vocations de certificat?: %s" #, c-format msgid "certificate with invalid validity: %s" @@ -5924,7 +5927,7 @@ msgstr "marquage de confiance interactif d?sactiv? pour cette session\n" msgid "WARNING: creation time of signature not known - assuming current time" msgstr "" -"Attention?: date de cr?ation de la signature inconnue ? date suppos?e " +"Attention?: date de cr?ation de la signature inconnue ??date suppos?e " "actuelle" msgid "no issuer found in certificate" @@ -5952,7 +5955,7 @@ msgstr "certificat avec une mauvaise signature" msgid "found another possible matching CA certificate - trying again" msgstr "" "un autre certificat d'autorit? de certification pouvant correspondre a ?t? " -"trouv? ? nouvel essai" +"trouv? ??nouvel essai" #, c-format msgid "certificate chain longer than allowed by CA (%d)" @@ -5992,16 +5995,16 @@ msgid "none" msgstr "aucun" msgid "[Error - invalid encoding]" -msgstr "[Erreur ? encodage incorrecte]" +msgstr "[Erreur ??encodage incorrecte]" msgid "[Error - out of core]" -msgstr "[Erreur ? hors limite]" +msgstr "[Erreur ??hors limite]" msgid "[Error - No name]" -msgstr "[Erreur ? pas de nom]" +msgstr "[Erreur ??pas de nom]" msgid "[Error - invalid DN]" -msgstr "[Erreur ? DN incorrect]" +msgstr "[Erreur ??DN incorrect]" #, c-format msgid "" @@ -6011,7 +6014,7 @@ msgid "" "S/N %s, ID 0x%08lX,\n" "created %s, expires %s.\n" msgstr "" -"Veuillez entrer la phrase de passe pour d?verrouiller la clef secr?te pour " +"Veuillez entrer la phrase secr?te pour d?verrouiller la clef secr?te pour " "le\n" "certificat X.509?:\n" "??%s??\n" @@ -6020,7 +6023,7 @@ msgstr "" msgid "no key usage specified - assuming all usages\n" msgstr "" -"aucune utilisation de clef indiqu?e ? toutes les utilisations sont " +"aucune utilisation de clef indiqu?e ??toutes les utilisations sont " "suppos?es\n" #, c-format @@ -6053,7 +6056,7 @@ msgstr "ligne?%d?: algorithme incorrect\n" #, c-format msgid "line %d: invalid key length %u (valid are %d to %d)\n" -msgstr "ligne?%d?: longueur?%u de clef incorrecte (%d ? %d possible)\n" +msgstr "ligne?%d?: taille?%u de clef incorrecte (%d ? %d possible)\n" #, c-format msgid "line %d: no subject name given\n" @@ -6088,7 +6091,7 @@ msgid "" "you just created once more.\n" msgstr "" "Pour terminer cette demande de certificat, veuillez entrer encore une fois " -"la phrase de passe pour la clef que vous venez de cr?er.\n" +"la phrase secr?te pour la clef que vous venez de cr?er.\n" #, c-format msgid " (%d) RSA\n" @@ -6296,7 +6299,7 @@ msgid "|FILE|add keyring to the list of keyrings" msgstr "|FICHIER|ajouter le trousseau ? la liste de trousseaux" msgid "|USER-ID|use USER-ID as default secret key" -msgstr "|IDENTIT?|utiliser IDENTIT? comme clef secr. par d?faut" +msgstr "|IDENTIT?| utiliser IDENTIT? comme clef secr. par d?faut" msgid "|SPEC|use this keyserver to lookup keys" msgstr "|SPEC|utiliser ce serveur pour rechercher les clefs" @@ -6367,7 +6370,7 @@ msgid "error storing certificate\n" msgstr "erreur de stockage du certificat\n" msgid "basic certificate checks failed - not imported\n" -msgstr "?chec des v?rifications de base du certificat ? non import?\n" +msgstr "?chec des v?rifications de base du certificat ??non import?\n" #, c-format msgid "error getting stored flags: %s\n" @@ -6413,11 +6416,11 @@ msgid "error storing flags: %s\n" msgstr "erreur de stockage des options?: %s\n" msgid "Error - " -msgstr "Erreur ? " +msgstr "Erreur ??" msgid "GPG_TTY has not been set - using maybe bogus default\n" msgstr "" -"GPG_TTY n'a pas ?t? d?finie ? utilisation de d?fauts peut-?tre d?fectueux\n" +"GPG_TTY n'a pas ?t? d?finie ??utilisation de d?fauts peut-?tre d?fectueux\n" #, c-format msgid "invalid formatted fingerprint in `%s', line %d\n" @@ -6548,7 +6551,7 @@ msgid "receiving line failed: %s\n" msgstr "?chec de r?ception de ligne?: %s\n" msgid "line too long - skipped\n" -msgstr "ligne trop longue ? ignor?e\n" +msgstr "ligne trop longue ??ignor?e\n" msgid "line shortened due to embedded Nul character\n" msgstr "ligne raccourcie ? cause de caract?re NULL inclus\n" @@ -6588,31 +6591,35 @@ msgid "|N|expire SSH keys after N seconds" msgstr "|N|oublier les clefs SSH apr?s N?secondes" msgid "|N|set maximum PIN cache lifetime to N seconds" -msgstr "|N|dur?e max. cache de code pers.?: N?secondes" +msgstr "|N|d?finir la dur?e maximale du cache de code personnel ? N?secondes" msgid "|N|set maximum SSH key lifetime to N seconds" -msgstr "|N|dur?e max. du cache de clef SSH?: N?secondes" +msgstr "|N|d?finir la dur?e maximale du cache de clef SSH ? N?secondes" msgid "Options enforcing a passphrase policy" -msgstr "Options d'application d'une politique de phrase de passe" +msgstr "Options d'application d'une politique de phrase secr?te" msgid "do not allow to bypass the passphrase policy" -msgstr "pas de contournement de politique de phrase de passe" +msgstr "pas de contournement de politique de phrase secr?te" msgid "|N|set minimal required length for new passphrases to N" -msgstr "|N|d?finir longueur minimale des nouvelles phrases de passe ? N" +msgstr "|N|d?finir la taille minimale des nouvelles phrases secr?tes ? N" msgid "|N|require at least N non-alpha characters for a new passphrase" -msgstr "|N|au moins N?caract?res non alphab. pour nouv. phrase de passe" +msgstr "" +"|N|n?cessiter au moins N caract?res non alphab?tiques pour les nouvelles " +"phrases secr?tes" msgid "|FILE|check new passphrases against pattern in FILE" -msgstr "|FICHIER|v?rifier nouv. phrase de passe par rapport motifs du FICHIER" +msgstr "" +"|FICHIER|v?rifier la nouvelle phrase secr?te par rapport aux motifs du " +"FICHIER" msgid "|N|expire the passphrase after N days" -msgstr "|N|la phrase de passe expire apr?s N?jours" +msgstr "|N|la phrase secr?te expire apr?s N?jours" msgid "do not allow the reuse of old passphrases" -msgstr "ne pas autoriser r?utilisation d'anciennes phrase de passe" +msgstr "ne pas autoriser la r?utilisation d'anciennes phrases secr?tes" msgid "|NAME|use NAME as default secret key" msgstr "|NOM|utiliser le NOM comme clef secr?te par d?faut" @@ -6633,16 +6640,16 @@ msgid "allow PKA lookups (DNS requests)" msgstr "permettre les recherches PKA (requ?tes DNS)" msgid "|MECHANISMS|use MECHANISMS to locate keys by mail address" -msgstr "|M?CANISMES|utiliser M?CANISMES pour localiser les clefs" +msgstr "|M?CANISMES|utiliser les M?CANISMES pour localiser les clefs" msgid "disable all access to the dirmngr" msgstr "d?sactiver tous les acc?s au dirmngr" msgid "|NAME|use encoding NAME for PKCS#12 passphrases" -msgstr "|NOM|utiliser encodage NOM pour phr. passe PKCS#12" +msgstr "|NOM|utiliser l?encodage NOM pour les phrases secr?te PKCS#12" msgid "do not check CRLs for root certificates" -msgstr "ne pas v?rifier listes r?voc. de cert. racines" +msgstr "ne pas v?rifier les listes de r?vocations de certificat racine" msgid "Options controlling the format of the output" msgstr "Options contr?lant le format de sortie" @@ -6828,7 +6835,7 @@ msgstr "?chec de select?: %s\n" #, c-format msgid "read failed: %s\n" -msgstr "?chec de read?: %s\n" +msgstr "?chec de lecture?: %s\n" #, c-format msgid "pty read failed: %s\n" @@ -6869,7 +6876,7 @@ msgid "" "Check a passphrase given on stdin against the patternfile\n" msgstr "" "Syntaxe?: gpg-check-pattern [options] ficmotif\n" -"V?rifier une phrase de passe donn?e sur l'entr?e standard par rapport ? " +"V?rifier une phrase secr?te donn?e sur l'entr?e standard par rapport ? " "ficmotif\n" #~ msgid "you may want to start the gpg-agent first\n" -- 2.1.1 From taffit at debian.org Mon Nov 3 04:24:56 2014 From: taffit at debian.org (=?UTF-8?q?David=20Pr=C3=A9vot?=) Date: Sun, 2 Nov 2014 23:24:56 -0400 Subject: [PATCH] [libgpg-error] Update French transaltion In-Reply-To: <5456E743.8090804@debian.org> References: <5456E743.8090804@debian.org> Message-ID: <1414985096-17961-1-git-send-email-taffit@debian.org> --- po/fr.po | 138 ++++++++++++++++++++++----------------------------------------- 1 file changed, 48 insertions(+), 90 deletions(-) diff --git a/po/fr.po b/po/fr.po index 0e308b4..7a3ba0f 100644 --- a/po/fr.po +++ b/po/fr.po @@ -1,21 +1,21 @@ # French translation of Libgpg-error -# Copyright (C) 2005, 2011, 2012 Free Software Foundation, Inc. +# Copyright (C) 2005, 2011, 2012, 2014 Free Software Foundation, Inc. # This file is distributed under the same license as the libgpg-error package. # # Stephane Roy , 2005. -# David Pr?vot , 2011, 2012. +# David Pr?vot , 2011, 2012, 2014. msgid "" msgstr "" -"Project-Id-Version: libgpg-error-1.10\n" +"Project-Id-Version: libgpg-error-1.17\n" "Report-Msgid-Bugs-To: translations at gnupg.org\n" -"PO-Revision-Date: 2013-02-23 20:09+0100\n" +"PO-Revision-Date: 2014-11-01 22:07-0400\n" "Last-Translator: David Pr?vot \n" "Language-Team: French \n" "Language: fr\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" -"X-Generator: Lokalize 1.4\n" +"X-Generator: Lokalize 1.5\n" "Plural-Forms: nplurals=2; plural=(n > 1);\n" msgid "Unspecified source" @@ -67,7 +67,7 @@ msgid "Assuan" msgstr "Assuan" msgid "TLS" -msgstr "" +msgstr "TLS" msgid "Any source" msgstr "N'importe quelle source" @@ -121,7 +121,7 @@ msgid "Checksum error" msgstr "Erreur de somme de contr?le" msgid "Bad passphrase" -msgstr "Mauvaise phrase de passe" +msgstr "Mauvaise phrase secr?te" msgid "Invalid cipher algorithm" msgstr "Algorithme de chiffrement incorrect" @@ -321,8 +321,6 @@ msgstr "R?ponse incorrecte" msgid "No agent running" msgstr "Pas d'agent en cours d'ex?cution" -#, fuzzy -#| msgid "agent error" msgid "Agent error" msgstr "Erreur d'agent" @@ -411,7 +409,7 @@ msgid "Corrupted protection" msgstr "Protection corrompue" msgid "Ambiguous name" -msgstr "Nom ambigu?" +msgstr "Nom ambigu" msgid "Card error" msgstr "Erreur de carte" @@ -621,7 +619,7 @@ msgid "Not operational" msgstr "Non op?rationnel" msgid "No passphrase given" -msgstr "Aucune phrase de passe fournie" +msgstr "Aucune phrase secr?te fournie" msgid "No PIN given" msgstr "Aucun code personnel fourni" @@ -656,48 +654,32 @@ msgstr "Courbe elliptique incorrecte" msgid "Unknown elliptic curve" msgstr "Courbe elliptique inconnue" -#, fuzzy -#| msgid "Duplicated value" msgid "Duplicated key" -msgstr "Valeur dupliqu?e" +msgstr "Clef dupliqu?e" -#, fuzzy -#| msgid "Ambiguous name" msgid "Ambiguous result" -msgstr "Nom ambigu?" +msgstr "R?sultat ambigu" -#, fuzzy -#| msgid "No crypto engine" msgid "No crypto context" -msgstr "Aucun moteur de chiffrement" +msgstr "Aucun contexte de chiffrement" -#, fuzzy -#| msgid "No crypto engine" msgid "Wrong crypto context" -msgstr "Aucun moteur de chiffrement" +msgstr "Contexte de chiffrement incorrect" -#, fuzzy -#| msgid "Invalid crypto engine" msgid "Bad crypto context" -msgstr "Moteur de chiffrement incorrect" +msgstr "Mauvais contexte de chiffrement" msgid "Conflict in the crypto context" -msgstr "" +msgstr "Conflit dans le contexte de chiffrement" -#, fuzzy -#| msgid "No public key" msgid "Broken public key" -msgstr "Pas de clef publique" +msgstr "Clef publique cass?e" -#, fuzzy -#| msgid "No secret key" msgid "Broken secret key" -msgstr "Pas de clef secr?te" +msgstr "Clef secr?te cass?e" -#, fuzzy -#| msgid "Invalid digest algorithm" msgid "Invalid MAC algorithm" -msgstr "Algorithme de hachage incorrect" +msgstr "Algorithme MAC incorrect" msgid "Operation fully cancelled" msgstr "Op?ration compl?tement annul?e" @@ -747,115 +729,91 @@ msgstr "Nombre hexad?cimal impair dans l'expression symbolique" msgid "Bad octal character in S-expression" msgstr "Mauvais caract?re octal dans l'expression symbolique" -#, fuzzy -#| msgid "Bad certificate chain" msgid "No certificate chain" -msgstr "Mauvaise cha?ne de certificat" +msgstr "Aucune cha?ne de certificat" -#, fuzzy -#| msgid "Certificate too young" msgid "Certificate is too large" -msgstr "Certificat trop r?cent" +msgstr "Le certificat est trop grand" -#, fuzzy -#| msgid "Invalid card" msgid "Invalid record" -msgstr "Carte incorrecte" +msgstr "Enregistrement incorrect" msgid "The MAC does not verify" -msgstr "" +msgstr "Le MAC ne peut pas ?tre v?rifi?" -#, fuzzy -#| msgid "Unexpected tag" msgid "Unexpected message" -msgstr "Balise inattendue" +msgstr "Message inattendu" msgid "Compression or decompression failed" -msgstr "" +msgstr "?chec de compression ou d?compression" msgid "A counter would wrap" -msgstr "" +msgstr "Un compteur devrait envelopper" msgid "Fatal alert message received" -msgstr "" +msgstr "Message d?alerte fatale re?u" -#, fuzzy -#| msgid "Invalid cipher algorithm" msgid "No cipher algorithm" -msgstr "Algorithme de chiffrement incorrect" +msgstr "Aucun algorithme de chiffrement" -#, fuzzy -#| msgid "Missing issuer certificate" msgid "Missing client certificate" -msgstr "Certificat de l'?metteur manquant" +msgstr "Certificat de client manquant" -#, fuzzy -#| msgid "Certificate revoked" msgid "Close notification received" -msgstr "Certificat r?voqu?" +msgstr "Notification de fermeture re?ue" -#, fuzzy -#| msgid "Key expired" msgid "Ticket expired" -msgstr "Clef expir?e" +msgstr "Ticket expir?" -#, fuzzy -#| msgid "Bad public key" msgid "Bad ticket" -msgstr "Mauvaise clef publique" +msgstr "Mauvais ticket" -#, fuzzy -#| msgid "Unknown packet" msgid "Unknown identity" -msgstr "Paquet inconnu" +msgstr "Identit? inconnue" -#, fuzzy -#| msgid "Bad certificate chain" msgid "Bad certificate message in handshake" -msgstr "Mauvaise cha?ne de certificat" +msgstr "Mauvais message de certificat dans l?initialisation" msgid "Bad certificate request message in handshake" -msgstr "" +msgstr "Mauvais message de demande de certificat dans l?initialisation" msgid "Bad certificate verify message in handshake" -msgstr "" +msgstr "Mauvais message de v?rification de certificat dans l?initialisation" +# NOTE: s/messsage/message/ msgid "Bad change cipher messsage in handshake" -msgstr "" +msgstr "Mauvais message de modification d?algorithme dans l?initialisation" msgid "Bad client hello message in handshake" -msgstr "" +msgstr "Mauvais message de salut du client dans l?initialisation" msgid "Bad server hello message in handshake" -msgstr "" +msgstr "Mauvais message de salut du serveur dans l?initialisation" +# NOTE: s/hanshake/handshake/ msgid "Bad server hello done message in hanshake" -msgstr "" +msgstr "Mauvais message de fin de salut du serveur dans l?initialisation" msgid "Bad finished message in handshake" -msgstr "" +msgstr "Mauvais message fini dans l?initialisation" msgid "Bad server key exchange message in handshake" -msgstr "" +msgstr "Mauvais message d??change de clef du serveur dans l?initialisation" msgid "Bad client key exchange message in handshake" -msgstr "" +msgstr "Mauvais message d??change de clef du client dans l?initialisation" msgid "Bogus string" -msgstr "" +msgstr "Cha?ne erron?e" -#, fuzzy -#| msgid "Key expired" msgid "Key disabled" -msgstr "Clef expir?e" +msgstr "Clef d?sactiv?e" msgid "Not possible with a card based key" -msgstr "" +msgstr "Impossible avec une clef bas?e sur carte" -#, fuzzy -#| msgid "Invalid object" msgid "Invalid lock object" -msgstr "Objet incorrect" +msgstr "Objet de verrouillage incorrect" msgid "General IPC error" msgstr "Erreur g?n?rale IPC" -- 2.1.1 From walter at torres.ws Mon Nov 3 04:52:41 2014 From: walter at torres.ws (Walter Torres) Date: Sun, 2 Nov 2014 21:52:41 -0600 Subject: unsub Message-ID: Walter *When planning for a year, plant oats; when planning for a decade, plant trees; when planning for a life, plant ideas.* -- Ancient Chinese Proverb -------------- next part -------------- An HTML attachment was scrubbed... URL: From md at Linux.IT Mon Nov 3 05:58:27 2014 From: md at Linux.IT (Marco d'Itri) Date: Mon, 3 Nov 2014 05:58:27 +0100 Subject: Removing v3 support from 2.1 In-Reply-To: <871tq9o0kb.fsf@vigenere.g10code.de> References: <87tx3c2tsk.fsf@vigenere.g10code.de> <87fvev23pv.fsf_-_@vigenere.g10code.de> <878ukmzsvv.fsf_-_@vigenere.g10code.de> <87lholxhtx.fsf@vigenere.g10code.de> <871tq9o0kb.fsf@vigenere.g10code.de> Message-ID: <20141103045827.GA7908@bongo.bofh.it> On Oct 15, Werner Koch wrote: > > I removed all code pertaining to v3 keys and also forced using v4 > > signatures. If you want to test this, please checkout the > > "wk/test-master" branch. > I plan to move that to master soon. If you want to send a "Please > consider not to do that" comment, you should hurry up. I should have checked... Let me present you my use case for v3 support: 0xB28B9B51 and 0x7D960EBD. I use these v3 keys to sign the control messages which manage the it.* and linux.* newsgroups, and given the sad state of Usenet nowadays I see no credible scenario in which I could persuade every site to update their keyring. Of the 101 keys currently used to sign control messages, 83 of them are v3 and we are stuck with them essentially forever: wget ftp://ftp.isc.org/pub/pgpcontrol/PGPKEYS gpg --batch --no-permission-warning \ --no-default-keyring --keyring=testring.pub --no-options \ --allow-non-selfsigned-uid --fast-import PGPKEYS gpg --no-default-keyring --keyring=testring.pub --fingerprint --list-keys --with-colons | awk -F: '/^pub:/ { cur = $10 } /^fpr:/ { if (length($10) == 32) print cur }' | wc -l -- ciao, Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 648 bytes Desc: Digital signature URL: From md at Linux.IT Mon Nov 3 04:54:51 2014 From: md at Linux.IT (Marco d'Itri) Date: Mon, 3 Nov 2014 04:54:51 +0100 Subject: Lots of "packet(6) too short" errors with gpg 2.1 In-Reply-To: <87zjccwpbb.fsf@vigenere.g10code.de> References: <545257B7.4080905@enigmail.net> <87zjccwpbb.fsf@vigenere.g10code.de> Message-ID: <20141103035451.GA6705@bongo.bofh.it> On Oct 31, Werner Koch wrote: > Found and fixed: The --keydb-rebuild-caches function which is also used > internally before checking the trustdb, caused the trouble. It parsed > the key and wrote it back. Now v3 keys are not anymore supported and > thus a garbled package was written. The parsing is required to check This also breaks the keyring for gpg 1.x BTW: md at bongo:~$ gpg --list-sigs gpg: packet(6) too short gpg: keyring_get_keyblock: read error: invalid packet gpg: keydb_get_keyblock failed: invalid keyring [Exit 2] -- ciao, Marco From wk at gnupg.org Mon Nov 3 11:14:42 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 03 Nov 2014 11:14:42 +0100 Subject: Removing v3 support from 2.1 In-Reply-To: <20141103045827.GA7908@bongo.bofh.it> (Marco d'Itri's message of "Mon, 3 Nov 2014 05:58:27 +0100") References: <87tx3c2tsk.fsf@vigenere.g10code.de> <87fvev23pv.fsf_-_@vigenere.g10code.de> <878ukmzsvv.fsf_-_@vigenere.g10code.de> <87lholxhtx.fsf@vigenere.g10code.de> <871tq9o0kb.fsf@vigenere.g10code.de> <20141103045827.GA7908@bongo.bofh.it> Message-ID: <87mw88twtp.fsf@vigenere.g10code.de> On Mon, 3 Nov 2014 05:58, md at Linux.IT said: > Of the 101 keys currently used to sign control messages, 83 of them are > v3 and we are stuck with them essentially forever: Okay. What about using gpg1 for this? I would actually suggest to use the name "gpg1" in your script and create a symlink to gpg 1.4. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Nov 3 11:11:19 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 03 Nov 2014 11:11:19 +0100 Subject: Lots of "packet(6) too short" errors with gpg 2.1 In-Reply-To: <20141103035451.GA6705@bongo.bofh.it> (Marco d'Itri's message of "Mon, 3 Nov 2014 04:54:51 +0100") References: <545257B7.4080905@enigmail.net> <87zjccwpbb.fsf@vigenere.g10code.de> <20141103035451.GA6705@bongo.bofh.it> Message-ID: <87r3xktwzc.fsf@vigenere.g10code.de> On Mon, 3 Nov 2014 04:54, md at Linux.IT said: > This also breaks the keyring for gpg 1.x BTW: Sure. However, that corruption is has been solved meanwhile. But v3 keys will be removed from the keyring with the next write operation. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Nov 3 11:18:21 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 03 Nov 2014 11:18:21 +0100 Subject: Translation updates In-Reply-To: <5456E743.8090804@debian.org> ("David =?utf-8?Q?Pr=C3=A9vot?= =?utf-8?Q?=22's?= message of "Sun, 02 Nov 2014 22:24:03 -0400") References: <5456E743.8090804@debian.org> Message-ID: <87ioiwtwnm.fsf@vigenere.g10code.de> On Mon, 3 Nov 2014 03:24, taffit at debian.org said: > I?ve submitted a few translation updates over a month ago to gnupg-i18n > but none of them seem to have been picked up, even if several releases I noticed them only a few days ago in my folder although they should have been there since Sep 10. It is possible that I just forgot about them or that there was indded some Gnus hiccup. > In case it was just some overlook, please find attached (compressed, Thanks. I usually apply PO updates right before a release. > since this one didn?t made it to the gnupg-i18n list) an updated French > translation update for gnupg master. > > I?ve also reviewed and updated the other files submitted in September, > and will send the according patches as a follow up to this mail unless > asked to process another way. > > Regards > > David > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dimitri.j.ledkov at intel.com Mon Nov 3 12:05:03 2014 From: dimitri.j.ledkov at intel.com (Dimitri John Ledkov) Date: Mon, 3 Nov 2014 11:05:03 +0000 Subject: [PATCH] pinentry: More gseal/gtk3 compatibility in the gtk+3 UI. Message-ID: <1415012703-7153-1-git-send-email-dimitri.j.ledkov@intel.com> Signed-off-by: Dimitri John Ledkov --- gtk+-2/gtksecentry.c | 84 ++++++++++++++++++++++++++++++------------------- gtk+-2/pinentry-gtk-2.c | 22 ++++++++----- 2 files changed, 66 insertions(+), 40 deletions(-) diff --git a/gtk+-2/gtksecentry.c b/gtk+-2/gtksecentry.c index 824d45a..1b630ac 100644 --- a/gtk+-2/gtksecentry.c +++ b/gtk+-2/gtksecentry.c @@ -802,7 +802,7 @@ gtk_secure_entry_get_property(GObject * object, static void gtk_secure_entry_init(GtkSecureEntry * entry) { - GTK_WIDGET_SET_FLAGS(entry, GTK_CAN_FOCUS); + gtk_widget_set_can_focus((GtkWidget *)entry, TRUE); entry->text_size = MIN_SIZE; WITH_SECURE_MEM(entry->text = g_malloc(entry->text_size)); @@ -864,7 +864,7 @@ gtk_secure_entry_realize(GtkWidget * widget) GdkWindowAttr attributes; gint attributes_mask; - GTK_WIDGET_SET_FLAGS(widget, GTK_REALIZED); + gtk_widget_set_realized(widget, TRUE); entry = GTK_SECURE_ENTRY(widget); attributes.window_type = GDK_WINDOW_CHILD; @@ -888,9 +888,9 @@ gtk_secure_entry_realize(GtkWidget * widget) attributes_mask = GDK_WA_X | GDK_WA_Y | GDK_WA_VISUAL | GDK_WA_COLORMAP; - widget->window = + gtk_widget_set_window (widget, gdk_window_new(gtk_widget_get_parent_window(widget), &attributes, - attributes_mask); + attributes_mask)); gdk_window_set_user_data(widget->window, entry); get_text_area_size(entry, &attributes.x, &attributes.y, @@ -911,10 +911,10 @@ gtk_secure_entry_realize(GtkWidget * widget) gdk_window_set_background(widget->window, &widget->style-> - base[GTK_WIDGET_STATE(widget)]); + base[gtk_widget_get_state(widget)]); gdk_window_set_background(entry->text_area, &widget->style-> - base[GTK_WIDGET_STATE(widget)]); + base[gtk_widget_get_state(widget)]); gdk_window_show(entry->text_area); @@ -1074,7 +1074,7 @@ gtk_secure_entry_size_allocate(GtkWidget * widget, widget->allocation = *allocation; - if (GTK_WIDGET_REALIZED(widget)) { + if (gtk_widget_get_realized(widget)) { /* We call gtk_widget_get_child_requisition, since we want (for * backwards compatibility reasons) the realization here to * be affected by the usize of the entry, if set @@ -1105,9 +1105,14 @@ gtk_secure_entry_draw_frame(GtkWidget * widget) "interior-focus", &interior_focus, "focus-line-width", &focus_width, NULL); +#if GTK_CHECK_VERSION (2, 24, 0) + width = gdk_window_get_width(widget->window); + height = gdk_window_get_height(widget->window); +#else gdk_drawable_get_size(widget->window, &width, &height); +#endif - if (GTK_WIDGET_HAS_FOCUS(widget) && !interior_focus) { + if (gtk_widget_has_focus(widget) && !interior_focus) { x += focus_width; y += focus_width; width -= 2 * focus_width; @@ -1118,14 +1123,14 @@ gtk_secure_entry_draw_frame(GtkWidget * widget) GTK_STATE_NORMAL, GTK_SHADOW_IN, NULL, widget, "entry", x, y, width, height); - if (GTK_WIDGET_HAS_FOCUS(widget) && !interior_focus) { + if (gtk_widget_has_focus(widget) && !interior_focus) { x -= focus_width; y -= focus_width; width += 2 * focus_width; height += 2 * focus_width; gtk_paint_focus(widget->style, widget->window, - GTK_WIDGET_STATE(widget), NULL, widget, "entry", 0, + gtk_widget_get_state(widget), NULL, widget, "entry", 0, 0, width, height); } } @@ -1143,12 +1148,12 @@ gtk_secure_entry_expose(GtkWidget * widget, GdkEventExpose * event) get_text_area_size(entry, NULL, NULL, &area_width, &area_height); gtk_paint_flat_box(widget->style, entry->text_area, - GTK_WIDGET_STATE(widget), GTK_SHADOW_NONE, + gtk_widget_get_state(widget), GTK_SHADOW_NONE, NULL, widget, "entry_bg", 0, 0, area_width, area_height); if ((entry->invisible_char != 0) && - GTK_WIDGET_HAS_FOCUS(widget) && + gtk_widget_has_focus(widget) && entry->selection_bound == entry->current_pos && entry->cursor_visible) gtk_secure_entry_draw_cursor(GTK_SECURE_ENTRY(widget)); @@ -1171,7 +1176,7 @@ gtk_secure_entry_button_press(GtkWidget * widget, GdkEventButton * event) entry->button = event->button; - if (!GTK_WIDGET_HAS_FOCUS(widget)) { + if (!gtk_widget_has_focus(widget)) { entry->in_click = TRUE; gtk_widget_grab_focus(widget); entry->in_click = FALSE; @@ -1248,7 +1253,11 @@ gtk_secure_entry_motion_notify(GtkWidget * widget, GdkEventMotion * event) { gint height; +#if GTK_CHECK_VERSION (2, 24, 0) + height = gdk_window_get_height(entry->text_area); +#else gdk_drawable_get_size(entry->text_area, NULL, &height); +#endif if (event->y < 0) tmp_pos = 0; @@ -1385,7 +1394,7 @@ gtk_secure_entry_grab_focus(GtkWidget * widget) GtkSecureEntry *entry = GTK_SECURE_ENTRY(widget); gboolean select_on_focus; - GTK_WIDGET_SET_FLAGS(widget, GTK_CAN_DEFAULT); + gtk_widget_set_can_default(widget, TRUE); GTK_WIDGET_CLASS(parent_class)->grab_focus(widget); /* read current select on focus setting from GtkEntry */ @@ -1416,16 +1425,16 @@ gtk_secure_entry_state_changed(GtkWidget * widget, { GtkSecureEntry *entry = GTK_SECURE_ENTRY(widget); - if (GTK_WIDGET_REALIZED(widget)) { + if (gtk_widget_get_realized(widget)) { gdk_window_set_background(widget->window, &widget->style-> - base[GTK_WIDGET_STATE(widget)]); + base[gtk_widget_get_state(widget)]); gdk_window_set_background(entry->text_area, &widget->style-> - base[GTK_WIDGET_STATE(widget)]); + base[gtk_widget_get_state(widget)]); } - if (!GTK_WIDGET_IS_SENSITIVE(widget)) { + if (!gtk_widget_is_sensitive(widget)) { /* Clear any selection */ gtk_editable_select_region(GTK_EDITABLE(entry), entry->current_pos, entry->current_pos); @@ -1553,13 +1562,13 @@ gtk_secure_entry_style_set(GtkWidget * widget, GtkStyle * previous_style) gtk_secure_entry_recompute(entry); - if (previous_style && GTK_WIDGET_REALIZED(widget)) { + if (previous_style && gtk_widget_get_realized(widget)) { gdk_window_set_background(widget->window, &widget->style-> - base[GTK_WIDGET_STATE(widget)]); + base[gtk_widget_get_state(widget)]); gdk_window_set_background(entry->text_area, &widget->style-> - base[GTK_WIDGET_STATE(widget)]); + base[gtk_widget_get_state(widget)]); } } @@ -2026,7 +2035,7 @@ gtk_secure_entry_real_activate(GtkSecureEntry * entry) widget != window->default_widget && !(widget == window->focus_widget && (!window->default_widget - || !GTK_WIDGET_SENSITIVE(window->default_widget)))) + || !gtk_widget_get_sensitive(window->default_widget)))) gtk_window_activate_default(window); } } @@ -2300,7 +2309,7 @@ gtk_secure_entry_create_layout(GtkSecureEntry * entry, pango_dir = pango_find_base_dir(entry->text, entry->n_bytes); if (pango_dir == PANGO_DIRECTION_NEUTRAL) { - if (GTK_WIDGET_HAS_FOCUS(widget)) { + if (gtk_widget_has_focus(widget)) { GdkDisplay *display = gtk_widget_get_display(widget); GdkKeymap *keymap = gdk_keymap_get_for_display(display); pango_dir = gdk_keymap_get_direction(keymap); @@ -2411,7 +2420,7 @@ gtk_secure_entry_draw_text(GtkSecureEntry * entry) if (entry->invisible_char == 0) return; - if (GTK_WIDGET_DRAWABLE(entry)) { + if (gtk_widget_is_drawable((GtkWidget *)entry)) { PangoLayout *layout = gtk_secure_entry_ensure_layout(entry, TRUE); gint x, y; gint start_pos, end_pos; @@ -2445,7 +2454,7 @@ gtk_secure_entry_draw_text(GtkSecureEntry * entry) pango_layout_get_extents(layout, NULL, &logical_rect); - if (GTK_WIDGET_HAS_FOCUS(entry)) { + if (gtk_widget_has_focus((GtkWidget *)entry)) { selection_gc = widget->style->base_gc[GTK_STATE_SELECTED]; text_gc = widget->style->text_gc[GTK_STATE_SELECTED]; } else { @@ -2508,7 +2517,7 @@ gtk_secure_entry_draw_cursor(GtkSecureEntry * entry) (GTK_WIDGET(entry))); PangoDirection keymap_direction = gdk_keymap_get_direction(keymap); - if (GTK_WIDGET_DRAWABLE(entry)) { + if (gtk_widget_is_drawable((GtkWidget *)entry)) { GtkWidget *widget = GTK_WIDGET(entry); GdkRectangle cursor_location; gboolean split_cursor; @@ -2521,7 +2530,12 @@ gtk_secure_entry_draw_cursor(GtkSecureEntry * entry) gint x1 = 0; gint x2 = 0; + +#if GTK_CHECK_VERSION (2, 24, 0) + text_area_height = gdk_window_get_height(entry->text_area); +#else gdk_drawable_get_size(entry->text_area, NULL, &text_area_height); +#endif gtk_secure_entry_get_cursor_locations(entry, &strong_x, &weak_x); @@ -2567,7 +2581,7 @@ gtk_secure_entry_draw_cursor(GtkSecureEntry * entry) static void gtk_secure_entry_queue_draw(GtkSecureEntry * entry) { - if (GTK_WIDGET_REALIZED(entry)) + if (gtk_widget_get_realized((GtkWidget *)entry)) gdk_window_invalidate_rect(entry->text_area, NULL, FALSE); } @@ -2656,10 +2670,14 @@ gtk_secure_entry_adjust_scroll(GtkSecureEntry * entry) PangoLayoutLine *line; PangoRectangle logical_rect; - if (!GTK_WIDGET_REALIZED(entry)) + if (!gtk_widget_get_realized((GtkWidget *)entry)) return; +#if GTK_CHECK_VERSION (2, 24, 0) + text_area_width = gdk_window_get_width(entry->text_area); +#else gdk_drawable_get_size(entry->text_area, &text_area_width, NULL); +#endif text_area_width -= 2 * INNER_BORDER; layout = gtk_secure_entry_ensure_layout(entry, TRUE); @@ -3309,7 +3327,7 @@ cursor_blinks(GtkSecureEntry * entry) GtkSettings *settings = gtk_widget_get_settings(GTK_WIDGET(entry)); gboolean blink; - if (GTK_WIDGET_HAS_FOCUS(entry) && + if (gtk_widget_has_focus((GtkWidget *)entry) && entry->selection_bound == entry->current_pos) { g_object_get(settings, "gtk-cursor-blink", &blink, NULL); return blink; @@ -3334,7 +3352,7 @@ show_cursor(GtkSecureEntry * entry) if (!entry->cursor_visible) { entry->cursor_visible = TRUE; - if (GTK_WIDGET_HAS_FOCUS(entry) + if (gtk_widget_has_focus((GtkWidget *)entry) && entry->selection_bound == entry->current_pos) gtk_widget_queue_draw(GTK_WIDGET(entry)); } @@ -3346,7 +3364,7 @@ hide_cursor(GtkSecureEntry * entry) if (entry->cursor_visible) { entry->cursor_visible = FALSE; - if (GTK_WIDGET_HAS_FOCUS(entry) + if (gtk_widget_has_focus((GtkWidget *)entry) && entry->selection_bound == entry->current_pos) gtk_widget_queue_draw(GTK_WIDGET(entry)); } @@ -3364,14 +3382,14 @@ blink_cb(gpointer data) entry = GTK_SECURE_ENTRY(data); - if (!GTK_WIDGET_HAS_FOCUS(entry)) { + if (!gtk_widget_has_focus((GtkWidget *)entry)) { g_warning ("GtkSecureEntry - did not receive focus-out-event. If you\n" "connect a handler to this signal, it must return\n" "FALSE so the entry gets the event as well"); } - g_assert(GTK_WIDGET_HAS_FOCUS(entry)); + g_assert(gtk_widget_has_focus((GtkWidget *)entry)); g_assert(entry->selection_bound == entry->current_pos); if (entry->cursor_visible) { diff --git a/gtk+-2/pinentry-gtk-2.c b/gtk+-2/pinentry-gtk-2.c index 1a8c083..235bd99 100644 --- a/gtk+-2/pinentry-gtk-2.c +++ b/gtk+-2/pinentry-gtk-2.c @@ -65,7 +65,9 @@ static GtkWidget *qualitybar; static GtkWidget *insure; static GtkWidget *time_out; #endif +#if !GTK_CHECK_VERSION (2, 12, 0) static GtkTooltips *tooltips; +#endif static gboolean got_input; /* Gnome hig small and large space in pixels. */ @@ -127,7 +129,7 @@ make_transient (GtkWidget *win, GdkEvent *event, gpointer data) /* Make window transient for the root window. */ screen = gdk_screen_get_default (); root = gdk_screen_get_root_window (screen); - gdk_window_set_transient_for (win->window, root); + gdk_window_set_transient_for (gtk_widget_get_window(win), root); } @@ -138,7 +140,7 @@ grab_keyboard (GtkWidget *win, GdkEvent *event, gpointer data) if (! pinentry->grab) return FALSE; - if (gdk_keyboard_grab (win->window, FALSE, gdk_event_get_time (event))) + if (gdk_keyboard_grab (gtk_widget_get_window(win), FALSE, gdk_event_get_time (event))) { g_critical ("could not grab keyboard"); grab_failed = 1; @@ -157,7 +159,7 @@ ungrab_keyboard (GtkWidget *win, GdkEvent *event, gpointer data) /* gdk_window_set_transient_for cannot be used with parent = NULL to unset transient hint (unlike gtk_ version which can). Replacement code is taken from gtk_window_transient_parent_unrealized. */ - gdk_property_delete (win->window, + gdk_property_delete (gtk_widget_get_window(win), gdk_atom_intern_static_string ("WM_TRANSIENT_FOR")); return FALSE; } @@ -330,7 +332,9 @@ create_window (int confirm_mode) GtkAccelGroup *acc; gchar *msg; +#if !GTK_CHECK_VERSION (2, 12, 0) tooltips = gtk_tooltips_new (); +#endif /* FIXME: check the grabbing code against the one we used with the old gpg-agent */ @@ -471,8 +475,12 @@ create_window (int confirm_mode) QUALITYBAR_EMPTY_TEXT); gtk_progress_bar_set_fraction (GTK_PROGRESS_BAR (qualitybar), 0.0); if (pinentry->quality_bar_tt) +#if !GTK_CHECK_VERSION (2, 12, 0) gtk_tooltips_set_tip (GTK_TOOLTIPS (tooltips), qualitybar, pinentry->quality_bar_tt, ""); +#else + gtk_widget_set_tooltip_text (qualitybar, pinentry->quality_bar_tt); +#endif gtk_table_attach (GTK_TABLE (table), qualitybar, 1, 2, nrow, nrow+1, GTK_EXPAND|GTK_FILL, GTK_EXPAND|GTK_FILL, 0, 0); nrow++; @@ -561,7 +569,7 @@ create_window (int confirm_mode) G_CALLBACK (confirm_mode ? confirm_button_clicked : button_clicked), (gpointer) CONFIRM_CANCEL); - GTK_WIDGET_SET_FLAGS (w, GTK_CAN_DEFAULT); + gtk_widget_set_can_default (w, TRUE); } if (confirm_mode && !pinentry->one_button && pinentry->notok) @@ -574,7 +582,7 @@ create_window (int confirm_mode) g_signal_connect (G_OBJECT (w), "clicked", G_CALLBACK (confirm_button_clicked), (gpointer) CONFIRM_NOTOK); - GTK_WIDGET_SET_FLAGS (w, GTK_CAN_DEFAULT); + gtk_widget_set_can_default (w, TRUE); } if (pinentry->ok) @@ -602,7 +610,7 @@ create_window (int confirm_mode) { g_signal_connect (G_OBJECT (w), "clicked", G_CALLBACK (button_clicked), "ok"); - GTK_WIDGET_SET_FLAGS (w, GTK_CAN_DEFAULT); + gtk_widget_set_can_default (w, TRUE); gtk_widget_grab_default (w); g_signal_connect_object (G_OBJECT (entry), "focus_in_event", G_CALLBACK (gtk_widget_grab_default), @@ -613,7 +621,7 @@ create_window (int confirm_mode) g_signal_connect (G_OBJECT (w), "clicked", G_CALLBACK(confirm_button_clicked), (gpointer) CONFIRM_OK); - GTK_WIDGET_SET_FLAGS (w, GTK_CAN_DEFAULT); + gtk_widget_set_can_default (w, TRUE); } gtk_window_set_position (GTK_WINDOW (win), GTK_WIN_POS_CENTER); -- 2.1.0 From wk at gnupg.org Thu Nov 6 10:01:51 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 06 Nov 2014 10:01:51 +0100 Subject: [Announce] GnuPG 2.1.0 "modern" released Message-ID: <87ioisn1mo.fsf@vigenere.g10code.de> Hello! The GnuPG Project is pleased to announce the availability of a new release: Version 2.1.0. The GNU Privacy Guard (GnuPG) is a complete and free implementation of the OpenPGP standard as defined by RFC-4880 and better known as PGP. GnuPG, also known as GPG, allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries making use of GnuPG are available. Since version 2 GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Three different versions of GnuPG are actively maintained: - GnuPG "modern" (2.1) is the latest development with a lot of new features. This announcement is about the first release of this version. - GnuPG "stable" (2.0) is the current stable version for general use. This is what most users are currently using. - GnuPG "classic" (1.4) is the old standalone version which is most suitable for older or embedded platforms. You may not install "modern" (2.1) and "stable" (2.0) at the same time. However, it is possible to install "classic" (1.4) along with any of the other versions. What's New in GnuPG-2.1 ======================= - The file "secring.gpg" is not anymore used to store the secret keys. Merging of secret keys is now supported. - All support for PGP-2 keys has been removed for security reasons. - The standard key generation interface is now much leaner. This will help a new user to quickly generate a suitable key. - Support for Elliptic Curve Cryptography (ECC) is now available. - Commands to create and sign keys from the command line without any extra prompts are now available. - The Pinentry may now show the new passphrase entry and the passphrase confirmation entry in one dialog. - There is no more need to manually start the gpg-agent. It is now started by any part of GnuPG as needed. - Problems with importing keys with the same long key id have been addressed. - The Dirmngr is now part of GnuPG proper and also takes care of accessing keyserver. - Keyserver pools are now handled in a smarter way. - A new format for locally storing the public keys is now used. This considerable speeds up operations on large keyrings. - Revocation certificates are now created by default. - Card support has been updated, new readers and token types are supported. - The format of the key listing has been changed to better identify the properties of a key. - The gpg-agent may now be used on Windows as a Pageant replacement for Putty in the same way it is used for years on Unix as ssh-agent replacement. - Creation of X.509 certificates has been improved. It is now also possible to export them directly in PKCS#8 and PEM format for use on TLS servers. A detailed description of the changes can be found at https://gnupg.org/faq/whats-new-in-2.1.html . Getting the Software ==================== Please follow the instructions found at https://gnupg.org/download/ or read on: GnuPG 2.1.0 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at https://gnupg.org/mirrors.html . Note that GnuPG is not available at ftp.gnu.org. On ftp.gnupg.org you find these files: ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.0.tar.bz2 (3039k) ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.0.tar.bz2.sig This is the GnuPG 2.1 source code compressed using BZIP2 and its OpenPGP signature. ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.0_20141105.exe (6225k) ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.0_20141105.exe.sig This is an experimental installer for Windows including GPA as graphical key manager and GpgEX as an Explorer extension. Please de-install an already installed Gpg4win version before trying this installer. This binary version has not been tested very well, thus it is likely that you will run into problems. The complete source code for the software included in this installer is in the same directory; use the suffix ".tar.xz" instead of ".exe". Although several beta versions have been released over the course of the last years, no extensive public field test has been done. Thus it is likely that bugs will show up. Please check the mailing list archives and the new wiki https://wiki.gnupg.org for latest information on known problems and workaround. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.1.0.tar.bz2 you would use this command: gpg --verify gnupg-2.1.0.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See below for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.1.0.tar.bz2, you would run the command like this: sha1sum gnupg-2.1.0.tar.bz2 and check that the output matches the first line from the following list: 2fcd0ca6889ef6cb59e3275e8411f8b7778c2f33 gnupg-2.1.0.tar.bz2 9907cb6509a0e63331b27a92e25c1ef956caaf3b gnupg-w32-2.1.0_20141105.exe 28dc1365292c61fbb2bbae730d4158f425463c91 gnupg-w32-2.1.0_20141105.tar.xz Release Signing Keys ==================== To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: 2048R/4F25E3B6 2011-01-12 Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048/E0856959 2014-10-29 Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048/33BD3F06 2014-10-29 Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa2048/7EFD60D9 2014-10-19 Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 Werner Koch (Release Signing Key) You may retrieve these files from the keyservers using this command gpg --recv-keys 249B39D24F25E3B6 04376F3EE0856959 \ 2071B08A33BD3F06 8A861B1C7EFD60D9 The keys are also available at https://gnupg.org/signature_key.html and in the released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed using my standard PGP key. Internationalization ==================== This new branch of GnuPG has support for 4 languages: French, German, Japanese, and Ukrainian. More translations can be expected with the next point releases. Documentation ============= If you used GnuPG in the past you should read the description of changes and new features at doc/whats-new-in-2.1.txt or online at https://gnupg.org/faq/whats-new-in-2.1.html The file gnupg.info has the complete user manual of the system. Separate man pages are included as well but they have not all the details available in the manual. It is also possible to read the complete manual online in HTML format at https://gnupg.org/documentation/manuals/gnupg/ or in Portable Document Format at https://gnupg.org/documentation/manuals/gnupg.pdf . The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. You may also want search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. Support ======= Please consult the archive of the gnupg-users mailing list before reporting a bug . We suggest to send bug reports for a new release to this list in favor of filing a bug at . For commercial support requests we keep a list of known service companies at: https://gnupg.org/service.html The driving force behind the development of GnuPG is the company of its principal author, Werner Koch. Maintenance and improvement of GnuPG and related software takes up most of their resources. To allow him to continue this work he kindly asks to either purchase a support contract, engage g10 Code for custom enhancements, or to donate money: https://gnupg.org/donate/ Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. A final big Thank You goes to Hal Finney, who too early passed away this year. Hal worked on PGP and helped to make OpenPGP a great standard; it has been a pleasure having worked with him. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From nicholas.cole at gmail.com Thu Nov 6 12:18:48 2014 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Thu, 6 Nov 2014 11:18:48 +0000 Subject: [Announce] GnuPG 2.1.0 "modern" released In-Reply-To: <87ioisn1mo.fsf@vigenere.g10code.de> References: <87ioisn1mo.fsf@vigenere.g10code.de> Message-ID: Hi Werner, Building on OS X using make -f build-aux/speedo.mk native INSTALL_DIR=/usr/local gets what looks like most of the way and then fails with the error shown below. Am I the only person experiencing this, or are others hitting the same problem? Best wishes, N. Undefined symbols for architecture x86_64: "_default_errsource", referenced from: _parse_ber_header in libcommon.a(libcommon_a-tlv.o) _parse_sexp in libcommon.a(libcommon_a-tlv.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[5]: *** [t-sexputil] Error 1 make[5]: *** Waiting for unfinished jobs.... make[4]: *** [all] Error 2 make[3]: *** [all-recursive] Error 1 make[2]: *** [all] Error 2 make[1]: *** [/Users/nicholas/Downloads/gnupg-2.1.0/PLAY/stamps/stamp-gnupg-02-make] Error 2 make: *** [native] Error 2 On Thu, Nov 6, 2014 at 9:01 AM, Werner Koch wrote: > Hello! > > The GnuPG Project is pleased to announce the availability of a > new release: Version 2.1.0. > > The GNU Privacy Guard (GnuPG) is a complete and free implementation of > the OpenPGP standard as defined by RFC-4880 and better known as PGP. > > GnuPG, also known as GPG, allows to encrypt and sign data and > communication, features a versatile key management system as well as > access modules for public key directories. GnuPG itself is a command > line tool with features for easy integration with other applications. > A wealth of frontend applications and libraries making use of GnuPG > are available. Since version 2 GnuPG provides support for S/MIME and > Secure Shell in addition to OpenPGP. > > GnuPG is Free Software (meaning that it respects your freedom). It can > be freely used, modified and distributed under the terms of the GNU > General Public License. > > Three different versions of GnuPG are actively maintained: > > - GnuPG "modern" (2.1) is the latest development with a lot of new > features. This announcement is about the first release of this > version. > > - GnuPG "stable" (2.0) is the current stable version for general use. > This is what most users are currently using. > > - GnuPG "classic" (1.4) is the old standalone version which is most > suitable for older or embedded platforms. > > You may not install "modern" (2.1) and "stable" (2.0) at the same > time. However, it is possible to install "classic" (1.4) along with > any of the other versions. > > > What's New in GnuPG-2.1 > ======================= > > - The file "secring.gpg" is not anymore used to store the secret > keys. Merging of secret keys is now supported. > > - All support for PGP-2 keys has been removed for security reasons. > > - The standard key generation interface is now much leaner. This > will help a new user to quickly generate a suitable key. > > - Support for Elliptic Curve Cryptography (ECC) is now available. > > - Commands to create and sign keys from the command line without any > extra prompts are now available. > > - The Pinentry may now show the new passphrase entry and the > passphrase confirmation entry in one dialog. > > - There is no more need to manually start the gpg-agent. It is now > started by any part of GnuPG as needed. > > - Problems with importing keys with the same long key id have been > addressed. > > - The Dirmngr is now part of GnuPG proper and also takes care of > accessing keyserver. > > - Keyserver pools are now handled in a smarter way. > > - A new format for locally storing the public keys is now used. > This considerable speeds up operations on large keyrings. > > - Revocation certificates are now created by default. > > - Card support has been updated, new readers and token types are > supported. > > - The format of the key listing has been changed to better identify > the properties of a key. > > - The gpg-agent may now be used on Windows as a Pageant replacement > for Putty in the same way it is used for years on Unix as > ssh-agent replacement. > > - Creation of X.509 certificates has been improved. It is now also > possible to export them directly in PKCS#8 and PEM format for use > on TLS servers. > > A detailed description of the changes can be found at > https://gnupg.org/faq/whats-new-in-2.1.html . > > > Getting the Software > ==================== > > Please follow the instructions found at https://gnupg.org/download/ or > read on: > > GnuPG 2.1.0 may be downloaded from one of the GnuPG mirror sites or > direct from its primary FTP server. The list of mirrors can be found > at https://gnupg.org/mirrors.html . Note that GnuPG is not available > at ftp.gnu.org. > > On ftp.gnupg.org you find these files: > > ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.0.tar.bz2 (3039k) > ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.0.tar.bz2.sig > > This is the GnuPG 2.1 source code compressed using BZIP2 and its > OpenPGP signature. > > ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.0_20141105.exe (6225k) > ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.0_20141105.exe.sig > > This is an experimental installer for Windows including GPA as > graphical key manager and GpgEX as an Explorer extension. Please > de-install an already installed Gpg4win version before trying this > installer. This binary version has not been tested very well, thus it > is likely that you will run into problems. The complete source code > for the software included in this installer is in the same directory; > use the suffix ".tar.xz" instead of ".exe". > > Although several beta versions have been released over the course of > the last years, no extensive public field test has been done. Thus it > is likely that bugs will show up. Please check the mailing list > archives and the new wiki https://wiki.gnupg.org for latest > information on known problems and workaround. > > > Checking the Integrity > ====================== > > In order to check that the version of GnuPG which you are going to > install is an original and unmodified one, you can do it in one of > the following ways: > > * If you already have a version of GnuPG installed, you can simply > verify the supplied signature. For example to verify the signature > of the file gnupg-2.1.0.tar.bz2 you would use this command: > > gpg --verify gnupg-2.1.0.tar.bz2.sig > > This checks whether the signature file matches the source file. > You should see a message indicating that the signature is good and > made by one or more of the release signing keys. Make sure that > this is a valid key, either by matching the shown fingerprint > against a trustworthy list of valid release signing keys or by > checking that the key has been signed by trustworthy other keys. > See below for information on the signing keys. > > * If you are not able to use an existing version of GnuPG, you have > to verify the SHA-1 checksum. On Unix systems the command to do > this is either "sha1sum" or "shasum". Assuming you downloaded the > file gnupg-2.1.0.tar.bz2, you would run the command like this: > > sha1sum gnupg-2.1.0.tar.bz2 > > and check that the output matches the first line from the > following list: > > 2fcd0ca6889ef6cb59e3275e8411f8b7778c2f33 gnupg-2.1.0.tar.bz2 > 9907cb6509a0e63331b27a92e25c1ef956caaf3b gnupg-w32-2.1.0_20141105.exe > 28dc1365292c61fbb2bbae730d4158f425463c91 gnupg-w32-2.1.0_20141105.tar.xz > > > Release Signing Keys > ==================== > > To guarantee that a downloaded GnuPG version has not been tampered by > malicious entities we provide signature files for all tarballs and > binary versions. The keys are also signed by the long term keys of > their respective owners. Current releases are signed by one or more > of these four keys: > > 2048R/4F25E3B6 2011-01-12 > Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 > Werner Koch (dist sig) > > rsa2048/E0856959 2014-10-29 > Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 > David Shaw (GnuPG Release Signing Key) > > rsa2048/33BD3F06 2014-10-29 > Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 > NIIBE Yutaka (GnuPG Release Key) > > rsa2048/7EFD60D9 2014-10-19 > Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 > Werner Koch (Release Signing Key) > > You may retrieve these files from the keyservers using this command > > gpg --recv-keys 249B39D24F25E3B6 04376F3EE0856959 \ > 2071B08A33BD3F06 8A861B1C7EFD60D9 > > The keys are also available at https://gnupg.org/signature_key.html > and in the released GnuPG tarball in the file g10/distsigkey.gpg . > Note that this mail has been signed using my standard PGP key. > > > Internationalization > ==================== > > This new branch of GnuPG has support for 4 languages: French, German, > Japanese, and Ukrainian. More translations can be expected with the > next point releases. > > > Documentation > ============= > > If you used GnuPG in the past you should read the description of > changes and new features at doc/whats-new-in-2.1.txt or online at > > https://gnupg.org/faq/whats-new-in-2.1.html > > The file gnupg.info has the complete user manual of the system. > Separate man pages are included as well but they have not all the > details available in the manual. It is also possible to read the > complete manual online in HTML format at > > https://gnupg.org/documentation/manuals/gnupg/ > > or in Portable Document Format at > > https://gnupg.org/documentation/manuals/gnupg.pdf . > > The chapters on gpg-agent, gpg and gpgsm include information on how > to set up the whole thing. You may also want search the GnuPG mailing > list archives or ask on the gnupg-users mailing lists for advise on > how to solve problems. Many of the new features are around for > several years and thus enough public knowledge is already available. > > > Support > ======= > > Please consult the archive of the gnupg-users mailing list before > reporting a bug . > We suggest to send bug reports for a new release to this list in favor > of filing a bug at . For commercial support > requests we keep a list of known service companies at: > > https://gnupg.org/service.html > > The driving force behind the development of GnuPG is the company of > its principal author, Werner Koch. Maintenance and improvement of > GnuPG and related software takes up most of their resources. To allow > him to continue this work he kindly asks to either purchase a support > contract, engage g10 Code for custom enhancements, or to donate money: > > https://gnupg.org/donate/ > > > Thanks > ====== > > We have to thank all the people who helped with this release, be it > testing, coding, translating, suggesting, auditing, administering the > servers, spreading the word, and answering questions on the mailing > lists. A final big Thank You goes to Hal Finney, who too early passed > away this year. Hal worked on PGP and helped to make OpenPGP a great > standard; it has been a pleasure having worked with him. > > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > _______________________________________________ > Gnupg-announce mailing list > Gnupg-announce at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-announce > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From jeanjacquesbrucker at gmail.com Thu Nov 6 12:10:22 2014 From: jeanjacquesbrucker at gmail.com (jbar) Date: Thu, 6 Nov 2014 12:10:22 +0100 Subject: [Bug][gpgme] mess with file descriptors Message-ID: <20141106121022.145b6985@aixplorer> I have meet strange behaviour of gpgme when having a listenning socket on the STDOUT_FILENO(=1) file descriptor. Can gpgpme not mess with file descriptors used by the calling program, or like syslog with openlog(), create one when calling gpgme_new() and use only it with the gpgpme context created ? My app is thttpgd which is linked to libgpgme-pthread, this is an HTTP and HKP server which may sign on-the-fly its HTTP responses*. U may try for example : - on an HKP request: $ curl -v -H "Accept: multipart/msigned" \ "http://node1.openudc.org/pks/lookup?search=brucker" - on a standard file: $ curl -v -H "Accept: multipart/msigned" \ "http://node1.openudc.org/_open-udc%40muc.jappix.com_/2014/11/06.txt" This thttpgpd (version 0.3.5) server is linked with libgpgme11_1.2.0-1.4+deb7u1. And you may see that concerning the second requests, such strange GNUPG trace are included in the gpgme_data_t containing the signature : [GNUPG:] GOOD_PASSPHRASE [GNUPG:] PROGRESS -&6 ? 0 0 [GNUPG:] BEGIN_SIGNING [GNUPG:] PROGRESS -&6 ? 602 0 [GNUPG:] SIG_CREATED D 1 2 00 1415269682 53D97DACE2B01EAB4409418E9007C80B71361973 When linking the same thttpgpd (version 0.3.5 and lower) with libgpgme11_1.3.0 and greater (I did try different versions of gpgpme, compiled from different tag on your git sources), the second request didn't sign at all. Technically: the call to gpgme_op_sign() in my httpd_parse_resp(), did return an error, and gpgme_strerror() said "General Error". (If you build my thttpgpd software to test all yourself, take care to (clean) the signature's cache used for regular files.) I found a workaround to that bug, by assigning the STDOUT_FILENO fd (the n?1) to /dev/null, instead of closing it and so using it later for a listening socket. https://github.com/Open-UDC/thttpgpd/commit/e07fd56d7b5364d658a951688e41bfa295cd0bf5#diff-eac80394dcd9b3636b0c8a47e128d1e6 (I did also assigning STDERR_FILENO to /dev/null, just in case, even if I didn't notice it changed gpgme's behaviour). But I do think it seems there is a vicious bug in gpgme, or a lack of documentation to make gpgme user's avoid such bug. In the documentation maybe can you also cite now GPGME_DEBUG environment variable and that STDERR_FILENO is used to display TRACEs when GPGME_DEBUG > 0. :-) To finish, i hope i am not out-of-topic, but BIG CONGRATULATION for GnuPG 2.1.0 ! ^^ ^ _...._ ^ .' '. _...._ ^ / \' '. |X / \ -. \ |X | ^ .-. |'.-. .' \ / \;/ `/\` '. .' / \ ( `/\` / \ \ ^ `) ^ / \ ) ( ^ /'-...-'\ ( \ /-.__ __.-\ ) jgs '._ ` _.' ^ / `"""""` ----------------------------------------------------- _ .-. / ) .-. ___ __ ( ) ( ( ( ) .'___) (__'-._) ( \ '._) (,'.' '. '-. '. / "\ ' -. '. ) / \ \ .-. ,'. ) ( ',_) _ .' ( \ \ ( \ . .' .' ) .-. ( \ ( .''. '. \ \| .' .' ,',--, / ( ) ) ) \ \ ', : \ .-' ( ( ( ( _) (,' / \ \ : : ) / _ ' . \ \ ,' / ,' ,' : ; / /,' '. /.' / / ( (\ ( '.' " ( .-'. \ '' \_)\ \ \ | \ \__ ) ) ___\ | \___; / , / / ___) ( ( ( PN '.' ) ;) ; (_/(_/ ---------------------------------------------------- Notes: * I plan also to implement OpenPGP HTTP authentication, as specified in this draft : https://raw.githubusercontent.com/Open-UDC/open-udc/master/docs/HTTP_OpenPGP_Authentication.draft.txt -- Jean-Jacques BRUCKER -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 316 bytes Desc: not available URL: From wk at gnupg.org Thu Nov 6 15:55:59 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 06 Nov 2014 15:55:59 +0100 Subject: [Bug][gpgme] mess with file descriptors In-Reply-To: <20141106121022.145b6985@aixplorer> (jbar's message of "Thu, 6 Nov 2014 12:10:22 +0100") References: <20141106121022.145b6985@aixplorer> Message-ID: <8761esjs3k.fsf@vigenere.g10code.de> Hi, can you please explain what you are doing. Best with some code. On Thu, 6 Nov 2014 12:10, jeanjacquesbrucker at gmail.com said: > I found a workaround to that bug, by assigning the STDOUT_FILENO fd > (the n?1) to /dev/null, instead of closing it and so using it later for > a listening socket. It is not a good idea to re-use the standard sockets. See this comment from GnuPG: /* Make sure that the standard file descriptors are opened. Obviously some folks close them before an exec and the next file we open will get one of them assigned and thus any output (i.e. diagnostics) end up in that file (e.g. the trustdb). Not actually a gpg problem as this will hapen with almost all utilities when called in a wrong way. However we try to minimize the damage here and raise awareness of the problem. Must be called before we open any files! */ > In the documentation maybe can you also cite now GPGME_DEBUG > environment variable and that STDERR_FILENO is used to display TRACEs > when GPGME_DEBUG > 0. :-) That is for what stderr is there. But okay, I add a comment. > To finish, i hope i am not out-of-topic, but BIG CONGRATULATION for > GnuPG 2.1.0 ! ^^ No. Thanks. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Nov 6 17:48:06 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 06 Nov 2014 17:48:06 +0100 Subject: [Announce] GnuPG 2.1.0 "modern" released In-Reply-To: ("Ville =?utf-8?B?TcOkw6R0dMOkIidz?= message of "Thu, 6 Nov 2014 16:14:57 +0200") References: <87ioisn1mo.fsf@vigenere.g10code.de> Message-ID: <87k338gtrt.fsf@vigenere.g10code.de> On Thu, 6 Nov 2014 15:14, mailing-lists at asatiifm.net said: > Undefined symbols for architecture x86_64: > "_default_errsource", referenced from: OS X ? Such a problem has already bee posted today. I have no access to OS X and thus can't help much. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Thu Nov 6 20:54:06 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 06 Nov 2014 14:54:06 -0500 Subject: autoreconf from tarballs produces beta Message-ID: <878ujortpd.fsf@alice.fifthhorseman.net> hi GnuPG folks-- As i review the gnupg 2.1.0 packaging in preparation for an upload to debian, i notice that using autoreconf against the source as distributed in tarball form invariably results in a package that thinks it's a "beta" package, which produces the "THIS IS A DEVELOPMENT VERSION" warning string. This beta indication comes from the test for the presence of .git in ./autogen.sh, which sets beta=yes if there is no .git directory. One common debian packaging practice is to use autoreconf during the build to take advantage of any improvements or fixes in the debian autotools chain that may not have been present on the system that created the tarball. (though i understand that there are autotools versioning constraints for gnupg, and we're sticking with the 1.11 autotools version for now) I plan to apply the following simple patch to autogen.sh so that debian package doesn't present itself as a beta: diff --git a/autogen.sh b/autogen.sh index 7effd56..5e8ca15 100755 --- a/autogen.sh +++ b/autogen.sh @@ -228,8 +228,8 @@ if [ "$myhost" = "find-version" ]; then rvd=$((0x$(echo ${rev} | head -c 4))) else ingit=no - beta=yes - tmp="-unknown" + beta=no + tmp="" rev="0000000" rvd="0" fi I don't know whether that's something that you want applied upstream as well or not (or if you want people building from the tarball to by default create versions that announce themselves as development versions if they run autoreconf). Anyway, i wanted to pass this on so that you're aware of the issue. If you see a problem with us doing that in debian, please let me know. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From dkg at fifthhorseman.net Thu Nov 6 23:39:09 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 06 Nov 2014 17:39:09 -0500 Subject: large keyring refresh fails with gpg 2.1.0: "Too many objects" Message-ID: <8761esrm2a.fsf@alice.fifthhorseman.net> hi GnuPG folks-- I have a large keyring with 2.5K OpenPGP keys in it. With GnuPG 2.0.x and 1.4.x, i am able to refresh the whole thing with: gpg --refresh with 2.1.0, that command produces this error: gpg: refreshing 2532 keys from hkp://keys.gnupg.net gpg: keyserver refresh failed: Too many objects I could use a tool like parcimonie [0] to refresh them one at a time, in the background, but that takes even longer. in some contexts, it would be nice to just have a single, full refresh happen as fast as possible. Is there a recommended way to refresh all the keys from a large keyring like this, or at least to conveniently chunk the requests into an acceptable number of objects at a time? --dkg [0] https://gaffer.ptitcanardnoir.org/intrigeri/code/parcimonie/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From chdiza at gmail.com Fri Nov 7 00:02:13 2014 From: chdiza at gmail.com (Charles Diza) Date: Thu, 6 Nov 2014 18:02:13 -0500 Subject: [Announce] GnuPG 2.1.0 "modern" released In-Reply-To: References: <87ioisn1mo.fsf@vigenere.g10code.de> Message-ID: On Thu, Nov 6, 2014 at 6:18 AM, Nicholas Cole wrote: > Hi Werner, > > Building on OS X using > > make -f build-aux/speedo.mk native INSTALL_DIR=/usr/local > > gets what looks like most of the way and then fails with the error > shown below. Am I the only person experiencing this, or are others > hitting the same problem? > > Best wishes, > > N. > This is AFAICT the exact error I reported a while back (though I did not try build with speedo because it required gpg1 package to be installed). There was no resolution. Cheers, Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Fri Nov 7 10:38:54 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 07 Nov 2014 10:38:54 +0100 Subject: autoreconf from tarballs produces beta In-Reply-To: <878ujortpd.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 06 Nov 2014 14:54:06 -0500") References: <878ujortpd.fsf@alice.fifthhorseman.net> Message-ID: <877fz7fiz5.fsf@vigenere.g10code.de> On Thu, 6 Nov 2014 20:54, dkg at fifthhorseman.net said: > This beta indication comes from the test for the presence of .git in > ./autogen.sh, which sets beta=yes if there is no .git directory. Well, if the release tag can't be found what shall we do - beta seems to better than claiming it is the "real release" If you want your own version numbers you need to chnage some more parts. > One common debian packaging practice is to use autoreconf during the I never use autroreconf because it introduces too many variants into the build process. Better live with the autoconf file present in the repo and update them only once in a while. If your concern is config.{guess,sub} et al. you may manuallay update them. I do this from time to time and try to make sure that all GnuypG related packages use the same version. > I plan to apply the following simple patch to autogen.sh so that debian > package doesn't present itself as a beta: Okay, should work. I would still suggest to use the tarball and apply the patches on top of the tarball. There should be no need to run autoconf - but well, if it is a Debian decision it is up to you. > I don't know whether that's something that you want applied upstream as > well or not (or if you want people building from the tarball to by Definitely not. autotools are maintainer only and are not expected to be run for build. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Nov 7 11:17:46 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 07 Nov 2014 11:17:46 +0100 Subject: large keyring refresh fails with gpg 2.1.0: "Too many objects" In-Reply-To: <8761esrm2a.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 06 Nov 2014 17:39:09 -0500") References: <8761esrm2a.fsf@alice.fifthhorseman.net> Message-ID: <87389vfh6d.fsf@vigenere.g10code.de> On Thu, 6 Nov 2014 23:39, dkg at fifthhorseman.net said: > gpg: refreshing 2532 keys from hkp://keys.gnupg.net > gpg: keyserver refresh failed: Too many objects This exhibits two problems: The way refresh works without user ids given: - Walk over the keyring and create a list of all keyids. - Show the number of keys to refresh ;-) - Use the standard keyserver_get to retrieve all keys, which is: - Walk over the list of search descriptions where there is one entry for each key and build a KS_GET command to send to dirmngr from that list. The first is that we store all keyids in an array - that is something which should be avoided. However, that is how it hasl always worked. The second is a regression. We need to split the KS_GET command lines send to dirmngr up into chunks so that they will make it through the Assuan interface. GnuPG-bug-id: 1755 Thanks, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From Jason at zx2c4.com Fri Nov 7 15:04:28 2014 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Fri, 7 Nov 2014 15:04:28 +0100 Subject: Curve25519 for Encryption and Signing? Message-ID: Hi folks, I wasn't able to create a Curve25519 key for both signing and encryption in the most recent 2.1.0. Is there a reason for this? Is it not possible to have a dual ECDH/EdDSA? Or is it still under development and simply not yet implemented? Thanks, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jason at zx2c4.com Fri Nov 7 15:16:44 2014 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Fri, 7 Nov 2014 15:16:44 +0100 Subject: Curve25519 for Encryption and Signing? In-Reply-To: References: Message-ID: Hi folks, I wasn't able to create a Curve25519 key for both signing and encryption in the most recent 2.1.0. Is there a reason for this? Is it not possible to have a dual ECDH/EdDSA? Or is it still under development and simply not yet implemented? Thanks, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From kristian.fiskerstrand at sumptuouscapital.com Fri Nov 7 16:38:32 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 07 Nov 2014 16:38:32 +0100 Subject: Curve25519 for Encryption and Signing? In-Reply-To: References: Message-ID: <545CE778.6050107@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/07/2014 03:16 PM, Jason A. Donenfeld wrote: > Hi folks, > Hi, > I wasn't able to create a Curve25519 key for both signing and > encryption in the most recent 2.1.0. Is there a reason for this? Is > it not possible to have a dual ECDH/EdDSA? Or is it still under > development and simply not yet implemented? Ed25519 is only for signatures, for encryption the only ECC alternatives at this point are those mentioned in RFC6637, i.e. the NIST, brainpool (and actually serpent that is not mentioned in the rfc) - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Carpe noctem Seize the night -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUXOd3AAoJEPw7F94F4TagAbkP/1Kle8OcbWlhoPWDA3G9YU16 ym6tmmdRvA7dzXMhOwRHQHx4qLKEwlvGhgk1ElzoIsvFdoI0wrl61V5BWHYZDfQN vT3icVhAsni1B7mpfs0Y9PUo6XwN48V1IaBmfBIjexB+K88SkTgo65PTIzJ52yf1 EZbncHmrHyoQIikR7O33vu5tvcBhcp3GCvGRkZbm0/Gymvdji49kBx/BCu/ARRIh T8dE+Zq9SfMhU8xcOP5SwLueCIJp5jj5LIbyRbPkJeYQqw5RtEUDkFjxH7nXKuyq H9PSc3kIMoay6o27X+Lwdg3huVAZRT11yCZwrPk80uz3Ss61iHJMdZ2dw5FZtUhi gydcGD5ppy6gIegHctAu4d4zfVQ4qUhE5dX5GftQhzMWVkC1L0Fy/SqD+cAvrvsj hUBvl3ZOPbX+kzJEeg97S5PnErTZHtHDJDj/V76R5ezV3WdKCVaZPBcVtRr8jzkb L1PSsRjTASZN6N5u22smuhqKWyhTRRMpgpsjKJlNmCzwHy9M73saTLqPHdWw5itj Z471oaO09q0lF6aOC9LyYqyj4LrVXa5xb+jNUqsE4ekAMzwuxg0iJxZdSC4/cHQO zvwQHvg/viQYpb6uB9oQ2SwQHUrIX0fl8hWNScuc2P3PKkHmYQNMtY+XY87aVaLV DOaAC8WigVVmtVdhN4xN =RdZG -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Fri Nov 7 16:46:20 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 07 Nov 2014 10:46:20 -0500 Subject: Curve25519 for Encryption and Signing? In-Reply-To: References: Message-ID: <545CE94C.10706@fifthhorseman.net> On 11/07/2014 09:04 AM, Jason A. Donenfeld wrote: > I wasn't able to create a Curve25519 key for both signing and encryption in > the most recent 2.1.0. Is there a reason for this? Is it not possible to > have a dual ECDH/EdDSA? Or is it still under development and simply not yet > implemented? GnuPG currently implements Curve25519 for signing and authentication, but not for encryption. There has been no consensus on how Curve25519 encryption would be structured on the wire, so it's likely to take a little longer to get that capability in place. Discussions about how to implement hybrid encryption using Curve25519 should probably take place on openpgp at ietf.org, though if you want to propose patches for GnuPG specifically, this is the right mailing list -- the community here can probably also help flesh out functional patches into clearer documentation to promote interoperability. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Fri Nov 7 17:58:39 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 07 Nov 2014 17:58:39 +0100 Subject: Curve25519 for Encryption and Signing? In-Reply-To: (Jason A. Donenfeld's message of "Fri, 7 Nov 2014 15:04:28 +0100") References: Message-ID: <87y4rnc5hc.fsf@vigenere.g10code.de> On Fri, 7 Nov 2014 15:04, Jason at zx2c4.com said: > Hi folks, > > I wasn't able to create a Curve25519 key for both signing and encryption in > the most recent 2.1.0. Is there a reason for this? Is it not possible to > have a dual ECDH/EdDSA? Or is it still under development and simply not yet > implemented? See the second paragraph at https://gnupg.org/faq/whats-new-in-2.1.html#ecc You may of course create an EdDSA primary key and the use "gpg --edit-key" to an an NIST or Brainpool ECDH encryption key. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From johans at stack.nl Fri Nov 7 16:10:04 2014 From: johans at stack.nl (Johan van Selst) Date: Fri, 7 Nov 2014 16:10:04 +0100 Subject: Curve25519 for Encryption and Signing? In-Reply-To: References: Message-ID: <20141107151004.GA70195@stack.nl> Jason A. Donenfeld wrote: > I wasn't able to create a Curve25519 key for both signing and encryption in > the most recent 2.1.0. Is there a reason for this? Is it not possible to > have a dual ECDH/EdDSA? Or is it still under development and simply not yet > implemented? Quoting from https://www.gnupg.org/faq/whats-new-in-2.1.html GnuPG 2.1.0 already comes with support for signing keys using the Ed25519 variant of this curve. [..] The format for an encryption key has not yet been finalized and will be added to GnuPG in one of the next point releases. Recall that an encryption subkey can be added to a key at any time. Regards, Johan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From dkg at fifthhorseman.net Sat Nov 8 00:24:15 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 07 Nov 2014 18:24:15 -0500 Subject: ownertrust database cleared on gpg 2.1 key import Message-ID: <87tx2ar3vk.fsf@alice.fifthhorseman.net> hi GnuPG folks-- It looks to me like gpg 2.1.0 is clearing parts of the ownertrust database when used with the same homedir as 1.4.x. There may be other circumstances where ownertrust is cleared as well. Consider a user who starts with a conversion to 2.1.0 over keys for Alice and Bob. so ~/.gnupg/.gpg-v21-migrated is present. Then the user ("Ed") creates a new key for himself with gpg 1.4, and imports keys for Carol and David (also with gpg 1.4). The user (still using 1.4) signs Carol and Bob's keys, and marks Carol with full ownertrust, and Bob with marginal ownertrust. at this point, gpg 1.4 knows the ownertrustdb looks like this: $BOB:4: $CAROL:5: $ED:6: But now the user tries to use gpg2, which only knows about Alice and Bob's keys. As a result, the user imports the keys: gpg --export | gpg2 --import In doing this, gpg2 appears to actively clear the ownertrust values for Carol and Ed's keys, leaving the user with no ultimately-trusted keys in either version of gpg, 2.1 or 1.4. This is particularly troubling, because: (a) it's difficult to notice that the trustdb has changed -- it's not an obvious scenario, and users can go hours or days without being aware that something is wrong. and (b) Even if the user is aware of it, older versions of the trustdb do not appear to be backed up anywhere, and this is user-entered data that isn't stored anywhere else, so it's difficult or impossible to recover from. So i guess one question is: * is it intentional for gpg2 to clear the trustdb entry for a key that it didn't have a copy of, but which was mentioned in the trustdb? and if so, why -- and is that something that should change? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From walter at torres.ws Sat Nov 8 05:09:39 2014 From: walter at torres.ws (Walter Torres) Date: Fri, 7 Nov 2014 22:09:39 -0600 Subject: unsub Message-ID: Walter *When planning for a year, plant oats; when planning for a decade, plant trees; when planning for a life, plant ideas.* -- Ancient Chinese Proverb -------------- next part -------------- An HTML attachment was scrubbed... URL: From georgiytreyvus at riseup.net Sat Nov 8 18:29:02 2014 From: georgiytreyvus at riseup.net (Georgiy Treyvus) Date: Sat, 08 Nov 2014 12:29:02 -0500 Subject: I want to help improve the documentation. In-Reply-To: <201410281445.48506.bernhard@intevation.de> References: <5442C186.8060409@riseup.net> <201410281445.48506.bernhard@intevation.de> Message-ID: <545E52DE.3050709@riseup.net> Hey Bernhard, I'm truly happy to be on board. If you think there are places I could be of better use let me know but all in all I think the best strategy is to go and improve bit by bit as my time permits the documentation in the man/info pages. Partly this is because I think that in any good piece of software the official manual should be the go to place where all of a user's questions are simply, clearly, and unambiguously answered. Another factor to keep in mind is that a user may not always have internet access and that's why all the critical information should be in the documentation that comes with GnuPG. Improving the website would be nice (and I do hope to get around to it) but in my opinion it's no substitute for a good manual that comes as a part of the software. I just hope to have a steady stream of incremental improvements to the man/info pages coming in. Also adding some complexity to the mix are all the changes that come with GnuPG 2.1.0 which I must first understand properly to fully see all the holes in the documentation which from previous precedent there definitely will be. All challenges considered this is still an awesome opportunity to improve a piece of software that is critical to preserving everyone's freedom and security. Another benefit is that in the process I will hopefully wind up knowing the OpenPGP spec inside out and get that much closer to being a truly hardcore cryptographer. Anyway if there is some way you feel I can improve my approach to improving the documentation let me know. Otherwise I'll just get to work and hopefully one day GnuPG will be documented so well even my grandma can use it. Feel free to suggest more specifically how I can be of use. Best Regards, Georgiy On 10/28/2014 09:45 AM, Bernhard Reiter wrote: > Hi Georgiy, > > On Saturday 18 October 2014 at 21:37:42, Georgiy Treyvus wrote: >> Please let me know how I can be of help on this front and >> how to best integrate myself with the overall workflow here. > > welcome as part of the GnuPG Initiative! > It is great that you want to help, we need all hands that we can get. :) > > There are probably a number of places you could start > or where you can contribute directly. > When in doubt, it is always fine to ask here or on gnupg-users > on how to progress a thing. > > If you find obvious issues in the documentation coming with gnupg > just try to create a suggestion and a diff to the latest git-master. > You can probably use the issue tracker. > > The website also needs help, I currently don't know how Werner organises > help there. > > In addition I've started wiki.gnupg.org just pick a few TODOs there, > if you like. E.g. complete the listing of the already familiar types of > documentation to get an overview. > > You can also read here or on gnupg-users and try to answer questions by > others. > > Best Regards, > Bernhard > > > > > From bjk at luxsci.net Sun Nov 9 23:10:25 2014 From: bjk at luxsci.net (Ben Kibbey) Date: Sun, 9 Nov 2014 17:10:25 -0500 Subject: [PATCH] Fix returning new signatures when there are none. Message-ID: <1415571062-4824724.05342434.fsA9MAPrg019199@rs146.luxsci.com> * src/sign.c (gpgme_op_sign_result): Test that invalid and valid signatures add up to gpgme_signers_count(). -- When invalid and valid signatures do not equal gpgme_signers_count() it means that there was a bad passphrase during signing after the first signer. This leaves the result.signatures from previous signers intact which isn't correct since gpg will report: gpg: number of one-pass packets does not match number of signature packets gpg: can't handle this ambiguous signature data during verify. So when this happens append the valid signatures to the .invalid_signers list with .reason set to GPG_ERR_GENERAL. --- src/sign.c | 61 +++++++++++++++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 53 insertions(+), 8 deletions(-) diff --git a/src/sign.c b/src/sign.c index c55441d..9ad589d 100644 --- a/src/sign.c +++ b/src/sign.c @@ -54,12 +54,22 @@ typedef struct } *op_data_t; +static void release_signatures (gpgme_new_signature_t sig) +{ + while (sig) + { + gpgme_new_signature_t next = sig->next; + free (sig->fpr); + free (sig); + sig = next; + } +} + static void release_op_data (void *hook) { op_data_t opd = (op_data_t) hook; gpgme_invalid_key_t invalid_signer = opd->result.invalid_signers; - gpgme_new_signature_t sig = opd->result.signatures; while (invalid_signer) { @@ -70,13 +80,7 @@ release_op_data (void *hook) invalid_signer = next; } - while (sig) - { - gpgme_new_signature_t next = sig->next; - free (sig->fpr); - free (sig); - sig = next; - } + release_signatures (opd->result.signatures); } @@ -115,6 +119,47 @@ gpgme_op_sign_result (gpgme_ctx_t ctx) sig = sig->next; } + if (signatures + inv_signers != gpgme_signers_count (ctx)) + { + TRACE_LOG3 ("result: invalid signers: %i, signatures: %i, count: %i", + inv_signers, signatures, gpgme_signers_count (ctx)); + + sig = opd->result.signatures; + while (sig) + { + gpgme_invalid_key_t key; + + key = malloc (sizeof (*key)); + key->fpr = strdup (sig->fpr); + key->reason = GPG_ERR_GENERAL; + key->next = NULL; + + inv_key = opd->result.invalid_signers; + if (!inv_key) + { + opd->result.invalid_signers = inv_key = key; + sig = sig->next; + continue; + } + + while (inv_key) + { + if (!inv_key->next) + { + inv_key->next = key; + break; + } + + inv_key = inv_key->next; + } + + sig = sig->next; + } + + release_signatures (opd->result.signatures); + opd->result.signatures = NULL; + } + TRACE_LOG2 ("result: invalid signers: %i, signatures: %i", inv_signers, signatures); inv_key = opd->result.invalid_signers; -- 2.1.1 From wk at gnupg.org Mon Nov 10 09:45:07 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 10 Nov 2014 09:45:07 +0100 Subject: ownertrust database cleared on gpg 2.1 key import In-Reply-To: <87tx2ar3vk.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 07 Nov 2014 18:24:15 -0500") References: <87tx2ar3vk.fsf@alice.fifthhorseman.net> Message-ID: <87oasfbg18.fsf@vigenere.g10code.de> On Sat, 8 Nov 2014 00:24, dkg at fifthhorseman.net said: > It looks to me like gpg 2.1.0 is clearing parts of the ownertrust > database when used with the same homedir as 1.4.x. There may be other > circumstances where ownertrust is cleared as well. That is quite possible, but a solution requires that we fix all GnuPG versions. I will look at this soon but I need to take a day off today. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bernhard at intevation.de Mon Nov 10 12:16:14 2014 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 10 Nov 2014 12:16:14 +0100 Subject: I want to help improve the documentation. In-Reply-To: <545E52DE.3050709@riseup.net> References: <5442C186.8060409@riseup.net> <201410281445.48506.bernhard@intevation.de> <545E52DE.3050709@riseup.net> Message-ID: <201411101216.18880.bernhard@intevation.de> Hi Georgiy, On Saturday 08 November 2014 at 18:29:02, Georgiy Treyvus wrote: > all in all I think the best strategy is to > go and improve bit by bit as my time permits the documentation in the > man/info pages. > I just hope to have a steady stream of incremental improvements to the > man/info pages coming in. yes, wonderful! Please keep in mind, that the target audience for some of those man/info pages is quite technical. Many less technical users should actually use one of the frontends or applications that use the GnuPG backend via gpgme and uiserver. So it is these frontends and applications that would need to be helped with even further. ;) Anyway if you have improvements for the info/man pages, send them here. :) Best, Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From dkg at fifthhorseman.net Mon Nov 10 21:52:57 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 10 Nov 2014 10:52:57 -1000 Subject: difference in output between 1.4.x and 2.0.x when agent fails to sign -- causes enigmail to send broken messages Message-ID: <87ioimydzq.fsf@alice.fifthhorseman.net> When creating a signed message (whether encrypted or not), if gpg-agent fails to sign the message, gpg 2.1.0 emits the first part of the message, but then terminates with a non-zero error code. gpg 1.4.x (and i think 2.0.x, but haven't tested today) both terminate with a non-zero error code but produce no output on stdout. This change in behavior causes problems with enigmail in particular, which appears to send the truncated results when producing a PGP/MIME encrypted+signed message if the agent fails to sign. I believe this is two distinct issues, and maybe we want to address them both: * gnupg 2.1.x might want to buffer data before the signature is made, and decline to emit anything if the signature fails * enigmail probably should detect that its invocation of gpg returns a non-zero error code and raise an error in the message creation step. I note that it appears to do so properly for when generating non-encrypted PGP/MIME-signed messages, it's just failing at PGP/MIME encrypted+signed messages. Below is a transcript showing the different behaviors between 1.4.18 (with --use-agent) and 2.1.0 when the agent fails to produce a signature. Regards, --dkg 0 dkg at alice:~$ gpg --version gpg (GnuPG) 1.4.18 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 0 dkg at alice:~$ gpg2 --version gpg (GnuPG) 2.1.0 libgcrypt 1.6.2 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 0 dkg at alice:~$ gpgconf --kill gpg-agent 0 dkg at alice:~$ gpgconf --launch gpg-agent 0 dkg at alice:~$ echo test | gpg --clearsign You need a passphrase to unlock the secret key for user: "Daniel Kahn Gillmor " 4096-bit RSA key, ID 0xA52401B11BFDFA5C, created 2013-03-12 (subkey on main key ID 0xCCD2ED94D21739E9) gpg: cancelled by user gpg: no default secret key: bad passphrase gpg: [stdin]: clearsign failed: bad passphrase 2 dkg at alice:~$ echo test | gpg2 --clearsign -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 test gpg: signing failed: Operation cancelled gpg: [stdin]: clearsign failed: Operation cancelled 2 dkg at alice:~$ echo test | gpg2 --sign --encrypt --armor -r $PGPID gpg: signing failed: Operation cancelled -----BEGIN PGP MESSAGE----- Version: GnuPG v2 hQIMA8Yb0+whSEz/ARAAnJCOUKoXQu0T0JCX3VmHzGW0HL5kvoZgrzYNzqfl2+0k HxKxZzic6sOuiXQ7GcZ6v6OuZy79brPU4vnpzy5DeeaVBE/6UKGhLVRQbaqFD74t PBVnwRdVKY7MHLeOn3H5H/CJRAqwXfYPBPTLEVb4HoJxtwR8GQcToqXTme42OHkd Vttfg6tUbfzwaqGuUHLVH12JP1g5Usq1RzhSbdrPBdB5bs4RNFkXYSW4hL2BWbvX ZoujMTXC+JwQJh5Edjav79rPXpCNuXZr6QS05FaDOfmDYRCSv+t1F1Yh0dIXwXcd h+TwJFGP27T/d2mE3o2uA1P1iZOh1V5czcNa2EwsE/My4/ou3kvSHMt8QhNIBJvB qENaQWM0hZKmPzlItc/J1oQW4BHvoOz5qNJxfxDw6aZrL7qP5+vgXD24JpR2DHzd 8/fi2QHsVnA7upMtfzaZ3x1jwbYxgM+/A3N8PdsKbyXu4SQwcvTmbRKgMx0L8DOJ hgsM/LrpuEJvpYAU7YSy2h5jANlNebhjGwfCDDmyR97BjXMcVt6BuJOS6JjN5plS RF6vrvdUD0NpJsPUkyVGD7RP6ofOScQ7oD8UfpegOldpK89U/3yJfk7yw2AYA0AI FZicmDyzWb/aKFbHzIMCi14u3x8BPSANfqnWv+/5yDsGkrydLWRMZeaeDZ9mgpg: [stdin]: sign+encrypt failed: Operation cancelled 2 dkg at alice:~$ echo test | gpg --sign --encrypt --armor -r $PGPID You need a passphrase to unlock the secret key for user: "Daniel Kahn Gillmor " 4096-bit RSA key, ID 0xA52401B11BFDFA5C, created 2013-03-12 (subkey on main key ID 0xCCD2ED94D21739E9) gpg: cancelled by user gpg: no default secret key: bad passphrase gpg: [stdin]: sign+encrypt failed: bad passphrase 2 dkg at alice:~$ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From bjk at luxsci.net Tue Nov 11 00:22:12 2014 From: bjk at luxsci.net (Ben Kibbey) Date: Mon, 10 Nov 2014 18:22:12 -0500 Subject: [PATCH] Fix returning new signatures when there are none. In-Reply-To: <1415571062-4824724.05342434.fsA9MAPrg019199@rs146.luxsci.com> References: <1415571062-4824724.05342434.fsA9MAPrg019199@rs146.luxsci.com> Message-ID: <1415661783-1197951.41027979.fsAANMDu6016782@rs146.luxsci.com> On Sun, Nov 09, 2014 at 05:10:25PM -0500, Ben Kibbey wrote: > * src/sign.c (gpgme_op_sign_result): Test that invalid and valid > signatures add up to gpgme_signers_count(). The attached patch is updated to only compare the count when gpgme_signers_count() is > 0 since using gpgme_signers_add() is optional. -- Ben Kibbey -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-returning-new-signatures-when-there-are-none.patch Type: text/x-diff Size: 3349 bytes Desc: not available URL: From wk at gnupg.org Tue Nov 11 15:49:03 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 11 Nov 2014 15:49:03 +0100 Subject: Current git changes Message-ID: <87k3317py8.fsf@vigenere.g10code.de> Hi I removed the use of the code in gl/. I hope that this will help to get rid of all those OS X problems related to stdint.h. New bugs are of course possible. I'd appreciate reports on whether this is helpful. Commits since 2.1.0: b8cdfac3 * Remove use of gnulib (part 2) 1adf719b * Remove use of gnulib (part 1) 7362c8c6 * gpg: Remove warning message for non-implemented search modes. f0f5cb6b * w32: Fix http access module. c7c79e31 * build: Add method to use a custom swdb.lst and use adns with Windows. f7e1be24 * build: Improve test for ADNS e0db5af7 * doc: Add announce text for 2.1 8ec0b384 * speedo: Append the date to the Windows installer. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Nov 11 15:45:25 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 11 Nov 2014 15:45:25 +0100 Subject: difference in output between 1.4.x and 2.0.x when agent fails to sign -- causes enigmail to send broken messages In-Reply-To: <87ioimydzq.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 10 Nov 2014 10:52:57 -1000") References: <87ioimydzq.fsf@alice.fifthhorseman.net> Message-ID: <87oasd7q4a.fsf@vigenere.g10code.de> On Mon, 10 Nov 2014 21:52, dkg at fifthhorseman.net said: > I believe this is two distinct issues, and maybe we want to address them > both: > > * gnupg 2.1.x might want to buffer data before the signature is made, > and decline to emit anything if the signature fails There is a lot of buffering going on and that may be the reason for the different behavior. Given that gpg is designed to work in a pipeline, it does not store any data and thus a cancel or any other error may leave unfinished output. If we know that we are writing to a file created by us, that file is removed on error - but for obvious reasons not if it goes to stdout. What we can do is to start implement a pre-sign command in gpg-agent which unprotects the key and then waits for the actual sign command at the end of the input data (which may take some minutes for large file). GPGME's UI-server protocols defines something similar. > * enigmail probably should detect that its invocation of gpg returns a > non-zero error code and raise an error in the message creation step. > I note that it appears to do so properly for when generating non-encrypted > PGP/MIME-signed messages, it's just failing at PGP/MIME > encrypted+signed messages. Maybe because of that ugly micalg MIME parameter which inhibits one-pass processing? We should anyway ignore that parameter - it is useless for OpenPGP. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Nov 12 08:59:41 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 12 Nov 2014 08:59:41 +0100 Subject: ownertrust database cleared on gpg 2.1 key import In-Reply-To: <87tx2ar3vk.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 07 Nov 2014 18:24:15 -0500") References: <87tx2ar3vk.fsf@alice.fifthhorseman.net> Message-ID: <87y4rg6e8i.fsf@vigenere.g10code.de> On Sat, 8 Nov 2014 00:24, dkg at fifthhorseman.net said: > It looks to me like gpg 2.1.0 is clearing parts of the ownertrust > database when used with the same homedir as 1.4.x. There may be other > circumstances where ownertrust is cleared as well. > * is it intentional for gpg2 to clear the trustdb entry for a key that > it didn't have a copy of, but which was mentioned in the trustdb? Yes. AFAICS we implemented that back in 2002. There are 3 places where we clear the ownertrust values (cf. clear_ownertrusts()): 1. Deleting a public key. We can assume that there is a reason for deleting a key. For example it is known that the key has been compromised and the user simply deletes it from the keyring. It would be surprising if ownertrust values persist and would be used the next time the key gets accidentally imported. This is in particular troublesome for an ultimately trusted key. 2. Importing a key /* This should not be possible since we delete the ownertrust when a key is deleted, but it can happen if the keyring and trustdb are out of sync. It can also be made to happen with the trusted-key command. */ clear_ownertrusts (pk); Thus it is closely related to deleting a key. 3. Importing a revocation certificate /* If the key we just revoked was ultimately trusted, remove its ultimate trust. This doesn't stop the user from putting the ultimate trust back, but is a reasonable solution for now. */ if(get_ownertrust(pk)==TRUST_ULTIMATE) clear_ownertrusts(pk); The simplest solution would be to use a different trustdb for keys stored in a keybox (pubring.kbx). However, this conflicts with the goal of allow several keyrings and the user would have the burden to maintain two sets of ownertrust. The actual problem is the use of this command gpg --export | gpg2.1 --import As described above --import will clear the ownertrust values which in this case is not desirable. The only solution I see is an import option which inhibits the trustdb updates or a separate command for this case (--migrate-import). Or to use gpg --export-ownertrust >ownertrust gpg --export | gpg2.1 --import gpg --import-ownertrust ownertrust I tend to implement an import options to make this easier. Maybe even a command to do that. As a first step I will change the introductions on how to use the faster keyring format. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bernhard at intevation.de Thu Nov 13 16:59:26 2014 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 13 Nov 2014 16:59:26 +0100 Subject: List of uids returned is out of sync with what gnupg knows (Debian #528391 pyme) Message-ID: <201411131659.32389.bernhard@intevation.de> Hi Devs and friends, just took a look at an old issue which probably is a gpgme issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528391 Having looked at the gpgme documentation, am I correct in that a) gpgme does not offer a possibility to sign certain uids? The manual does not expand on it. Maybe an example would be nice. b) image ids are not supported (again, no mention) I've checked https://www.gnupg.org/documentation/manuals/gpgme/ but this is really old (from 1.2 please take it down). And 1.3.1 and git. I wonder what the correct way of fixing this would be. Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From dkg at fifthhorseman.net Thu Nov 13 19:47:12 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 13 Nov 2014 08:47:12 -1000 Subject: 2.1.0 out of memory Message-ID: <5464FCB0.4080505@fifthhorseman.net> hi folks-- sorry i haven't had time to debug this further, just wanted to note it now: if i have dirmngr 1.1.1 installed alongside gnupg 2.1.0, and i do: gpg2 --refresh $PGPID (where $PGPID is a full fingerprint) then gpg2 gets into some sort of memory allocation loop and is eventually struck down by the oom-killer. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From patrick at enigmail.net Sat Nov 15 17:47:26 2014 From: patrick at enigmail.net (Patrick Brunschwig) Date: Sat, 15 Nov 2014 17:47:26 +0100 Subject: Current git changes In-Reply-To: <87k3317py8.fsf@vigenere.g10code.de> References: <87k3317py8.fsf@vigenere.g10code.de> Message-ID: <5467839E.5080901@enigmail.net> On 11.11.14 15:49, Werner Koch wrote: > Hi > > I removed the use of the code in gl/. I hope that this will help to get > rid of all those OS X problems related to stdint.h. New bugs are of > course possible. > > I'd appreciate reports on whether this is helpful. > > Commits since 2.1.0: > > b8cdfac3 * Remove use of gnulib (part 2) > 1adf719b * Remove use of gnulib (part 1) > 7362c8c6 * gpg: Remove warning message for non-implemented search modes. > f0f5cb6b * w32: Fix http access module. > c7c79e31 * build: Add method to use a custom swdb.lst and use adns with Windows. > f7e1be24 * build: Improve test for ADNS > e0db5af7 * doc: Add announce text for 2.1 > 8ec0b384 * speedo: Append the date to the Windows installer. This builds fine on Mac OS X (did not test all functionality yet). The only remaining issue when building on OS X is in common/. The build fails with this error when linking libcommon: Undefined symbols for architecture x86_64: "_default_errsource", referenced from: _parse_ber_header in libcommon.a(libcommon_a-tlv.o) _parse_sexp in libcommon.a(libcommon_a-tlv.o) ld: symbol(s) not found for architecture x86_64 To resolve this, the following patch is needed: --- Makefile.orig 2014-11-15 17:42:44.000000000 +0100 +++ Makefile 2014-11-15 17:43:15.000000000 +0100 @@ -656,7 +656,7 @@ t_common_cflags = $(KSBA_CFLAGS) $(LIBGCRYPT_CFLAGS) \ $(LIBASSUAN_CFLAGS) $(GPG_ERROR_CFLAGS) -t_common_ldadd = libcommon.a \ +t_common_ldadd = libcommon.a libcommon_a-init.o \ $(LIBGCRYPT_LIBS) $(LIBASSUAN_LIBS) $(GPG_ERROR_LIBS) \ $(LIBINTL) $(LIBICONV) I suppose that the default ld on OS X (which seems to stem from LLVM 3.5) behaves differently than other variants of ld -Patrick From gniibe at fsij.org Tue Nov 18 02:23:43 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 18 Nov 2014 10:23:43 +0900 Subject: Translation updates In-Reply-To: <87ioiwtwnm.fsf@vigenere.g10code.de> References: <5456E743.8090804@debian.org> <87ioiwtwnm.fsf@vigenere.g10code.de> Message-ID: <546A9F9F.9000203@fsij.org> I update Japanese Translation for libgpg-error (git master). I'm going to update for gnupg 2.0 and master. I maintain those. Situation of Japanese translation of gnupg 1.4 is not good shape. I don't maintain this. I don't think it will be updated by the previous maintainer. We recommend using gnupg 2.0. David, I will reply to your messages attaching updated files. -- From wk at gnupg.org Tue Nov 18 11:27:48 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 18 Nov 2014 11:27:48 +0100 Subject: Translation updates In-Reply-To: <546A9F9F.9000203@fsij.org> (NIIBE Yutaka's message of "Tue, 18 Nov 2014 10:23:43 +0900") References: <5456E743.8090804@debian.org> <87ioiwtwnm.fsf@vigenere.g10code.de> <546A9F9F.9000203@fsij.org> Message-ID: <87bno4pzvf.fsf@vigenere.g10code.de> On Tue, 18 Nov 2014 02:23, gniibe at fsij.org said: > Situation of Japanese translation of gnupg 1.4 is not good shape. > I don't maintain this. I don't think it will be updated by the > previous maintainer. We recommend using gnupg 2.0. I second this. The idea to maintain 1.4 is to help running gpg on old platforms and on servers. Old platforms are rarely internationalized and even if the they are we had no better translation for the last 15 years so not updating the translation should not add additional inconveniences. However, if there is a new translation I will include in the next release anyway. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From shea at shealevy.com Wed Nov 19 00:05:46 2014 From: shea at shealevy.com (Shea Levy) Date: Tue, 18 Nov 2014 18:05:46 -0500 Subject: [PATCH] gpg-agent: Enable socket activation Message-ID: <200F26F7-51DA-4067-AB11-27AF481DA146@shealevy.com> Hi all, I?ve attached a patch to enable the '--agent-fd' (and, similarly, '--ssh-agent-fd') flags to be used to specify a file descriptor to use as the agent listening socket. This allows service managers like launchd or systemd to enable on-demand activation of gpg-agent without potential races at initialization or termination time. I?ve also attached an example launchd configuration and program that can be used with this patch to set up on-demand activation on OS X. You can also pull the change directly from the 'socket-activate? branch of git://github.com/shlevy/gnupg.git Cheers, Shea Levy -------------- next part -------------- A non-text attachment was scrubbed... Name: socket-activate.patch Type: application/octet-stream Size: 5499 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: agent.c Type: application/octet-stream Size: 678 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: com.shealevy.gpg-agent.plist Type: application/octet-stream Size: 653 bytes Desc: not available URL: From wk at gnupg.org Wed Nov 19 08:59:02 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 19 Nov 2014 08:59:02 +0100 Subject: [PATCH] gpg-agent: Enable socket activation In-Reply-To: <200F26F7-51DA-4067-AB11-27AF481DA146@shealevy.com> (Shea Levy's message of "Tue, 18 Nov 2014 18:05:46 -0500") References: <200F26F7-51DA-4067-AB11-27AF481DA146@shealevy.com> Message-ID: <87r3wzoc3d.fsf@vigenere.g10code.de> On Wed, 19 Nov 2014 00:05, shea at shealevy.com said: > as the agent listening socket. This allows service managers like > launchd or systemd to enable on-demand activation of gpg-agent without > potential races at initialization or termination time. gpg-agent is started on demand by the modules which need gpg-agent. There is no need for any init service to start gpg-agent in advance. Even 2.0 may be build or runtime configured to be started on demand. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Nov 19 17:04:03 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 19 Nov 2014 17:04:03 +0100 Subject: Current git changes In-Reply-To: <5467839E.5080901@enigmail.net> (Patrick Brunschwig's message of "Sat, 15 Nov 2014 17:47:26 +0100") References: <87k3317py8.fsf@vigenere.g10code.de> <5467839E.5080901@enigmail.net> Message-ID: <87389fnpn0.fsf@vigenere.g10code.de> On Sat, 15 Nov 2014 17:47, patrick at enigmail.net said: > The only remaining issue when building on OS X is in common/. The build > fails with this error when linking libcommon: > > Undefined symbols for architecture x86_64: > "_default_errsource", referenced from: > _parse_ber_header in libcommon.a(libcommon_a-tlv.o) > I suppose that the default ld on OS X (which seems to stem from LLVM > 3.5) behaves differently than other variants of ld Can you please test wether it helps to chnage in common/init.c /* The default error source of the application. This is different from GPG_ERR_SOURCE_DEFAULT in that it does not depend on the source file and thus is usable in code shared by applications. */ gpg_err_source_t default_errsource; to gpg_err_source_t default_errsource = 0; and thus moving this variable from BSS to DATA? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From grantksupport at operamail.com Wed Nov 19 18:30:01 2014 From: grantksupport at operamail.com (grantksupport at operamail.com) Date: Wed, 19 Nov 2014 09:30:01 -0800 Subject: batch automation for GPG2 v >= 2.1? how to implement per-user passphrase & multipl-subkeys? Message-ID: <1416418201.672045.192985637.69A0D569@webmail.messagingengine.com> I'm working with GPG 2.1.0 gpg2 --version gpg (GnuPG) 2.1.0 libgcrypt 1.6.2 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 I need to create master keys + multiple subkeys for ~1000 users. Each user's keys' config (usage, algo, size) will be: master (sign, cert) RSA/4096 sub1 (sign only) ECDH/2048 sub2 (encrypt only) ECDH/2048 sub3 (auth only) RSA/2048 unattended/batch operation is the intended approach. However, IIUC, (1) passphrase can no longer be passed in GPG2 v>= 2.1 (2) only one sub-key can be generated in batch processing is that correct? What's an effective/efficient approach for mass generation, allowing for full automation per-user passphrase entry and, multiple sub-key generation ? From shea at shealevy.com Thu Nov 20 01:19:29 2014 From: shea at shealevy.com (shea at shealevy.com) Date: Wed, 19 Nov 2014 19:19:29 -0500 Subject: [PATCH] gpg-agent: Enable socket activation In-Reply-To: <87r3wzoc3d.fsf@vigenere.g10code.de> References: <200F26F7-51DA-4067-AB11-27AF481DA146@shealevy.com> <87r3wzoc3d.fsf@vigenere.g10code.de> Message-ID: <2f78e282396ddd9837a82d3a30ce1bd2@shealevy.com> Hi Werner, There are three issues that using externally-managed socket activation can bypass: * With socket activation, external programs talking to the agent simply need to try to connect to the socket. With on-demand activation as it currently exists, they must try to connect and then spawn gpg-agent and try again. This is more complicated and requires the external program to run with gpg-agent in PATH or with a hard-coded path to the agent. * With on-demand activation as it currently exists, two agent-using programs spawned simultaneously may step on each other creating the socket (this can theoretically be bypassed with file locks, perhaps this is already done in which case this is a non-issue). * User-level daemon managers like systemd --user and launchd know when the user has logged out, and thus can kill the running agent and refuse to spawn new instances upon new connections. With on-demand activations as it currently exists, there's no easy way to kill the daemon on log out, and even if you add a custom service that runs gpg-connect-agent KILLAGENT on logout there is a race possible where another process tries to connect after the kill goes through. I've actually hit this issue. ~Shea On 2014-11-19 02:59, Werner Koch wrote: > On Wed, 19 Nov 2014 00:05, shea at shealevy.com said: > >> as the agent listening socket. This allows service managers like >> launchd or systemd to enable on-demand activation of gpg-agent >> without >> potential races at initialization or termination time. > > gpg-agent is started on demand by the modules which need gpg-agent. > There is no need for any init service to start gpg-agent in advance. > Even 2.0 may be build or runtime configured to be started on demand. > > > Shalom-Salam, > > Werner From shea at shealevy.com Thu Nov 20 02:18:11 2014 From: shea at shealevy.com (shea at shealevy.com) Date: Wed, 19 Nov 2014 20:18:11 -0500 Subject: Current git changes In-Reply-To: <87389fnpn0.fsf@vigenere.g10code.de> References: <87k3317py8.fsf@vigenere.g10code.de> <5467839E.5080901@enigmail.net> <87389fnpn0.fsf@vigenere.g10code.de> Message-ID: <9480aa6e82592304a4d4159e117883bc@shealevy.com> FWIW, the attached patch is how I fixed this for my OS X 10.10 build. On 2014-11-19 11:04, Werner Koch wrote: > On Sat, 15 Nov 2014 17:47, patrick at enigmail.net said: > >> The only remaining issue when building on OS X is in common/. The >> build >> fails with this error when linking libcommon: >> >> Undefined symbols for architecture x86_64: >> "_default_errsource", referenced from: >> _parse_ber_header in libcommon.a(libcommon_a-tlv.o) > > >> I suppose that the default ld on OS X (which seems to stem from LLVM >> 3.5) behaves differently than other variants of ld > > Can you please test wether it helps to chnage in common/init.c > > /* The default error source of the application. This is different > from GPG_ERR_SOURCE_DEFAULT in that it does not depend on the > source file and thus is usable in code shared by applications. > */ > gpg_err_source_t default_errsource; > > to > > gpg_err_source_t default_errsource = 0; > > and thus moving this variable from BSS to DATA? > > > Shalom-Salam, > > Werner -------------- next part -------------- A non-text attachment was scrubbed... Name: libcommon-darwin.patch Type: application/octet-stream Size: 585 bytes Desc: not available URL: From patrick at enigmail.net Thu Nov 20 08:53:08 2014 From: patrick at enigmail.net (Patrick Brunschwig) Date: Thu, 20 Nov 2014 08:53:08 +0100 Subject: Current git changes In-Reply-To: <87389fnpn0.fsf@vigenere.g10code.de> References: <87k3317py8.fsf@vigenere.g10code.de> <5467839E.5080901@enigmail.net> <87389fnpn0.fsf@vigenere.g10code.de> Message-ID: <546D9DE4.9060709@enigmail.net> On 19.11.14 17:04, Werner Koch wrote: > On Sat, 15 Nov 2014 17:47, patrick at enigmail.net said: > >> The only remaining issue when building on OS X is in common/. The build >> fails with this error when linking libcommon: >> >> Undefined symbols for architecture x86_64: >> "_default_errsource", referenced from: >> _parse_ber_header in libcommon.a(libcommon_a-tlv.o) > > >> I suppose that the default ld on OS X (which seems to stem from LLVM >> 3.5) behaves differently than other variants of ld > > Can you please test wether it helps to chnage in common/init.c > > /* The default error source of the application. This is different > from GPG_ERR_SOURCE_DEFAULT in that it does not depend on the > source file and thus is usable in code shared by applications. */ > gpg_err_source_t default_errsource; > > to > > gpg_err_source_t default_errsource = 0; > > and thus moving this variable from BSS to DATA? Yes, this fixes the build. -Patrick From wk at gnupg.org Thu Nov 20 12:18:29 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 20 Nov 2014 12:18:29 +0100 Subject: Current git changes In-Reply-To: <546D9DE4.9060709@enigmail.net> (Patrick Brunschwig's message of "Thu, 20 Nov 2014 08:53:08 +0100") References: <87k3317py8.fsf@vigenere.g10code.de> <5467839E.5080901@enigmail.net> <87389fnpn0.fsf@vigenere.g10code.de> <546D9DE4.9060709@enigmail.net> Message-ID: <87tx1uktmi.fsf@vigenere.g10code.de> On Thu, 20 Nov 2014 08:53, patrick at enigmail.net said: >> and thus moving this variable from BSS to DATA? > > Yes, this fixes the build. Great. That is far better than the hack of adding an object file already in the library. Pushed. (Now if I could only remember why I declared default_errsource as extern instead of using the usual common block approach.) Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Nov 20 12:31:35 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 20 Nov 2014 12:31:35 +0100 Subject: [PATCH] gpg-agent: Enable socket activation In-Reply-To: <2f78e282396ddd9837a82d3a30ce1bd2@shealevy.com> (shea@shealevy.com's message of "Wed, 19 Nov 2014 19:19:29 -0500") References: <200F26F7-51DA-4067-AB11-27AF481DA146@shealevy.com> <87r3wzoc3d.fsf@vigenere.g10code.de> <2f78e282396ddd9837a82d3a30ce1bd2@shealevy.com> Message-ID: <87ppcikt0o.fsf@vigenere.g10code.de> On Thu, 20 Nov 2014 01:19, shea at shealevy.com said: > * With socket activation, external programs talking to the agent > simply need to try to connect to the socket. With on-demand activation That would a very different program than we have now. The Hurd calls this a translator and it is a nice technique. However, neither systemd nor translators are established and portable methods and thus should be avoided by portable software. But please save us a systemd discussion. Actually, we do this for years on Windows and it works very reliable. > socket (this can theoretically be bypassed with file locks, perhaps > this is already done in which case this is a non-issue). Sure that is done. In addition gpg-agent checks that its socket has not been reused by another aganet and termintes itself in this case. > * User-level daemon managers like systemd --user and launchd know when > the user has logged out, and thus can kill the running agent and Valid point. Hwoever I don't see a problem to not terminate the gpg-agent on logout. After all most mechines today are single user and the agent is supposed to run on your own desktop and not on a remote machine. What one should put into the ~/.xession at exit is gpgconf --reload gpg-agent (or code to send a HUP) to flush the caches. This should also be done before the system hibernates. > daemon on log out, and even if you add a custom service that runs > gpg-connect-agent KILLAGENT on logout there is a race possible where > another process tries to connect after the kill goes through. I've Well that would be hard to avoid unless one accespts a stale lock file. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From shea at shealevy.com Thu Nov 20 14:20:16 2014 From: shea at shealevy.com (Shea Levy) Date: Thu, 20 Nov 2014 08:20:16 -0500 Subject: [PATCH] gpg-agent: Enable socket activation In-Reply-To: <87ppcikt0o.fsf@vigenere.g10code.de> References: <200F26F7-51DA-4067-AB11-27AF481DA146@shealevy.com> <87r3wzoc3d.fsf@vigenere.g10code.de> <2f78e282396ddd9837a82d3a30ce1bd2@shealevy.com> <87ppcikt0o.fsf@vigenere.g10code.de> Message-ID: <1D7D521C-A299-42E4-A785-433BC40D3190@shealevy.com> Hi Werner, > On Nov 20, 2014, at 6:31 AM, Werner Koch wrote: > > On Thu, 20 Nov 2014 01:19, shea at shealevy.com said: > >> * With socket activation, external programs talking to the agent >> simply need to try to connect to the socket. With on-demand activation > > That would a very different program than we have now. The Hurd calls > this a translator and it is a nice technique. However, neither systemd > nor translators are established and portable methods and thus should be > avoided by portable software. But please save us a systemd discussion. > Hm, I don?t understand this reasoning. Why is it bad to use non-portable methods in a completely optional feature? I?m not suggesting we abandon the current on-demand logic. And FWIW, both OS X and Linux have existing support for socket activation (I?m pretty sure systemd ?user can be used even on hosts that don?t use systemd as init), and it is very easy to write a socket-activating wrapper around a program in POSIX C. If all portable software avoided optional use of non-portable functionality, I doubt any functionality would gain enough prominence to become established. > Actually, we do this for years on Windows and it works very reliable. > >> socket (this can theoretically be bypassed with file locks, perhaps >> this is already done in which case this is a non-issue). > > Sure that is done. In addition gpg-agent checks that its socket has not > been reused by another aganet and termintes itself in this case. > Ah, I?m glad to know :) >> * User-level daemon managers like systemd --user and launchd know when >> the user has logged out, and thus can kill the running agent and > > Valid point. Hwoever I don't see a problem to not terminate the > gpg-agent on logout. After all most mechines today are single user and > the agent is supposed to run on your own desktop and not on a remote > machine. What one should put into the ~/.xession at exit is > > gpgconf --reload gpg-agent > > (or code to send a HUP) to flush the caches. This should also be done > before the system hibernates. > Not everyone has the luxury of a personal single-user machine, and it?s IMO bad etiquette to leave software running unnecessarily after your session. But fair enough. >> daemon on log out, and even if you add a custom service that runs >> gpg-connect-agent KILLAGENT on logout there is a race possible where >> another process tries to connect after the kill goes through. I've > > Well that would be hard to avoid unless one accespts a stale lock file. Or, in the case where the socket is managed by a session-aware daemon, it can just refuse to spawn a new instance :) > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > If socket activation isn?t an option, can we at least have a flag to not fork and set a new session? At least we still get some of the benefits of having the daemon manage lifetime easier in that scenario. ~Shea From dkg at fifthhorseman.net Thu Nov 20 18:14:26 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 20 Nov 2014 12:14:26 -0500 Subject: [PATCH] gpg-agent: Enable socket activation In-Reply-To: <1D7D521C-A299-42E4-A785-433BC40D3190@shealevy.com> References: <200F26F7-51DA-4067-AB11-27AF481DA146@shealevy.com> <87r3wzoc3d.fsf@vigenere.g10code.de> <2f78e282396ddd9837a82d3a30ce1bd2@shealevy.com> <87ppcikt0o.fsf@vigenere.g10code.de> <1D7D521C-A299-42E4-A785-433BC40D3190@shealevy.com> Message-ID: <546E2172.80501@fifthhorseman.net> On 11/20/2014 08:20 AM, Shea Levy wrote: >> On Nov 20, 2014, at 6:31 AM, Werner Koch wrote: > Hm, I don?t understand this reasoning. Why is it bad to use non-portable methods in a completely optional feature? I?m not suggesting we abandon the current on-demand logic. And FWIW, both OS X and Linux have existing support for socket activation (I?m pretty sure systemd ?user can be used even on hosts that don?t use systemd as init), and it is very easy to write a socket-activating wrapper around a program in POSIX C. > > If all portable software avoided optional use of non-portable functionality, I doubt any functionality would gain enough prominence to become established. I haven't tested this patch, but i do think that what shea aims to offer here is a valuable feature for those operating systems which support it. I would like to see the gpg-agent be able to start based on a passed-in file descriptor and stay foregrounded. What can we do to encourage you to reconsider this approach, Werner? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Nov 20 19:34:45 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 20 Nov 2014 19:34:45 +0100 Subject: [PATCH] gpg-agent: Enable socket activation In-Reply-To: <546E2172.80501@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 20 Nov 2014 12:14:26 -0500") References: <200F26F7-51DA-4067-AB11-27AF481DA146@shealevy.com> <87r3wzoc3d.fsf@vigenere.g10code.de> <2f78e282396ddd9837a82d3a30ce1bd2@shealevy.com> <87ppcikt0o.fsf@vigenere.g10code.de> <1D7D521C-A299-42E4-A785-433BC40D3190@shealevy.com> <546E2172.80501@fifthhorseman.net> Message-ID: <87egsxlnzu.fsf@vigenere.g10code.de> On Thu, 20 Nov 2014 18:14, dkg at fifthhorseman.net said: > I would like to see the gpg-agent be able to start based on a passed-in > file descriptor and stay foregrounded. We had several ways to start gpg-agent in the past and am glad that most of this mess could been removed. This makes maintenance and evaluating bug reports much easier. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Nov 20 19:59:04 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 20 Nov 2014 19:59:04 +0100 Subject: [PATCH] gpg-agent: Enable socket activation In-Reply-To: <1D7D521C-A299-42E4-A785-433BC40D3190@shealevy.com> (Shea Levy's message of "Thu, 20 Nov 2014 08:20:16 -0500") References: <200F26F7-51DA-4067-AB11-27AF481DA146@shealevy.com> <87r3wzoc3d.fsf@vigenere.g10code.de> <2f78e282396ddd9837a82d3a30ce1bd2@shealevy.com> <87ppcikt0o.fsf@vigenere.g10code.de> <1D7D521C-A299-42E4-A785-433BC40D3190@shealevy.com> Message-ID: <87a93llmvb.fsf@vigenere.g10code.de> On Thu, 20 Nov 2014 14:20, shea at shealevy.com said: > Hm, I don?t understand this reasoning. Why is it bad to use > non-portable methods in a completely optional feature? I?m not For maintenance reasons and to reduce code complexity. > If all portable software avoided optional use of non-portable > functionality, I doubt any functionality would gain enough prominence > to become established. True if that would solve any real problem. systemd is the Windowization of Unix and such the opposite of portable and modularized software. It is sad to see how WindowsNT moved over the last 15 years towards a system more similar to Unix while Linux as the spearhead of the Unix standardization is splitting up into the non-interoperable Unix world we had reached 25 years ago. Time to reconsider FreeBSD > Not everyone has the luxury of a personal single-user machine, and You shall not use private keys on a multi-user machine. > If socket activation isn?t an option, can we at least have a flag to > not fork and set a new session? At least we still get some of the --no-detach already exists but it is mostly useless. Yes we can probably add an option to run without a fork but I see no use case for that except for starting gpg-agent from inittab (or whatever you guys do on your not-anymore-Unix boxes these days). The main point is: gpg-agent shall be started on demand and not by any session control daemon. > benefits of having the daemon manage lifetime easier in that scenario. BTW, having a session logoff script remove the socket file is an easy way to shutdown gpg-agent: 4 - 19:57:49 gpg-agent[563]: can't connect my own socket: IPC connect call failed 4 - 19:57:49 gpg-agent[563]: this process is useless - shutting down 4 - 19:57:51 gpg-agent[563]: gpg-agent (GnuPG) 2.1.1-beta19 stopped and by using rm(1) this is race free. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rjh at sixdemonbag.org Thu Nov 20 20:11:24 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 20 Nov 2014 14:11:24 -0500 Subject: [PATCH] gpg-agent: Enable socket activation In-Reply-To: <87a93llmvb.fsf@vigenere.g10code.de> References: <200F26F7-51DA-4067-AB11-27AF481DA146@shealevy.com> <87r3wzoc3d.fsf@vigenere.g10code.de> <2f78e282396ddd9837a82d3a30ce1bd2@shealevy.com> <87ppcikt0o.fsf@vigenere.g10code.de> <1D7D521C-A299-42E4-A785-433BC40D3190@shealevy.com> <87a93llmvb.fsf@vigenere.g10code.de> Message-ID: <546E3CDC.9040200@sixdemonbag.org> > ... So when are we going to see GnuPG folded into systemd? >> Not everyone has the luxury of a personal single-user machine, and > > You shall not use private keys on a multi-user machine. I think this is a little extreme. If the other users are all trusted, the risk is manageable. For instance, over the Christmas holidays my younger relatives will often use my laptop to do some of their schoolwork. I'm pretty sure my nieces aren't putting malware or keyloggers on my laptop, so I'm fine with my private key being on my laptop even though I'm permitting others to use it. From wk at gnupg.org Thu Nov 20 21:18:07 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 20 Nov 2014 21:18:07 +0100 Subject: [PATCH] gpg-agent: Enable socket activation In-Reply-To: <546E3CDC.9040200@sixdemonbag.org> (Robert J. Hansen's message of "Thu, 20 Nov 2014 14:11:24 -0500") References: <200F26F7-51DA-4067-AB11-27AF481DA146@shealevy.com> <87r3wzoc3d.fsf@vigenere.g10code.de> <2f78e282396ddd9837a82d3a30ce1bd2@shealevy.com> <87ppcikt0o.fsf@vigenere.g10code.de> <1D7D521C-A299-42E4-A785-433BC40D3190@shealevy.com> <87a93llmvb.fsf@vigenere.g10code.de> <546E3CDC.9040200@sixdemonbag.org> Message-ID: <87zjblk4n4.fsf@vigenere.g10code.de> On Thu, 20 Nov 2014 20:11, rjh at sixdemonbag.org said: > I think this is a little extreme. If the other users are all trusted, > the risk is manageable. For instance, over the Christmas holidays my > younger relatives will often use my laptop to do some of their Of course I was thinking of a machine with concurrent working users. There are too many local root exploits and even a fully fixed box is never safe from side-channel attacks. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Thu Nov 20 23:54:54 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 20 Nov 2014 17:54:54 -0500 Subject: smartcard stub not imported Message-ID: <87fvddv5xd.fsf@alice.fifthhorseman.net> hi folks-- I just got a report from a user that the issue "smartcard stub not imported when migrated to gnupg 2.1" [0] has not been resolved. [0] http://thread.gmane.org/gmane.comp.encryption.gpg.devel/17974 The report was from a debian user who switched to the 2.1.0 package in debian experimental. The reporter said that this workaround worked for them: gpg-connect-agent learn /bye But users really shouldn't have to do that. I don't have a key on a GnuPG smartcard right now, so i haven't tested the situation myself. Has anyone tried the upgrade process recently? should i open this as a bug report? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From dkg at fifthhorseman.net Fri Nov 21 00:50:00 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 20 Nov 2014 18:50:00 -0500 Subject: [PATCH] gpg-agent: Enable socket activation In-Reply-To: <87egsxlnzu.fsf@vigenere.g10code.de> References: <200F26F7-51DA-4067-AB11-27AF481DA146@shealevy.com> <87r3wzoc3d.fsf@vigenere.g10code.de> <2f78e282396ddd9837a82d3a30ce1bd2@shealevy.com> <87ppcikt0o.fsf@vigenere.g10code.de> <1D7D521C-A299-42E4-A785-433BC40D3190@shealevy.com> <546E2172.80501@fifthhorseman.net> <87egsxlnzu.fsf@vigenere.g10code.de> Message-ID: <546E7E28.4030202@fifthhorseman.net> On 11/20/2014 01:34 PM, Werner Koch wrote: > On Thu, 20 Nov 2014 18:14, dkg at fifthhorseman.net said: > >> I would like to see the gpg-agent be able to start based on a passed-in >> file descriptor and stay foregrounded. > > We had several ways to start gpg-agent in the past and am glad that most > of this mess could been removed. This makes maintenance and evaluating > bug reports much easier. Shea's proposal would not affect the daemon-starting logic that currently exists in other parts of the GnuPG suite. It just provides a way that a supervised agent could be initialized (and therefore could be cleanly torn down). If any supervising process doesn't use this feature, then everything behaves as normal. If a supervising process does use this feature, then the daemon is already in place, and it works anyway (but the clients never end up spawning the daemon). I don't want to get into a tangential argument about what is "the Unix way", but in many ways the tradition of composable tools that do "one thing well" suggests that the triplet of is in some ways more "unix-like" than having every potential client need to know how to spawn every potential daemon that it might use. Being able to use gpg-agent as part of such a composable environment would be a very nice option to have. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Fri Nov 21 01:16:50 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 20 Nov 2014 19:16:50 -0500 Subject: gpg-agent 2.1.0's ssh-agent functionality produces error messages about smartcards when no smartcards are present or used Message-ID: <878uj5v24t.fsf@alice.fifthhorseman.net> when i use gpg-agent 2.1.0's ssh-agent functionality, and try to make use of an existing ssh key, gpg-agent produces some pointless error messages: scdaemon[7674]: pcsc_establish_context failed: no service (0x8010001d) scdaemon[7674]: pcsc_establish_context failed: no service (0x8010001d) gpg-agent[7636]: no authentication key for ssh on card: Card error This is visible only if stderr remains bound to the terminal. so, for example, launch gpg-agent as: gpg-agent --daemon --enable-ssh-agent --no-detach This happens even if there is no smartcard configured or used for ssh. These seem like spurious warnings to me, which might distract from more important warnings. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From eternaleye at gmail.com Fri Nov 21 00:37:05 2014 From: eternaleye at gmail.com (Alex Elsayed) Date: Thu, 20 Nov 2014 15:37:05 -0800 Subject: [PATCH] gpg-agent: Enable socket activation References: <200F26F7-51DA-4067-AB11-27AF481DA146@shealevy.com> <87r3wzoc3d.fsf@vigenere.g10code.de> <2f78e282396ddd9837a82d3a30ce1bd2@shealevy.com> <87ppcikt0o.fsf@vigenere.g10code.de> <1D7D521C-A299-42E4-A785-433BC40D3190@shealevy.com> <87a93llmvb.fsf@vigenere.g10code.de> <546E3CDC.9040200@sixdemonbag.org> <87zjblk4n4.fsf@vigenere.g10code.de> Message-ID: Werner Koch wrote: > On Thu, 20 Nov 2014 20:11, rjh at sixdemonbag.org said: > >> I think this is a little extreme. If the other users are all trusted, >> the risk is manageable. For instance, over the Christmas holidays my >> younger relatives will often use my laptop to do some of their > > Of course I was thinking of a machine with concurrent working users. > There are too many local root exploits and even a fully fixed box is > never safe from side-channel attacks. IMO, this is a _very convincing_ reason to deterministically kill off gpg- agent on logout, which session-daemon control makes feasible. From shea at shealevy.com Fri Nov 21 05:19:00 2014 From: shea at shealevy.com (Shea Levy) Date: Thu, 20 Nov 2014 23:19:00 -0500 Subject: [PATCH] gpg-agent: Enable socket activation In-Reply-To: <87a93llmvb.fsf@vigenere.g10code.de> References: <200F26F7-51DA-4067-AB11-27AF481DA146@shealevy.com> <87r3wzoc3d.fsf@vigenere.g10code.de> <2f78e282396ddd9837a82d3a30ce1bd2@shealevy.com> <87ppcikt0o.fsf@vigenere.g10code.de> <1D7D521C-A299-42E4-A785-433BC40D3190@shealevy.com> <87a93llmvb.fsf@vigenere.g10code.de> Message-ID: <7C9D4D04-790E-4D38-8147-4CD1E44C2F55@shealevy.com> > On Nov 20, 2014, at 1:59 PM, Werner Koch wrote: > > On Thu, 20 Nov 2014 14:20, shea at shealevy.com said: > >> Hm, I don?t understand this reasoning. Why is it bad to use >> non-portable methods in a completely optional feature? I?m not > > For maintenance reasons and to reduce code complexity. > Fair enough, but that has nothing to do with portability :) >> If all portable software avoided optional use of non-portable >> functionality, I doubt any functionality would gain enough prominence >> to become established. > > True if that would solve any real problem. systemd is the > Windowization of Unix and such the opposite of portable and modularized > software. It is sad to see how WindowsNT moved over the last 15 years > towards a system more similar to Unix while Linux as the spearhead of > the Unix standardization is splitting up into the non-interoperable Unix > world we had reached 25 years ago. Time to reconsider FreeBSD > Hey, I dislike a lot of what systemd is doing/has done to the Linux community too. But just because one of the main implementors of socket activation has some bad qualities doesn?t mean socket activation itself isn?t a useful tool :) I?ve pointed out the specific problems socket activation solves, and as I?ve said I?ve hit some of these problems in practice. >> Not everyone has the luxury of a personal single-user machine, and > > You shall not use private keys on a multi-user machine. > Some people have no other option, and while of course it?s not ideal I?d prefer that they have access to some measure of privacy (as I?m sure you would too). >> If socket activation isn?t an option, can we at least have a flag to >> not fork and set a new session? At least we still get some of the > > --no-detach already exists but it is mostly useless. Yes we can > probably add an option to run without a fork but I see no use case for > that except for starting gpg-agent from inittab (or whatever you guys do > on your not-anymore-Unix boxes these days). > Yes, starting it from inittab (or the user-level version of it) is exactly the use case. > The main point is: gpg-agent shall be started on demand and not by any > session control daemon. > If that is final then I guess there?s nothing more I can say. >> benefits of having the daemon manage lifetime easier in that scenario. > > BTW, having a session logoff script remove the socket file is an easy > way to shutdown gpg-agent: > > 4 - 19:57:49 gpg-agent[563]: can't connect my own socket: IPC connect call failed > 4 - 19:57:49 gpg-agent[563]: this process is useless - shutting down > 4 - 19:57:51 gpg-agent[563]: gpg-agent (GnuPG) 2.1.1-beta19 stopped > > and by using rm(1) this is race free. > This is not race free, some process still running after the logoff script can try to connect, see there?s no socket, and spawn a new agent. > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > From shea at shealevy.com Fri Nov 21 05:20:14 2014 From: shea at shealevy.com (Shea Levy) Date: Thu, 20 Nov 2014 23:20:14 -0500 Subject: [PATCH] gpg-agent: Enable socket activation In-Reply-To: <87zjblk4n4.fsf@vigenere.g10code.de> References: <200F26F7-51DA-4067-AB11-27AF481DA146@shealevy.com> <87r3wzoc3d.fsf@vigenere.g10code.de> <2f78e282396ddd9837a82d3a30ce1bd2@shealevy.com> <87ppcikt0o.fsf@vigenere.g10code.de> <1D7D521C-A299-42E4-A785-433BC40D3190@shealevy.com> <87a93llmvb.fsf@vigenere.g10code.de> <546E3CDC.9040200@sixdemonbag.org> <87zjblk4n4.fsf@vigenere.g10code.de> Message-ID: <0831E14A-93CE-4CAB-8EF1-98144807F774@shealevy.com> > On Nov 20, 2014, at 3:18 PM, Werner Koch wrote: > > On Thu, 20 Nov 2014 20:11, rjh at sixdemonbag.org said: > >> I think this is a little extreme. If the other users are all trusted, >> the risk is manageable. For instance, over the Christmas holidays my >> younger relatives will often use my laptop to do some of their > > Of course I was thinking of a machine with concurrent working users. > There are too many local root exploits and even a fully fixed box is > never safe from side-channel attacks. Even in the case of a multi-user machine with only one working user at a time, surely it?s still good practice to kill all unnecessary processes after logout? If you accept this use case then my argument still holds. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From gnupg-devel at spodhuis.org Fri Nov 21 08:31:09 2014 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Fri, 21 Nov 2014 02:31:09 -0500 Subject: dead FTP mirror: NL, Demon Message-ID: <20141121073106.GA26105@breadbox> Folks, Dead mirror: ftp.demon.nl I am the person who set up the ftp.demon.nl mirror of GnuPG, many years ago. In 2006, Demon Internet Netherlands was sold to KPN N.V. and various services and customers started to move across to the XS4All subsidiary. I left (the company and the country) that year. These days, ftp.demon.nl appears to be a CNAME for an XS4All download service and if GnuPG is mirrored, it's not mirrored in the same place. I suggest removing the Netherlands/Demon entry from . Thanks, -Phil -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Digital signature URL: From wk at gnupg.org Fri Nov 21 14:12:05 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 21 Nov 2014 14:12:05 +0100 Subject: [PATCH] gpg-agent: Enable socket activation In-Reply-To: (Alex Elsayed's message of "Thu, 20 Nov 2014 15:37:05 -0800") References: <200F26F7-51DA-4067-AB11-27AF481DA146@shealevy.com> <87r3wzoc3d.fsf@vigenere.g10code.de> <2f78e282396ddd9837a82d3a30ce1bd2@shealevy.com> <87ppcikt0o.fsf@vigenere.g10code.de> <1D7D521C-A299-42E4-A785-433BC40D3190@shealevy.com> <87a93llmvb.fsf@vigenere.g10code.de> <546E3CDC.9040200@sixdemonbag.org> <87zjblk4n4.fsf@vigenere.g10code.de> Message-ID: <87lhn4k89m.fsf@vigenere.g10code.de> On Fri, 21 Nov 2014 00:37, eternaleye at gmail.com said: > IMO, this is a _very convincing_ reason to deterministically kill off gpg- > agent on logout, which session-daemon control makes feasible. Fine, do that. You only need to run rm "$HOME"/.gnupg/S.gpg-agent || true Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Nov 21 14:17:57 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 21 Nov 2014 14:17:57 +0100 Subject: [PATCH] gpg-agent: Enable socket activation In-Reply-To: <7C9D4D04-790E-4D38-8147-4CD1E44C2F55@shealevy.com> (Shea Levy's message of "Thu, 20 Nov 2014 23:19:00 -0500") References: <200F26F7-51DA-4067-AB11-27AF481DA146@shealevy.com> <87r3wzoc3d.fsf@vigenere.g10code.de> <2f78e282396ddd9837a82d3a30ce1bd2@shealevy.com> <87ppcikt0o.fsf@vigenere.g10code.de> <1D7D521C-A299-42E4-A785-433BC40D3190@shealevy.com> <87a93llmvb.fsf@vigenere.g10code.de> <7C9D4D04-790E-4D38-8147-4CD1E44C2F55@shealevy.com> Message-ID: <87h9xsk7zu.fsf@vigenere.g10code.de> On Fri, 21 Nov 2014 05:19, shea at shealevy.com said: > activation has some bad qualities doesn?t mean socket activation > itself isn?t a useful tool :) I?ve pointed out the specific problems It definititely is a nice feature. However, for gpg-agent it is not required. gpg-agent shall only be started by the GnuPG tools. If you need to start it advance (e.g. for ssh support) run gpgconf --launch gpg-agent no need to mess around with init systems. > This is not race free, some process still running after the logoff script can try to connect, see there?s no socket, and spawn a new agent. You need to run it last of course ;-) Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Nov 21 14:19:27 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 21 Nov 2014 14:19:27 +0100 Subject: smartcard stub not imported In-Reply-To: <87fvddv5xd.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 20 Nov 2014 17:54:54 -0500") References: <87fvddv5xd.fsf@alice.fifthhorseman.net> Message-ID: <87d28gk7xc.fsf@vigenere.g10code.de> On Thu, 20 Nov 2014 23:54, dkg at fifthhorseman.net said: > I just got a report from a user that the issue "smartcard stub not > imported when migrated to gnupg 2.1" [0] has not been resolved. Yes, I still have that on my list. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From shea at shealevy.com Fri Nov 21 14:25:11 2014 From: shea at shealevy.com (Shea Levy) Date: Fri, 21 Nov 2014 08:25:11 -0500 Subject: [PATCH] gpg-agent: Enable socket activation In-Reply-To: <87h9xsk7zu.fsf@vigenere.g10code.de> References: <200F26F7-51DA-4067-AB11-27AF481DA146@shealevy.com> <87r3wzoc3d.fsf@vigenere.g10code.de> <2f78e282396ddd9837a82d3a30ce1bd2@shealevy.com> <87ppcikt0o.fsf@vigenere.g10code.de> <1D7D521C-A299-42E4-A785-433BC40D3190@shealevy.com> <87a93llmvb.fsf@vigenere.g10code.de> <7C9D4D04-790E-4D38-8147-4CD1E44C2F55@shealevy.com> <87h9xsk7zu.fsf@vigenere.g10code.de> Message-ID: <19CF9F81-98B9-48EA-BFFD-0E37833F0989@shealevy.com> > On Nov 21, 2014, at 8:17 AM, Werner Koch wrote: > > gpg-agent shall only be started by the GnuPG tools. Hmm, so is there any stable interface to gnupg then? > You need to run it last of course ;-) > Avoiding explicit dependency ordering specifications is one of the main benefits of socket activation ;) But I suspect we?re going in circles at this point. ~Shea From wk at gnupg.org Fri Nov 21 14:25:42 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 21 Nov 2014 14:25:42 +0100 Subject: gpg-agent 2.1.0's ssh-agent functionality produces error messages about smartcards when no smartcards are present or used In-Reply-To: <878uj5v24t.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 20 Nov 2014 19:16:50 -0500") References: <878uj5v24t.fsf@alice.fifthhorseman.net> Message-ID: <878uj4k7mx.fsf@vigenere.g10code.de> On Fri, 21 Nov 2014 01:16, dkg at fifthhorseman.net said: > gpg-agent[7636]: no authentication key for ssh on card: Card error > This happens even if there is no smartcard configured or used for ssh. This should not be different from 2.0. gpg-agent always checks whether a smartcard is inserted and tries to use this smartcard, regardless of ~/.gnupg/sshcontrol. Thus you see that warning (and with PC/SC the additional warnings). This might have been introduced a while back when gniibe fixed the handling of plugable smartcard readers. I am not sure what to do about this. We would need to tell scdaemon to silence these warnings iff they are due to the use-plugged-card-for-ssh feature. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Nov 21 14:30:49 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 21 Nov 2014 14:30:49 +0100 Subject: dead FTP mirror: NL, Demon In-Reply-To: <20141121073106.GA26105@breadbox> (Phil Pennock's message of "Fri, 21 Nov 2014 02:31:09 -0500") References: <20141121073106.GA26105@breadbox> Message-ID: <871towk7ee.fsf@vigenere.g10code.de> On Fri, 21 Nov 2014 08:31, gnupg-devel at spodhuis.org said: > I suggest removing the Netherlands/Demon entry from > . Commited. Will show up the next time I rebuild the web (currently no cron job for this). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Nov 21 16:22:12 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 21 Nov 2014 16:22:12 +0100 Subject: [PATCH] gpg-agent: Enable socket activation In-Reply-To: <19CF9F81-98B9-48EA-BFFD-0E37833F0989@shealevy.com> (Shea Levy's message of "Fri, 21 Nov 2014 08:25:11 -0500") References: <200F26F7-51DA-4067-AB11-27AF481DA146@shealevy.com> <87r3wzoc3d.fsf@vigenere.g10code.de> <2f78e282396ddd9837a82d3a30ce1bd2@shealevy.com> <87ppcikt0o.fsf@vigenere.g10code.de> <1D7D521C-A299-42E4-A785-433BC40D3190@shealevy.com> <87a93llmvb.fsf@vigenere.g10code.de> <7C9D4D04-790E-4D38-8147-4CD1E44C2F55@shealevy.com> <87h9xsk7zu.fsf@vigenere.g10code.de> <19CF9F81-98B9-48EA-BFFD-0E37833F0989@shealevy.com> Message-ID: <87ppcginob.fsf@vigenere.g10code.de> On Fri, 21 Nov 2014 14:25, shea at shealevy.com said: > Hmm, so is there any stable interface to gnupg then? Sorry, I don't understand. In case you want to know how to start gpg-agent for use by ssh, tehre are two ways: gpgconf --launch gpg-agent which is the modern one. And the old one which also works for 2.0 if build or configured to use a standard socket is gpg-connect-agent NUP /bye Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From shea at shealevy.com Fri Nov 21 16:50:26 2014 From: shea at shealevy.com (Shea Levy) Date: Fri, 21 Nov 2014 10:50:26 -0500 Subject: [PATCH] gpg-agent: Enable socket activation In-Reply-To: <87ppcginob.fsf@vigenere.g10code.de> References: <200F26F7-51DA-4067-AB11-27AF481DA146@shealevy.com> <87r3wzoc3d.fsf@vigenere.g10code.de> <2f78e282396ddd9837a82d3a30ce1bd2@shealevy.com> <87ppcikt0o.fsf@vigenere.g10code.de> <1D7D521C-A299-42E4-A785-433BC40D3190@shealevy.com> <87a93llmvb.fsf@vigenere.g10code.de> <7C9D4D04-790E-4D38-8147-4CD1E44C2F55@shealevy.com> <87h9xsk7zu.fsf@vigenere.g10code.de> <19CF9F81-98B9-48EA-BFFD-0E37833F0989@shealevy.com> <87ppcginob.fsf@vigenere.g10code.de> Message-ID: <052FE7FD-1F9E-492B-9B31-6BAD2984FD45@shealevy.com> > On Nov 21, 2014, at 10:22 AM, Werner Koch wrote: > > Sorry, I don't understand. In case you want to know how to start > gpg-agent for use by ssh, tehre are two ways: > > gpgconf --launch gpg-agent > Hm then I?m confused, what did you mean by "gpg-agent shall only be started by the GnuPG tools? if there?s a well-defined way to start gpg-agent directly? From wk at gnupg.org Fri Nov 21 20:21:28 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 21 Nov 2014 20:21:28 +0100 Subject: [PATCH] gpg-agent: Enable socket activation In-Reply-To: <052FE7FD-1F9E-492B-9B31-6BAD2984FD45@shealevy.com> (Shea Levy's message of "Fri, 21 Nov 2014 10:50:26 -0500") References: <200F26F7-51DA-4067-AB11-27AF481DA146@shealevy.com> <87r3wzoc3d.fsf@vigenere.g10code.de> <2f78e282396ddd9837a82d3a30ce1bd2@shealevy.com> <87ppcikt0o.fsf@vigenere.g10code.de> <1D7D521C-A299-42E4-A785-433BC40D3190@shealevy.com> <87a93llmvb.fsf@vigenere.g10code.de> <7C9D4D04-790E-4D38-8147-4CD1E44C2F55@shealevy.com> <87h9xsk7zu.fsf@vigenere.g10code.de> <19CF9F81-98B9-48EA-BFFD-0E37833F0989@shealevy.com> <87ppcginob.fsf@vigenere.g10code.de> <052FE7FD-1F9E-492B-9B31-6BAD2984FD45@shealevy.com> Message-ID: <87h9xsiclj.fsf@vigenere.g10code.de> On Fri, 21 Nov 2014 16:50, shea at shealevy.com said: > Hm then I?m confused, what did you mean by "gpg-agent shall only be > started by the GnuPG tools? if there?s a well-defined way to start > gpg-agent directly? gpg-connect-agent is a GnuPG tool gpgconf is a GnuPG tool. They both start gpg-agent if the need it. As do gpg, gpgsm, and g13. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Nov 21 21:15:47 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 21 Nov 2014 21:15:47 +0100 Subject: [PATCH] Fix returning new signatures when there are none. In-Reply-To: <1415661783-1197951.41027979.fsAANMDu6016782@rs146.luxsci.com> (Ben Kibbey's message of "Mon, 10 Nov 2014 18:22:12 -0500") References: <1415571062-4824724.05342434.fsA9MAPrg019199@rs146.luxsci.com> <1415661783-1197951.41027979.fsAANMDu6016782@rs146.luxsci.com> Message-ID: <87bno0ia30.fsf@vigenere.g10code.de> On Tue, 11 Nov 2014 00:22, bjk at luxsci.net said: > The attached patch is updated to only compare the count when > gpgme_signers_count() is > 0 since using gpgme_signers_add() is > optional. Applied. However, I am not sure whether this is the right solution because I doubt that all users check the list of created signatures. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bjk at luxsci.net Fri Nov 21 22:27:33 2014 From: bjk at luxsci.net (Ben Kibbey) Date: Fri, 21 Nov 2014 16:27:33 -0500 Subject: [PATCH] Fix returning new signatures when there are none. In-Reply-To: <87bno0ia30.fsf@vigenere.g10code.de> References: <1415571062-4824724.05342434.fsA9MAPrg019199@rs146.luxsci.com> <1415661783-1197951.41027979.fsAANMDu6016782@rs146.luxsci.com> <87bno0ia30.fsf@vigenere.g10code.de> Message-ID: <1416605282-3269771.3024702.fsALLRY21024040@rs146.luxsci.com> On Fri, Nov 21, 2014 at 09:15:47PM +0100, Werner Koch wrote: > On Tue, 11 Nov 2014 00:22, bjk at luxsci.net said: > > > The attached patch is updated to only compare the count when > > gpgme_signers_count() is > 0 since using gpgme_signers_add() is > > optional. > > Applied. However, I am not sure whether this is the right solution > because I doubt that all users check the list of created signatures. Yeah. It also may not be the right solution because the failed signature isn't included in the list of invalid signatures either. But the app would know which signatures were wanted to begin with. -- Ben Kibbey From dkg at fifthhorseman.net Fri Nov 21 22:44:07 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 21 Nov 2014 16:44:07 -0500 Subject: [Pkg-gnupg-maint] packaging dirmngr from 2.1.0 In-Reply-To: <87vbnw9vz1.fsf@vigenere.g10code.de> References: <8761fwu6bt.fsf@alice.fifthhorseman.net> <20141007033749.GO24040@gambit> <87vbnw9vz1.fsf@vigenere.g10code.de> Message-ID: <87zjbktejc.fsf@alice.fifthhorseman.net> (sorry for the late followup on this) On Tue 2014-10-07 03:31:46 -0400, Werner Koch wrote: > It would save us a lot of trouble if we could do with a per-user > dirmngr. I just noticed that doc/dirmngr.texi currently says: Dirmngr is supposed to be used as a system wide daemon It doesn't look to me like this is true any more, so maybe the documentation just needs an update. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From dkg at fifthhorseman.net Fri Nov 21 23:04:42 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 21 Nov 2014 17:04:42 -0500 Subject: [PATCH] distinguish between ARGPARSE_AMBIGUOUS_{OPTION,COMMAND} Message-ID: <1416607482-11978-1-git-send-email-dkg@fifthhorseman.net> This avoids a dead path in the argparse code. It's not clear that this is needed, however, since ARGPARSE_AMBIGUOUS_COMMAND is never actually used in the code. Another approach would be to trim out ARGPARSE_AMBIGUOUS_COMMAND entirely. --- common/argparse.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/argparse.c b/common/argparse.c index 0a36a9e..169e234 100644 --- a/common/argparse.c +++ b/common/argparse.c @@ -290,7 +290,7 @@ initialize( ARGPARSE_ARGS *arg, const char *filename, unsigned *lineno ) jnlib_log_error (_("invalid command \"%.50s\"\n"), s); else if ( arg->r_opt == ARGPARSE_AMBIGUOUS_OPTION ) jnlib_log_error (_("option \"%.50s\" is ambiguous\n"), s); - else if ( arg->r_opt == ARGPARSE_AMBIGUOUS_OPTION ) + else if ( arg->r_opt == ARGPARSE_AMBIGUOUS_COMMAND ) jnlib_log_error (_("command \"%.50s\" is ambiguous\n"),s ); else if ( arg->r_opt == ARGPARSE_OUT_OF_CORE ) jnlib_log_error ("%s\n", _("out of core\n")); -- 2.1.3 From bisson at archlinux.org Fri Nov 21 22:21:21 2014 From: bisson at archlinux.org (Gaetan Bisson) Date: Fri, 21 Nov 2014 11:21:21 -1000 Subject: Batch Ed25519 key generation Message-ID: <20141121212121.GA1807@kujira.vesath.org> Dear list, With a freshly compiled gnupg-2.1.0 on an up-to-date Arch Linux system, running: gpg2 --batch --full-gen-key < Having both "throw-keyid" and "throw-keyids" as long-opts for the same value (oThrowKeyids) means that the long-opt disambiguation code in common/argparse.c fails to figure out what to do with an argument --throw-key, despite it being an unambiguous prefix to oThrowKeyids. Dropping the shorter version shouldn't change any behavior currently in use, since --throw-keyid should be treated as an unambiguous prefix to --throw-keyids, and is now more consistent with other argument disambiguation handling. (this patch does the same for --no-throw-keyid and --no-throw-keyids) --- g10/gpg.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/g10/gpg.c b/g10/gpg.c index a2225a0..08bcd45 100644 --- a/g10/gpg.c +++ b/g10/gpg.c @@ -586,9 +586,7 @@ static ARGPARSE_OPTS opts[] = { ARGPARSE_s_s (oCertDigestAlgo, "cert-digest-algo", "@"), ARGPARSE_s_s (oCompressAlgo,"compress-algo", "@"), ARGPARSE_s_s (oCompressAlgo, "compression-algo", "@"), /* Alias */ - ARGPARSE_s_n (oThrowKeyids, "throw-keyid", "@"), ARGPARSE_s_n (oThrowKeyids, "throw-keyids", "@"), - ARGPARSE_s_n (oNoThrowKeyids, "no-throw-keyid", "@"), ARGPARSE_s_n (oNoThrowKeyids, "no-throw-keyids", "@"), ARGPARSE_s_n (oShowPhotos, "show-photos", "@"), ARGPARSE_s_n (oNoShowPhotos, "no-show-photos", "@"), -- 2.1.3 From dkg at fifthhorseman.net Fri Nov 21 23:33:01 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 21 Nov 2014 17:33:01 -0500 Subject: [PATCH] refer to --throw-keyids instead of --throw-keyid Message-ID: <1416609181-12557-1-git-send-email-dkg@fifthhorseman.net> The full option name is --throw-keyids, so we should refer to it consistently. * g10/encrypt.c: adjust error message --- g10/encrypt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/g10/encrypt.c b/g10/encrypt.c index d1ce933..518b544 100644 --- a/g10/encrypt.c +++ b/g10/encrypt.c @@ -872,7 +872,7 @@ write_pubkey_enc_from_list (PK_LIST pk_list, DEK *dek, iobuf_t out) if (opt.throw_keyid && (PGP6 || PGP7 || PGP8)) { log_info(_("you may not use %s while in %s mode\n"), - "--throw-keyid",compliance_option_string()); + "--throw-keyids",compliance_option_string()); compliance_failure(); } -- 2.1.3 From dkg at fifthhorseman.net Fri Nov 21 23:52:14 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 21 Nov 2014 17:52:14 -0500 Subject: gnu privacy handbook move to git? Message-ID: <87vbm8tbdt.fsf@alice.fifthhorseman.net> Hi GnuPG folks-- I notice from https://gnupg.org/download/cvs_access.html that the GNU Privacy Handbook (GPH) is still hosted via cvs instead of git: GPH The GNU Privacy Handbook cvs -z3 -d :pserver:anoncvs at cvs.gnupg.org:/cvs/gph co gph Is the GPH still maintained? If so, is this something that needs to be moved to git so that future contributions use the same workflow? I can do the initial conversion if that would be useful. Regards, --dkg From dkg at fifthhorseman.net Fri Nov 21 23:56:47 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 21 Nov 2014 17:56:47 -0500 Subject: gnu privacy handbook move to git? In-Reply-To: <87vbm8tbdt.fsf@alice.fifthhorseman.net> References: <87vbm8tbdt.fsf@alice.fifthhorseman.net> Message-ID: <546FC32F.1070103@fifthhorseman.net> On 11/21/2014 05:52 PM, Daniel Kahn Gillmor wrote: > Hi GnuPG folks-- > > I notice from https://gnupg.org/download/cvs_access.html that the GNU > Privacy Handbook (GPH) is still hosted via cvs instead of git: > > GPH > The GNU Privacy Handbook > > cvs -z3 -d :pserver:anoncvs at cvs.gnupg.org:/cvs/gph co gph hm, i note that this repo appears to be out of date: 0 $ cvs -z3 -d :pserver:anoncvs at cvs.gnupg.org:/cvs/gph co gph cvs [checkout aborted]: connect to cvs.gnupg.org(217.69.76.56):2401 failed: Connection refused 1 $ Where should i find this revision history? --dkg From gnupg-devel at spodhuis.org Sat Nov 22 02:09:59 2014 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Sat, 22 Nov 2014 01:09:59 +0000 Subject: GnuPG 2.1.0: key too large, import stops Message-ID: <20141122010959.GA77998@tower.spodhuis.org> While migrating keyring formats for GnuPG 2.1.0, with this command: % gpg --import old-linear-public-keyring.gpg the import stopped at key 0x57930DAB0B86B067: gpg: error writing keyring '/home/username/.gnupg/pubring.kbx': Provided object is too large gpg: key 0x57930DAB0B86B067: public key "[User ID not found]" imported gpg: error reading 'old-linear-public-keyring.gpg': Provided object is too large gpg: import from 'old-linear-public-keyring.gpg' failed: Provided object is too large I've confirmed that import also fails with: % gpg --keyserver sks.spodhuis.org --recv-key 0x57930DAB0B86B067 and I've seen the size caps on keys mentioned in mails on this list, but I was expecting this to cause the import of this key to be skipped, not for it to abort the entire keyring import. % gpg --keyring old-linear-public-keyring.gpg --export 0x57930DAB0B86B067 > toolarge.0x57930DAB0B86B067 % ls -ld toolarge.0x57930DAB0B86B067 | awk '{print $5}' 2364114 It's a legitimate key. I've used --delete-key to remove it from that keyring, and fired up the import once more. I left the second run going under screen last night, after the first failed. BTW: kudos on the speed improvements for large keyrings, they're very _very_ much appreciated. Even with an incomplete import, I still had nearly three quarters of the old keyring in and the performance differences are _very_ marked. I'd realized the cause of the problems and had been mulling over a project idea of trying to use sqlite with GnuPG and am exceedingly happy that a good and maintained solution has already been found and incorporated. Now just to figure out why I have to keep specifying the keyserver manually ... From chdiza at gmail.com Sat Nov 22 16:47:14 2014 From: chdiza at gmail.com (Charles Diza) Date: Sat, 22 Nov 2014 10:47:14 -0500 Subject: [PATCH] gpg-agent: Enable socket activation In-Reply-To: <1D7D521C-A299-42E4-A785-433BC40D3190@shealevy.com> References: <200F26F7-51DA-4067-AB11-27AF481DA146@shealevy.com> <87r3wzoc3d.fsf@vigenere.g10code.de> <2f78e282396ddd9837a82d3a30ce1bd2@shealevy.com> <87ppcikt0o.fsf@vigenere.g10code.de> <1D7D521C-A299-42E4-A785-433BC40D3190@shealevy.com> Message-ID: FWIW, it is perfectly possible to auto-kill gpg-agent upon user logout on Mac OSX. I've been doing this for years, and it still works on Yosemite. Make a shell script that does "killall -u $1 gpg-agent". Then do this in your terminal: sudo defaults write com.apple.loginwindow LogoutHook "path-to-your-script" Now whenever any user logs out, that script gets executed and only kills the gpg-agent instance associated with that user. Cheers, Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Mon Nov 24 09:39:49 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 24 Nov 2014 09:39:49 +0100 Subject: GnuPG 2.1.0: key too large, import stops In-Reply-To: <20141122010959.GA77998@tower.spodhuis.org> (Phil Pennock's message of "Sat, 22 Nov 2014 01:09:59 +0000") References: <20141122010959.GA77998@tower.spodhuis.org> Message-ID: <87mw7hgffu.fsf@vigenere.g10code.de> On Sat, 22 Nov 2014 02:09, gnupg-devel at spodhuis.org said: > % ls -ld toolarge.0x57930DAB0B86B067 | awk '{print $5}' > 2364114 kbx/keybox-file.c: #define IMAGELEN_LIMIT (2*1024*1024) This is intended as a sanity check. Obviously too short for Joost's key. Increase that to 10MB or even 20MB? > BTW: kudos on the speed improvements for large keyrings, they're very > _very_ much appreciated. Even with an incomplete import, I still had It could even be more imporved but the client who ordererd that was pleased with the achieved speedup. There are two ways in which it can be improved: 1. Primprove update speed by replacing the copy-keyring-during-update scheme by a more clever strategy. 2. Improve read speed by using an index. The latter is easier to implement becuase we have matured code for this in the management of trustdb.gpg. Yet another way to improve on it is to use sqllite which gives us both of the above at once. However, all further improvements will require sybtsantial time for proper testing and thus I think it is better tpo spend the time on other things. > Now just to figure out why I have to keep specifying the keyserver > manually ... Remember to add use --hkp-cacert for dirmngr; there is no default certificate right now, but that will probably change with the next release. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Nov 24 09:42:27 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 24 Nov 2014 09:42:27 +0100 Subject: [PATCH] handle disambiguation of --throw-keyids more cleanly In-Reply-To: <1416608751-12382-1-git-send-email-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 21 Nov 2014 17:25:51 -0500") References: <1416608751-12382-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <87ioi5gfbg.fsf@vigenere.g10code.de> On Fri, 21 Nov 2014 23:25, dkg at fifthhorseman.net said: > Dropping the shorter version shouldn't change any behavior currently > in use, since --throw-keyid should be treated as an unambiguous prefix > to --throw-keyids, and is now more consistent with other argument > disambiguation handling. Not really. The full name is required in the conf files. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Nov 24 09:49:10 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 24 Nov 2014 09:49:10 +0100 Subject: [PATCH] distinguish between ARGPARSE_AMBIGUOUS_{OPTION,COMMAND} In-Reply-To: <1416607482-11978-1-git-send-email-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 21 Nov 2014 17:04:42 -0500") References: <1416607482-11978-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <874mtpgf09.fsf@vigenere.g10code.de> On Fri, 21 Nov 2014 23:04, dkg at fifthhorseman.net said: > This avoids a dead path in the argparse code. Taken. Thanks. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Nov 24 09:46:31 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 24 Nov 2014 09:46:31 +0100 Subject: [PATCH] refer to --throw-keyids instead of --throw-keyid In-Reply-To: <1416609181-12557-1-git-send-email-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 21 Nov 2014 17:33:01 -0500") References: <1416609181-12557-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <87bnnxgf4o.fsf@vigenere.g10code.de> On Fri, 21 Nov 2014 23:33, dkg at fifthhorseman.net said: > The full option name is --throw-keyids, so we should refer to it > consistently. Taken. Thanks. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Nov 24 10:17:50 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 24 Nov 2014 10:17:50 +0100 Subject: [Pkg-gnupg-maint] packaging dirmngr from 2.1.0 In-Reply-To: <87zjbktejc.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 21 Nov 2014 16:44:07 -0500") References: <8761fwu6bt.fsf@alice.fifthhorseman.net> <20141007033749.GO24040@gambit> <87vbnw9vz1.fsf@vigenere.g10code.de> <87zjbktejc.fsf@alice.fifthhorseman.net> Message-ID: <87ppcdez41.fsf@vigenere.g10code.de> On Fri, 21 Nov 2014 22:44, dkg at fifthhorseman.net said: > Dirmngr is supposed to be used as a system wide daemon > > It doesn't look to me like this is true any more, so maybe the > documentation just needs an update. I'll do it. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Nov 24 10:17:02 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 24 Nov 2014 10:17:02 +0100 Subject: gnu privacy handbook move to git? In-Reply-To: <87vbm8tbdt.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 21 Nov 2014 17:52:14 -0500") References: <87vbm8tbdt.fsf@alice.fifthhorseman.net> Message-ID: <87zjbhez5d.fsf@vigenere.g10code.de> On Fri, 21 Nov 2014 23:52, dkg at fifthhorseman.net said: > I notice from https://gnupg.org/download/cvs_access.html that the GNU > Privacy Handbook (GPH) is still hosted via cvs instead of git: As you noted with your other mail, this is probably out of date. > Is the GPH still maintained? If so, is this something that needs to be > moved to git so that future contributions use the same workflow? I can > do the initial conversion if that would be useful. Sure, it needs to be moved to git. I have an established workflow for this. I also think that it would be good to have the GPH in the gnupg-doc repo as a central place for all (online) documentation. The problem with GPH is the license (GFDL) which I do not like. About the same time last year we started a discussion on how to update the GPH. The FSF is the copyright holder and as you can imagine, it is hard to convince RMS to switch to CC-by-SA. Even without having this notorious invariant section I would not suggest to put any work into it before the license has been changed. Fortunately the original author, Mike Ashley, agreed to terminate his copyright assignment and to re-license the GPH if that would be helpful. IIRC, the discussion stopped because I had to take care of the Goteo campaign and after that this issue went asleep. I also think it would be good to merge parts of the GPH with the Gpg4win Compendium. The latter is also GFDLed but I reached informal agreement with the copyright holders to re-license it. The formal parts need to be done, though. There are also a couple of other documents which would benefit from being all synchronized. Now these delays indicate that my workload is too high to diligently take care of the documentation. It would be good to have someone who would take over responsibility for the documentation. See http://wiki.gnupg.org/documentation Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Nov 24 11:59:08 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 24 Nov 2014 11:59:08 +0100 Subject: Batch Ed25519 key generation In-Reply-To: <20141121212121.GA1807@kujira.vesath.org> (Gaetan Bisson's message of "Fri, 21 Nov 2014 11:21:21 -1000") References: <20141121212121.GA1807@kujira.vesath.org> Message-ID: <87lhn0g8zn.fsf@vigenere.g10code.de> On Fri, 21 Nov 2014 22:21, bisson at archlinux.org said: > Is this expected? How should I go about batch creating Ed25519 keys? Apply the patch below or use the algorithm number as a workaround. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-gpg-Fix-batch-generation-of-ECC-keys.patch Type: text/x-diff Size: 1556 bytes Desc: not available URL: From dimitri.j.ledkov at intel.com Mon Nov 24 11:04:23 2014 From: dimitri.j.ledkov at intel.com (Dimitri John Ledkov) Date: Mon, 24 Nov 2014 10:04:23 +0000 Subject: gnupg 2.1 vs rpmsign Message-ID: It appears that rpmsign does not co-operate well enough with gnupg. Reading the rpm source code, it forks, creates file-descriptors, wraps gnupg exec call in those file-descriptors and hopes to pass the passphrase via "--passphrase-fd 3" and that fails. However if I perform any other gpg operation with a private key (e.g. sign an arbitrary file) then gpg-agent is spawned and pinentry passphrase is stored, then subsequent calls to gpgsign succeed even if a bogus passphrase is passed to rpmsign/gpg --passphrase-fd. What should rpmsign be doing instead? (cause it looks like --passphrase-fd option is no longer supported by gpg 2.1) E.g. should it use gpg-preset-passphrase --passphrase STRING and then invoke gpg command? -- Regards, Dimitri. Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. From kristian.fiskerstrand at sumptuouscapital.com Mon Nov 24 12:40:12 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Mon, 24 Nov 2014 12:40:12 +0100 Subject: gnupg 2.1 vs rpmsign In-Reply-To: References: Message-ID: <5473191C.7090705@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/24/2014 11:04 AM, Dimitri John Ledkov wrote: > It appears that rpmsign does not co-operate well enough with > gnupg. > ... > What should rpmsign be doing instead? (cause it looks like > --passphrase-fd option is no longer supported by gpg 2.1) Look into --pinentry-mode loopback[0] > > E.g. should it use gpg-preset-passphrase --passphrase STRING and > then invoke gpg command? > That would also work References [0] http://lists.gnupg.org/pipermail/gnupg-devel/2013-February/027345.html - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- "I never worry about action, but only inaction." (Winston Churchill) -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUcxkbAAoJEPw7F94F4Tag0l8P/jZfvFM5MJsexrA+FfanIU6h RVLz87yI3RadlVAz+CJAeFXsA7ZbHOMDFwaCPFIp2xDiKw2oJ8OHjaRm1QjalH/a z4A5d12Ma1P7HGRsXIMjQjZAp/twnUij+xoRXJf4pK5P4UOQfRqKQfgGO2o+XanR 8VfRRULqKZOWlaKei1yMH2xD7sOzUX6oqnvN7107jwzm4CVqOd1jomuvS3qcK/zc LcKqPlioN3fjNLJCX0jG5K7OuDeiyachVZeivZqc27v5cPMCJbvkgHfGEniUqZmc /B7A31qMLcTSxqC4e82I5o9Mi2L/mz7W0rms2KpAAX8D0Sy12rZEsflM1unPE+tp O0+RRiInIrEMAtNpfaBKwZ8xzhaGqJT073CNb6eHUopSsMBzjfiMCg5CLIvDpuy+ uU1WHQ7uqoA+9/zI7YRCaumIOJ3Tnm/nOtL4Rgfas/EBFmQ8oTdfKLbv5hNcizAX tPgTTml92amhQUQFlSecCPY9ebz8WZU2+5n/HEETFrNpIX7gZzNvdj76FrXmg6hr tToE/O56392kpGWDJYpUXjhT8EmuQ1tjHU9cOGADQrlAqEY1apo5k8wYFVI1pzOP 4OIAB2l2cV/QfVARqVqsv4d8AONzusqPM7QpP/JIjz0Zot0DliN63CIL+lHnR/JL 1LE/HwwXF2npN+wV/AfG =CoIo -----END PGP SIGNATURE----- From dimitri.j.ledkov at intel.com Mon Nov 24 13:25:36 2014 From: dimitri.j.ledkov at intel.com (Dimitri John Ledkov) Date: Mon, 24 Nov 2014 12:25:36 +0000 Subject: gnupg 2.1 vs rpmsign In-Reply-To: <5473191C.7090705@sumptuouscapital.com> References: <5473191C.7090705@sumptuouscapital.com> Message-ID: Hello, On 24 November 2014 at 11:40, Kristian Fiskerstrand wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 11/24/2014 11:04 AM, Dimitri John Ledkov wrote: >> It appears that rpmsign does not co-operate well enough with >> gnupg. >> > > ... > >> What should rpmsign be doing instead? (cause it looks like >> --passphrase-fd option is no longer supported by gpg 2.1) > > Look into --pinentry-mode loopback[0] > >> >> E.g. should it use gpg-preset-passphrase --passphrase STRING and >> then invoke gpg command? >> > > That would also work > Hm, thanks. However reading the man page --batch --passphrase-fd 3 should still work in GnuPG 2.1, no? I'm also getting "gpg: setting pinentry mode 'loopback' failed: Not supported" which seems odd to me, is my gpg2 or pinentry miscompiled? Regards, Dimitri. > References > [0] http://lists.gnupg.org/pipermail/gnupg-devel/2013-February/027345.html > > > - -- > - ---------------------------- > Kristian Fiskerstrand > Blog: http://blog.sumptuouscapital.com > Twitter: @krifisk > - ---------------------------- > Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net > fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 > - ---------------------------- > "I never worry about action, but only inaction." > (Winston Churchill) > -----BEGIN PGP SIGNATURE----- > > iQIcBAEBCgAGBQJUcxkbAAoJEPw7F94F4Tag0l8P/jZfvFM5MJsexrA+FfanIU6h > RVLz87yI3RadlVAz+CJAeFXsA7ZbHOMDFwaCPFIp2xDiKw2oJ8OHjaRm1QjalH/a > z4A5d12Ma1P7HGRsXIMjQjZAp/twnUij+xoRXJf4pK5P4UOQfRqKQfgGO2o+XanR > 8VfRRULqKZOWlaKei1yMH2xD7sOzUX6oqnvN7107jwzm4CVqOd1jomuvS3qcK/zc > LcKqPlioN3fjNLJCX0jG5K7OuDeiyachVZeivZqc27v5cPMCJbvkgHfGEniUqZmc > /B7A31qMLcTSxqC4e82I5o9Mi2L/mz7W0rms2KpAAX8D0Sy12rZEsflM1unPE+tp > O0+RRiInIrEMAtNpfaBKwZ8xzhaGqJT073CNb6eHUopSsMBzjfiMCg5CLIvDpuy+ > uU1WHQ7uqoA+9/zI7YRCaumIOJ3Tnm/nOtL4Rgfas/EBFmQ8oTdfKLbv5hNcizAX > tPgTTml92amhQUQFlSecCPY9ebz8WZU2+5n/HEETFrNpIX7gZzNvdj76FrXmg6hr > tToE/O56392kpGWDJYpUXjhT8EmuQ1tjHU9cOGADQrlAqEY1apo5k8wYFVI1pzOP > 4OIAB2l2cV/QfVARqVqsv4d8AONzusqPM7QpP/JIjz0Zot0DliN63CIL+lHnR/JL > 1LE/HwwXF2npN+wV/AfG > =CoIo > -----END PGP SIGNATURE----- -- Regards, Dimitri. Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. From wk at gnupg.org Mon Nov 24 16:14:45 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 24 Nov 2014 16:14:45 +0100 Subject: batch automation for GPG2 v >= 2.1? how to implement per-user passphrase & multipl-subkeys? In-Reply-To: <1416418201.672045.192985637.69A0D569@webmail.messagingengine.com> (grantksupport@operamail.com's message of "Wed, 19 Nov 2014 09:30:01 -0800") References: <1416418201.672045.192985637.69A0D569@webmail.messagingengine.com> Message-ID: <874mtoeil6.fsf@vigenere.g10code.de> On Wed, 19 Nov 2014 18:30, grantksupport at operamail.com said: > Each user's keys' config (usage, algo, size) will be: > > master (sign, cert) RSA/4096 > sub1 (sign only) ECDH/2048 > sub2 (encrypt only) ECDH/2048 > sub3 (auth only) RSA/2048 This is not the default thing and there is no direct way to do it unless you want to add the keys one after the other. > (1) passphrase can no longer be passed in GPG2 v>= 2.1 In theory not since 2.0 but we initially implemented the new thing only for the S/MIME part. > (2) only one sub-key can be generated in batch processing Right. > What's an effective/efficient approach for mass generation, allowing for > > full automation > per-user passphrase entry > and, > multiple sub-key generation Extending the parameter file feature is probably the easiest way. It would be a low priority task. But if it is for a commercial use there are ways to speed it up ;-). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Nov 24 16:10:23 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 24 Nov 2014 16:10:23 +0100 Subject: gnupg 2.1 vs rpmsign In-Reply-To: (Dimitri John Ledkov's message of "Mon, 24 Nov 2014 12:25:36 +0000") References: <5473191C.7090705@sumptuouscapital.com> Message-ID: <878uj0eisg.fsf@vigenere.g10code.de> On Mon, 24 Nov 2014 13:25, dimitri.j.ledkov at intel.com said: > Hm, thanks. However reading the man page --batch --passphrase-fd 3 > should still work in GnuPG 2.1, no? I think so, It behaves slightly different than in 1.4 and it has not been tested extensively. > I'm also getting "gpg: setting pinentry mode 'loopback' failed: Not > supported" which seems odd to me, is my gpg2 or pinentry miscompiled? This is implemented on the Assuan layer between gpg and gpg-agent: `pinentry-mode' This option is used to change the operation mode of the pinentry. The following values are defined: `ask' This is the default mode which pops up a pinentry as needed. `cancel' Instead of popping up a pinentry, return the error code `GPG_ERR_CANCELED'. `error' Instead of popping up a pinentry, return the error code `GPG_ERR_NO_PIN_ENTRY'. `loopback' Use a loopback pinentry. This fakes a pinentry by using inquiries back to the caller to ask for a passphrase. This option may only be set if the agent has been configured for that. Use the *Note option --allow-loopback-pinentry::. ... which you need to put into gpg-agent.conf: `--allow-loopback-pinentry' Allow clients to use the loopback pinentry features; see the option `pinentry-mode' for details. (but remove the two dashes) Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rjh at sixdemonbag.org Mon Nov 24 16:20:07 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 24 Nov 2014 10:20:07 -0500 Subject: gnupg 2.1 vs rpmsign In-Reply-To: References: Message-ID: <54734CA7.9080101@sixdemonbag.org> > It appears that rpmsign does not co-operate well enough with gnupg. This is if anything an understatement. rpmsign doesn't work with anything except RSA keys, for starters. From dimitri.j.ledkov at intel.com Mon Nov 24 16:49:33 2014 From: dimitri.j.ledkov at intel.com (Dimitri John Ledkov) Date: Mon, 24 Nov 2014 15:49:33 +0000 Subject: gnupg 2.1 vs rpmsign In-Reply-To: <54734CA7.9080101@sixdemonbag.org> References: <54734CA7.9080101@sixdemonbag.org> Message-ID: On 24 November 2014 at 15:20, Robert J. Hansen wrote: >> It appears that rpmsign does not co-operate well enough with gnupg. > > > This is if anything an understatement. rpmsign doesn't work with > anything except RSA keys, for starters. I am aware, and am using RSA keys with GPG 2.1. It's a shame that rpm format is so inflexible to support arbitrary algos/digest for signatures, but oh well. -- Regards, Dimitri. Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. From dkg at fifthhorseman.net Mon Nov 24 17:30:44 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 24 Nov 2014 11:30:44 -0500 Subject: [PATCH] handle disambiguation of --throw-keyids more cleanly In-Reply-To: <87ioi5gfbg.fsf@vigenere.g10code.de> References: <1416608751-12382-1-git-send-email-dkg@fifthhorseman.net> <87ioi5gfbg.fsf@vigenere.g10code.de> Message-ID: <54735D34.9080701@fifthhorseman.net> On 11/24/2014 03:42 AM, Werner Koch wrote: > On Fri, 21 Nov 2014 23:25, dkg at fifthhorseman.net said: > >> Dropping the shorter version shouldn't change any behavior currently >> in use, since --throw-keyid should be treated as an unambiguous prefix >> to --throw-keyids, and is now more consistent with other argument >> disambiguation handling. > > Not really. The full name is required in the conf files. so is --throw-keyid just an older variant of the command? Do we plan to keep it around forever? It seems like we should choose one of these approaches for long-term cleanliness: a) deprecate --throw-keyid now and make plans to remove it in the future, or b) remove throw-keyid but make it produce an error when found in the config file c) go ahead and remove throw-keyid entirely as we transition to 2.1, where several other minor changes are happening. fixing a config file "throw-keyid" to "throw-keyids" isn't a difficult change, and it's only likely to be relevant for a very small number of people. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From bisson at archlinux.org Mon Nov 24 19:47:59 2014 From: bisson at archlinux.org (Gaetan Bisson) Date: Mon, 24 Nov 2014 08:47:59 -1000 Subject: Batch Ed25519 key generation In-Reply-To: <87lhn0g8zn.fsf@vigenere.g10code.de> References: <20141121212121.GA1807@kujira.vesath.org> <87lhn0g8zn.fsf@vigenere.g10code.de> Message-ID: <20141124184759.GA23972@kujira.vesath.org> [2014-11-24 11:59:08 +0100] Werner Koch: > On Fri, 21 Nov 2014 22:21, bisson at archlinux.org said: > > > Is this expected? How should I go about batch creating Ed25519 keys? > > Apply the patch below or use the algorithm number as a workaround. Thanks! -- Gaetan From dkg at fifthhorseman.net Tue Nov 25 04:12:09 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 24 Nov 2014 22:12:09 -0500 Subject: updating translations from non-UTF-8 to UTF-8 Message-ID: <87sih8t1me.fsf@alice.fifthhorseman.net> Hi GnuPG folks-- We just got some Spanish translations for GnuPG 1.4.x and 2.0.x reported to the Debian Project by Manuel "Venturi" Porras Peralta. They're here: https://bugs.debian.org/770726 https://bugs.debian.org/770727 They convert po/es.po from ISO-8859-1 to UTF-8, and they also make a number of changes to the .po file (apparently for consistency and for up-to-dateness, though i'm not a Spanish-speaker so i can't vouch for them). I don't see a good way to send a git changeset via e-mail where the file is in a different encoding before and after the change, unfortunately. I think the right way to apply them in git is to convert po/es.po to UTF-8 in one commit and then to drop the new file in place, something like this for 1.4.x: git checkout STABLE-BRANCH-1-4 iconf -f iso-8859-1 -t utf-8 < po/es.po | sed s/ISO-8859-1/UTF-8/ > po/es.po.utf8 mv po/es.po.utf8 po/es.po git add po/es.po git commit -m 'Converted po/es.po to UTF-8' wget -O po/es.po 'https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=es.po;att=3;bug=770726' git add po/es.po git commit --author 'Manuel "Venturi" Porras Peralta ' and for 2.0.x: git checkout STABLE-BRANCH-2-0 iconf -f iso-8859-1 -t utf-8 < po/es.po | sed s/ISO-8859-1/UTF-8/ > po/es.po.utf8 mv po/es.po.utf8 po/es.po git add po/es.po git commit -m 'Converted po/es.po to UTF-8' wget -O po/es.po 'https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=es.po;att=3;bug=770727' git add po/es.po git commit --author 'Manuel "Venturi" Porras Peralta ' Please let me know if these are applied upstream! Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From gnupg-devel at spodhuis.org Tue Nov 25 03:26:11 2014 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Tue, 25 Nov 2014 02:26:11 +0000 Subject: GnuPG 2.1.0: key too large, import stops In-Reply-To: <87mw7hgffu.fsf@vigenere.g10code.de> References: <20141122010959.GA77998@tower.spodhuis.org> <87mw7hgffu.fsf@vigenere.g10code.de> Message-ID: <20141125022610.GA93687@tower.spodhuis.org> On 2014-11-24 at 09:39 +0100, Werner Koch wrote: > This is intended as a sanity check. Obviously too short for Joost's > key. Increase that to 10MB or even 20MB? Is there a way to skip the import of that one key, continuing on, so that one unimportable key doesn't abort the entire keyring? > > Now just to figure out why I have to keep specifying the keyserver > > manually ... > > Remember to add use --hkp-cacert for dirmngr; there is no default > certificate right now, but that will probably change with the next > release. Ah, dirmngr.conf and the `keyserver-options ca-cert-file=...` from gnupg.conf is now ignored, okay. Some comments from debugging dirmngr: * dirmngr.texi suggests a config file containing at least: log-file ~/dirmngr.log that doesn't work, and looking in common/logging.c:set_file_fd() I can see nothing which would expand the string; I think that the only handling for ~/ is from the shell, for --options, and that listing this for a config file is a documentation bug. * supporting ~/ in the config file would be nice :) * there's no documentation on the working directory for the daemon; it looks like, during daemonization, there's a `chdir("/")`, even for per-user daemons? * while `http_register_tls_ca()` can be called multiple times, to accumulate CAs, as far as I can see there's nothing which lets the config option hkp-cacert supply multiple values; I don't think it can be repeated? * --no-detach doesn't prevent detach with --daemon * I can't see a way to get --server to create the Unix socket, to let a foreground server be used to answer questions from gpg clients; --homedir is not sufficient and the debugging option --socket-name doesn't appear to work * the hkp-cacert filename *must* end `.pem` if the file is to be read in PEM format; this appears to be an undocumented constraint * there's no logging or handling for showing why hkps: is failing if GnuPG was built without TLS support And the last point is the critical one: because curl is not being used anymore and GnuTLS must be available, there's a regression in default behaviour from the configure command-line given the dependent libraries; this one isn't anyone's fault, but I think that there probably needs to be clearer communication to OS packagers that they now need to make sure that GnuTLS is available. I'm using FreeBSD Ports, and the FreeBSD Port does not register GnuTLS as a dependency, and I'm building ports with poudriere, so that each port build is isolated (this is the default for the packages shipped by FreeBSD) the end result is a GnuPG package with no TLS support. I'll fiddle some more to hack my port build. Regards, -Phil From dkg at fifthhorseman.net Tue Nov 25 04:17:09 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 24 Nov 2014 22:17:09 -0500 Subject: [PATCH] po: Portuguese translation for libgpg-error Message-ID: <1416885429-807-1-git-send-email-dkg@fifthhorseman.net> From: Paulo Tom? * po/pt.po: new Portuguese translation Debian-Bug-Id: 770983 --- po/pt.po | 953 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 953 insertions(+) create mode 100644 po/pt.po diff --git a/po/pt.po b/po/pt.po new file mode 100644 index 0000000..7c0d2c8 --- /dev/null +++ b/po/pt.po @@ -0,0 +1,953 @@ +# Portuguese translations for libgpg-error package. +# Copyright (C) 2014 g10 Code GmbH +# This file is distributed under the same license as the libgpg-error package. +# +# paulo , 2014. +msgid "" +msgstr "" +"Project-Id-Version: libgpg-error 1.17\n" +"Report-Msgid-Bugs-To: translations at gnupg.org\n" +"PO-Revision-Date: 2014-11-24 02:32+0000\n" +"Last-Translator: Paulo Tom? \n" +"Language-Team: Portuguese \n" +"Language: pt\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Plural-Forms: nplurals=2; plural=(n != 1);\n" +"X-Generator: Lokalize 1.4\n" + +msgid "Unspecified source" +msgstr "Fonte n?o especificada" + +msgid "gcrypt" +msgstr "gcrypt" + +msgid "GnuPG" +msgstr "GnuPG" + +msgid "GpgSM" +msgstr "GpgSM" + +msgid "GPG Agent" +msgstr "Agente GPG" + +msgid "Pinentry" +msgstr "Pinentry" + +msgid "SCD" +msgstr "SCD" + +msgid "GPGME" +msgstr "GPGME" + +msgid "Keybox" +msgstr "Keybox" + +msgid "KSBA" +msgstr "KSBA" + +msgid "Dirmngr" +msgstr "Dirmngr" + +msgid "GSTI" +msgstr "GSTI" + +msgid "GPA" +msgstr "GPA" + +msgid "Kleopatra" +msgstr "Kleopatra" + +msgid "G13" +msgstr "G13" + +msgid "Assuan" +msgstr "Assuan" + +msgid "TLS" +msgstr "TLS" + +msgid "Any source" +msgstr "Qualquer fonte" + +msgid "User defined source 1" +msgstr "Fonte definida pelo utilizador 1" + +msgid "User defined source 2" +msgstr "Fonte definida pelo utilizador 2" + +msgid "User defined source 3" +msgstr "Fonte definida pelo utilizador 3" + +msgid "User defined source 4" +msgstr "Fonte definida pelo utilizador 4" + +msgid "Unknown source" +msgstr "Fonte n?o conhecida" + +msgid "Success" +msgstr "Sucesso" + +msgid "General error" +msgstr "Erro gen?rico" + +msgid "Unknown packet" +msgstr "Pacote desconhecido" + +msgid "Unknown version in packet" +msgstr "Vers?o desconhecida no pacote" + +msgid "Invalid public key algorithm" +msgstr "Algoritmo de chave p?blica inv?lido" + +msgid "Invalid digest algorithm" +msgstr "Algoritmo de resumo inv?lido" + +msgid "Bad public key" +msgstr "Chave p?blica errada" + +msgid "Bad secret key" +msgstr "Chave secreta errada" + +msgid "Bad signature" +msgstr "Assinatura errada" + +msgid "No public key" +msgstr "Sem chave p?blica" + +msgid "Checksum error" +msgstr "Soma de verifica??o errada" + +msgid "Bad passphrase" +msgstr "Senha errada" + +msgid "Invalid cipher algorithm" +msgstr "Algoritmo de cifra inv?lido" + +msgid "Keyring open" +msgstr "Chaveiro aberto" + +msgid "Invalid packet" +msgstr "Pacote inv?lido" + +msgid "Invalid armor" +msgstr "Armadura inv?lida" + +msgid "No user ID" +msgstr "Sem identificador de utilizador" + +msgid "No secret key" +msgstr "Sem chave secreta" + +msgid "Wrong secret key used" +msgstr "Utilizada chave secreta errada" + +msgid "Bad session key" +msgstr "Chave de sess?o errada" + +msgid "Unknown compression algorithm" +msgstr "Algoritmo de compress?o desconhecido" + +msgid "Number is not prime" +msgstr "O n?mero n?o ? primo" + +msgid "Invalid encoding method" +msgstr "M?todo de codifica??o errado" + +msgid "Invalid encryption scheme" +msgstr "Esquema de encripta??o errado" + +msgid "Invalid signature scheme" +msgstr "Esquema de assinatura inv?lido" + +msgid "Invalid attribute" +msgstr "Atributo inv?lido" + +msgid "No value" +msgstr "Sem valor" + +msgid "Not found" +msgstr "N?o encontrado" + +msgid "Value not found" +msgstr "Valor n?o encontrado" + +msgid "Syntax error" +msgstr "Erro de sintaxe" + +msgid "Bad MPI value" +msgstr "Valor de MPI errado" + +msgid "Invalid passphrase" +msgstr "Senha inv?lida" + +msgid "Invalid signature class" +msgstr "Classe de assinatura inv?lida" + +msgid "Resources exhausted" +msgstr "Recursos esgotados" + +msgid "Invalid keyring" +msgstr "Chaveiro inv?lido" + +msgid "Trust DB error" +msgstr "Erro na Base de Dados de confian?a" + +msgid "Bad certificate" +msgstr "Certificado errado" + +msgid "Invalid user ID" +msgstr "Identificador de utilizador errado" + +msgid "Unexpected error" +msgstr "Erro inesperado" + +msgid "Time conflict" +msgstr "Conflito temporal" + +msgid "Keyserver error" +msgstr "Erro no servidor de chaves" + +msgid "Wrong public key algorithm" +msgstr "Algoritmo da chave p?blica errado" + +msgid "Tribute to D. A." +msgstr "Tributo a D. A." + +msgid "Weak encryption key" +msgstr "Chave de encripta??o fraca" + +msgid "Invalid key length" +msgstr "Comprimento da chave inv?lido" + +msgid "Invalid argument" +msgstr "Argumento inv?lido" + +msgid "Syntax error in URI" +msgstr "Erro de sintaxe no URI" + +msgid "Invalid URI" +msgstr "URI inv?lido" + +msgid "Network error" +msgstr "Erro de rede" + +msgid "Unknown host" +msgstr "Anfitri?o desconhecido" + +msgid "Selftest failed" +msgstr "Auto teste falhou" + +msgid "Data not encrypted" +msgstr "Dados n?o encriptados" + +msgid "Data not processed" +msgstr "Dados n?o processados" + +msgid "Unusable public key" +msgstr "Chave p?blica inutiliz?vel" + +msgid "Unusable secret key" +msgstr "Chave secreta inutiliz?vel" + +msgid "Invalid value" +msgstr "Valor inv?lido" + +msgid "Bad certificate chain" +msgstr "Cadeia de certificados errada" + +msgid "Missing certificate" +msgstr "Certificado em falta" + +msgid "No data" +msgstr "N?o existem dados" + +msgid "Bug" +msgstr "Erro" + +msgid "Not supported" +msgstr "N?o suportado" + +msgid "Invalid operation code" +msgstr "C?digo de opera??o inv?lido" + +msgid "Timeout" +msgstr "Tempo limite" + +msgid "Internal error" +msgstr "Erro interno" + +msgid "EOF (gcrypt)" +msgstr "EOF (gcrypt)" + +msgid "Invalid object" +msgstr "Objecto inv?lido" + +msgid "Provided object is too short" +msgstr "O objecto fornecido ? demasiado curto" + +msgid "Provided object is too large" +msgstr "O objecto fornecido ? demasiado grande" + +msgid "Missing item in object" +msgstr "Item em falta no objecto" + +msgid "Not implemented" +msgstr "N?o implementado" + +msgid "Conflicting use" +msgstr "Utiliza??o em conflito" + +msgid "Invalid cipher mode" +msgstr "Modo de cifra inv?lido" + +msgid "Invalid flag" +msgstr "Flag inv?lido" + +msgid "Invalid handle" +msgstr "Identificador inv?lido" + +msgid "Result truncated" +msgstr "Resultado truncado" + +msgid "Incomplete line" +msgstr "Linha incompleta" + +msgid "Invalid response" +msgstr "Resposta inv?lida" + +msgid "No agent running" +msgstr "Nenhum agente em execu??o" + +msgid "Agent error" +msgstr "Erro no agente" + +msgid "Invalid data" +msgstr "Dados inv?lidos" + +msgid "Unspecific Assuan server fault" +msgstr "Falha n?o especificada no servidor Assuan" + +msgid "General Assuan error" +msgstr "Erro Assuan gen?rico" + +msgid "Invalid session key" +msgstr "Chave de sess?o inv?lida" + +msgid "Invalid S-expression" +msgstr "Express?o simb?lica inv?lida" + +msgid "Unsupported algorithm" +msgstr "Algoritmo n?o suportado" + +msgid "No pinentry" +msgstr "Sem pinentry" + +msgid "pinentry error" +msgstr "Erro no pinentry" + +msgid "Bad PIN" +msgstr "PIN errado" + +msgid "Invalid name" +msgstr "Nome inv?lido" + +msgid "Bad data" +msgstr "Dados errados" + +msgid "Invalid parameter" +msgstr "Par?metro inv?lido" + +msgid "Wrong card" +msgstr "Cart?o errado" + +msgid "No dirmngr" +msgstr "Sem dirmngr" + +msgid "dirmngr error" +msgstr "Erro no dirmngr" + +msgid "Certificate revoked" +msgstr "Certificado revogado" + +msgid "No CRL known" +msgstr "Sem CRL conhecido" + +msgid "CRL too old" +msgstr "CRL muito velho" + +msgid "Line too long" +msgstr "Linha demasiado longa" + +msgid "Not trusted" +msgstr "N?o ? de confian?a" + +msgid "Operation cancelled" +msgstr "Opera??o cancelada" + +msgid "Bad CA certificate" +msgstr "Certificado BA errado" + +msgid "Certificate expired" +msgstr "Certificado expirou" + +msgid "Certificate too young" +msgstr "Certificado demasiado novo" + +msgid "Unsupported certificate" +msgstr "Certificado n?o suportado" + +msgid "Unknown S-expression" +msgstr "Express?o simb?lica desconhecida" + +msgid "Unsupported protection" +msgstr "Protec??o n?o suportada" + +msgid "Corrupted protection" +msgstr "Protec??o corrompida" + +msgid "Ambiguous name" +msgstr "Nome amb?guo" + +msgid "Card error" +msgstr "Erro de cart?o" + +msgid "Card reset required" +msgstr "Reinicializa??o de cart?o necess?ria" + +msgid "Card removed" +msgstr "Cart?o removido" + +msgid "Invalid card" +msgstr "Cart?o inv?lido" + +msgid "Card not present" +msgstr "Cart?o n?o presente" + +msgid "No PKCS15 application" +msgstr "Sem aplica??o PKCS15" + +msgid "Not confirmed" +msgstr "N?o confirmado" + +msgid "Configuration error" +msgstr "Erro de configura??o" + +msgid "No policy match" +msgstr "Sem correspond?ncia de pol?tica" + +msgid "Invalid index" +msgstr "?ndice inv?lido" + +msgid "Invalid ID" +msgstr "Identificador inv?lido" + +msgid "No SmartCard daemon" +msgstr "Sem dem?nio de SmartCard" + +msgid "SmartCard daemon error" +msgstr "Erro no dem?nio de SmartCard" + +msgid "Unsupported protocol" +msgstr "Protocolo n?o suportado" + +msgid "Bad PIN method" +msgstr "M?todo de PIN errado" + +msgid "Card not initialized" +msgstr "Cart?o n?o inicializado" + +msgid "Unsupported operation" +msgstr "Opera??o n?o suportada" + +msgid "Wrong key usage" +msgstr "Utiliza??o de chave errada" + +msgid "Nothing found" +msgstr "Nada encontrado" + +msgid "Wrong blob type" +msgstr "Tipo de blob errado" + +msgid "Missing value" +msgstr "Valor em falta" + +msgid "Hardware problem" +msgstr "Problema de hardware" + +msgid "PIN blocked" +msgstr "PIN bloqueado" + +msgid "Conditions of use not satisfied" +msgstr "Condi??es de utiliza??o n?o satisfeitas" + +msgid "PINs are not synced" +msgstr "PINs n?o est?o sincronizados" + +msgid "Invalid CRL" +msgstr "CRL inv?lido" + +msgid "BER error" +msgstr "Erro de BER" + +msgid "Invalid BER" +msgstr "BER inv?lido" + +msgid "Element not found" +msgstr "Elemento n?o encontrado" + +msgid "Identifier not found" +msgstr "Identificador n?o encontrado" + +msgid "Invalid tag" +msgstr "Etiqueta inv?lida" + +msgid "Invalid length" +msgstr "Comprimento inv?lido" + +msgid "Invalid key info" +msgstr "Informa??o de chave errada" + +msgid "Unexpected tag" +msgstr "Etiqueta inesperada" + +msgid "Not DER encoded" +msgstr "N?o codificado atrav?s de DER" + +msgid "No CMS object" +msgstr "Sem objecto CMS" + +msgid "Invalid CMS object" +msgstr "Objecto CMS inv?lido" + +msgid "Unknown CMS object" +msgstr "Objecto CMS desconhecido" + +msgid "Unsupported CMS object" +msgstr "Objecto CMS n?o suportado" + +msgid "Unsupported encoding" +msgstr "Codifica??o n?o suportada" + +msgid "Unsupported CMS version" +msgstr "Vers?o de CMS n?o suportada" + +msgid "Unknown algorithm" +msgstr "Algoritmo desconhecido" + +msgid "Invalid crypto engine" +msgstr "Motor de encripta??o inv?lido" + +msgid "Public key not trusted" +msgstr "Chave p?blica n?o ? de confian?a" + +msgid "Decryption failed" +msgstr "Desencripta??o falhada" + +msgid "Key expired" +msgstr "Chave expirada" + +msgid "Signature expired" +msgstr "Assinatura expirada" + +msgid "Encoding problem" +msgstr "Problema de codifica??o" + +msgid "Invalid state" +msgstr "Estado inv?lido" + +msgid "Duplicated value" +msgstr "Valor duplicado" + +msgid "Missing action" +msgstr "Ac??o em falta" + +msgid "ASN.1 module not found" +msgstr "M?dulo ASN.1 n?o encontrado" + +msgid "Invalid OID string" +msgstr "Sequ?ncia OID inv?lida" + +msgid "Invalid time" +msgstr "Tempo inv?lido" + +msgid "Invalid CRL object" +msgstr "Objecto CRL inv?lido" + +msgid "Unsupported CRL version" +msgstr "Vers?o CRL n?o suportada" + +msgid "Invalid certificate object" +msgstr "Objecto de certificado inv?lido" + +msgid "Unknown name" +msgstr "Nome desconhecido" + +msgid "A locale function failed" +msgstr "Uma fun??o de localiza??o falhou" + +msgid "Not locked" +msgstr "N?o trancado" + +msgid "Protocol violation" +msgstr "Viola??o de protocolo" + +msgid "Invalid MAC" +msgstr "MAC inv?lido" + +msgid "Invalid request" +msgstr "Pedido inv?lido" + +msgid "Unknown extension" +msgstr "Extens?o desconhecida" + +msgid "Unknown critical extension" +msgstr "Extens?o cr?tica desconhecida" + +msgid "Locked" +msgstr "Trancado" + +msgid "Unknown option" +msgstr "Op??o desconhecida" + +msgid "Unknown command" +msgstr "Comando desconhecido" + +msgid "Not operational" +msgstr "N?o operacional" + +msgid "No passphrase given" +msgstr "Nenhuma senha dada" + +msgid "No PIN given" +msgstr "Sem PIN dado" + +msgid "Not enabled" +msgstr "N?o habilitado" + +msgid "No crypto engine" +msgstr "Sem motor de encripta??o" + +msgid "Missing key" +msgstr "Chave em falta" + +msgid "Too many objects" +msgstr "Demasiados objectos" + +msgid "Limit reached" +msgstr "Limite atingido" + +msgid "Not initialized" +msgstr "N?o inicializado" + +msgid "Missing issuer certificate" +msgstr "Certificado do emissor em falta" + +msgid "No keyserver available" +msgstr "Sem servidor de chaves dispon?vel" + +msgid "Invalid elliptic curve" +msgstr "Curva el?ptica inv?lida" + +msgid "Unknown elliptic curve" +msgstr "Curva el?ptica desconhecida" + +msgid "Duplicated key" +msgstr "Chave duplicada" + +msgid "Ambiguous result" +msgstr "Resultado amb?guo" + +msgid "No crypto context" +msgstr "Sem contexto de encripta??o" + +msgid "Wrong crypto context" +msgstr "Contexto de encripta??o errado" + +msgid "Bad crypto context" +msgstr "Contexto de encripta??o inv?lido" + +msgid "Conflict in the crypto context" +msgstr "Conflito no contexto de encripta??o" + +msgid "Broken public key" +msgstr "Chave p?blica quebrada" + +msgid "Broken secret key" +msgstr "Chave secreta quebrada" + +msgid "Invalid MAC algorithm" +msgstr "Algoritmo MAC inv?lido" + +msgid "Operation fully cancelled" +msgstr "Opera??o totalmente cancelada" + +msgid "Operation not yet finished" +msgstr "Opera??o ainda n?o completada" + +msgid "Buffer too short" +msgstr "Buffer demasiado curto" + +msgid "Invalid length specifier in S-expression" +msgstr "Especificador de comprimento inv?lido na express?o simb?lica" + +msgid "String too long in S-expression" +msgstr "Sequ?ncia de caracteres demasiado longa na express?o simb?lica" + +msgid "Unmatched parentheses in S-expression" +msgstr "Par?nteses n?o correspondidos na express?o simb?lica" + +msgid "S-expression not canonical" +msgstr "Express?o simb?lica n?o can?nica" + +msgid "Bad character in S-expression" +msgstr "Car?cter errado na express?o simb?lica" + +msgid "Bad quotation in S-expression" +msgstr "Plicas erradas na express?o simb?lica" + +msgid "Zero prefix in S-expression" +msgstr "Prefixo zero na express?o simb?lica" + +msgid "Nested display hints in S-expression" +msgstr "Dicas de exibi??o aninhadas na express?o simb?lica" + +msgid "Unmatched display hints" +msgstr "Dicas de exibi??o n?o correspondidas" + +msgid "Unexpected reserved punctuation in S-expression" +msgstr "Pontua??o reservada n?o esperada na express?o simb?lica" + +msgid "Bad hexadecimal character in S-expression" +msgstr "Car?cter hexadecimal errado na express?o simb?lica" + +msgid "Odd hexadecimal numbers in S-expression" +msgstr "N?meros hexadecimais ?mpares na express?o simb?lica" + +msgid "Bad octal character in S-expression" +msgstr "Car?cter octal errado na express?o simb?lica" + +msgid "No certificate chain" +msgstr "Sem cadeia de certificados" + +msgid "Certificate is too large" +msgstr "Certificado ? demasiado grande" + +msgid "Invalid record" +msgstr "Registo inv?lido" + +msgid "The MAC does not verify" +msgstr "O MAC n?o se verifica" + +msgid "Unexpected message" +msgstr "Mensagem inesperada" + +msgid "Compression or decompression failed" +msgstr "Compress?o ou descompress?o falhada" + +msgid "A counter would wrap" +msgstr "Um contador daria a volta" + +msgid "Fatal alert message received" +msgstr "Mensagem de alerta fatal recebida" + +msgid "No cipher algorithm" +msgstr "Algoritmo de criptografia inexistente" + +msgid "Missing client certificate" +msgstr "Certificado cliente em falta" + +msgid "Close notification received" +msgstr "Notifica??o de encerramento recebida" + +msgid "Ticket expired" +msgstr "Ticket expirou" + +msgid "Bad ticket" +msgstr "Ticket errado" + +msgid "Unknown identity" +msgstr "Identidade desconhecida" + +msgid "Bad certificate message in handshake" +msgstr "Mensagem de certificado errada no handshake" + +msgid "Bad certificate request message in handshake" +msgstr "Mensagem de pedido de certificado errada no handshake" + +msgid "Bad certificate verify message in handshake" +msgstr "Mensagem de verifica??o de certificado errada no handshake" + +msgid "Bad change cipher messsage in handshake" +msgstr "Mensagem de altera??o de certificado errada no handshake" + +msgid "Bad client hello message in handshake" +msgstr "Mensagem de hello do cliente errada no handshake" + +msgid "Bad server hello message in handshake" +msgstr "Mensagem de hello do servidor errada no handshake" + +msgid "Bad server hello done message in hanshake" +msgstr "Mensagem de hello done do servidor errada no handshake" + +msgid "Bad finished message in handshake" +msgstr "Mensagem de conclus?o errada no handshake" + +msgid "Bad server key exchange message in handshake" +msgstr "Mensagem de troca de chaves do servidor errada no handshake" + +msgid "Bad client key exchange message in handshake" +msgstr "Mensagem de troca de chaves do cliente errada no handshake" + +msgid "Bogus string" +msgstr "Sequ?ncia de caracteres adulterada" + +msgid "Key disabled" +msgstr "Chave desabilitada" + +msgid "Not possible with a card based key" +msgstr "N?o poss?vel com uma chave baseada num cart?o" + +msgid "Invalid lock object" +msgstr "Objecto de tranca inv?lido" + +msgid "General IPC error" +msgstr "Erro gen?rico de IPC" + +msgid "IPC accept call failed" +msgstr "Chamada de aceita??o de IPC falhada" + +msgid "IPC connect call failed" +msgstr "Chamada de conex?o de IPC falhada" + +msgid "Invalid IPC response" +msgstr "Resposta de IPC inv?lida" + +msgid "Invalid value passed to IPC" +msgstr "Valor inv?lido passado ao IPC" + +msgid "Incomplete line passed to IPC" +msgstr "Linha inv?lida passada ao IPC" + +msgid "Line passed to IPC too long" +msgstr "Linha passada ao IPC demasiado longa" + +msgid "Nested IPC commands" +msgstr "Comandos IPC aninhados" + +msgid "No data callback in IPC" +msgstr "Sem retorno de chamada de dados no IPC" + +msgid "No inquire callback in IPC" +msgstr "Sem retorno de chamada de inquiri??o no IPC" + +msgid "Not an IPC server" +msgstr "N?o ? um servidor IPC" + +msgid "Not an IPC client" +msgstr "N?o ? um cliente IPC" + +msgid "Problem starting IPC server" +msgstr "Problema na inicia??o do servidor IPC" + +msgid "IPC read error" +msgstr "Erro de leitura de IPC" + +msgid "IPC write error" +msgstr "Erro de escrita de IPC" + +msgid "Too much data for IPC layer" +msgstr "Demasiados dados para a camada IPC" + +msgid "Unexpected IPC command" +msgstr "Comando IPC inesperado" + +msgid "Unknown IPC command" +msgstr "Comando IPC desconhecido" + +msgid "IPC syntax error" +msgstr "Erro de sintaxe IPC" + +msgid "IPC call has been cancelled" +msgstr "Chamada de IPC foi cancelada" + +msgid "No input source for IPC" +msgstr "Sem fonte de entrada para o IPC" + +msgid "No output source for IPC" +msgstr "Nenhuma fonte de sa?da para IPC" + +msgid "IPC parameter error" +msgstr "Erro de par?metro IPC" + +msgid "Unknown IPC inquire" +msgstr "Inquiri??o IPC desconhecida" + +msgid "User defined error code 1" +msgstr "C?digo de erro definido pelo utilizador 1" + +msgid "User defined error code 2" +msgstr "C?digo de erro definido pelo utilizador 2" + +msgid "User defined error code 3" +msgstr "C?digo de erro definido pelo utilizador 3" + +msgid "User defined error code 4" +msgstr "C?digo de erro definido pelo utilizador 4" + +msgid "User defined error code 5" +msgstr "C?digo de erro definido pelo utilizador 5" + +msgid "User defined error code 6" +msgstr "C?digo de erro definido pelo utilizador 6" + +msgid "User defined error code 7" +msgstr "C?digo de erro definido pelo utilizador 7" + +msgid "User defined error code 8" +msgstr "C?digo de erro definido pelo utilizador 8" + +msgid "User defined error code 9" +msgstr "C?digo de erro definido pelo utilizador 9" + +msgid "User defined error code 10" +msgstr "C?digo de erro definido pelo utilizador 10" + +msgid "User defined error code 11" +msgstr "C?digo de erro definido pelo utilizador 11" + +msgid "User defined error code 12" +msgstr "C?digo de erro definido pelo utilizador 12" + +msgid "User defined error code 13" +msgstr "C?digo de erro definido pelo utilizador 13" + +msgid "User defined error code 14" +msgstr "C?digo de erro definido pelo utilizador 14" + +msgid "User defined error code 15" +msgstr "C?digo de erro definido pelo utilizador 15" + +msgid "User defined error code 16" +msgstr "C?digo de erro definido pelo utilizador 16" + +msgid "System error w/o errno" +msgstr "Erro de sistema sem errno" + +msgid "Unknown system error" +msgstr "Erro de sistema desconhecido" + +msgid "End of file" +msgstr "Fim do ficheiro" + +msgid "Unknown error code" +msgstr "C?digo de erro desconhecido" + +#, c-format +msgid "Usage: %s GPG-ERROR [...]\n" +msgstr "Utiliza??o: %s GPG-ERROR [...]\n" + +#, c-format +msgid "%s: warning: could not recognize %s\n" +msgstr "%s: aviso: n?o consegui reconhecer %s\n" -- 2.1.3 From dkg at fifthhorseman.net Tue Nov 25 04:24:24 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 24 Nov 2014 22:24:24 -0500 Subject: GnuPG 2.1.0: key too large, import stops In-Reply-To: <20141125022610.GA93687@tower.spodhuis.org> References: <20141122010959.GA77998@tower.spodhuis.org> <87mw7hgffu.fsf@vigenere.g10code.de> <20141125022610.GA93687@tower.spodhuis.org> Message-ID: <5473F668.6000205@fifthhorseman.net> On 11/24/2014 09:26 PM, Phil Pennock wrote: > Is there a way to skip the import of that one key, continuing on, so > that one unimportable key doesn't abort the entire keyring? I agree that this would be desirable behavior. > Ah, dirmngr.conf and the `keyserver-options ca-cert-file=...` from > gnupg.conf is now ignored, okay. shouldn't gnupg 2.1 at least raise a warning about that keyserver-option being ignored, and recommend setting hkp-cacert in ~/.dirmngr.conf instead? > * the hkp-cacert filename *must* end `.pem` if the file is to be read > in PEM format; this appears to be an undocumented constraint This appears to be documented in dirmngr.text, fwict: --hkp-cacert file Use the root certificates in file for verification of the TLS certificates used with hkps (keyserver access over TLS). If the file is in PEM format a suffix of .pem is expected for file. This option may be given multiple times to add more root cer? tificates. (though i admit that when i stumbled across this recently i didn't notice it my first couple passes through "man dirmngr" either) > * there's no logging or handling for showing why hkps: is failing if > GnuPG was built without TLS support I agree that this would also be a nice thing to have -- what error-reporting mechanisms are possible between dirmngr and gnupg 2.1? > And the last point is the critical one: because curl is not being used > anymore and GnuTLS must be available, there's a regression in default > behaviour from the configure command-line given the dependent libraries; > this one isn't anyone's fault, but I think that there probably needs to > be clearer communication to OS packagers that they now need to make sure > that GnuTLS is available. fwiw, i updated the build-deps of gnupg 2.1.0 to include gnutls specifically because of this change. I think it's the right way to go. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue Nov 25 13:40:02 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 25 Nov 2014 13:40:02 +0100 Subject: [Announce] [security fix] Libksba 1.3.2 for GnuPG released Message-ID: <87y4qzbgil.fsf@vigenere.g10code.de> Hello! I am pleased to announce version 1.3.2 of Libksba. This is a *security fix* release and all users of Libksba should update to this version. Note that GnuPG 2.x makes use of Libksba and thus all user of GnuPG 2.x need to install this new version of libksba and at least restart the dirmngr process. Libksba is an X.509 and CMS (PKCS#7) library. It is for example required by the S/MIME part of GnuPG-2 (gpgsm and dirmngr). The only build requirement for Libksba itself is the libgpg-error package. There are no other dependencies; actual cryptographic operations need to be done by the user. Libksba is distributed under the LGPLv3+/GPLv2+. There are no user tools accompanying this software, thus it is mostly relevant to developers. You may download the library and its OpenPGP signature from: ftp://ftp.gnupg.org/gcrypt/libksba/libksba-1.3.2.tar.bz2 (587k) ftp://ftp.gnupg.org/gcrypt/libksba/libksba-1.3.2.tar.bz2.sig The SHA-1 checksum is 37d0893a587354af2b6e49f6ae701ca84f52da67 libksba-1.3.2.tar.bz2 Noteworthy changes in version 1.3.2 =================================== * Fixed a buffer overflow in ksba_oid_to_str. Impact of the security bug ========================== By using special crafted S/MIME messages or ECC based OpenPGP data, it is possible to create a buffer overflow. The bug is not easy to exploit because there only 80 possible values which can be used to overwrite memory. However, a denial of service is possible and someone may come up with other clever attacks. Thus this should be fix. Affected versions: All Libksba versions < 1.3.2 Background: Yesterday Hanno B?ck found an invalid memory access in the 2.1 branch of GnuPG by conveying a malformed OID as part of an ECC key. It turned out that this bug has also been in libksba ever since and affects at least gpgsm and dirmngr. The code to convert an OID to its string representation has an obvious error of not considering an invalid encoding for arc-2. A first byte of 0x80 can be used to make a value of less then 80 and we then subtract 80 from it as required by the OID encoding rules. Due to the use of an unsigned integer this results in a pretty long value which won't fit anymore into the allocated buffer. The actual fix for lib Libksba is commit f715b9e. Support ======= For help on developing with Libksba you should read the included manual and optional ask on the gnupg-devel mailing list [1]. A listing with commercial support offers for GnuPG and related software is available at the GnuPG web site [2]. The driving force behind the development of GnuPG is my company g10 Code GmbH. Maintenance and improvement of GnuPG and related software takes up most of my time. To allow me to continue this work, I kindly asks to either purchase a support contract, engage g10 Code for custom work, or to donate money: https://gnupg.org/donate/ Thanks ====== Thanks to Hanno B?ck for taking the time to run fuzzing tests on GnuPG and reporting them. Happy hacking, Werner [1] https://lists.gnupg.org/mailman/listinfo/gnupg-devel [2] https://gnupg.org/service.html -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From kristian.fiskerstrand at sumptuouscapital.com Tue Nov 25 19:27:11 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 25 Nov 2014 19:27:11 +0100 Subject: [PATCH] Only report hkps scheme when available Message-ID: <5474C9FF.2050009@sumptuouscapital.com> Only report support for the hkps scheme when GnuPG / dirmngr has been built with a TLS library. -- This helps debuging and enable the user to detect whether support for hkps is included by doing a `gpg-connect-agent --dirmngr 'keyserver --help' /bye`. Currently hkps will be listed as a supported scheme but trying to add a keyserver using it will silently fail. As a digression, https is never listed as a valid scheme. -- ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Ne nuntium necare Don't kill the messenger -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Only-report-hkps-scheme-when-available.patch Type: text/x-patch Size: 1577 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed Nov 26 14:41:33 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 26 Nov 2014 14:41:33 +0100 Subject: updating translations from non-UTF-8 to UTF-8 In-Reply-To: <87sih8t1me.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 24 Nov 2014 22:12:09 -0500") References: <87sih8t1me.fsf@alice.fifthhorseman.net> Message-ID: <87h9xm3wqa.fsf@vigenere.g10code.de> On Tue, 25 Nov 2014 04:12, dkg at fifthhorseman.net said: > We just got some Spanish translations for GnuPG 1.4.x and 2.0.x reported > to the Debian Project by Manuel "Venturi" Porras Peralta. I pushed the update for 2.0. The next time I work on 1.4 I will update it too. > I think the right way to apply them in git is to convert po/es.po to > UTF-8 in one commit and then to drop the new file in place, something Good idea. > git checkout STABLE-BRANCH-1-4 > iconf -f iso-8859-1 -t utf-8 < po/es.po | sed s/ISO-8859-1/UTF-8/ > po/es.po.utf8 msgconv -t utf-8 es.po >es.po-new is easier ;-) > git commit --author 'Manuel "Venturi" Porras Peralta ' BTW, if you use Emacs with an older Magit do not forget to eval --8<---------------cut here---------------start------------->8--- (defun reset-git-env () "Reset the environ vaiables used by GIT. This is required to fix a bug in Magit which does not reset them after a rewrite." (interactive) (let ((list '("GIT_AUTHOR_DATE" "GIT_AUTHOR_EMAIL" "GIT_AUTHOR_MAME"))) (while list (setenv (car list)) (setq list (cdr list))))) --8<---------------cut here---------------end--------------->8--- after this or are rewrite operation. Otherwise all following commits are wrongly attributed. > Please let me know if these are applied upstream! David Pr?vot also tracks them; I notified him. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gnupg-devel at spodhuis.org Fri Nov 28 00:40:25 2014 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Thu, 27 Nov 2014 23:40:25 +0000 Subject: GnuPG 2.1.0: key too large, import stops In-Reply-To: <20141125022610.GA93687@tower.spodhuis.org> References: <20141122010959.GA77998@tower.spodhuis.org> <87mw7hgffu.fsf@vigenere.g10code.de> <20141125022610.GA93687@tower.spodhuis.org> Message-ID: <20141127234024.GA66081@tower.spodhuis.org> On 2014-11-25 at 02:26 +0000, Phil Pennock wrote: > And the last point is the critical one: because curl is not being used > anymore and GnuTLS must be available, there's a regression in default > behaviour from the configure command-line given the dependent libraries; > this one isn't anyone's fault, but I think that there probably needs to > be clearer communication to OS packagers that they now need to make sure > that GnuTLS is available. > > I'm using FreeBSD Ports, and the FreeBSD Port does not register GnuTLS > as a dependency, and I'm building ports with poudriere, so that each > port build is isolated (this is the default for the packages shipped by > FreeBSD) the end result is a GnuPG package with no TLS support. > > I'll fiddle some more to hack my port build. Fixed the Ports build, filed a FreeBSD bug with patch attached: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195459 raw patch: https://bz-attachments.freebsd.org/attachment.cgi?id=149946&action=diff&collapsed=&context=patch&format=raw&headers=1 -Phil From mailinglists at gusnan.se Sun Nov 30 04:42:38 2014 From: mailinglists at gusnan.se (Andreas =?UTF-8?B?UsO2bm5xdWlzdA==?=) Date: Sun, 30 Nov 2014 04:42:38 +0100 Subject: [PATCH] typo nown/known Message-ID: <20141130044238.7dfc40e4@debian-workstation.lan> GPA typo nown/known - patch attached best regards -- Andreas R?nnquist mailinglists at gusnan.se gusnan at gusnan.se -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-typo-nown-known.patch Type: text/x-patch Size: 1015 bytes Desc: not available URL: From architekt at coding4coffee.org Sun Nov 30 16:35:29 2014 From: architekt at coding4coffee.org (Fabian Mewes) Date: Sun, 30 Nov 2014 16:35:29 +0100 Subject: [PATCH] tools/watchgnupg: Include for fd_set Message-ID: <1417361729-25456-1-git-send-email-architekt@coding4coffee.org> This is necessary to compile GnuPG with musl libc Signed-off-by: Fabian Mewes --- tools/watchgnupg.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/watchgnupg.c b/tools/watchgnupg.c index 4f4d54d..c2384c8 100644 --- a/tools/watchgnupg.c +++ b/tools/watchgnupg.c @@ -29,6 +29,7 @@ #include #include #include +#include #include #include #include -- 2.1.3