From wk at gnupg.org Mon Dec 1 09:23:31 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 01 Dec 2014 09:23:31 +0100 Subject: [PATCH] tools/watchgnupg: Include for fd_set In-Reply-To: <1417361729-25456-1-git-send-email-architekt@coding4coffee.org> (Fabian Mewes's message of "Sun, 30 Nov 2014 16:35:29 +0100") References: <1417361729-25456-1-git-send-email-architekt@coding4coffee.org> Message-ID: <87sigzzsl8.fsf@vigenere.g10code.de> On Sun, 30 Nov 2014 16:35, architekt at coding4coffee.org said: > This is necessary to compile GnuPG with musl libc What is musl libc ? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From architekt at coding4coffee.org Mon Dec 1 10:40:25 2014 From: architekt at coding4coffee.org (Fabian Mewes) Date: Mon, 1 Dec 2014 10:40:25 +0100 Subject: [PATCH] tools/watchgnupg: Include for fd_set In-Reply-To: <87sigzzsl8.fsf@vigenere.g10code.de> References: <1417361729-25456-1-git-send-email-architekt@coding4coffee.org> <87sigzzsl8.fsf@vigenere.g10code.de> Message-ID: <20141201094023.GA9295@remote.coding4coffee.org> On Mon, Dec 01, 2014 at 09:23:31AM +0100, Werner Koch wrote: > On Sun, 30 Nov 2014 16:35, architekt at coding4coffee.org said: > > This is necessary to compile GnuPG with musl libc > > What is musl libc ? It is a C standard library, see http://www.musl-libc.org/ From dimitri.j.ledkov at intel.com Mon Dec 1 11:17:42 2014 From: dimitri.j.ledkov at intel.com (Dimitri John Ledkov) Date: Mon, 1 Dec 2014 10:17:42 +0000 Subject: [PATCH] pinentry: More gseal/gtk3 compatibility in the gtk+3 UI. In-Reply-To: <1415012703-7153-1-git-send-email-dimitri.j.ledkov@intel.com> References: <1415012703-7153-1-git-send-email-dimitri.j.ledkov@intel.com> Message-ID: Hello, On 3 November 2014 at 11:05, Dimitri John Ledkov wrote: > 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(-) > This patch improves compatibility with Gtk+3, without removing support for any of the currently supported Gtk+2 versions. Looking at the git repository for the pinentry this patch has not been applied. Is work towards improving Gtk+3 support not welcomed? This is not a complete port and further changes would be needed to support Gtk+3. -- Regards, Dimitri. Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. From wk at gnupg.org Mon Dec 1 15:56:18 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 01 Dec 2014 15:56:18 +0100 Subject: [PATCH] tools/watchgnupg: Include for fd_set In-Reply-To: <20141201094023.GA9295@remote.coding4coffee.org> (Fabian Mewes's message of "Mon, 1 Dec 2014 10:40:25 +0100") References: <1417361729-25456-1-git-send-email-architekt@coding4coffee.org> <87sigzzsl8.fsf@vigenere.g10code.de> <20141201094023.GA9295@remote.coding4coffee.org> Message-ID: <87k32bzael.fsf@vigenere.g10code.de> On Mon, 1 Dec 2014 10:40, architekt at coding4coffee.org said: > It is a C standard library, see http://www.musl-libc.org/ Okay, I pushed a change for this. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Dec 3 10:48:16 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 03 Dec 2014 10:48:16 +0100 Subject: I want to help improve the documentation. In-Reply-To: <5442C186.8060409@riseup.net> (Georgiy Treyvus's message of "Sat, 18 Oct 2014 15:37:42 -0400") References: <5442C186.8060409@riseup.net> Message-ID: <87y4qpvzbz.fsf@vigenere.g10code.de> Hi Georgiy, quite some time ago you offered to help on the documentation. I think a first step here is to find someone who considers this important enough to take responsibility to manage the development of documentation. I have always tried to do that but I am overloaded anyway and thus I better concentrate on the stuff I can do best. I mentioned the need for a doc maintainer en passant some time ago but there was no response on it. See and edit also "Maintainer wanted" at http://wiki.gnupg.org/documentation . Do you think that is something you can do? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Dec 3 11:10:02 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 03 Dec 2014 11:10:02 +0100 Subject: [PATCH] pinentry: More gseal/gtk3 compatibility in the gtk+3 UI. In-Reply-To: (Dimitri John Ledkov's message of "Mon, 1 Dec 2014 10:17:42 +0000") References: <1415012703-7153-1-git-send-email-dimitri.j.ledkov@intel.com> Message-ID: <87tx1dvybp.fsf@vigenere.g10code.de> On Mon, 1 Dec 2014 11:17, dimitri.j.ledkov at intel.com said: > This patch improves compatibility with Gtk+3, without removing support > for any of the currently supported Gtk+2 versions. I have not looked at it but I plan to apply it the next time I turn my head to pinentry. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Dec 3 11:12:31 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 03 Dec 2014 11:12:31 +0100 Subject: [PATCH] handle disambiguation of --throw-keyids more cleanly In-Reply-To: <54735D34.9080701@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 24 Nov 2014 11:30:44 -0500") References: <1416608751-12382-1-git-send-email-dkg@fifthhorseman.net> <87ioi5gfbg.fsf@vigenere.g10code.de> <54735D34.9080701@fifthhorseman.net> Message-ID: <87ppc1vy7k.fsf@vigenere.g10code.de> On Mon, 24 Nov 2014 17:30, dkg at fifthhorseman.net said: > so is --throw-keyid just an older variant of the command? Do we plan to > keep it around forever? Quite possible but not worth to research it. > c) go ahead and remove throw-keyid entirely as we transition to 2.1, > where several other minor changes are happening. Good idea. I'll do it now. While I looked at it I figured that GPGME has no support for hidden recipients and thus does not need throw-keyid. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Dec 4 10:54:33 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 04 Dec 2014 10:54:33 +0100 Subject: GnuPG 2.1.0: key too large, import stops In-Reply-To: <20141125022610.GA93687@tower.spodhuis.org> (Phil Pennock's message of "Tue, 25 Nov 2014 02:26:11 +0000") References: <20141122010959.GA77998@tower.spodhuis.org> <87mw7hgffu.fsf@vigenere.g10code.de> <20141125022610.GA93687@tower.spodhuis.org> Message-ID: <87k327u4di.fsf@vigenere.g10code.de> On Tue, 25 Nov 2014 03:26, gnupg-devel at spodhuis.org said: > 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? Done: gpg: Allow import of large keys. * g10/import.c (import): Skip too large keys. * kbx/keybox-file.c (IMAGELEN_LIMIT): Change limit from 2MB to 5MB. -- The key which triggered the problem was 0x57930DAB0B86B067. With this patch it can be imported. Keys larger than the now increased limit of 5MB will are skipped and the already existing not_imported counter is bumped up. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From mailinglisten at hauke-laging.de Thu Dec 4 11:05:44 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 04 Dec 2014 11:05:44 +0100 Subject: GnuPG 2.1.0: key too large, import stops In-Reply-To: <87k327u4di.fsf@vigenere.g10code.de> References: <20141122010959.GA77998@tower.spodhuis.org> <20141125022610.GA93687@tower.spodhuis.org> <87k327u4di.fsf@vigenere.g10code.de> Message-ID: <2202794.Vf58GbzmGN@inno> Am Do 04.12.2014, 10:54:33 schrieb Werner Koch: > gpg: Allow import of large keys. > > * g10/import.c (import): Skip too large keys. > * kbx/keybox-file.c (IMAGELEN_LIMIT): Change limit from 2MB to > 5MB. -- Wouldn't it make sense to leave this value rather low and create an option for overriding? --max-file-size 5000000 If a large cert is skipped a warning pointing at this option could be printed. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- 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 wk at gnupg.org Thu Dec 4 15:09:53 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 04 Dec 2014 15:09:53 +0100 Subject: GnuPG 2.1.0: key too large, import stops In-Reply-To: <2202794.Vf58GbzmGN@inno> (Hauke Laging's message of "Thu, 04 Dec 2014 11:05:44 +0100") References: <20141122010959.GA77998@tower.spodhuis.org> <20141125022610.GA93687@tower.spodhuis.org> <87k327u4di.fsf@vigenere.g10code.de> <2202794.Vf58GbzmGN@inno> Message-ID: <87bnnjtsjy.fsf@vigenere.g10code.de> On Thu, 4 Dec 2014 11:05, mailinglisten at hauke-laging.de said: > Wouldn't it make sense to leave this value rather low and create an > option for overriding? Note that this is a limit for a single keyblock and not for a file. Large keyblock are really problematic because they make a key unusable on smaller devices. > If a large cert is skipped a warning pointing at this option could be Using --import-options import-minimal can help to import the key. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Fri Dec 5 06:06:57 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 05 Dec 2014 14:06:57 +0900 Subject: scd: Fix for NIST P-256 Message-ID: <54813D71.1010507@fsij.org> Hello, Scdaemon in 2.1.x has some bugs. I'm fixinig one by one. Here is the one for ECC with NIST P-256 curve. Curren experimental branch of Gnuk (rsa_4096_support at git.gniibe.org) has support of RSA-4096 and ECC (NIST P-256, SEC P256K1, and EdDSA) along with RSA-2048. For RSA-4096, it takes more than 8.7 second. For NIST P-256, it's 0.28 second (real time measured on host PC by 'time gpg --clearsign...'). The fixes are simple error handlings and reflect private key format change of curve name. Once, we used curve OID, but it's name now. OK to commit? * g10/card-util.c (card_store_subkey): Error check. * scd/app-openpgp.c (ecc_writekey): Support NIST P-256. (do_writekey): Error check. diff --git a/g10/card-util.c b/g10/card-util.c index 3d5c43c..4f1c9d8 100644 --- a/g10/card-util.c +++ b/g10/card-util.c @@ -1619,7 +1619,7 @@ card_store_subkey (KBNODE node, int use) goto leave; epoch2isotime (timebuf, (time_t)pk->timestamp); - agent_keytocard (hexgrip, keyno, rc, info.serialno, timebuf); + rc = agent_keytocard (hexgrip, keyno, rc, info.serialno, timebuf); if (rc) log_error (_("KEYTOCARD failed: %s\n"), gpg_strerror (rc)); diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index 9b4ab22..e27a2cb 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -3258,8 +3258,8 @@ ecc_writekey (app_t app, gpg_error_t (*pincb)(void*, const char *, char **), u32 created_at = 0; int curve = CURVE_UNKNOWN; - /* (private-key(ecdsa(curve%s)(q%m)(d%m))(created-at%d)): - curve = "1.2.840.10045.3.1.7" */ + /* (private-key(ecc(curve%s)(q%m)(d%m))(created-at%d)): + curve = "NIST P-256" */ /* (private-key(ecc(curve%s)(q%m)(d%m))(created-at%d)): curve = "secp256k1" */ /* (private-key(ecc(curve%s)(flags eddsa)(q%m)(d%m))(created-at%d)): @@ -3281,12 +3281,18 @@ ecc_writekey (app_t app, gpg_error_t (*pincb)(void*, const char *, char **), if ((err = parse_sexp (&buf, &buflen, &depth, &tok, &toklen))) goto leave; - if (tok && toklen == 19 && !memcmp (tok, "1.2.840.10045.3.1.7", 19)) + if (tok && toklen == 10 && !memcmp (tok, "NIST P-256", 10)) curve = CURVE_NIST_P256; else if (tok && toklen == 9 && !memcmp (tok, "secp256k1", 9)) curve = CURVE_SEC_P256K1; else if (tok && toklen == 7 && !memcmp (tok, "Ed25519", 7)) curve = CURVE_ED25519; + else + { + log_error (_("unsupported curve\n")); + err = gpg_error (GPG_ERR_INV_VALUE); + goto leave; + } } else if (tok && toklen == 1) { @@ -3491,15 +3497,15 @@ do_writekey (app_t app, ctrl_t ctrl, if ((err = parse_sexp (&buf, &buflen, &depth, &tok, &toklen))) goto leave; if (tok && toklen == 3 && memcmp ("rsa", tok, toklen) == 0) - rsa_writekey (app, pincb, pincb_arg, keyno, buf, buflen, depth); + err = rsa_writekey (app, pincb, pincb_arg, keyno, buf, buflen, depth); else if ((tok && toklen == 3 && memcmp ("ecc", tok, toklen) == 0 && (keyno == 0 || keyno == 2)) || (tok && toklen == 5 && memcmp ("ecdsa", tok, toklen) == 0)) - ecc_writekey (app, pincb, pincb_arg, keyno, buf, buflen, depth); + err = ecc_writekey (app, pincb, pincb_arg, keyno, buf, buflen, depth); else if ((tok && toklen == 3 && memcmp ("ecc", tok, toklen) == 0 && keyno == 1) || (tok && toklen == 4 && memcmp ("ecdh", tok, toklen) == 0)) - ecdh_writekey (app, pincb, pincb_arg, keyno, buf, buflen, depth); + err = ecdh_writekey (app, pincb, pincb_arg, keyno, buf, buflen, depth); else { err = gpg_error (GPG_ERR_WRONG_PUBKEY_ALGO); -- From wk at gnupg.org Fri Dec 5 08:46:16 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 05 Dec 2014 08:46:16 +0100 Subject: scd: Fix for NIST P-256 In-Reply-To: <54813D71.1010507@fsij.org> (NIIBE Yutaka's message of "Fri, 05 Dec 2014 14:06:57 +0900") References: <54813D71.1010507@fsij.org> Message-ID: <87tx1asfnb.fsf@vigenere.g10code.de> On Fri, 5 Dec 2014 06:06, gniibe at fsij.org said: > For RSA-4096, it takes more than 8.7 second. For NIST P-256, it's > 0.28 second (real time measured on host PC by 'time gpg --clearsign...'). That is quite an improvement. > The fixes are simple error handlings and reflect private key format > change of curve name. Once, we used curve OID, but it's name now. > > OK to commit? Sure, your gnuk is the only ECC implementation anyway and thus you should know best. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Fri Dec 5 09:50:39 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 05 Dec 2014 17:50:39 +0900 Subject: scd: Fix for EdDSA In-Reply-To: <87tx1asfnb.fsf@vigenere.g10code.de> References: <54813D71.1010507@fsij.org> <87tx1asfnb.fsf@vigenere.g10code.de> Message-ID: <548171DF.8030200@fsij.org> Fix for NIST P-256 curve has been pushed. On 12/05/2014 04:46 PM, Werner Koch wrote: > Sure, your gnuk is the only ECC implementation anyway and thus you > should know best. Thank you. I should, yes. But I am keeping up changes of GnuPG 2.1.0, now. I need to fix ECC related code of scdaemon. Well, here is another change needed to support EdDSA. It works with experimental version of Gnuk. It takes about 0.29 second to sign. It's a bit slower than NIST P-256, but I guess that people want to use this than NIST P-256. diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index e27a2cb..663b7d3 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -752,7 +752,7 @@ get_algo_byte (key_type_t key_type) else if (key_type == KEY_TYPE_ECDH) return 18; else if (key_type == KEY_TYPE_EDDSA) - return 105; /* (experimental) */ + return 22; else return 1; /* RSA */ } @@ -790,8 +790,10 @@ store_fpr (app_t app, int keynumber, u32 timestamp, { m[i] = va_arg (ap, const unsigned char *); mlen[i] = va_arg (ap, size_t); - for (; mlen[i] && !*m[i]; mlen[i]--, m[i]++) /* strip leading zeroes */ - ; + if (key_type != KEY_TYPE_EDDSA) + /* strip off leading zeroes */ + for (; mlen[i] && !*m[i]; mlen[i]--, m[i]++) + ; if (key_type == KEY_TYPE_RSA || i == 1) n += 2; n += mlen[i]; -- From wk at gnupg.org Fri Dec 5 10:04:57 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 05 Dec 2014 10:04:57 +0100 Subject: scd: Fix for EdDSA In-Reply-To: <548171DF.8030200@fsij.org> (NIIBE Yutaka's message of "Fri, 05 Dec 2014 17:50:39 +0900") References: <54813D71.1010507@fsij.org> <87tx1asfnb.fsf@vigenere.g10code.de> <548171DF.8030200@fsij.org> Message-ID: <87ppbysc06.fsf@vigenere.g10code.de> On Fri, 5 Dec 2014 09:50, gniibe at fsij.org said: > second to sign. It's a bit slower than NIST P-256, but I guess that > people want to use this than NIST P-256. Sure. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From aheinecke at intevation.de Fri Dec 5 11:29:22 2014 From: aheinecke at intevation.de (Andre Heinecke) Date: Fri, 05 Dec 2014 11:29:22 +0100 Subject: Document no-allow-mark-trusted for gpg-agent Message-ID: <2183000.zZpjiiEYsy@esus> There was some confusion in our organization if allow-mark-trusted for Root CA's was default or not. It was changed in master with 78a56b14 but the documentation still documented the allow-mark-trusted option instead of no-allow-mark-trusted. Please apply attached patch to the gpg-agent documentation Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Document-no-allow-mark-trusted-option.patch Type: text/x-patch Size: 3185 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From dgouttegattat at incenp.org Sun Dec 7 03:41:52 2014 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sun, 07 Dec 2014 03:41:52 +0100 Subject: [PATCH] Scute sometimes fails with GnuPG 2.1.0 Message-ID: <5483BE70.2010908@incenp.org> Hi folks, This is a follow-up to a discussion that occured on this list a few months ago [1], about Scute and the fact that the last released version didn?t work with TLS 1.2. At that time, Werner Koch proposed a patch against Scute [2], but it seemed not to work with GnuPG 2.0.26. With GnuPG 2.1.0 and Werner?s patch applied to Scute, it mostly works fine, but Scute *sometimes* fails with a generic error (CKR_FUNCTION_FAILED). As far as my understanding of the problem goes, it comes from the fact that GnuPG Agent sometimes prepends a nul byte to the signature data it got from Scdaemon, iff that signature begins with a byte with the 7th bit set. This extra byte foils the parsing code inside Scute, which only expects the signature to be 128- or 256-byte long. The patch below attempts to fix the problem in Scute, first by reading the actual size of the signature from the S-expression, and second by removing the first nul byte, if present. This is a rather crude attempt (although it works, for me anyway), and as the comment in the code says, it would probably be better to actually parse the S-expression, and then extract the signature data from it. What do you think of using libgcrypt?s gcry_sexp_* functions to do that? Regards, Damien [1] http://lists.gnupg.org/pipermail/gnupg-devel/2014-August/028709.html [2] http://lists.gnupg.org/pipermail/gnupg-devel/2014-September/028750.html --- src/agent.c | 54 ++++++++++++++++++++++++++++++------------------------ 1 file changed, 30 insertions(+), 24 deletions(-) diff --git a/src/agent.c b/src/agent.c index edf8d2d..1e4e0ca 100644 --- a/src/agent.c +++ b/src/agent.c @@ -981,13 +981,12 @@ pksign_cb (void *opaque, const void *buffer, size_t length) } -#define SIG_PREFIX "(7:sig-val(3:rsa(1:s128:" -#define SIG_PREFIX_2 "(7:sig-val(3:rsa(1:s256:" +#define SIG_PREFIX "(7:sig-val(3:rsa(1:s" #define SIG_PREFIX_LEN (sizeof (SIG_PREFIX) - 1) #define SIG_POSTFIX ")))" #define SIG_POSTFIX_LEN (sizeof (SIG_POSTFIX) - 1) -#define SIG_LEN 128 -#define SIG_LEN_2 256 +#define SIG_MIN_LEN 128 +#define SIG_MAX_LEN 256 static unsigned char sha1_prefix[15] = /* (1.3.14.3.2.26) */ @@ -1033,14 +1032,14 @@ scute_agent_sign (char *grip, unsigned char *data, int len, if (sig_result == NULL) { /* FIXME: We return the largest supported size - is that correct? */ - *sig_len = SIG_LEN_2; + *sig_len = SIG_MAX_LEN; return 0; } if (len > MAX_DATA_LEN) return gpg_error (GPG_ERR_INV_ARG); - if (grip == NULL || sig_result == NULL || *sig_len < SIG_LEN) + if (grip == NULL || sig_result == NULL || *sig_len < SIG_MIN_LEN) return gpg_error (GPG_ERR_INV_ARG); snprintf (cmd, sizeof (cmd), "SIGKEY %s", grip); @@ -1092,29 +1091,36 @@ scute_agent_sign (char *grip, unsigned char *data, int len, return err; /* FIXME: we need a real parser to cope with all kind of S-expressions. */ - if (sig.len == SIG_PREFIX_LEN + SIG_LEN_2 + SIG_POSTFIX_LEN) + if (!memcmp (sig.data, SIG_PREFIX, SIG_PREFIX_LEN)) { - if (memcmp (sig.data, SIG_PREFIX_2, SIG_PREFIX_LEN)) - return gpg_error (GPG_ERR_BAD_SIGNATURE); - if (memcmp (sig.data + sig.len - SIG_POSTFIX_LEN, - SIG_POSTFIX, SIG_POSTFIX_LEN)) - return gpg_error (GPG_ERR_BAD_SIGNATURE); - memcpy (sig_result, sig.data + SIG_PREFIX_LEN, SIG_LEN_2); - *sig_len = SIG_LEN_2; - } - else - { - if (sig.len != SIG_PREFIX_LEN + SIG_LEN + SIG_POSTFIX_LEN) + int data_len; + unsigned char *sig_begin; + + data_len = atoi(sig.data + SIG_PREFIX_LEN); + sig_begin = strchr(sig.data + SIG_PREFIX_LEN, ':'); + if (!sig_begin) /* Invalid S-expression? */ return gpg_error (GPG_ERR_BAD_SIGNATURE); - if (memcmp (sig.data, SIG_PREFIX, SIG_PREFIX_LEN)) + + sig_begin += 1; /* Skip colon. */ + + if (sig.len != sig_begin - sig.data + data_len + SIG_POSTFIX_LEN) return gpg_error (GPG_ERR_BAD_SIGNATURE); - if (memcmp (sig.data + sig.len - SIG_POSTFIX_LEN, - SIG_POSTFIX, SIG_POSTFIX_LEN)) + if (memcmp (sig.data + sig.len - SIG_POSTFIX_LEN, SIG_POSTFIX, SIG_POSTFIX_LEN)) return gpg_error (GPG_ERR_BAD_SIGNATURE); - memcpy (sig_result, sig.data + SIG_PREFIX_LEN, SIG_LEN); - *sig_len = SIG_LEN; - } + if ( *sig_begin == 0 && *(sig_begin+1) & 0x80 ) + { + /* Remove the extra nul byte that was added to prevent + * the signature from being interpreted as a negative value. */ + sig_begin += 1; + data_len -= 1; + } + + memcpy (sig_result, sig_begin, data_len); + *sig_len = data_len; + } + else + return gpg_error( GPG_ERR_BAD_SIGNATURE ); /* Unexpected signature prefix. */ return 0; } -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From mailinglists at gusnan.se Mon Dec 8 08:46:08 2014 From: mailinglists at gusnan.se (Andreas =?UTF-8?B?UsO2bm5xdWlzdA==?=) Date: Mon, 8 Dec 2014 08:46:08 +0100 Subject: [PATCH] [GPA] Modernize floppy to flash drive Message-ID: <20141208084608.0638bb03@debian-workstation.lan> Working on the Swedish translation of GPA, I discovered a reference in the original english strings to floppy, which seems a bit outdated. See the attached patch for a fix. best -- Andreas R?nnquist gusnan at gusnan.se mailinglists at gusnan.se -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Modernize-floppy-to-flash-memory.patch Type: text/x-patch Size: 843 bytes Desc: not available URL: From Vincent.Riera at imgtec.com Mon Dec 8 14:57:39 2014 From: Vincent.Riera at imgtec.com (Vicente Olivert Riera) Date: Mon, 8 Dec 2014 13:57:39 +0000 Subject: pinentry-0.9.0 wrong #include paths in .moc files In-Reply-To: <5485A7F7.4050502@imgtec.com> References: <5485A7F7.4050502@imgtec.com> Message-ID: <5485AE53.9000601@imgtec.com> On 12/08/2014 01:30 PM, Vicente Olivert Riera wrote: > Hello, > > I have downloaded the pinentry-0.9.0 tarball, and when I try to build > pinentry-qt4 it fails with some errors like these ones: > > In file included from pinentryconfirm.cpp:52:0: > pinentryconfirm.moc:9:53: fatal error: > ../../../s/pinentry/qt4/pinentryconfirm.h: No such file or directory > #include "../../../s/pinentry/qt4/pinentryconfirm.h" > > In file included from qsecurelineedit.cpp:3602:0: > qsecurelineedit.moc:9:53: fatal error: > ../../../s/pinentry/qt4/qsecurelineedit.h: No such file or directory > #include "../../../s/pinentry/qt4/qsecurelineedit.h" > > In file included from pinentrydialog.cpp:347:0: > pinentrydialog.moc:9:52: fatal error: > ../../../s/pinentry/qt4/pinentrydialog.h: No such file or directory > #include "../../../s/pinentry/qt4/pinentrydialog.h" > > The problem is the .moc files under the pinentry-0.9.0/qt4/ directory > have an #include which is wrong: > > pinentryconfirm.moc:9 > #include "../../../s/pinentry/qt4/pinentryconfirm.h" > > qsecurelineedit.moc:9 > #include "../../../s/pinentry/qt4/qsecurelineedit.h" > > pinentrydialog.moc:9 > #include "../../../s/pinentry/qt4/pinentrydialog.h" > > In previous pinentry versions these includes are just like these: > > #include "pinentryconfirm.h" > #include "qsecurelineedit.h" > #include "pinentrydialog.h" > > I have changed the new includes to look like the old ones, and then the > compilation works perfectly. So, could you please fix that and upload a > new pinentry-0.9.0 tarball with that fix included? > > Best regards, > Finally the registration confirmation in the bug tracker arrived. I have reported this issue there: https://bugs.g10code.com/gnupg/issue1784 -- Vicente Olivert Riera Graduate Software Engineer, MIPS Platforms Imagination Technologies Limited t: +44 (0)113 2429814 www.imgtec.com From Vincent.Riera at imgtec.com Mon Dec 8 14:30:31 2014 From: Vincent.Riera at imgtec.com (Vicente Olivert Riera) Date: Mon, 8 Dec 2014 13:30:31 +0000 Subject: pinentry-0.9.0 wrong #include paths in .moc files Message-ID: <5485A7F7.4050502@imgtec.com> Hello, I have downloaded the pinentry-0.9.0 tarball, and when I try to build pinentry-qt4 it fails with some errors like these ones: In file included from pinentryconfirm.cpp:52:0: pinentryconfirm.moc:9:53: fatal error: ../../../s/pinentry/qt4/pinentryconfirm.h: No such file or directory #include "../../../s/pinentry/qt4/pinentryconfirm.h" In file included from qsecurelineedit.cpp:3602:0: qsecurelineedit.moc:9:53: fatal error: ../../../s/pinentry/qt4/qsecurelineedit.h: No such file or directory #include "../../../s/pinentry/qt4/qsecurelineedit.h" In file included from pinentrydialog.cpp:347:0: pinentrydialog.moc:9:52: fatal error: ../../../s/pinentry/qt4/pinentrydialog.h: No such file or directory #include "../../../s/pinentry/qt4/pinentrydialog.h" The problem is the .moc files under the pinentry-0.9.0/qt4/ directory have an #include which is wrong: pinentryconfirm.moc:9 #include "../../../s/pinentry/qt4/pinentryconfirm.h" qsecurelineedit.moc:9 #include "../../../s/pinentry/qt4/qsecurelineedit.h" pinentrydialog.moc:9 #include "../../../s/pinentry/qt4/pinentrydialog.h" In previous pinentry versions these includes are just like these: #include "pinentryconfirm.h" #include "qsecurelineedit.h" #include "pinentrydialog.h" I have changed the new includes to look like the old ones, and then the compilation works perfectly. So, could you please fix that and upload a new pinentry-0.9.0 tarball with that fix included? Best regards, -- Vicente Olivert Riera Graduate Software Engineer, MIPS Platforms Imagination Technologies Limited t: +44 (0)113 2429814 www.imgtec.com From wk at gnupg.org Mon Dec 8 15:16:11 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 08 Dec 2014 15:16:11 +0100 Subject: GnuPG 2.1.0: key too large, import stops In-Reply-To: <5473F668.6000205@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 24 Nov 2014 22:24:24 -0500") References: <20141122010959.GA77998@tower.spodhuis.org> <87mw7hgffu.fsf@vigenere.g10code.de> <20141125022610.GA93687@tower.spodhuis.org> <5473F668.6000205@fifthhorseman.net> Message-ID: <87fvcqqlas.fsf@vigenere.g10code.de> On Tue, 25 Nov 2014 04:24, dkg at fifthhorseman.net said: > 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? Okay: gpg: keyserver option 'ca-cert-file' is obsolete; please use 'hkp-cacert' in dirmngr.conf > I agree that this would also be a nice thing to have -- what > error-reporting mechanisms are possible between dirmngr and gnupg 2.1? Whatever you want. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Mon Dec 8 15:56:34 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 08 Dec 2014 09:56:34 -0500 Subject: [PATCH] [GPA] Modernize floppy to flash drive In-Reply-To: <20141208084608.0638bb03@debian-workstation.lan> References: <20141208084608.0638bb03@debian-workstation.lan> Message-ID: <5485BC22.5030306@fifthhorseman.net> On 12/08/2014 02:46 AM, Andreas R?nnquist wrote: > Working on the Swedish translation of GPA, I discovered a reference in > the original english strings to floppy, which seems a bit outdated. Thanks for catching this, Andreas. I suspect there are people using GnuPG today who have never even seen a floppy disk, so i think you're right to suggest a change. As a native english speaker, I'd suggest "on a USB flash drive" or "on a USB stick" instead of "on a flash memory" It's a narrower meaning, but more common usage. and as an example, it doesn't need to have the widest possible meaning, just something that people will recognize. --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 Mon Dec 8 17:34:23 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 08 Dec 2014 17:34:23 +0100 Subject: [PATCH] [GPA] Modernize floppy to flash drive In-Reply-To: <5485BC22.5030306@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 08 Dec 2014 09:56:34 -0500") References: <20141208084608.0638bb03@debian-workstation.lan> <5485BC22.5030306@fifthhorseman.net> Message-ID: <877fy2qewg.fsf@vigenere.g10code.de> On Mon, 8 Dec 2014 15:56, dkg at fifthhorseman.net said: > As a native english speaker, I'd suggest "on a USB flash drive" or "on a > USB stick" instead of "on a flash memory" It's a narrower meaning, but Actually I used that term for the German translation because that is the common term here too. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From Vincent.Riera at imgtec.com Mon Dec 8 17:44:44 2014 From: Vincent.Riera at imgtec.com (Vicente Olivert Riera) Date: Mon, 8 Dec 2014 16:44:44 +0000 Subject: [PATCH] pinentry-qt4: make the accessibility part optional Message-ID: <1418057084-12354-1-git-send-email-Vincent.Riera@imgtec.com> Check if the Qt libraries have support for QT Accessibility before using it. Otherwise it will raise error like these one: main.cpp: In function 'int qt_cmd_handler(pinentry_t)': main.cpp:220:51: error: 'class QAbstractButton' has no member named 'setAccessibleDescription' Signed-off-by: Vicente Olivert Riera --- qt4/main.cpp | 3 ++- qt4/pinentryconfirm.cpp | 2 ++ qt4/pinentrydialog.cpp | 10 ++++++++++ 3 files changed, 14 insertions(+), 1 deletions(-) diff --git a/qt4/main.cpp b/qt4/main.cpp index 106999e..b2a69f2 100644 --- a/qt4/main.cpp +++ b/qt4/main.cpp @@ -217,8 +217,9 @@ qt_cmd_handler (pinentry_t pe) for ( size_t i = 0 ; i < sizeof buttonLabels / sizeof *buttonLabels ; ++i ) if ( (buttons & buttonLabels[i].button) && !buttonLabels[i].label.isEmpty() ) { box.button( buttonLabels[i].button )->setText( buttonLabels[i].label ); +#ifndef QT_NO_ACCESSIBILITY box.button( buttonLabels[i].button )->setAccessibleDescription ( buttonLabels[i].label ); - +#endif } box.setIconPixmap( icon() ); diff --git a/qt4/pinentryconfirm.cpp b/qt4/pinentryconfirm.cpp index dfbd19f..6b3d545 100644 --- a/qt4/pinentryconfirm.cpp +++ b/qt4/pinentryconfirm.cpp @@ -30,8 +30,10 @@ PinentryConfirm::PinentryConfirm(Icon icon, int timeout, const QString &title, connect(_timer, SIGNAL(timeout()), this, SLOT(slotTimeout())); _timer->start(timeout*1000); } +#ifndef QT_NO_ACCESSIBILITY setAccessibleDescription (desc); setAccessibleName (title); +#endif raiseWindow (this); } diff --git a/qt4/pinentrydialog.cpp b/qt4/pinentrydialog.cpp index 3a6dacc..456f022 100644 --- a/qt4/pinentrydialog.cpp +++ b/qt4/pinentrydialog.cpp @@ -217,7 +217,9 @@ void PinEntryDialog::setDescription( const QString& txt ) { _desc->setVisible( !txt.isEmpty() ); _desc->setText( txt ); +#ifndef QT_NO_ACCESSIBILITY _desc->setAccessibleDescription ( txt ); +#endif _icon->setPixmap( icon() ); setError( QString::null ); } @@ -231,7 +233,9 @@ void PinEntryDialog::setError( const QString& txt ) { if( !txt.isNull() )_icon->setPixmap( icon( QStyle::SP_MessageBoxCritical ) ); _error->setText( txt ); +#ifndef QT_NO_ACCESSIBILITY _error->setAccessibleDescription ( txt ); +#endif _error->setVisible( !txt.isEmpty() ); } @@ -264,14 +268,18 @@ QString PinEntryDialog::prompt() const void PinEntryDialog::setOkText( const QString& txt ) { _ok->setText( txt ); +#ifndef QT_NO_ACCESSIBILITY _ok->setAccessibleDescription ( txt ); +#endif _ok->setVisible( !txt.isEmpty() ); } void PinEntryDialog::setCancelText( const QString& txt ) { _cancel->setText( txt ); +#ifndef QT_NO_ACCESSIBILITY _cancel->setAccessibleDescription ( txt ); +#endif _cancel->setVisible( !txt.isEmpty() ); } @@ -279,7 +287,9 @@ void PinEntryDialog::setQualityBar( const QString& txt ) { if (_have_quality_bar) { _quality_bar_label->setText( txt ); +#ifndef QT_NO_ACCESSIBILITY _quality_bar_label->setAccessibleDescription ( txt ); +#endif } } -- 1.7.1 From gniibe at fsij.org Tue Dec 9 08:27:56 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 09 Dec 2014 16:27:56 +0900 Subject: scd: ECDH Support (was: scd: Fix for EdDSA) In-Reply-To: <548171DF.8030200@fsij.org> References: <54813D71.1010507@fsij.org> <87tx1asfnb.fsf@vigenere.g10code.de> <548171DF.8030200@fsij.org> Message-ID: <5486A47C.2090609@fsij.org> Here are changes to support ECDH by scdaemon. I tested this code with experimental version of Gnuk. It takes about 0.6 second to decrypt for NIST P-256 (measured on host PC by gpg --decrypt). Around 2011 when I implemented NIST P-256 computation itself, I had thought less second. This year, I modified the code to be more constant time, computation requires more time now. Still, it's good than RSA-2048 which takes more than 1.4 second. I don't know if this protocol is good (or compatible) with existing smartcard/token/hsm. In this implementation, scdaemon only computes [d]P (d: private key, P: point) to get shared point and does not compute AESWrap, following the protocol of gpg-agent. OK to commit? * agent/divert-scd.c (divert_pkdecrypt): Support ECDH. * scd/app-openpgp.c (get_algo_byte, store_fpr): Support ECDH. (send_key_attr): Support ECDH. Fix EdDSA algorithm value. (retrieve_key_material): Initialize fields. (get_public_key, ecc_writekey, do_writekey): Support ECDH. (ecdh_writekey): Remove. (do_decipher): Support ECDH. (parse_algorithm_attribute): Support ECDH. Fix EdDSA. diff --git a/agent/divert-scd.c b/agent/divert-scd.c index ceef588..1408d65 100644 --- a/agent/divert-scd.c +++ b/agent/divert-scd.c @@ -417,17 +417,45 @@ divert_pkdecrypt (ctrl_t ctrl, n = snext (&s); if (!n) return gpg_error (GPG_ERR_INV_SEXP); - if (!smatch (&s, n, "rsa")) + if (smatch (&s, n, "rsa")) + { + if (*s != '(') + return gpg_error (GPG_ERR_UNKNOWN_SEXP); + s++; + n = snext (&s); + if (!n) + return gpg_error (GPG_ERR_INV_SEXP); + if (!smatch (&s, n, "a")) + return gpg_error (GPG_ERR_UNKNOWN_SEXP); + n = snext (&s); + } + else if (smatch (&s, n, "ecdh")) + { + if (*s != '(') + return gpg_error (GPG_ERR_UNKNOWN_SEXP); + s++; + n = snext (&s); + if (!n) + return gpg_error (GPG_ERR_INV_SEXP); + if (smatch (&s, n, "s")) + { + n = snext (&s); + s += n; + if (*s++ != ')') + return gpg_error (GPG_ERR_INV_SEXP); + if (*s++ != '(') + return gpg_error (GPG_ERR_UNKNOWN_SEXP); + n = snext (&s); + if (!n) + return gpg_error (GPG_ERR_INV_SEXP); + } + if (!smatch (&s, n, "e")) + return gpg_error (GPG_ERR_UNKNOWN_SEXP); + n = snext (&s); + } + else return gpg_error (GPG_ERR_UNSUPPORTED_ALGORITHM); - if (*s != '(') - return gpg_error (GPG_ERR_UNKNOWN_SEXP); - s++; - n = snext (&s); - if (!n) - return gpg_error (GPG_ERR_INV_SEXP); - if (!smatch (&s, n, "a")) - return gpg_error (GPG_ERR_UNKNOWN_SEXP); - n = snext (&s); + if (!n) return gpg_error (GPG_ERR_UNKNOWN_SEXP); ciphertext = s; diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index 663b7d3..b35a3f2 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -120,8 +120,7 @@ static struct { /* Type of keys. */ typedef enum { - KEY_TYPE_ECDH, - KEY_TYPE_ECDSA, + KEY_TYPE_ECC, KEY_TYPE_EDDSA, KEY_TYPE_RSA, } @@ -236,15 +235,10 @@ struct app_local_s { } rsa; struct { int curve; - } ecdsa; + } ecc; struct { int curve; } eddsa; - struct { - int curve; - int hashalgo; - int cipheralgo; - } ecdh; }; } keyattr[3]; }; @@ -745,11 +739,11 @@ parse_login_data (app_t app) static unsigned char -get_algo_byte (key_type_t key_type) +get_algo_byte (int keynumber, key_type_t key_type) { - if (key_type == KEY_TYPE_ECDSA) + if (key_type == KEY_TYPE_ECC && keynumber != 1) return 19; - else if (key_type == KEY_TYPE_ECDH) + else if (key_type == KEY_TYPE_ECC && keynumber == 1) return 18; else if (key_type == KEY_TYPE_EDDSA) return 22; @@ -777,13 +771,10 @@ store_fpr (app_t app, int keynumber, u32 timestamp, int i; n = 6; /* key packet version, 4-byte timestamps, and algorithm */ - if (key_type == KEY_TYPE_RSA || key_type == KEY_TYPE_ECDSA - || key_type == KEY_TYPE_EDDSA) - argc = 2; - else if (key_type == KEY_TYPE_ECDH) + if (keynumber == 1 && key_type == KEY_TYPE_ECC) argc = 3; else - return gpg_error (GPG_ERR_NOT_IMPLEMENTED); + argc = 2; va_start (ap, key_type); for (i = 0; i < argc; i++) @@ -812,7 +803,7 @@ store_fpr (app_t app, int keynumber, u32 timestamp, *p++ = timestamp >> 16; *p++ = timestamp >> 8; *p++ = timestamp; - *p++ = get_algo_byte (key_type); + *p++ = get_algo_byte (keynumber, key_type); for (i = 0; i < argc; i++) { @@ -977,27 +968,18 @@ send_key_attr (ctrl_t ctrl, app_t app, const char *keyword, int number) app->app_local->keyattr[number].rsa.n_bits, app->app_local->keyattr[number].rsa.e_bits, app->app_local->keyattr[number].rsa.format); - else if (app->app_local->keyattr[number].key_type == KEY_TYPE_ECDSA) + else if (app->app_local->keyattr[number].key_type == KEY_TYPE_ECC) { - get_ecc_key_parameters (app->app_local->keyattr[number].ecdsa.curve, + get_ecc_key_parameters (app->app_local->keyattr[number].ecc.curve, &n_bits, &curve_oid); - snprintf (buffer, sizeof buffer, "%d 19 %u %s", - number+1, n_bits, curve_oid); - } - else if (app->app_local->keyattr[number].key_type == KEY_TYPE_ECDH) - { - get_ecc_key_parameters (app->app_local->keyattr[number].ecdh.curve, - &n_bits, &curve_oid); - snprintf (buffer, sizeof buffer, "%d 18 %u %s %d %d", - number+1, n_bits, curve_oid, - app->app_local->keyattr[number].ecdh.hashalgo, - app->app_local->keyattr[number].ecdh.cipheralgo); + snprintf (buffer, sizeof buffer, "%d %d %u %s", + number+1, number==1? 18: 19, n_bits, curve_oid); } else if (app->app_local->keyattr[number].key_type == KEY_TYPE_EDDSA) { get_ecc_key_parameters (app->app_local->keyattr[number].eddsa.curve, &n_bits, &curve_oid); - snprintf (buffer, sizeof buffer, "%d 105 %u %s", + snprintf (buffer, sizeof buffer, "%d 22 %u %s", number+1, n_bits, curve_oid); } else @@ -1214,7 +1196,7 @@ retrieve_key_material (FILE *fp, const char *hexkeyid, for (;;) { char *p; - char *fields[6]; + char *fields[6] = { NULL, NULL, NULL, NULL, NULL, NULL }; int nfields; size_t max_length; gcry_mpi_t mpi; @@ -1529,10 +1511,10 @@ get_public_key (app_t app, int keyno) gcry_sexp_sprint (s_pkey, GCRYSEXP_FMT_CANON, keybuf, len); gcry_sexp_release (s_pkey); } - else if (app->app_local->keyattr[keyno].key_type == KEY_TYPE_ECDSA) + else if (app->app_local->keyattr[keyno].key_type == KEY_TYPE_ECC) { const char *curve_name - = get_curve_name (app->app_local->keyattr[keyno].ecdsa.curve); + = get_curve_name (app->app_local->keyattr[keyno].ecc.curve); err = gcry_sexp_build (&s_pkey, NULL, "(public-key(ecc(curve%s)(q%b)))", @@ -3226,23 +3208,6 @@ rsa_writekey (app_t app, gpg_error_t (*pincb)(void*, const char *, char **), static gpg_error_t -ecdh_writekey (app_t app, gpg_error_t (*pincb)(void*, const char *, char **), - void *pincb_arg, int keyno, - const unsigned char *buf, size_t buflen, int depth) -{ - (void)app; - (void)pincb; - (void)pincb_arg; - (void)keyno; - (void)buf; - (void)buflen; - (void)depth; - - return GPG_ERR_NOT_IMPLEMENTED; -} - - -static gpg_error_t ecc_writekey (app_t app, gpg_error_t (*pincb)(void*, const char *, char **), void *pincb_arg, int keyno, const unsigned char *buf, size_t buflen, int depth) @@ -3418,15 +3383,15 @@ ecc_writekey (app_t app, gpg_error_t (*pincb)(void*, const char *, char **), } err = store_fpr (app, keyno, created_at, fprbuf, app->card_version, - curve == CURVE_ED25519 ? KEY_TYPE_EDDSA : KEY_TYPE_ECDSA, + curve == CURVE_ED25519 ? KEY_TYPE_EDDSA : KEY_TYPE_ECC, curve == CURVE_ED25519 ? "\x09\x2b\x06\x01\x04\x01\xda\x47\x0f\x01" : curve == CURVE_NIST_P256 ? "\x08\x2a\x86\x48\xce\x3d\x03\x01\x07" - : "\05\x2b\x81\x04\x00\x0a", + : "\x05\x2b\x81\x04\x00\x0a", curve == CURVE_ED25519 ? 10 : curve == CURVE_NIST_P256? 9 : 6, - ecc_q, ecc_q_len); + ecc_q, ecc_q_len, "\x03\x01\x08\x07", 4); if (err) goto leave; @@ -3500,14 +3465,11 @@ do_writekey (app_t app, ctrl_t ctrl, goto leave; if (tok && toklen == 3 && memcmp ("rsa", tok, toklen) == 0) err = rsa_writekey (app, pincb, pincb_arg, keyno, buf, buflen, depth); - else if ((tok && toklen == 3 && memcmp ("ecc", tok, toklen) == 0 - && (keyno == 0 || keyno == 2)) - || (tok && toklen == 5 && memcmp ("ecdsa", tok, toklen) == 0)) + else if (tok + && ((toklen == 3 && memcmp ("ecc", tok, toklen) == 0) + || (toklen == 4 && memcmp ("ecdh", tok, toklen) == 0) + || (toklen == 5 && memcmp ("ecdsa", tok, toklen) == 0))) err = ecc_writekey (app, pincb, pincb_arg, keyno, buf, buflen, depth); - else if ((tok && toklen == 3 && memcmp ("ecc", tok, toklen) == 0 - && keyno == 1) - || (tok && toklen == 4 && memcmp ("ecdh", tok, toklen) == 0)) - err = ecdh_writekey (app, pincb, pincb_arg, keyno, buf, buflen, depth); else { err = gpg_error (GPG_ERR_WRONG_PUBKEY_ALGO); @@ -3994,7 +3956,7 @@ do_auth (app_t app, const char *keyidstr, && indatalen > 101) /* For a 2048 bit key. */ return gpg_error (GPG_ERR_INV_VALUE); - if (app->app_local->keyattr[2].key_type == KEY_TYPE_ECDSA + if (app->app_local->keyattr[2].key_type == KEY_TYPE_ECC && (indatalen == 51 || indatalen == 67 || indatalen == 83)) { const char *p = (const char *)indata + 19; @@ -4082,6 +4044,8 @@ do_decipher (app_t app, const char *keyidstr, int n; const char *fpr = NULL; int exmode, le_value; + unsigned char *fixbuf = NULL; + int padind = 0; if (!keyidstr || !*keyidstr || !indatalen) return gpg_error (GPG_ERR_INV_VALUE); @@ -4123,11 +4087,12 @@ do_decipher (app_t app, const char *keyidstr, return rc; rc = verify_chv2 (app, pincb, pincb_arg); - if (!rc) + if (rc) + return rc; + + if (app->app_local->keyattr[1].key_type == KEY_TYPE_RSA) { int fixuplen; - unsigned char *fixbuf = NULL; - int padind = 0; /* We might encounter a couple of leading zeroes in the cryptogram. Due to internal use of MPIs these leading zeroes @@ -4179,33 +4144,37 @@ do_decipher (app_t app, const char *keyidstr, /* We use the extra leading zero as the padding byte. */ padind = -1; } + } + else if (app->app_local->keyattr[1].key_type == KEY_TYPE_ECC) + padind = -1; + else + return gpg_error (GPG_ERR_INV_VALUE); - if (app->app_local->cardcap.ext_lc_le && indatalen > 254 ) - { - exmode = 1; /* Extended length w/o a limit. */ - le_value = app->app_local->extcap.max_rsp_data; - } - else if (app->app_local->cardcap.cmd_chaining && indatalen > 254) - { - exmode = -254; /* Command chaining with max. 254 bytes. */ - le_value = 0; - } - else - exmode = le_value = 0; + if (app->app_local->cardcap.ext_lc_le && indatalen > 254 ) + { + exmode = 1; /* Extended length w/o a limit. */ + le_value = app->app_local->extcap.max_rsp_data; + } + else if (app->app_local->cardcap.cmd_chaining && indatalen > 254) + { + exmode = -254; /* Command chaining with max. 254 bytes. */ + le_value = 0; + } + else + exmode = le_value = 0; - rc = iso7816_decipher (app->slot, exmode, - indata, indatalen, le_value, padind, - outdata, outdatalen); - xfree (fixbuf); + rc = iso7816_decipher (app->slot, exmode, + indata, indatalen, le_value, padind, + outdata, outdatalen); + xfree (fixbuf); - if (gpg_err_code (rc) == GPG_ERR_CARD /* actual SW is 0x640a */ - && app->app_local->manufacturer == 5 - && app->card_version == 0x0200) - log_info ("NOTE: Cards with manufacturer id 5 and s/n <= 346 (0x15a)" - " do not work with encryption keys > 2048 bits\n"); + if (gpg_err_code (rc) == GPG_ERR_CARD /* actual SW is 0x640a */ + && app->app_local->manufacturer == 5 + && app->card_version == 0x0200) + log_info ("NOTE: Cards with manufacturer id 5 and s/n <= 346 (0x15a)" + " do not work with encryption keys > 2048 bits\n"); - *r_info |= APP_DECIPHER_INFO_NOPAD; - } + *r_info |= APP_DECIPHER_INFO_NOPAD; return rc; } @@ -4454,25 +4423,25 @@ parse_algorithm_attribute (app_t app, int keyno) app->app_local->keyattr[keyno].rsa.format == RSA_CRT? "crt" : app->app_local->keyattr[keyno].rsa.format == RSA_CRT_N?"crt+n":"?"); } - else if (*buffer == 19) /* ECDSA */ + else if (*buffer == 18 || *buffer == 19) /* ECDH or ECDSA */ { - app->app_local->keyattr[keyno].key_type = KEY_TYPE_ECDSA; - app->app_local->keyattr[keyno].ecdsa.curve + app->app_local->keyattr[keyno].key_type = KEY_TYPE_ECC; + app->app_local->keyattr[keyno].ecc.curve = parse_ecc_curve (buffer + 1, buflen - 1); + if (opt.verbose) + log_printf + ("ECC, curve=%s\n", + get_curve_name (app->app_local->keyattr[keyno].ecc.curve)); } - else if (*buffer == 18 && buflen == 11) /* ECDH */ - { - app->app_local->keyattr[keyno].key_type = KEY_TYPE_ECDH; - app->app_local->keyattr[keyno].ecdh.hashalgo = buffer[1]; - app->app_local->keyattr[keyno].ecdh.cipheralgo = buffer[2]; - app->app_local->keyattr[keyno].ecdh.curve - = parse_ecc_curve (buffer + 3, buflen - 3); - } - else if (*buffer == 105) /* EdDSA (experimental) */ + else if (*buffer == 22) /* EdDSA */ { app->app_local->keyattr[keyno].key_type = KEY_TYPE_EDDSA; app->app_local->keyattr[keyno].eddsa.curve = parse_ecc_curve (buffer + 1, buflen - 1); + if (opt.verbose) + log_printf + ("EdDSA, curve=%s\n", + get_curve_name (app->app_local->keyattr[keyno].eddsa.curve)); } else if (opt.verbose) log_printhex ("", buffer, buflen); -- From aheinecke at intevation.de Tue Dec 9 21:41:15 2014 From: aheinecke at intevation.de (Andre Heinecke) Date: Tue, 09 Dec 2014 21:41:15 +0100 Subject: [PATCH] pinentry-qt4: make the accessibility part optional In-Reply-To: <1418057084-12354-1-git-send-email-Vincent.Riera@imgtec.com> References: <1418057084-12354-1-git-send-email-Vincent.Riera@imgtec.com> Message-ID: <14043986.dv6nyEBprU@esus> Hi, On Monday, December 08, 2014 04:44:44 PM Vicente Olivert Riera wrote: > Check if the Qt libraries have support for QT Accessibility before using > it. Otherwise it will raise error like these one: > > main.cpp: In function 'int qt_cmd_handler(pinentry_t)': > main.cpp:220:51: error: 'class QAbstractButton' has no member named > 'setAccessibleDescription' > You are right of course. I had not thought about it that this optional in qt. I've applied this patch to master. Thanks! -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From john.marshall at riverwillow.com.au Wed Dec 10 04:46:25 2014 From: john.marshall at riverwillow.com.au (John Marshall) Date: Wed, 10 Dec 2014 14:46:25 +1100 Subject: Whither DNS SRV in 2.1.0? Message-ID: <20141210034625.GA1106@rwpc15.gfn.riverwillow.net.au> I have just upgraded a desktop to GnuPG 2.1.0. I rely upon DNS SRV domain names for keyserver selection. Since upgrading from 2.0.26 keyserver (SRV) selection appears to be broken. Note that the only RR's at the hkp:// DNS domain label in use are SRV records (no A or AAAA). GnuPG 2.0 retrieves and processes the SRV RR's. GnuPG 2.1 (dirmngr) ignores them and gives up due to lack of address records: gpg: error searching keyserver: Unknown host gpg: keyserver search failed: Unknown host There is no indication that SRV support has been removed from GnuPG. At the end of configure I see: GnuPG v2.1.0 has been configured as follows: Revision: e22b459 (57899) Platform: FreeBSD (i386-portbld-freebsd10.1) OpenPGP: yes S/MIME: yes Agent: yes Smartcard: no G13: yes Dirmngr: yes Gpgtar: yes Protect tool: (default) LDAP wrapper: (default) Default agent: (default) Default pinentry: (default) Default scdaemon: (default) Default dirmngr: (default) Dirmngr auto start: yes Readline support: yes LDAP support: no DNS SRV support: yes <------------ TLS support: gnutls config.log finishes up with: #define USE_DNS_SRV 1 <------------ but dirmngr just ignores SRV records. I did some digging and found the following in dirmngr/ks-engine-hkp.c: 813: else 814: { 815: /*fixme_do_srv_lookup ()*/ 816: } I suppose that this regression was not intentional since I cannot find any mention of it in the ChangeLog or README or Release Announcement. In fact, the only mention I can find in ChangeLog is: 2014-06-26 Werner Koch Enable DNS SRV records again. * configure.ac (GPGKEYS_HKP, GPGKEYS_FINGER): Remove ac_subst. (use_dns_srv): Make test work. Am I missing something or is my only option to revert to GnuPG 2.0? Will SRV support be provided in later 2.1 releases or will it be removed altogether? Thank you again for maintaining this wonderful software. -- John Marshall -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From Vincent.Riera at imgtec.com Wed Dec 10 11:32:06 2014 From: Vincent.Riera at imgtec.com (Vicente Olivert Riera) Date: Wed, 10 Dec 2014 10:32:06 +0000 Subject: [PATCH] pinentry-qt4: make the accessibility part optional In-Reply-To: <14043986.dv6nyEBprU@esus> References: <1418057084-12354-1-git-send-email-Vincent.Riera@imgtec.com> <14043986.dv6nyEBprU@esus> Message-ID: <54882126.90300@imgtec.com> Dear Andre Heinecke, On 12/09/2014 08:41 PM, Andre Heinecke wrote: > Hi, > > On Monday, December 08, 2014 04:44:44 PM Vicente Olivert Riera wrote: >> Check if the Qt libraries have support for QT Accessibility before using >> it. Otherwise it will raise error like these one: >> >> main.cpp: In function 'int qt_cmd_handler(pinentry_t)': >> main.cpp:220:51: error: 'class QAbstractButton' has no member named >> 'setAccessibleDescription' >> > > You are right of course. I had not thought about it that this optional in qt. > I've applied this patch to master. > > Thanks! > Thank you very much for fixing this issue. Now I only need this one to be fixed as well: https://bugs.g10code.com/gnupg/issue1784 Then I will be able to backport the patches to Buildroot and fix the pinentry-qt4 package, which is broken right now. Could you have a look to it, please? Best regards, -- Vicente Olivert Riera Graduate Software Engineer, MIPS Platforms Imagination Technologies Limited t: +44 (0)113 2429814 www.imgtec.com From wk at gnupg.org Wed Dec 10 15:29:06 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 10 Dec 2014 15:29:06 +0100 Subject: Whither DNS SRV in 2.1.0? In-Reply-To: <20141210034625.GA1106@rwpc15.gfn.riverwillow.net.au> (John Marshall's message of "Wed, 10 Dec 2014 14:46:25 +1100") References: <20141210034625.GA1106@rwpc15.gfn.riverwillow.net.au> Message-ID: <877fxzpoi5.fsf@vigenere.g10code.de> On Wed, 10 Dec 2014 04:46, john.marshall at riverwillow.com.au said: > I suppose that this regression was not intentional since I cannot find > any mention of it in the ChangeLog or README or Release Announcement. > In fact, the only mention I can find in ChangeLog is: The thing is that the keyserver support has been completely redone. Thus it is not a regression but a new bug. Before 2.1 we let the DNS figure out the address to use from a round-robin pool. With 2.1 dirmngr builds a list of all host in the pool and selects one randomly. This allows to mark unresponsive hosts as dead and move on to another one - with < 2.1 you were stuck with the selected keyserver as long as the DNS decided. Despite all the beta version released this year, this has not been tested very much. We need to sort out these problems with the next or next+1 release. > Will SRV support be provided in later 2.1 releases or will it be removed > altogether? Yes, SRV record will be supported. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From Vincent.Riera at imgtec.com Wed Dec 10 15:35:26 2014 From: Vincent.Riera at imgtec.com (Vicente Olivert Riera) Date: Wed, 10 Dec 2014 14:35:26 +0000 Subject: [PATCH] pinentry-qt4: make the accessibility part optional In-Reply-To: <54882126.90300@imgtec.com> References: <1418057084-12354-1-git-send-email-Vincent.Riera@imgtec.com> <14043986.dv6nyEBprU@esus> <54882126.90300@imgtec.com> Message-ID: <54885A2E.6080000@imgtec.com> CCing Werner as Andre mentioned him in the bug report: https://bugs.g10code.com/gnupg/msg5631 On 12/10/2014 10:32 AM, Vicente Olivert Riera wrote: > Dear Andre Heinecke, > > On 12/09/2014 08:41 PM, Andre Heinecke wrote: >> Hi, >> >> On Monday, December 08, 2014 04:44:44 PM Vicente Olivert Riera wrote: >>> Check if the Qt libraries have support for QT Accessibility before using >>> it. Otherwise it will raise error like these one: >>> >>> main.cpp: In function 'int qt_cmd_handler(pinentry_t)': >>> main.cpp:220:51: error: 'class QAbstractButton' has no member named >>> 'setAccessibleDescription' >>> >> >> You are right of course. I had not thought about it that this optional in qt. >> I've applied this patch to master. >> >> Thanks! >> > > Thank you very much for fixing this issue. Now I only need this one to > be fixed as well: > > https://bugs.g10code.com/gnupg/issue1784 > > Then I will be able to backport the patches to Buildroot and fix the > pinentry-qt4 package, which is broken right now. > > Could you have a look to it, please? > > Best regards, > -- Vicente Olivert Riera Graduate Software Engineer, MIPS Platforms Imagination Technologies Limited t: +44 (0)113 2429814 www.imgtec.com From mailinglists at gusnan.se Wed Dec 10 18:15:32 2014 From: mailinglists at gusnan.se (Andreas =?UTF-8?B?UsO2bm5xdWlzdA==?=) Date: Wed, 10 Dec 2014 18:15:32 +0100 Subject: [GPA] Updated Swedish translation Message-ID: <20141210181532.50af9e3e@debian-workstation.lan> Hi! As I have mentioned previously, I have made an updated po for the Swedish translation of GPA (see link below). However, working on this I have discovered a inconsistency: The Key Manager window says "Key Manager" as a title, but the menu item under the "Windows" submeny, says "Keyring Manager". I have made it available here: http://www.gusnan.se/gpa/sv.po best -- Andreas R?nnquist gusnan at gusnan.se mailinglists at gusnan.se From mailinglists at gusnan.se Thu Dec 11 07:43:21 2014 From: mailinglists at gusnan.se (Andreas =?UTF-8?B?UsO2bm5xdWlzdA==?=) Date: Thu, 11 Dec 2014 07:43:21 +0100 Subject: [GPA] Problems in the original English strings Message-ID: <20141211074321.59864d2a@debian-workstation.lan> Hi Some more problems were discovered in the original English strings by the people reviewing my translations (Two spelling problems/typos, and one missing space - see the attached patch). Unfortunately these were reported after I have provided the Swedish translation here, but I'll provide an updated Swedish translation when you have updated the git repo with these changes. best -- Andreas R?nnquist mailinglists at gusnan.se gusnan at gusnan.se -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-some-minor-problems-in-original-English-strings.patch Type: text/x-patch Size: 2128 bytes Desc: not available URL: From john.marshall at riverwillow.com.au Fri Dec 12 00:32:42 2014 From: john.marshall at riverwillow.com.au (John Marshall) Date: Fri, 12 Dec 2014 10:32:42 +1100 Subject: Whither DNS SRV in 2.1.0? In-Reply-To: <877fxzpoi5.fsf@vigenere.g10code.de> References: <20141210034625.GA1106@rwpc15.gfn.riverwillow.net.au> <877fxzpoi5.fsf@vigenere.g10code.de> Message-ID: <20141211233242.GA3268@rwpc15.gfn.riverwillow.net.au> On Wed, 10 Dec 2014, 15:29 +0100, Werner Koch wrote: > On Wed, 10 Dec 2014 04:46, john.marshall at riverwillow.com.au said: > > > I suppose that this regression was not intentional since I cannot find > > any mention of it in the ChangeLog or README or Release Announcement. > > The thing is that the keyserver support has been completely redone. Thus > it is not a regression but a new bug. OK. I have created a new bug report for it [issue1788]. > > Will SRV support be provided in later 2.1 releases or will it be removed > > altogether? > > Yes, SRV record will be supported. Thank you. -- John Marshall From gniibe at fsij.org Fri Dec 12 02:00:38 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 12 Dec 2014 10:00:38 +0900 Subject: [PATCH] g10: release DEK soon after its use Message-ID: <548A3E36.4050802@fsij.org> Reported to Debian gnupg 1.4: bugs.debian.org/772780 With the configuration of : s2k-cipher-algo S10, adding a subkey of RSA-4096 to primary of RSA-4096 (by --edit-key) causes out_of_core of secmem in write_keybinding function (if its size is 32768). I think that this is a regression introduced by RSA Blinding. Here is a patch to lower the memory pressure of secmem and fix the particular failure. Mostly same fix can be applied to 2.0.x. For 2.1, the management of private key is under gpg-agent, so, this is not relevant. May I apply this change (to 1.4.x and 2.0.x)? diff --git a/g10/keygen.c b/g10/keygen.c index 9020908..5af0043 100644 --- a/g10/keygen.c +++ b/g10/keygen.c @@ -3447,6 +3447,7 @@ generate_subkeypair( KBNODE pub_keyblock, KBNODE sec_keyblock ) rc = do_create (algo, nbits, pub_keyblock, sec_keyblock, dek, s2k, &sub_sk, timestamp, expire, 1 ); + xfree( dek ); if (!rc) rc = write_keybinding (pub_keyblock, pub_keyblock, pri_sk, sub_sk, use, timestamp); @@ -3463,7 +3464,6 @@ generate_subkeypair( KBNODE pub_keyblock, KBNODE sec_keyblock ) if( rc ) log_error(_("Key generation failed: %s\n"), g10_errstr(rc) ); xfree( passphrase ); - xfree( dek ); xfree( s2k ); /* release the copy of the (now unprotected) secret keys */ if( pri_sk ) -- From wk at gnupg.org Fri Dec 12 08:53:28 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 12 Dec 2014 08:53:28 +0100 Subject: [PATCH] g10: release DEK soon after its use In-Reply-To: <548A3E36.4050802@fsij.org> (NIIBE Yutaka's message of "Fri, 12 Dec 2014 10:00:38 +0900") References: <548A3E36.4050802@fsij.org> Message-ID: <87bnn9mhhj.fsf@vigenere.g10code.de> On Fri, 12 Dec 2014 02:00, gniibe at fsij.org said: > May I apply this change (to 1.4.x and 2.0.x)? Sure. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Fri Dec 12 09:51:17 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 12 Dec 2014 17:51:17 +0900 Subject: [PATCH] g10: release DEK soon after its use In-Reply-To: <87bnn9mhhj.fsf@vigenere.g10code.de> References: <548A3E36.4050802@fsij.org> <87bnn9mhhj.fsf@vigenere.g10code.de> Message-ID: <548AAC85.6040705@fsij.org> On 12/12/2014 04:53 PM, Werner Koch wrote: > On Fri, 12 Dec 2014 02:00, gniibe at fsij.org said: > >> May I apply this change (to 1.4.x and 2.0.x)? > > Sure. Applied and pushed. -- From dkg at fifthhorseman.net Fri Dec 12 22:53:06 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 12 Dec 2014 16:53:06 -0500 Subject: [PATCH] update gpgme's doc/gpl.texi to match version from gnupg In-Reply-To: <874mvxnny3.fsf@vigenere.g10code.de> References: <1409979847-31480-1-git-send-email-dkg@fifthhorseman.net> <87bnq5w4lh.fsf@alice.fifthhorseman.net> <874mvxnny3.fsf@vigenere.g10code.de> Message-ID: <871to4tu0t.fsf@alice.fifthhorseman.net> On Wed 2014-09-24 09:32:52 -0400, Werner Koch wrote: > On Wed, 24 Sep 2014 15:06, dkg at fifthhorseman.net said: > >> Any followup on this patch? > > Still ticked in my mail folder. Will thus eventually be processed. There've been two libgpgme releases (1.5.2 and 1.5.3) since this exchange, and libgpgme's doc/gpl.texi is still out of sync with the version in gnupg. If you apply the change i promise i won't bug you about it any more! :) --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 Dec 12 23:17:18 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 12 Dec 2014 17:17:18 -0500 Subject: who is the target audience of gpgme-tool? Message-ID: <87y4qcsec1.fsf@alice.fifthhorseman.net> I notice that as of gpgme 1.5.2, the tarball now installs the gpgme-tool binary. i'm wondering who the target audience of this binary is. it's not well documented outside the source, but the source (src/gpgme-tool.c) says: static char doc[] = "GPGME Tool -- Assuan server exposing GPGME operations"; static char args_doc[] = "COMMAND [OPTIONS...]"; static struct argp_option options[] = { { "server", 's', 0, 0, "Server mode" }, { "gpg-binary", 501, "FILE", 0, "Use FILE for the GPG backend" }, { 0 } }; Is primarily intended for developers? should it be available for anyone who happens to have libgpgme installed? should it be installable even if you are trying to avoid having developer tools installed? (i'm asking this because i'm looking at the debian packaging). in debian, libgpgme11 is "multiarch", which means that different architectures are co-installable on the same machine. (e.g. i386 libraries alongside amd64 libraries) But executable binaries are not co-installable in the same way, so deploying /usr/bin/gpgme-tool in the same package with libgpgme.so.11 would break the multiarch nature of the library package. The choices i see for debian packaging are: 0) don't ship gpgme-tool in any debian binary package 1) ship gpgme-tool in libgpgme11-dev (the -dev package isn't multiarch) 2) create a new gpgme-tool binary package that just ships /usr/bin/gpgme-tool and Depends: libgpgme11 If it's likely that the only people who will ever need gpgme-tool are developers or people who are doing serious debugging, i'm inclined to say we should choose option (1) above. Any preference? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From infinity0 at pwned.gg Sat Dec 13 16:12:03 2014 From: infinity0 at pwned.gg (Ximin Luo) Date: Sat, 13 Dec 2014 16:12:03 +0100 Subject: Weird behaviours with validity Message-ID: <548C5743.5060208@pwned.gg> (new,mine) If I import my public key [1] into an empty homedir and set ownertrust to ultimate, the validity (on all UIDs) is also set to ultimate. (old,mine) If I do the same thing with my pre-existing homedir, the validity (on all UIDs) is set to "undef" for some reason. (old,other) If I do the same thing with my pre-existing homedir, but with (e.g.) dkg's key [2], some UIDs are "undef" and other UIDs are "ultimate". (new,other) If I do the same thing with dkg's key in an empty homedir, the validity is set to ultimate. The validity also remains unchanged as "undef", even if I import a masterless secret key. (But GPG 1.4 seems to set the validity to "ultimate", in the same situation.) All of these behaviours are pretty weird. I couldn't find a good explanation of them in the docs. At the end of the day, I just want GPG to recognise my own key (with secret subkeys available, secret master key not available) as "ultimate" validity. How do I do this? X [1] A405 E58A B372 5B39 6ED1 B85C 1318 EFAC 5FBB DBCE [2] 0EE5 BE97 9282 D80B 9F75 40F1 CCD2 ED94 D217 39E9 -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From aathalye at mit.edu Sat Dec 13 20:39:00 2014 From: aathalye at mit.edu (Anish R Athalye) Date: Sat, 13 Dec 2014 19:39:00 +0000 Subject: gpg: return value, validity vs trust Message-ID: Hello, I have some thoughts about gpg and it?s return value, making it hard to spot the distinction between validity versus trust. From the man pages, gpg (command line tool) says: "The program returns 0 if everything was fine, 1 if at least a signature was bad, and other error codes for fatal errors.? Unfortunately, valid != trusted. In terms of security, validity means almost nothing. Especially when public keys can be auto-downloaded, and random public keys can be present in the keychain through a variety of methods, it seems that a validity check is basically no better than a checksum ? it would work great for protecting against corruption, but it?s not going to help in terms of protection from an actual attacker. It seems like there are four meaningful cases that we?d want to return to someone calling gpg, and gpg currently assigns return values like: valid, trusted -> 0 valid, NOT trusted -> 0 (!) NOT valid, trusted -> 1 NOT valid, NOT trusted -> 1 This seems like an unfortunate interface design choice. In terms of security, an untrusted signature should be treated as something that is just as bad as an invalid signature. It is all-too-easy to get random public keys in your keychain (through getting emails, having random tools having auto-key-retreive, etc), so the mere presence of a public key in the keychain should not mean *anything* in terms of the trustworthiness of the signature. When used interactively, gpg outputs a warning to stdout, so this is okay, but when gpg is used by another tool or script, and only the return value is checked, this can be a huge issue. --- If people/tools want to use gpg without the WOT model, they should add things to the keychain and explicitly assign user trust. That seems like a more reasonable and safe thing to do, instead of the people/tools making the assumption that no other/bad keys will be present in the keychain (unless the tool explicitly makes this happen, and protects against other things getting in the keychain). Right now, if tools want to know if a signature is valid and trusted, the tools is forced to *parse* the output that gpg has to stderr. This is pretty painful, and it?s the only way to get proper security as far as I can tell. This is unsafe and error-prone for something as critical as this. --- Some tools do go through the trouble of parsing (or handling this case in other ways), but their interface isn?t quite right either. For example, MacGPG?s integration with Apple Mail looks like this. I got an email from someone who I don?t know on the gnupg-users mailing list, and MacGPG auto-downloaded the key for me. This should be fine. This is what I see in the top: http://i.imgur.com/vb6Vfbg.png But the signature isn?t trusted. Double clicking on the checkmark (which indicates that all is good), this is what you get: http://i.imgur.com/sgoy07N.png In light grey, ?not to be trusted?. If someone were performing a targeted attack, this would be pretty hard to spot. This is a bad interface decision on MacGPG?s part. ---- It would be nice if gpg did this instead: valid, trusted -> 0 valid, NOT trusted -> 1 NOT valid, trusted -> 1 NOT valid, NOT trusted -> 1 This would be a change that changes the interface, but I think it would be acceptable change in terms of providing proper security. Only valid and trusted signatures should check out, in terms of return value. And tools should do a better job making a distinction between valid and trusted. Unfortunately, there are widely used tools that go as far as running gpg verify on something, and then executing code on the machine after successful validation. I?m doing some security research, and there are tools in the real world that do this (I can provide more details if you would like). --- I?ve built proof-of-concept exploits against these tools that modify and re-sign things on the fly (and when public keys that are auto-downloaded from public key servers, or we can force/trick it into the keychain by sending someone an email that is signed by that key, etc), and gpg returns success on validating those signatures. Using this attack on these tools, I can get arbitrary code to run on targets (often times as root), and I believe that this is mostly caused by gpg?s interface / return value and perhaps the people who implemented the tool not fully understanding what is going on and how gpg works. These tools rely on using the gpg command line tool and looking at the return value, and I don?t know if gpg was originally meant to only be used interactively, but it is the case that there are many tools calling to gpg and checking the return value. --- I would love to hear your thoughts on this. If you think that this is a change that would be beneficial to make, I can go ahead and submit patches for this. Regards, Anish -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mailinglisten at hauke-laging.de Sat Dec 13 22:43:46 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sat, 13 Dec 2014 22:43:46 +0100 Subject: gpg: return value, validity vs trust In-Reply-To: References: Message-ID: <5180269.XRBDg6F6eh@inno> Am Sa 13.12.2014, 19:39:00 schrieb Anish R Athalye: > Unfortunately, valid != trusted. > > In terms of security, validity means almost nothing. Once more the terminology is the problem. What you mean with "valid" is called "correct". Validity is a key status. A "valid signature" is a signature by a valid key. A key usually becomes valid by getting signed. "Trust" refers to owner trust (certification trust). Setting owner trust to "ultimate" makes a key valid. Apart from that "trust" is not related to (data) signature checking. A few months ago we had here a discussion about an improved terminology. IIRC "accepted" was preferred over "valid". Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 603 bytes Desc: This is a digitally signed message part. URL: From aathalye at mit.edu Sun Dec 14 00:25:17 2014 From: aathalye at mit.edu (Anish R Athalye) Date: Sat, 13 Dec 2014 23:25:17 +0000 Subject: gpg: return value, validity vs trust In-Reply-To: <5180269.XRBDg6F6eh@inno> References: <5180269.XRBDg6F6eh@inno> Message-ID: What I meant by valid is that given the key, the signature is made correctly (not forged or something like that). So I guess I?ll call that ?correct? from now on. What I mean by trusted is that the public key making the signature is trusted. This can be verified by checking explicitly assigned user trust or by checking it using a web of trust model. When most people check signatures, they want a correct signature made by a trusted party ? a signature that is ?valid". That?s what many seem to expect when using the `gpg` command line tool to check signatures. However, the `gpg` tool checks only for ?correct? (and outputs a message to stderr if the signature in untrusted, but still returns 0 for success). And it seems pretty difficult to check for trust (there?s no clean API for this that I found). ?Anish On Dec 13, 2014, at 4:43 PM, Hauke Laging wrote: > Am Sa 13.12.2014, 19:39:00 schrieb Anish R Athalye: > >> Unfortunately, valid != trusted. >> >> In terms of security, validity means almost nothing. > > Once more the terminology is the problem. > > What you mean with "valid" is called "correct". Validity is a key > status. A "valid signature" is a signature by a valid key. A key usually > becomes valid by getting signed. > > "Trust" refers to owner trust (certification trust). Setting owner trust > to "ultimate" makes a key valid. Apart from that "trust" is not related > to (data) signature checking. > > > A few months ago we had here a discussion about an improved terminology. > IIRC "accepted" was preferred over "valid". > > > Hauke > -- > Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ > http://userbase.kde.org/Concepts/OpenPGP_Help_Spread > OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mailinglisten at hauke-laging.de Sun Dec 14 05:09:20 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sun, 14 Dec 2014 05:09:20 +0100 Subject: gpg: return value, validity vs trust In-Reply-To: References: <5180269.XRBDg6F6eh@inno> Message-ID: <16497773.YEHMhZ8hCj@inno> Am Sa 13.12.2014, 23:25:17 schrieb Anish R Athalye: > When most people check signatures, they want a correct signature made > by a trusted party ? a signature that is ?valid". That?s what many > seem to expect when using the `gpg` command line tool to check > signatures. Quite difficult to tell what "many seem to expect". Soon a certain someone will ask you for a valid study... ;-) It seems to me that too many people expect miracles from crypto software. They don't wanna care about what is going on there but nonetheless everything shall be handled just as they expect... > However, the `gpg` tool checks only for ?correct? (and > outputs a message to stderr if the signature in untrusted, but still > returns 0 for success). The situation is too complex to be usefully handled by exit codes. > And it seems pretty difficult to check for > trust (there?s no clean API for this that I found). Fortunately you are wrong about that. For what you want you shall make the verification call like this: gpg --status-fd 1 --verify file.asc That leads to output like this (plus some more lines intended more for the human reader than for parsing): [GNUPG:] SIG_ID EC64yxSlofLKaZ2wyLvSGDkRAT8 2014-12-06 1417856145 [GNUPG:] GOODSIG 486B17AB3F96AD8E Hauke Laging (Standardadresse) [GNUPG:] VALIDSIG 03C7C358A842126450C104BA486B17AB3F96AD8E 2014-12-06 1417856145 0 4 0 1 2 00 7D82FB9FD25A2CE452416C37BF4B8EEF1A571DF5 [GNUPG:] TRUST_ULTIMATE The last line is what you want to know (in combination with GOODSIG / VALIDSIG). Thus you have to check the output for some keywords. Quoting the DETAILS file: ################################ TRUST_UNDEFINED TRUST_NEVER TRUST_MARGINAL [0 []] TRUST_FULLY [0 []] TRUST_ULTIMATE [0 []] For good signatures one of these status lines are emitted to indicate the validity of the key used to create the signature. The error token values are currently only emitted by gpgsm. VALIDATION_MODEL describes the algorithm used to check the validity of the key. The defaults are the standard Web of Trust model for gpg and the the standard X.509 model for gpgsm. The defined values are "pgp" for the standard PGP WoT. "shell" for the standard X.509 model. "chain" for the chain model. Note that we use the term "TRUST_" in the status names for historic reasons; we now speak of validity. ################################ Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 603 bytes Desc: This is a digitally signed message part. URL: From hans at guardianproject.info Sun Dec 14 11:24:05 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Sun, 14 Dec 2014 11:24:05 +0100 Subject: patch: disable docs in libgpg-error build Message-ID: <548D6545.2090307@guardianproject.info> Hey all, The build process for Android is already quite complicated, so removing the documentation from the build process is quite helpful in keeping things manageable. Plus, there is currently some error in building the docs in the GnuPG-for-Android build. The documentation is not included in the Android app anyway. This would be a useful option to have on all of the GnuPG projects, this is the currently broken build, so I'm starting here. The patch is attached. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-.-configure-disable-documentation-for-builds-that-do.patch Type: text/x-patch Size: 1457 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 aathalye at mit.edu Sun Dec 14 15:15:36 2014 From: aathalye at mit.edu (Anish R Athalye) Date: Sun, 14 Dec 2014 14:15:36 +0000 Subject: gpg: return value, validity vs trust In-Reply-To: <16497773.YEHMhZ8hCj@inno> References: <5180269.XRBDg6F6eh@inno> <16497773.YEHMhZ8hCj@inno> Message-ID: <17545B97-C652-4820-8B18-979155BB63A4@mit.edu> On Dec 13, 2014, at 11:09 PM, Hauke Laging wrote: > Am Sa 13.12.2014, 23:25:17 schrieb Anish R Athalye: > >> When most people check signatures, they want a correct signature made >> by a trusted party ? a signature that is ?valid". That?s what many >> seem to expect when using the `gpg` command line tool to check >> signatures. > > Quite difficult to tell what "many seem to expect". Soon a certain someone > will ask you for a valid study... ;-) It seems to me that too many > people expect miracles from crypto software. They don't wanna care about > what is going on there but nonetheless everything shall be handled just > as they expect... > > >> However, the `gpg` tool checks only for ?correct? (and >> outputs a message to stderr if the signature in untrusted, but still >> returns 0 for success). > > The situation is too complex to be usefully handled by exit codes. > > >> And it seems pretty difficult to check for >> trust (there?s no clean API for this that I found). > > Fortunately you are wrong about that. For what you want you shall make > the verification call like this: > > gpg --status-fd 1 --verify file.asc Great, I didn?t know this existed. Thanks! > > That leads to output like this (plus some more lines intended more for > the human reader than for parsing): > > [GNUPG:] SIG_ID EC64yxSlofLKaZ2wyLvSGDkRAT8 2014-12-06 1417856145 > [GNUPG:] GOODSIG 486B17AB3F96AD8E Hauke Laging (Standardadresse) > [GNUPG:] VALIDSIG 03C7C358A842126450C104BA486B17AB3F96AD8E 2014-12-06 > 1417856145 0 4 0 1 2 00 7D82FB9FD25A2CE452416C37BF4B8EEF1A571DF5 > [GNUPG:] TRUST_ULTIMATE > > > The last line is what you want to know (in combination with GOODSIG / > VALIDSIG). Thus you have to check the output for some keywords. > > Quoting the DETAILS file: > > ################################ > TRUST_UNDEFINED > TRUST_NEVER > TRUST_MARGINAL [0 []] > TRUST_FULLY [0 []] > TRUST_ULTIMATE [0 []] > For good signatures one of these status lines are emitted to > indicate the validity of the key used to create the signature. > The error token values are currently only emitted by gpgsm. > VALIDATION_MODEL describes the algorithm used to check the > validity of the key. The defaults are the standard Web of > Trust model for gpg and the the standard X.509 model for > gpgsm. The defined values are > > "pgp" for the standard PGP WoT. > "shell" for the standard X.509 model. > "chain" for the chain model. > > Note that we use the term "TRUST_" in the status names for > historic reasons; we now speak of validity. > ################################ > > > Hauke > -- > Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ > http://userbase.kde.org/Concepts/OpenPGP_Help_Spread > OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From infinity0 at pwned.gg Sun Dec 14 15:47:01 2014 From: infinity0 at pwned.gg (Ximin Luo) Date: Sun, 14 Dec 2014 15:47:01 +0100 Subject: Weird behaviours in GPG 2.1 with validity In-Reply-To: <548C5743.5060208@pwned.gg> References: <548C5743.5060208@pwned.gg> Message-ID: <548DA2E5.9070403@pwned.gg> To clarify, the below was observed in GPG 2.1. On 13/12/14 16:12, Ximin Luo wrote: > (new,mine) If I import my public key [1] into an empty homedir and set ownertrust to ultimate, the validity (on all UIDs) is also set to ultimate. > > (old,mine) If I do the same thing with my pre-existing homedir, the validity (on all UIDs) is set to "undef" for some reason. > > (old,other) If I do the same thing with my pre-existing homedir, but with (e.g.) dkg's key [2], some UIDs are "undef" and other UIDs are "ultimate". > > (new,other) If I do the same thing with dkg's key in an empty homedir, the validity is set to ultimate. > > The validity also remains unchanged as "undef", even if I import a masterless secret key. (But GPG 1.4 seems to set the validity to "ultimate", in the same situation.) > > All of these behaviours are pretty weird. I couldn't find a good explanation of them in the docs. > > At the end of the day, I just want GPG to recognise my own key (with secret subkeys available, secret master key not available) as "ultimate" validity. How do I do this? > > X > > [1] A405 E58A B372 5B39 6ED1 B85C 1318 EFAC 5FBB DBCE > [2] 0EE5 BE97 9282 D80B 9F75 40F1 CCD2 ED94 D217 39E9 > > -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From gniibe at fsij.org Mon Dec 15 09:00:47 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 15 Dec 2014 17:00:47 +0900 Subject: Gnuk 1.1.4 Message-ID: <548E952F.7090701@fsij.org> Hello, Because GnuGP 2.1 offers ECC, I enabled ECC on Gnuk. Upon release of newer gcc-arm-embedded, it's good season to build newer Gnuk. Still, we need some fixes of GnuPG (because of private key format change during our development of GnuPG), but that's not larger now and it's going to be merged soon. We don't yet have standardized protocol of ECC for smartcard/token, but since we now have working example of gpg-agent protocol, we can evaluate the implementation of Gnuk. Here is the announcement. Enjoy, ========================= Gnuk version 1.1.4 is released. This is another experimental release of version 1.1.x series. Because of the incompatible change to 1.0 series, please refer new documentation for instructions of how to use Gnuk Token. (New documentation can be used for 1.0.x, too.) * Gnuk Documentation: http://www.fsij.org/doc-gnuk/ Here are highlights. * Experimental RSA-4096 support. Although it takes too long (more than 8.7 second), RSA-4096 is now implemented. * ECDH support. ECDH is now supported. You need development branch (master) of GnuPG to use this feature. * ECDSA and EdDSA is not that experimental. You don't need to edit DEFS variable in src/Makefile. * STM8S_DISCOVERY is not supported any more. It's flash ROM size (64KiB) is a bit small to have all features of Gnuk now. If you manually edit code to limit the size of executable, it still could run Gnuk, though. * configure's default target is now FST-01. Receiving reports from those who complain default target, I reconsidered. Those who has Olimex STM32 H103 usually has JTAG debugger, while FST-01 users don't. So, to be safe, the default target is now FST-01, instead of Olimex STM32 H103. Links ===== Gnuk Users Mailing List at alioth.debian.org: https://lists.alioth.debian.org/mailman/listinfo/gnuk-users Gnuk Repository: http://gitorious.org/gnuk/ FST-01 Gnuk Handbook (in Japanese); http://no-passwd.net/fst-01-gnuk-handbook/ FST-01 introduction: http://www.seeedstudio.com/wiki/index.php?title=FST-01 -- From wk at gnupg.org Mon Dec 15 11:01:48 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 15 Dec 2014 11:01:48 +0100 Subject: who is the target audience of gpgme-tool? In-Reply-To: <87y4qcsec1.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 12 Dec 2014 17:17:18 -0500") References: <87y4qcsec1.fsf@alice.fifthhorseman.net> Message-ID: <87k31tjkoj.fsf@vigenere.g10code.de> On Fri, 12 Dec 2014 23:17, dkg at fifthhorseman.net said: > I notice that as of gpgme 1.5.2, the tarball now installs the gpgme-tool > binary. i'm wondering who the target audience of this binary is. I use it for testing gpgme and I can imagine that it can be useful for scripting applications if you want some XML output. Ben added the XML stuff, so he might have some more ideas. > The choices i see for debian packaging are: > > 0) don't ship gpgme-tool in any debian binary package > > 1) ship gpgme-tool in libgpgme11-dev (the -dev package isn't multiarch) Here is might make sense > developers or people who are doing serious debugging, i'm inclined to > say we should choose option (1) above. Ack. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Dec 15 11:49:42 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 15 Dec 2014 11:49:42 +0100 Subject: patch: disable docs in libgpg-error build In-Reply-To: <548D6545.2090307@guardianproject.info> (Hans-Christoph Steiner's message of "Sun, 14 Dec 2014 11:24:05 +0100") References: <548D6545.2090307@guardianproject.info> Message-ID: <87fvchjigp.fsf@vigenere.g10code.de> On Sun, 14 Dec 2014 11:24, hans at guardianproject.info said: > The build process for Android is already quite complicated, so removing the > documentation from the build process is quite helpful in keeping things > manageable. Plus, there is currently some error in building the docs in the > GnuPG-for-Android build. The documentation is not included in the Android app Yep, I noticed the failures from the build robot. Indeed, being able to disable the documentation build makes sense. Actually we already have this for GnuPG and it should go into all packages. I just pushed the change for libgpg-error and will do that for all other packages too. To be compatible with gnupg the option is named --disable-doc, though. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Dec 15 11:57:10 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 15 Dec 2014 11:57:10 +0100 Subject: [PATCH] update gpgme's doc/gpl.texi to match version from gnupg In-Reply-To: <871to4tu0t.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 12 Dec 2014 16:53:06 -0500") References: <1409979847-31480-1-git-send-email-dkg@fifthhorseman.net> <87bnq5w4lh.fsf@alice.fifthhorseman.net> <874mvxnny3.fsf@vigenere.g10code.de> <871to4tu0t.fsf@alice.fifthhorseman.net> Message-ID: <8761ddji49.fsf@vigenere.g10code.de> On Fri, 12 Dec 2014 22:53, dkg at fifthhorseman.net said: > If you apply the change i promise i won't bug you about it any more! :) Thanks for the reminder. Commit c32fab4 pushed. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Mon Dec 15 14:42:09 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Mon, 15 Dec 2014 14:42:09 +0100 Subject: patch: disable docs in libgpg-error build In-Reply-To: <87fvchjigp.fsf@vigenere.g10code.de> References: <548D6545.2090307@guardianproject.info> <87fvchjigp.fsf@vigenere.g10code.de> Message-ID: <548EE531.40601@guardianproject.info> Werner Koch: > On Sun, 14 Dec 2014 11:24, hans at guardianproject.info said: > >> The build process for Android is already quite complicated, so removing the >> documentation from the build process is quite helpful in keeping things >> manageable. Plus, there is currently some error in building the docs in the >> GnuPG-for-Android build. The documentation is not included in the Android app > > Yep, I noticed the failures from the build robot. Indeed, being able > to disable the documentation build makes sense. Actually we already have > this for GnuPG and it should go into all packages. I just pushed the > change for libgpg-error and will do that for all other packages too. > > To be compatible with gnupg the option is named --disable-doc, though. > > > Shalom-Salam, > > Werner Sounds good to me, thanks for the quick review. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81 From dgouttegattat at incenp.org Tue Dec 16 11:52:47 2014 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Tue, 16 Dec 2014 11:52:47 +0100 Subject: [PATCH] gpg: read private DOs from card. Message-ID: <54900EFF.6000502@incenp.org> In GnuPG 2.x, when learning about an inserted OpenPGP smartcard, the PRIVATE-DO-{1..4} data lines sent by the agent are ignored by the learn_status_cb callback in g10/call-agent.c. This results in the card editor not listing the contents of the private data objects on the card. This was not the behavior of GnuPG 1.x, which correctly listed the private DOs. The attached patch allows gpg2 to lists the private DOs again (it's actually a simple copy-paste of the relevant GnuPG 1.x code in g10/cardglue.c). --- g10/call-agent.c | 8 ++++++++ 1 file changed, 8 insertions(+) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-gpg-read-private-DOs-from-card.patch Type: text/x-patch Size: 700 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 wk at gnupg.org Tue Dec 16 17:36:19 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 16 Dec 2014 17:36:19 +0100 Subject: [Announce] GnuPG 2.1.1 released Message-ID: <874msveem4.fsf@vigenere.g10code.de> Hello! The GnuPG Project is pleased to announce the availability of the second release of GnuPG modern: Version 2.1.1. 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 ======================= * gpg: Detect faulty use of --verify on detached signatures. * gpg: New import option "keep-ownertrust". * gpg: New sub-command "factory-reset" for --card-edit. * gpg: A stub key for smartcards is now created by --card-status. * gpg: Fixed regression in --refresh-keys. * gpg: Fixed regresion in %g and %p codes for --sig-notation. * gpg: Fixed best matching hash algo detection for ECDSA and EdDSA. * gpg: Improved perceived speed of secret key listisngs. * gpg: Print number of skipped PGP-2 keys on import. * gpg: Removed the option aliases --throw-keyid and --notation-data; use --throw-keyids and --set-notation instead. * gpg: New import option "keep-ownertrust". * gpg: Skip too large keys during import. * gpg,gpgsm: New option --no-autostart to avoid starting gpg-agent or dirmngr. * gpg-agent: New option --extra-socket to provide a restricted command set for use with remote clients. * gpgconf --kill does not anymore start a service only to kill it. * gpg-pconnect-agent: Add convenience option --uiserver. * Fixed keyserver access for Windows. * Fixed build problems on Mac OS X * The Windows installer does now install development files * More translations (but most of them are not complete). * To support remotely mounted home directories, the IPC sockets may now be redirected. This feature requires Libassuan 2.2.0. * Improved portability and the usual bunch of bug fixes. A detailed description of the changes found in 2.1 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.1 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.1.tar.bz2 (4689k) ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.1.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.1_20141216.exe (6364k) ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.1_20141216.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 with ".exe" replaced by ".tar.xz". This version fixes a lot of bugs found after the release of 2.1.0 but there are still known bugs which we are working on. Please check the mailing list archives and https://wiki.gnupg.org for 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.1.tar.bz2 you would use this command: gpg --verify gnupg-2.1.1.tar.bz2.sig gnupg-2.1.1.tar.bz2 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.1.tar.bz2, you would run the command like this: sha1sum gnupg-2.1.1.tar.bz2 and check that the output matches the first line from the following list: 3d11fd150cf86f842d077437edb119a775c7325d gnupg-2.1.1.tar.bz2 fb541b8685b78541c9b2fadb026787f535863b4a gnupg-w32-2.1.1_20141216.exe 72d65f33d070aeb1894b0415533aad1a131899f4 gnupg-w32-2.1.1_20141216.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 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048/E0856959 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31] 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 version of GnuPG has support for 26 languages with Chinese, Czech, French, German, Japanese, Russian, and Ukrainian being almost completely translated (2061 different strings). 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 as are 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. You may also want to follow postings at https://gnupg.org/blob/. 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. Finally, a big Thank You to all who helped greatly by donating money. Salam-Shalom, Werner -- 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 wk at gnupg.org Tue Dec 16 17:36:19 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 16 Dec 2014 17:36:19 +0100 Subject: [Announce] GnuPG 2.1.1 released Message-ID: <874msveem4.fsf@vigenere.g10code.de> Hello! The GnuPG Project is pleased to announce the availability of the second release of GnuPG modern: Version 2.1.1. 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 ======================= * gpg: Detect faulty use of --verify on detached signatures. * gpg: New import option "keep-ownertrust". * gpg: New sub-command "factory-reset" for --card-edit. * gpg: A stub key for smartcards is now created by --card-status. * gpg: Fixed regression in --refresh-keys. * gpg: Fixed regresion in %g and %p codes for --sig-notation. * gpg: Fixed best matching hash algo detection for ECDSA and EdDSA. * gpg: Improved perceived speed of secret key listisngs. * gpg: Print number of skipped PGP-2 keys on import. * gpg: Removed the option aliases --throw-keyid and --notation-data; use --throw-keyids and --set-notation instead. * gpg: New import option "keep-ownertrust". * gpg: Skip too large keys during import. * gpg,gpgsm: New option --no-autostart to avoid starting gpg-agent or dirmngr. * gpg-agent: New option --extra-socket to provide a restricted command set for use with remote clients. * gpgconf --kill does not anymore start a service only to kill it. * gpg-pconnect-agent: Add convenience option --uiserver. * Fixed keyserver access for Windows. * Fixed build problems on Mac OS X * The Windows installer does now install development files * More translations (but most of them are not complete). * To support remotely mounted home directories, the IPC sockets may now be redirected. This feature requires Libassuan 2.2.0. * Improved portability and the usual bunch of bug fixes. A detailed description of the changes found in 2.1 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.1 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.1.tar.bz2 (4689k) ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.1.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.1_20141216.exe (6364k) ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.1_20141216.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 with ".exe" replaced by ".tar.xz". This version fixes a lot of bugs found after the release of 2.1.0 but there are still known bugs which we are working on. Please check the mailing list archives and https://wiki.gnupg.org for 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.1.tar.bz2 you would use this command: gpg --verify gnupg-2.1.1.tar.bz2.sig gnupg-2.1.1.tar.bz2 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.1.tar.bz2, you would run the command like this: sha1sum gnupg-2.1.1.tar.bz2 and check that the output matches the first line from the following list: 3d11fd150cf86f842d077437edb119a775c7325d gnupg-2.1.1.tar.bz2 fb541b8685b78541c9b2fadb026787f535863b4a gnupg-w32-2.1.1_20141216.exe 72d65f33d070aeb1894b0415533aad1a131899f4 gnupg-w32-2.1.1_20141216.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 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048/E0856959 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31] 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 version of GnuPG has support for 26 languages with Chinese, Czech, French, German, Japanese, Russian, and Ukrainian being almost completely translated (2061 different strings). 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 as are 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. You may also want to follow postings at https://gnupg.org/blob/. 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. Finally, a big Thank You to all who helped greatly by donating money. Salam-Shalom, Werner -- 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 dkg at fifthhorseman.net Wed Dec 17 00:23:57 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 16 Dec 2014 18:23:57 -0500 Subject: semantics of gnupg --keyserver in 2.1 Message-ID: <87k31rrxf6.fsf@alice.fifthhorseman.net> in GnuPG 2.1, keyserver operations are delegated to the dirmngr daemon. This is a good move overall, because it means the daemon can do things like keep track of which keyservers it has tried recently. however, it means that some commands that users may be used to won't do what they expect. For example, in 2.1: gpg --keyserver foo.example --recv 0xdeadbeef won't actually try to talk to foo.example, if dirmngr is already started and has decided that it will use bar.example (e.g. from ~/.gnupg/gpg.conf). Should gpg warn about the fact that --keyserver is being ignored here? --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 Wed Dec 17 01:13:19 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 16 Dec 2014 19:13:19 -0500 Subject: gpg --refresh with large keyrings and hkps in 2.1.1 Message-ID: <87h9wvrv4w.fsf@alice.fifthhorseman.net> i'm trying to test "gpg --refresh" with large keyrings in gnupg 2.1.1. It's better than it was before, but i'm still getting some errors with a larger keyring. In particular, i'm seeing an abort when i try to refresh the a large keyring against an hkps keyserver; only the first 83 keys get refreshed, and then gpg aborts with: gpg: keyserver refresh failed: Input/output error Trying the same thing again only results in the same first 83 keys being refreshed, which means the rest of the keyring is never refreshed. This appears to be reproducible on a debian system, using a fresh, non-privileged user account: $ mkdir ~/.gnupg $ cat > ~/.gnupg/gpg.conf < ~/.gnupg/gpg.conf <" not changed [...] gpg: key DECAFBAD: "example 2 " not changed gpg: Total number processed: 83 gpg: unchanged: 83 gpg: keyserver refresh failed: Input/output error 2 test at tester:~$ clearly, the other 900 keys were not properly imported. I can see from looking at packet captures that multiple connections were opened and closed to this keyserver during the refresh, though. I'm not sure why one of them ultimately failed. If i add the following three lines in dirmngr.conf: log-file /home/example/dirmngr.log debug-level expert gnutls-debug 9999 then it creates a 14MiB logfile, which looks fine right up until the end, but in the middle of the last batch of updates: 2014-12-16 18:54:41 dirmngr[7939.0] DBG: chan_0 -> D qHV+tY0R04hvWVwVKwcLs1xv/W66GgiKrm173QpVzjXCKLucSZWhdkhGZAdEosXFqg2xYRhV%0A 2014-12-16 18:54:41 dirmngr[7939.0] DBG: chan_0 -> D cagU/RiPS4ZH4uI16pA9XrQkTWF0dGhldyBQYWxtZXIgP 2014-12-16 18:54:41 dirmngr[7939.0] DBG: gnutls:L10: READ: Got 0 bytes from 0x7f9168008ba0 2014-12-16 18:54:41 dirmngr[7939.0] DBG: gnutls:L10: READ: read 0 bytes from 0x7f9168008ba0 2014-12-16 18:54:41 dirmngr[7939.0] DBG: gnutls:L3: ASSERT: gnutls_buffers.c:551 2014-12-16 18:54:41 dirmngr[7939.0] DBG: gnutls:L3: ASSERT: gnutls_record.c:1064 2014-12-16 18:54:41 dirmngr[7939.0] DBG: gnutls:L3: ASSERT: gnutls_record.c:1185 2014-12-16 18:54:41 dirmngr[7939.0] DBG: gnutls:L3: ASSERT: gnutls_record.c:1437 2014-12-16 18:54:41 dirmngr[7939.0] TLS network read failed: The TLS connection was non-properly terminated. 2014-12-16 18:54:41 dirmngr[7939.0] DBG: gnutls:L5: REC[0x7f9168013590]: Start of epoch cleanup 2014-12-16 18:54:41 dirmngr[7939.0] DBG: gnutls:L5: REC[0x7f9168013590]: End of epoch cleanup 2014-12-16 18:54:41 dirmngr[7939.0] DBG: gnutls:L5: REC[0x7f9168013590]: Epoch #1 freed 2014-12-16 18:54:41 dirmngr[7939.0] DBG: chan_0 -> D G1wYWxtZXJAaGV6bWF0dC5vcmc+%0A 2014-12-16 18:54:41 dirmngr[7939.0] DBG: chan_0 -> D iEYEEBECAAYFAk0u17YACgkQBEnrTWk1E4frMwCfQPUV0U46c+t7/oW8rRfToVox8n4An3Ct%0A 2014-12-16 18:54:41 dirmngr[7939.0] DBG: chan_0 -> D x484xfR/UGtxapG3ofBkF7gciEYEEBEIAAYFAk1RccsACgkQKb5dImj9VJ/8xgCgrWse1rUU%0A 2014-12-16 18:54:41 dirmngr[7939.0] DBG: chan_0 -> D 08U3gqW27k0l0riZ34kAn3hM7PmRXEMTSc4H5e111gxJgWC8iEYEEBEIAAYFAlQ+8B0ACgkQ%0A [...another 100 or so lines of base64-encoded PGP data here...] 2014-12-16 18:54:41 dirmngr[7939.0] DBG: chan_0 -> D SnmID0CrTa9jjOxussClKrn9VErdVtP5iaPceUWvYezrtZeIB6l0K0ZwChgUsKt4Gkoj95LJ%0A 2014-12-16 18:54:41 dirmngr[7939.0] DBG: chan_0 -> D hC9F9npWhNa3UfBhYQlF3svIQE+WhhG5kp/h4+ZqKKhdkMJEE7dWiMGVCxm5hVeklsoeSEPJ%0A 2014-12-16 18:54:41 dirmngr[7939.0] DBG: chan_0 -> D qjD88Op0y+gvrqQQkrhHEz2eW0agplSBOxDss47NGv6yk9vzfMnkyHLWw13d8pI8TAJKa 2014-12-16 18:54:41 dirmngr[7939.0] command 'KS_GET' failed: Input/output error 2014-12-16 18:54:41 dirmngr[7939.0] DBG: chan_0 -> ERR 167804977 Input/output error 2014-12-16 18:54:41 dirmngr[7939.0] DBG: chan_0 <- BYE 2014-12-16 18:54:41 dirmngr[7939.0] DBG: chan_0 -> OK closing connection 2014-12-16 18:54:41 dirmngr[7939.0] handler for fd 0 terminated I don't know if this is a timing issue with the particular TLS backend of this server (nginx acting as a reverse proxy), a network failure, or if it's something else entirely, but it seems like an intermittent network failure shouldn't cause the full keyring refresh to abort. I've also tried this with the keyserver being hkps://hkps.sks-keyservers.net and hkp-ca-cert set to the file fetched From here: https://sks-keyservers.net/sks-keyservers.netCA.pem -- and i ran into the same 83-key cutoff. Can anyone else confirm that this is happening? I'm not sure what the next steps are for diagnosis. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: mfpl.pem Type: application/x-x509-ca-cert Size: 1294 bytes Desc: mfpl CA URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From gniibe at fsij.org Wed Dec 17 02:00:42 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 17 Dec 2014 10:00:42 +0900 Subject: po: Update Japanese Translation Message-ID: <5490D5BA.6090003@fsij.org> Hello, I am always late, but I updated Japanese Translation of po/ja.po for 2.1.1, and pushed. Congratulation for the release. -- From gniibe at fsij.org Wed Dec 17 03:39:39 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 17 Dec 2014 11:39:39 +0900 Subject: scd: ECDH Support In-Reply-To: <5486A47C.2090609@fsij.org> References: <54813D71.1010507@fsij.org> <87tx1asfnb.fsf@vigenere.g10code.de> <548171DF.8030200@fsij.org> <5486A47C.2090609@fsij.org> Message-ID: <5490ECEB.30106@fsij.org> On 12/09/2014 04:27 PM, NIIBE Yutaka wrote: > Here are changes to support ECDH by scdaemon. > > I tested this code with experimental version of Gnuk. It takes about > 0.6 second to decrypt for NIST P-256 (measured on host PC by gpg > --decrypt). And it works with Gnuk 1.1.4. > I don't know if this protocol is good (or compatible) with existing > smartcard/token/hsm. In this implementation, scdaemon only computes > [d]P (d: private key, P: point) to get shared point and does not > compute AESWrap, following the protocol of gpg-agent. It was around March 2013, when I wrote some code for scdaemon's partial support of ECDH. At that time, I thought it were card/token which also computes AESWrap. In the current implementation of GnuPG, it's not even gpg-agent, but gpg frontend itself which does AESWrap. So, the changes in the patch make sense. Since March 2013, I haven't got any information about existing card/hsm which supports C(1, 1, ECC CDH). (While I know those which support ECDSA.) Speaking about situation in Japan, "Specifications of ciphers in the e-Government Recommended Ciphers List" was published (after I wrote code in 2013): http://www.cryptrec.go.jp/english/method.html It only addresses C(2, 0, ECC CDH) (as the former version of 2003). Given this situation, I think that this patch is relevant and it can be a reference for those who want to implement ECC on their card/token. -- From gnupg-devel at spodhuis.org Wed Dec 17 03:58:54 2014 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Wed, 17 Dec 2014 02:58:54 +0000 Subject: gpg --refresh with large keyrings and hkps in 2.1.1 In-Reply-To: <87h9wvrv4w.fsf@alice.fifthhorseman.net> References: <87h9wvrv4w.fsf@alice.fifthhorseman.net> Message-ID: <20141217025853.GA80826@tower.spodhuis.org> On 2014-12-16 at 19:13 -0500, Daniel Kahn Gillmor wrote: > i'm trying to test "gpg --refresh" with large keyrings in gnupg 2.1.1. > It's better than it was before, but i'm still getting some errors with a > larger keyring. > > In particular, i'm seeing an abort when i try to refresh the a large > keyring against an hkps keyserver; only the first 83 keys get refreshed, > and then gpg aborts with: > > gpg: keyserver refresh failed: Input/output error Does the same happen with an hkp keyserver? You don't explicitly note that you see things proceed further with hkp, which would lead to knowing if the problem is with key sizes (on particular key, which you see 83 keys into your keyring) or with TLS. If you only see this with TLS, are you able to get a pcap capture of what's happening and get a protocol trace? Things which come to mind as avenues for investigation, assuming TLS-specific: * TLS session renegotiation and whether or not the GnuTLS integration in GnuPG is missing some callback to allow this * keyserver TLS proxy size limits, hitting some particular caching limit in size which fits in memory in a common configuration * Whether or not smaller keys kept you from reaching MTU-sized packets and something bad is happening locally for you with timeouts during Path MTU Discovery, only kicking in once the flows are large enough inbound The webpage is very ugly, but does at least show you in-line in the table what the Via: header is (and the Server: header too). It might be worth selecting a host each with "nginx", "Apache", "lighttpd", "Squid", "xs-httpd" and "HAProxy" as the TLS provider on the server-side. This will at least let you rule out client/server TLS interop issues. You'll probably need to coerce the hostname to be the pool server, though, to get a validatable certificate presented to you. Might be easiest to just hack /etc/hosts around as needed. -Phil From wk at gnupg.org Wed Dec 17 09:49:13 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 17 Dec 2014 09:49:13 +0100 Subject: po: Update Japanese Translation In-Reply-To: <5490D5BA.6090003@fsij.org> (NIIBE Yutaka's message of "Wed, 17 Dec 2014 10:00:42 +0900") References: <5490D5BA.6090003@fsij.org> Message-ID: <87bnn2d5km.fsf@vigenere.g10code.de> On Wed, 17 Dec 2014 02:00, gniibe at fsij.org said: > I am always late, but I updated Japanese Translation of po/ja.po for > 2.1.1, and pushed. Yeah, I changed or added a few strings this year but given that we have many open bugs, I didn't bothered to ask for new translations. Frankly, I'd be glad if we could separate PO files from the release that would make it easier to add new translations. IIRC< we had such a discussion on gnu-prog-discuss many years ago but didn't agree that it is worth to implement. > Congratulation for the release. Thanks, for your work. BTW, I have not tested the factory reset with gnuk yet. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From aheinecke at intevation.de Wed Dec 17 10:37:39 2014 From: aheinecke at intevation.de (Andre Heinecke) Date: Wed, 17 Dec 2014 10:37:39 +0100 Subject: semantics of gnupg --keyserver in 2.1 In-Reply-To: <87k31rrxf6.fsf@alice.fifthhorseman.net> References: <87k31rrxf6.fsf@alice.fifthhorseman.net> Message-ID: <2262124.SUJ4eYZhfN@esus> Hi, On Tuesday, December 16, 2014 06:23:57 PM Daniel Kahn Gillmor wrote: > in GnuPG 2.1, keyserver operations are delegated to the dirmngr daemon. > > This is a good move overall, because it means the daemon can do things > like keep track of which keyservers it has tried recently. > > however, it means that some commands that users may be used to won't do > what they expect. For example, in 2.1: > > gpg --keyserver foo.example --recv 0xdeadbeef > > won't actually try to talk to foo.example, if dirmngr is already started > and has decided that it will use bar.example (e.g. from > ~/.gnupg/gpg.conf). Gnupg sends the dirmngr the keyserver it should use with a KEYSERVER command. In dirmngr's debug output you can see that it sends KEYSERVER --clear and then another KEYSERVER command for each keyserver configured. In my tests it always used the last one. > Should gpg warn about the fact that --keyserver is being ignored here? I hacked it for me locally to send the keyserver supplied with --keyserver as the last one. (Added a commit message and attached this) I have not sent this to werner as I am not sure that this a proper solution. If the keyserver setting from the command line should just overwrite the settings from the config then there is no need for a list. And I would have expected dirmngr to fall back to the configured keyserver if the server provided by --keyserver is not available. This also does not happen. Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-gpg-Append-command-line-keyserver-to-options.patch Type: text/x-patch Size: 1318 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From gniibe at fsij.org Wed Dec 17 11:11:15 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 17 Dec 2014 19:11:15 +0900 Subject: po: Update Japanese Translation In-Reply-To: <87bnn2d5km.fsf@vigenere.g10code.de> References: <5490D5BA.6090003@fsij.org> <87bnn2d5km.fsf@vigenere.g10code.de> Message-ID: <549156C3.2060802@fsij.org> On 12/17/2014 05:49 PM, Werner Koch wrote: > BTW, I have not tested the factory reset with gnuk yet. I will do. Gnuk doesn't support factory reset. I wrote following comment in openpgp-do.c: /* * Currently, we support no life cycle management. * In case of Gnuk, user could flash the MCU, instead. * Thus, just return the template as is. * * In future (when Gnuk will be on the real smartcard), * we can support life cycle management by implementing * TERMINATE DF / ACTIVATE FILE and fix code around here. */ ... and there is another way: by upgrading its firmware. I need to test if gpg returns error correctly. -- From kristian.fiskerstrand at sumptuouscapital.com Wed Dec 17 12:03:27 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 17 Dec 2014 12:03:27 +0100 Subject: gpg --refresh with large keyrings and hkps in 2.1.1 In-Reply-To: <87h9wvrv4w.fsf@alice.fifthhorseman.net> References: <87h9wvrv4w.fsf@alice.fifthhorseman.net> Message-ID: <549162FF.4020009@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 12/17/2014 01:13 AM, Daniel Kahn Gillmor wrote: > i'm trying to test "gpg --refresh" with large keyrings in gnupg > 2.1.1. It's better than it was before, but i'm still getting some > errors with a larger keyring. .. > > Can anyone else confirm that this is happening? I can reproduce the error, but not the number of keys before hitting it while connecting with keys2.kfwebs.net over HKPS on an external network (using the sks-keyservers.net CA cert) gpg: DBG: chan_5 <- ERR 167804977 Input/output error gpg: Total number processed: 416 gpg: next trustdb check due at 2014-12-25 gpg: keyserver refresh failed: Input/output error gpg: DBG: chan_5 -> BYE - -- - ---------------------------- 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 - ---------------------------- Donec eris sospes, multos numerabis amicos. Tempora si fuerint nubila, solus eris. As long as you are wealthy,you will have many friends. When the tough times come, you will be left alone -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUkWL2AAoJEPw7F94F4TagbxsQAJRRuqJXrGZ8QBuZRsCm7Wcp XpCsLULtCQ3775tQXMYzzG2Vg91J7v8yYynbWSEHpe5ipbISW98R8cYwnbvQ/DSp R/6Raq+4NzY446qjRI3Bb2EcxOrgnDZFaV/oOcxrBRY3vczCjnf37JiI5mch+3NX Yr6GRtuxYTm0cQefMYYRR15W3eo58+Xk0TSkpS4sTfjIp04nJcmHpJmsILP9ai0/ Zh78tfLOuVSMVs/Gf9ZXJsipMXDuUv4dNcauWulvPXFmZj8nIfrLBmf0g4tCdnWi 59KU9gkeMTr7wghyE7vXuP0vKD9zMoFODr51gi+nJWMopwimYP9isBpRSa8oaGWw WEICebnP0nHVuOxrPRXcmFfLzITa3ShiyWxLM8bYqD4OwCeWm6inv483Ld7wa6tQ TZLYnJgAlHAdbt/Tp3jzc+k8L4Ds7NzhySlVmKtN+uPY1G5b9L2q0D4sVzK4Ucv5 CGBEFyiFaeVnRxUVKQDDn15nKZGtjNCXeYkePaAn7fe8Ws2ktOBqLsYkxrwpTTME EUA50CiocGaHLEr9hkigGGIP5W19Fmt48c0uKuVNucEUX0OjWLG8X3HEaOUx+IFR hLC8y7eNuxQjwysc3q5F2Y2vrFklUstRCyCOBfyWYH0g0umrE8dF3sSoTJnQE/xi xut7pFRnInMMT/6Bh/Pz =evrB -----END PGP SIGNATURE----- From wk at gnupg.org Wed Dec 17 15:29:19 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 17 Dec 2014 15:29:19 +0100 Subject: gpg --refresh with large keyrings and hkps in 2.1.1 In-Reply-To: <549162FF.4020009@sumptuouscapital.com> (Kristian Fiskerstrand's message of "Wed, 17 Dec 2014 12:03:27 +0100") References: <87h9wvrv4w.fsf@alice.fifthhorseman.net> <549162FF.4020009@sumptuouscapital.com> Message-ID: <87egry9wow.fsf@vigenere.g10code.de> On Wed, 17 Dec 2014 12:03, kristian.fiskerstrand at sumptuouscapital.com said: > I can reproduce the error, but not the number of keys before hitting > it while connecting with keys2.kfwebs.net over HKPS on an external > network (using the sks-keyservers.net CA cert) I conclude that there is a need to look closer at the HKPS implementation and also the SRV records and such. The dirmngr log should give some more error messages than in 2.1.0 - maybe that is of help. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Dec 17 15:37:31 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 17 Dec 2014 15:37:31 +0100 Subject: po: Update Japanese Translation In-Reply-To: <549156C3.2060802@fsij.org> (NIIBE Yutaka's message of "Wed, 17 Dec 2014 19:11:15 +0900") References: <5490D5BA.6090003@fsij.org> <87bnn2d5km.fsf@vigenere.g10code.de> <549156C3.2060802@fsij.org> Message-ID: <87a92m9wb8.fsf@vigenere.g10code.de> On Wed, 17 Dec 2014 11:11, gniibe at fsij.org said: > On 12/17/2014 05:49 PM, Werner Koch wrote: >> BTW, I have not tested the factory reset with gnuk yet. > > I will do. Gnuk doesn't support factory reset. Alright, it actually acnnounceds it: $ gpg-connect-agent 'scd getattr EXTCAP' /bye S EXTCAP gc=0+ki=1+fc=1+pd=0+mcl3=0+aac=0+sm=0+si=0 OK si=0 is the Life Cycle status indicator which is 5 for cards which support it. Thus for my gnuk it does not work: gpg/card> factory-reset gpg: OpenPGP card no. D276000124010200FFFE55FF6D060000 detected gpg: This command is not supported by this card > ... and there is another way: by upgrading its firmware. Yeah, right. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Dec 17 15:40:23 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 17 Dec 2014 15:40:23 +0100 Subject: semantics of gnupg --keyserver in 2.1 In-Reply-To: <2262124.SUJ4eYZhfN@esus> (Andre Heinecke's message of "Wed, 17 Dec 2014 10:37:39 +0100") References: <87k31rrxf6.fsf@alice.fifthhorseman.net> <2262124.SUJ4eYZhfN@esus> Message-ID: <874msu9w6g.fsf@vigenere.g10code.de> On Wed, 17 Dec 2014 10:37, aheinecke at intevation.de said: > If the keyserver setting from the command line should just overwrite the > settings from the config then there is no need for a list. And I would have Frankly, I am not sure what to do, either. My code tried to make it mostly compatible with gnupg < 2.1 but there are other options, Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From aheinecke at intevation.de Wed Dec 17 17:08:57 2014 From: aheinecke at intevation.de (Andre Heinecke) Date: Wed, 17 Dec 2014 17:08:57 +0100 Subject: semantics of gnupg --keyserver in 2.1 In-Reply-To: <874msu9w6g.fsf@vigenere.g10code.de> References: <87k31rrxf6.fsf@alice.fifthhorseman.net> <2262124.SUJ4eYZhfN@esus> <874msu9w6g.fsf@vigenere.g10code.de> Message-ID: <2630341.O0MPFsDyWl@esus> Hi, On Wednesday, December 17, 2014 03:40:23 PM Werner Koch wrote: > Frankly, I am not sure what to do, either. My code tried to make it > mostly compatible with gnupg < 2.1 but there are other options, In that case I would vote for just overwriting the config value if it is provided on the command line and use a fallback mechanism using one or multiple config entries otherwise. (or multiple keyserver options on the command line) If you explicitly set the command line keyserver parameter you probably really want that keyserver to be used for some reason. So this should overwrite the config. This would also avoid the necessity of detecting if a keyserver came from config or from the command line to print a proper informational message if a fallback is used in case the command line keyserver is not available. (I would expect this in that case) Now for configured keyservers or multiple keyserver arguments on the command line dirmngr should use all of them and try them out. Currently it fails on the first failing server but I would expect that if i have keyserver hkp://foo.bar keyserver hkp://bar.baz in my config that it would first try foo.bar and if that server is unreachable try bar.baz. (I think this is how the protocol is currently supposed to work with KEYSERVER --clear and multiple KEYSERVER commands but for me it always fails if it encounters a server that is unreachable) Btw. kleopatra already offers to configure multiple keyservers although this did not work with older versions. Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From laurent at elanor.org Wed Dec 17 17:05:09 2014 From: laurent at elanor.org (Laurent Blume) Date: Wed, 17 Dec 2014 17:05:09 +0100 Subject: libgpg_error gmake check fails on Solaris 10 sparc Message-ID: <5491A9B5.7010708@elanor.org> Hello, I'm building libgpg_error 1.17 on Solaris 10 using GCC 4.9.2. It builds, but the ?gmake check? part fails with multiple errors like this one: /bin/bash: line 5: 245 Abort (core dumped) ${dir}$tst FAIL: t-version It appears some of the binaries in tests/ are crashing: $ pstack core core 'core' of 16087: ./t-printf ff2debc4 _lwp_kill (6, 0, 0, ff2be06c, ffffffff, 6) + 8 ff2529b0 abort (ff1c35ec, 1, ff1de3e0, ffb3c, ff355518, 0) + 110 ff1c35b8 get_lock_object (ff1dea64, ff1c2fa8, ff1c6e68, ff1c6c98, 1, 0) + 4 ff1c35f0 _gpgrt_lock_lock (ff1dea64, 1, ff202a00, ff3ec984, 1, ff3ef6d0) + 4 ff1c6d60 _gpgrt_fflush (0, 0, ff1dea64, 1c00, 0, 0) + c8 ff1c6e68 do_deinit (ffbff858, 0, 4, 0, ff359540, ff3a5a04) + 10 ff253178 _exithandle (ff359540, ff357940, 1c00, 80808080, ff00, f) + 40 ff241138 exit (0, 114d0, f, f, f, 15) + 4 00010c58 _start (0, 0, 0, 0, 0, 0) + 64 A build using the same recipe on Solaris 10 x86 works fine, Since I hadn't built it since 1.12, I did some tests on older versions, it seems there was a crash of t-lock starting with 1.13. Anything else I can provide to help fix that? I can easily apply patches and rebuild if needed. Thanks! Laurent From dkg at fifthhorseman.net Wed Dec 17 18:31:24 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 17 Dec 2014 12:31:24 -0500 Subject: semantics of gnupg --keyserver in 2.1 In-Reply-To: <2630341.O0MPFsDyWl@esus> References: <87k31rrxf6.fsf@alice.fifthhorseman.net> <2262124.SUJ4eYZhfN@esus> <874msu9w6g.fsf@vigenere.g10code.de> <2630341.O0MPFsDyWl@esus> Message-ID: <5491BDEC.3060904@fifthhorseman.net> On 12/17/2014 11:08 AM, Andre Heinecke wrote: > In that case I would vote for just overwriting the config value if it is > provided on the command line and use a fallback mechanism using one or > multiple config entries otherwise. (or multiple keyserver options on the > command line) > > If you explicitly set the command line keyserver parameter you probably really > want that keyserver to be used for some reason. So this should overwrite the > config. Just to clarify, i think you mean "override", not "overwrite" -- there is no need to modify the configuration file because of the presence of the command-line argument, correct? I like the idea that if a --keyserver command line argument is present, it would supersede the configuration information that dirmngr started up with -- but only for these specific queries. other queries routed through the same dirmngr process concurrently (or afterward) should retain their initial configuration. --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 aheinecke at intevation.de Wed Dec 17 19:48:32 2014 From: aheinecke at intevation.de (Andre Heinecke) Date: Wed, 17 Dec 2014 19:48:32 +0100 Subject: semantics of gnupg --keyserver in 2.1 In-Reply-To: <5491BDEC.3060904@fifthhorseman.net> References: <87k31rrxf6.fsf@alice.fifthhorseman.net> <2630341.O0MPFsDyWl@esus> <5491BDEC.3060904@fifthhorseman.net> Message-ID: <4878620.3TiIonn2yu@esus> On Wednesday, December 17, 2014 12:31:24 PM Daniel Kahn Gillmor wrote: > On 12/17/2014 11:08 AM, Andre Heinecke wrote: > > If you explicitly set the command line keyserver parameter you probably > > really want that keyserver to be used for some reason. So this should > > overwrite the config. > > Just to clarify, i think you mean "override", not "overwrite" -- there > is no need to modify the configuration file because of the presence of > the command-line argument, correct? Yes you are correct. Apologies for the bad wording. > I like the idea that if a --keyserver command line argument is present, > it would supersede the configuration information that dirmngr started up > with -- but only for these specific queries. other queries routed > through the same dirmngr process concurrently (or afterward) should > retain their initial configuration. I also agree with you there. Afaik this happens now as the gnupg process always sends a --clear with the first KEYSERVER command. Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From kristian.fiskerstrand at sumptuouscapital.com Wed Dec 17 19:58:10 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 17 Dec 2014 19:58:10 +0100 Subject: gpg --refresh with large keyrings and hkps in 2.1.1 In-Reply-To: <549162FF.4020009@sumptuouscapital.com> References: <87h9wvrv4w.fsf@alice.fifthhorseman.net> <549162FF.4020009@sumptuouscapital.com> Message-ID: <5491D242.4070302@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 12/17/2014 12:03 PM, Kristian Fiskerstrand wrote: > On 12/17/2014 01:13 AM, Daniel Kahn Gillmor wrote: >> i'm trying to test "gpg --refresh" with large keyrings in gnupg >> 2.1.1. It's better than it was before, but i'm still getting >> some errors with a larger keyring. > > .. > > >> Can anyone else confirm that this is happening? > > I can reproduce the error, but not the number of keys before > hitting it while connecting with keys2.kfwebs.net over HKPS on an > external network (using the sks-keyservers.net CA cert) > > gpg: DBG: chan_5 <- ERR 167804977 Input/output error gpg: > Total number processed: 416 gpg: next trustdb check due at > 2014-12-25 gpg: keyserver refresh failed: Input/output error gpg: > DBG: chan_5 -> BYE > > Hmm, now that I'm back on my home network it seems to fully complete refresh to hkps pool. Perhaps a network issue from my last location gpg: Total number processed: 451 - -- - ---------------------------- 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 - ---------------------------- "The best way to predict the future is to invent it" (Alan Kay) -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUkdJAAAoJEPw7F94F4TagXwoP/0ZLN8IppuV55k/rzwZtRovJ 716Z0fNTCqHoVDj/YOehaf7r8yGY4fm889SlZJe29uOZca3BOTiulyK5RPR7jnca xy6meE7Zz9HOjMnLfsVpupkqdj0I+hoIFHYfC8S2ltrpXDsJ+LwrmYSCmEfG0WwU GtvPNvGQzj8DdX/V/9rWyiAZ6L92lKosRzfH/5nLqLvkVmaSIZu+VHNvVHkQyTSv zQbM/HFVar9Bm1GH/6dy88RD9lMIGWRgWLI08nOXFfY+q22mAMYDCorTVyVa6rGv eD3thso4BN0kNfnguCbHaNFj84L4ccLgyB8rkASeNCLRXagU+nYP4dnX3f0C11yT VowvOUpt/xqas4ajByxMSCVIQsX5ORX6A4WQKGoOzfWKpRbhKMH0YqDI4T8ZdwgJ tt/mc37baZdlgJa/LHQk91Nca38tbNsuTYPO+jZbIJQhCsnGx/CnGC1QYk+qNEuC 8Z9AvPccNxKAA0J/MU9wsPjryeSrLR6wWgc+rqEPeMFvD7Z9/T+8GpssxH0IS7vV zSPRx+uz02QEFbH9m5hEoTpMdhfiDJzwKxQpbBp5D3YXraA6lxr6xKZl/Q9wH/GN 9PZNjxkcSyctqACu6jBTslPYbtd3CkIZKknKav9eGrisL7S6oxvm+pg8mU7RjUnP 8x/8dr4SyK4aP0lfFOOq =4V8d -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Wed Dec 17 20:03:24 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 17 Dec 2014 14:03:24 -0500 Subject: semantics of gnupg --keyserver in 2.1 In-Reply-To: <4878620.3TiIonn2yu@esus> References: <87k31rrxf6.fsf@alice.fifthhorseman.net> <2630341.O0MPFsDyWl@esus> <5491BDEC.3060904@fifthhorseman.net> <4878620.3TiIonn2yu@esus> Message-ID: <87egryrtdv.fsf@alice.fifthhorseman.net> On Wed 2014-12-17 13:48:32 -0500, Andre Heinecke wrote: > On Wednesday, December 17, 2014 12:31:24 PM Daniel Kahn Gillmor wrote: >> I like the idea that if a --keyserver command line argument is present, >> it would supersede the configuration information that dirmngr started up >> with -- but only for these specific queries. other queries routed >> through the same dirmngr process concurrently (or afterward) should >> retain their initial configuration. > > I also agree with you there. Afaik this happens now as the gnupg process > always sends a --clear with the first KEYSERVER command. Here's what i see in the dirmngr log when doing: gpg2 --keyserver hkp://keys.gnupg.org --refresh $PGPID 2014-12-17 13:49:27 dirmngr[7354.0] ready with housekeeping 2014-12-17 13:58:21 dirmngr[7354.0] handler for fd 0 started 2014-12-17 13:58:21 dirmngr[7354.0] DBG: chan_0 -> # Home: /home/dkg/.gnupg 2014-12-17 13:58:21 dirmngr[7354.0] DBG: chan_0 -> # Config: /home/dkg/.gnupg/dirmngr.conf 2014-12-17 13:58:21 dirmngr[7354.0] DBG: chan_0 -> OK Dirmngr 2.1.1 at your service 2014-12-17 13:58:21 dirmngr[7354.0] connection from process 21358 (1000:1000) 2014-12-17 13:58:21 dirmngr[7354.1] handler for fd 1 started 2014-12-17 13:58:21 dirmngr[7354.1] DBG: chan_1 -> # Home: /home/dkg/.gnupg 2014-12-17 13:58:21 dirmngr[7354.1] DBG: chan_1 -> # Config: /home/dkg/.gnupg/dirmngr.conf 2014-12-17 13:58:21 dirmngr[7354.1] DBG: chan_1 -> OK Dirmngr 2.1.1 at your service 2014-12-17 13:58:21 dirmngr[7354.1] connection from process 21358 (1000:1000) 2014-12-17 13:58:21 dirmngr[7354.1] DBG: chan_1 <- KEYSERVER --clear hkp://keys.mayfirst.org 2014-12-17 13:58:21 dirmngr[7354.1] DBG: chan_1 -> OK 2014-12-17 13:58:21 dirmngr[7354.1] DBG: chan_1 <- KEYSERVER hkps://keys.mayfirst.org 2014-12-17 13:58:21 dirmngr[7354.1] DBG: chan_1 -> OK 2014-12-17 13:58:21 dirmngr[7354.1] DBG: chan_1 <- KS_GET -- 0x0EE5BE979282D80B9F7540F1CCD2ED94D21739E9 2014-12-17 13:58:21 dirmngr[7354.1] DBG: gnutls:L5: REC[0x7fce58008600]: Allocating epoch #0 2014-12-17 13:58:21 dirmngr[7354.1] DBG: gnutls:L3: ASSERT: gnutls_constate.c:586 (yes, my gpg.conf says "keyserver hkps://keys.mayfirst.org") so --clear is present, but the keyserver from the configuration file is also introduced (and appears to take precedence, since you can see gnutls being initialized). --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From wk at gnupg.org Wed Dec 17 22:34:35 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 17 Dec 2014 22:34:35 +0100 Subject: gpg --refresh with large keyrings and hkps in 2.1.1 In-Reply-To: <5491D242.4070302@sumptuouscapital.com> (Kristian Fiskerstrand's message of "Wed, 17 Dec 2014 19:58:10 +0100") References: <87h9wvrv4w.fsf@alice.fifthhorseman.net> <549162FF.4020009@sumptuouscapital.com> <5491D242.4070302@sumptuouscapital.com> Message-ID: <87egry6jv8.fsf@vigenere.g10code.de> On Wed, 17 Dec 2014 19:58, kristian.fiskerstrand at sumptuouscapital.com said: > Hmm, now that I'm back on my home network it seems to fully complete > refresh to hkps pool. Perhaps a network issue from my last location But it shows that we need better error messages shown directly by gpg and not maybe somewhere in the dirmngr log. Will for sure safe us time while helping users. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Wed Dec 17 23:42:50 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 17 Dec 2014 17:42:50 -0500 Subject: gpg --refresh with large keyrings and hkps in 2.1.1 In-Reply-To: <87egry6jv8.fsf@vigenere.g10code.de> References: <87h9wvrv4w.fsf@alice.fifthhorseman.net> <549162FF.4020009@sumptuouscapital.com> <5491D242.4070302@sumptuouscapital.com> <87egry6jv8.fsf@vigenere.g10code.de> Message-ID: <549206EA.7060901@fifthhorseman.net> On 12/17/2014 04:34 PM, Werner Koch wrote: > On Wed, 17 Dec 2014 19:58, kristian.fiskerstrand at sumptuouscapital.com > said: > >> Hmm, now that I'm back on my home network it seems to fully complete >> refresh to hkps pool. Perhaps a network issue from my last location > > But it shows that we need better error messages shown directly by gpg > and not maybe somewhere in the dirmngr log. Will for sure safe us time > while helping users. Agreed. It seems like "gpg --refresh" should also handle errors more gracefully. If there is a persistent failure at a given key, maybe it should restart the batched refresh after that failed fetch or something? I'm not sure what the right behavior would be, though. perhaps a "gpg --refresh" could select keys in a randomized order so that a manual restart wouldn't always get stuck in the same place? (of course, that would make reproducing bugs related to key fetch order pretty frustrating) --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 Thu Dec 18 01:17:30 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 17 Dec 2014 19:17:30 -0500 Subject: gpg --refresh with large keyrings and hkps in 2.1.1 In-Reply-To: <20141217025853.GA80826@tower.spodhuis.org> References: <87h9wvrv4w.fsf@alice.fifthhorseman.net> <20141217025853.GA80826@tower.spodhuis.org> Message-ID: <54921D1A.9070809@fifthhorseman.net> Hi Phil-- On 12/16/2014 09:58 PM, Phil Pennock wrote: > Does the same happen with an hkp keyserver? You don't explicitly note > that you see things proceed further with hkp, which would lead to > knowing if the problem is with key sizes (on particular key, which you > see 83 keys into your keyring) or with TLS. sorry, i should have mentioned this -- i have no problems with hkp, the full keyring refreshes. > If you only see this with TLS, are you able to get a pcap capture of > what's happening and get a protocol trace? i've gotten a pcap capture, but it's large (20MiB, 2408 packets, 22 TCP sessions for a query that fails 20 keys into the refresh) and encrypted, of course :/ Any suggestions for how to reduce its size to something more managable? > Things which come to mind as avenues for investigation, assuming > TLS-specific: > > * TLS session renegotiation and whether or not the GnuTLS integration > in GnuPG is missing some callback to allow this I'm not seeing any session resumption on any of the 22 TCP sessions in the packet capture. > * keyserver TLS proxy size limits, hitting some particular caching > limit in size which fits in memory in a common configuration i guess i'd need to turn on server-side logging on the keyserver i'm testing to catch that case, but it doesn't seem to line up with kristian's report of it changing depending on what network he used. > * Whether or not smaller keys kept you from reaching MTU-sized packets > and something bad is happening locally for you with timeouts during > Path MTU Discovery, only kicking in once the flows are large enough > inbound the MTU i'm seeing is F=1500 at the first hop (based on my running "traceroute --mtu keys2.kfwebs.net") > The webpage is very ugly, but does > at least show you in-line in the table what the Via: header is (and the > Server: header too). It might be worth selecting a host each with > "nginx", "Apache", "lighttpd", "Squid", "xs-httpd" and "HAProxy" as the > TLS provider on the server-side. This will at least let you rule out > client/server TLS interop issues. You'll probably need to coerce the > hostname to be the pool server, though, to get a validatable certificate > presented to you. Might be easiest to just hack /etc/hosts around as > needed. well, i've seen failures with the two that i've tested so far: keys.mayfirst.org (zimmermann.mayfirst.org), which is nginx + sks 1.1.5 and keys2.kfwebs.net, which doesn't indicate what its proxy mechanism is in that table. any other suggestions to help with the debugging would be welcome! --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 Dec 18 10:10:34 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 18 Dec 2014 10:10:34 +0100 Subject: gpg --refresh with large keyrings and hkps in 2.1.1 In-Reply-To: <549206EA.7060901@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 17 Dec 2014 17:42:50 -0500") References: <87h9wvrv4w.fsf@alice.fifthhorseman.net> <549162FF.4020009@sumptuouscapital.com> <5491D242.4070302@sumptuouscapital.com> <87egry6jv8.fsf@vigenere.g10code.de> <549206EA.7060901@fifthhorseman.net> Message-ID: <87vbl9492t.fsf@vigenere.g10code.de> On Wed, 17 Dec 2014 23:42, dkg at fifthhorseman.net said: > perhaps a "gpg --refresh" could select keys in a randomized order so > that a manual restart wouldn't always get stuck in the same place? (of > course, that would make reproducing bugs related to key fetch order > pretty frustrating) What do you think of having a queue in dirmngr with keys to be refreshed and dirmngr can handle that in its spare time. Either calling gpg from time to time to import the refreshed keys or - better - add a new command to gpg to fetch those retrieved keys from dirmngr. Such a queuing mechanism would also come handy when implementing a GNUnet based key retrieval which would anyway take longer than the direct access fro a fast keyserver. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From laurent at elanor.org Thu Dec 18 11:29:32 2014 From: laurent at elanor.org (Laurent Blume) Date: Thu, 18 Dec 2014 11:29:32 +0100 Subject: Most GnuPG 2.1.1 tests fail on Solaris 10 Message-ID: <5492AC8C.3000804@elanor.org> Hello, On Solaris 10, GnuPG 2.1.1 builds fine, but most tests fail: ====================================== 28 of 30 tests failed Please report to http://bugs.gnupg.org ====================================== I see two issues causing it, one is easy, the other seems odd. The first: /bin/sh on Solaris 10 is an old-fashioned Bourne shell, and it doesn't support $(). I attached a small patch to replace that by ``. The second: even after that, gpg-agent would fail to start. What it boils down too, apparently, is that if the GNUPGHOME variable is too long (as is the case when using the build directory for the tests), it fails. Here's a copy/paste example, using an empty directory: // First try, short GNUPGHOME, it starts normally $ mkdir /tmp/gnupg $ export GNUPGHOME=/tmp/gnupg $ ../../tools/gpg-connect-agent -v --agent-program="$(pwd)/../../agent/gpg-agent|--debug-quick-random" /bye gpg-connect-agent: no running gpg-agent - starting '/export/espace/apps/OpenCSW/mgar/gnupg2/branches/gnupg-2.1/work/build-isa-pentium_pro/gnupg-2.1.1/tests/openpgp/../../agent/gpg-agent|--debug-quick-random' gpg-connect-agent: waiting for the agent to come up ... (5s) gpg-connect-agent: connection to agent established gpg-connect-agent: closing connection to agent $ pkill gpg-agent // Second try, using an artificially long GNUPGHOME, it fails. Note that I used a multiple ../ only to emphasize it's the same directory, the issue is of course the same with a really long path. $ rm -rf /tmp/gnupg $ mkdir /tmp/gnupg $ export GNUPGHOME=/tmp/gnupg/../gnupg/../gnupg/../gnupg/../gnupg/../gnupg/../gnupg/../gnupg/../gnupg/../gnupg/../gnupg/../gnupg/../gnupg/../gnupg $ ../../tools/gpg-connect-agent -v --agent-program="$(pwd)/../../agent/gpg-agent|--debug-quick-random" /bye gpg-connect-agent: no running gpg-agent - starting '/export/espace/apps/OpenCSW/mgar/gnupg2/branches/gnupg-2.1/work/build-isa-pentium_pro/gnupg-2.1.1/tests/openpgp/../../agent/gpg-agent|--debug-quick-random' gpg-connect-agent: waiting for the agent to come up ... (5s) gpg-connect-agent: waiting for the agent to come up ... (4s) gpg-connect-agent: waiting for the agent to come up ... (3s) gpg-connect-agent: waiting for the agent to come up ... (2s) gpg-connect-agent: waiting for the agent to come up ... (1s) gpg-connect-agent: can't connect to the agent: Invalid value passed to IPC gpg-connect-agent: error sending standard options: No agent running Thanks, Laurent -------------- next part -------------- diff --git a/tests/openpgp/defs.inc b/tests/openpgp/defs.inc index 941f786..c7390cf 100755 --- a/tests/openpgp/defs.inc +++ b/tests/openpgp/defs.inc @@ -217,12 +217,12 @@ unset GPG_AGENT_INFO # (--no-permission-warning makes only sense on the commandline) GPG="../../g10/gpg2 --no-permission-warning " # (We may not use a relative name for gpg-agent.) -GPG_AGENT="$(cd ../../agent && /bin/pwd)/gpg-agent" +GPG_AGENT="`cd ../../agent && /bin/pwd`/gpg-agent" GPG_CONNECT_AGENT="../../tools/gpg-connect-agent" GPGCONF="../../tools/gpgconf" GPG_PRESET_PASSPHRASE="../../agent/gpg-preset-passphrase" MKTDATA="../../tools/mk-tdata" -PINENTRY="$(cd $srcdir && /bin/pwd)/pinentry.sh" +PINENTRY="`cd $srcdir && /bin/pwd`/pinentry.sh" # Default to empty passphrase for pinentry.sh PINENTRY_USER_DATA= From wk at gnupg.org Thu Dec 18 12:04:41 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 18 Dec 2014 12:04:41 +0100 Subject: Most GnuPG 2.1.1 tests fail on Solaris 10 In-Reply-To: <5492AC8C.3000804@elanor.org> (Laurent Blume's message of "Thu, 18 Dec 2014 11:29:32 +0100") References: <5492AC8C.3000804@elanor.org> Message-ID: <87oar143sm.fsf@vigenere.g10code.de> On Thu, 18 Dec 2014 11:29, laurent at elanor.org said: > /bin/sh on Solaris 10 is an old-fashioned Bourne shell, and it doesn't > support $(). I attached a small patch to replace that by ``. Oh dear, I thought we can meanwhile do without the old quotes. $() is POSIX and is much easier to use and read. Any chance to use a different shell? > even after that, gpg-agent would fail to start. > What it boils down too, apparently, is that if the GNUPGHOME variable > is too long (as is the case when using the build directory for the > tests), it fails. > gpg-connect-agent: waiting for the agent to come up ... (1s) > gpg-connect-agent: can't connect to the agent: Invalid value passed to IPC I would not have expected that error message. Can you use truss to trace the exec and socket calls? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From infinity0 at pwned.gg Thu Dec 18 13:00:00 2014 From: infinity0 at pwned.gg (Ximin Luo) Date: Thu, 18 Dec 2014 13:00:00 +0100 Subject: Weird behaviours in GPG 2.1 with validity In-Reply-To: <548DA2E5.9070403@pwned.gg> References: <548C5743.5060208@pwned.gg> <548DA2E5.9070403@pwned.gg> Message-ID: <5492C1C0.1030307@pwned.gg> Ping! Did anyone else look into this yet? On 14/12/14 15:47, Ximin Luo wrote: > To clarify, the below was observed in GPG 2.1. > > On 13/12/14 16:12, Ximin Luo wrote: >> (new,mine) If I import my public key [1] into an empty homedir and set ownertrust to ultimate, the validity (on all UIDs) is also set to ultimate. >> >> (old,mine) If I do the same thing with my pre-existing homedir, the validity (on all UIDs) is set to "undef" for some reason. >> >> (old,other) If I do the same thing with my pre-existing homedir, but with (e.g.) dkg's key [2], some UIDs are "undef" and other UIDs are "ultimate". >> >> (new,other) If I do the same thing with dkg's key in an empty homedir, the validity is set to ultimate. >> >> The validity also remains unchanged as "undef", even if I import a masterless secret key. (But GPG 1.4 seems to set the validity to "ultimate", in the same situation.) >> >> All of these behaviours are pretty weird. I couldn't find a good explanation of them in the docs. >> >> At the end of the day, I just want GPG to recognise my own key (with secret subkeys available, secret master key not available) as "ultimate" validity. How do I do this? >> >> X >> >> [1] A405 E58A B372 5B39 6ED1 B85C 1318 EFAC 5FBB DBCE >> [2] 0EE5 BE97 9282 D80B 9F75 40F1 CCD2 ED94 D217 39E9 >> >> -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git From laurent at elanor.org Thu Dec 18 13:45:35 2014 From: laurent at elanor.org (Laurent Blume) Date: Thu, 18 Dec 2014 13:45:35 +0100 Subject: Most GnuPG 2.1.1 tests fail on Solaris 10 In-Reply-To: <87oar143sm.fsf@vigenere.g10code.de> References: <5492AC8C.3000804@elanor.org> <87oar143sm.fsf@vigenere.g10code.de> Message-ID: <5492CC6F.5@elanor.org> Le 2014/12/18 12:04 +0100, Werner Koch a ?crit: > Oh dear, I thought we can meanwhile do without the old quotes. $() is > POSIX and is much easier to use and read. Any chance to use a different > shell? Well, I hate the backquotes myself, so if you've got a policy to replace them with $(), I can manage on my side to replace the shell with bash. WONTFIX is fine. >> gpg-connect-agent: waiting for the agent to come up ... (1s) >> gpg-connect-agent: can't connect to the agent: Invalid value passed to IPC > I would not have expected that error message. Can you use truss to > trace the exec and socket calls? There's a secret message in there, a gpg-agent error that was not displayed, it's really being picky on the path length: 29851: so_socket(PF_UNIX, SOCK_STREAM, 0, "", SOV_XPG4_2) = 3 29851: getpid() = 29851 [1] 29851: write(2, 0x080AECC8, 170) = 170 29851: g p g - a g e n t [ 2 9 8 5 1 ] : s o c k e t n a m e ' / 29851: t m p / g n u p g / . . / g n u p g / . . / g n u p g / . . / g 29851: n u p g / . . / g n u p g / . . / g n u p g / . . / g n u p g / 29851: . . / g n u p g / . . / g n u p g / . . / g n u p g / . . / g n 29851: u p g / . . / g n u p g / . . / g n u p g / . . / g n u p g / S 29851: . g p g - a g e n t 29851: write(2, 0x0809193F, 14) = 14 29851: ' i s t o o l o n g\n Laurent From wk at gnupg.org Thu Dec 18 14:30:50 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 18 Dec 2014 14:30:50 +0100 Subject: Most GnuPG 2.1.1 tests fail on Solaris 10 In-Reply-To: <5492CC6F.5@elanor.org> (Laurent Blume's message of "Thu, 18 Dec 2014 13:45:35 +0100") References: <5492AC8C.3000804@elanor.org> <87oar143sm.fsf@vigenere.g10code.de> <5492CC6F.5@elanor.org> Message-ID: <87h9wt3x11.fsf@vigenere.g10code.de> On Thu, 18 Dec 2014 13:45, laurent at elanor.org said: > Well, I hate the backquotes myself, so if you've got a policy to > replace them with $(), I can manage on my side to replace the shell > with bash. WONTFIX is fine. Well, if Solaris is the last of the modern Unices to not support a POSIX shell, I would indeed tag it as wontfix. > There's a secret message in there, a gpg-agent error that was not > displayed, it's really being picky on the path length: Alright, this is not Solaris specific. You have this problem on all Unices because the path length of a Unix domain socket is limit (107 seems to be a common value). We hafe this socket redirection feature but the API for this also uses the sun_path field of the sockaddr_un structure. Thus we have the same limitations. But that would also require manual configuration. Is it really worth to do that or should we better document that limitation? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Thu Dec 18 15:57:55 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 18 Dec 2014 09:57:55 -0500 Subject: gpg --refresh with large keyrings and hkps in 2.1.1 In-Reply-To: <87vbl9492t.fsf@vigenere.g10code.de> References: <87h9wvrv4w.fsf@alice.fifthhorseman.net> <549162FF.4020009@sumptuouscapital.com> <5491D242.4070302@sumptuouscapital.com> <87egry6jv8.fsf@vigenere.g10code.de> <549206EA.7060901@fifthhorseman.net> <87vbl9492t.fsf@vigenere.g10code.de> Message-ID: <5492EB73.7060905@fifthhorseman.net> On 12/18/2014 04:10 AM, Werner Koch wrote: > What do you think of having a queue in dirmngr with keys to be refreshed > and dirmngr can handle that in its spare time. Either calling gpg from > time to time to import the refreshed keys or - better - add a new > command to gpg to fetch those retrieved keys from dirmngr. I like this idea -- it sounds similar to parcimonie and its variants: https://gaffer.ptitcanardnoir.org/intrigeri/code/parcimonie/ https://github.com/EtiennePerot/parcimonie.sh Having something like this behavior built into a core GnuPG component seems like a good thing. > Such a queuing mechanism would also come handy when implementing a GNUnet > based key retrieval which would anyway take longer than the direct > access fro a fast keyserver. yep, and a simple configuration option would be an easy way to help people keep their keys up-to-date, instead of asking them to remember to run --refresh at $some_interval. --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 laurent at elanor.org Thu Dec 18 19:41:57 2014 From: laurent at elanor.org (Laurent Blume) Date: Thu, 18 Dec 2014 19:41:57 +0100 Subject: Most GnuPG 2.1.1 tests fail on Solaris 10 In-Reply-To: <87h9wt3x11.fsf@vigenere.g10code.de> References: <5492AC8C.3000804@elanor.org> <87oar143sm.fsf@vigenere.g10code.de> <5492CC6F.5@elanor.org> <87h9wt3x11.fsf@vigenere.g10code.de> Message-ID: <54931FF5.4080400@elanor.org> Le 2014/12/18 14:30 +0100, Werner Koch a ?crit: > Well, if Solaris is the last of the modern Unices to not support a > POSIX shell, I would indeed tag it as wontfix. Oh, it has some POSIX shells, just not as default. So wontfix it is, good! > Alright, this is not Solaris specific. You have this problem on all > Unices because the path length of a Unix domain socket is limit (107 > seems to be a common value). > > We hafe this socket redirection feature but the API for this also uses > the sun_path field of the sockaddr_un structure. Thus we have the same > limitations. But that would also require manual configuration. > > Is it really worth to do that or should we better document that > limitation? > Some more feedback would help, since the gpg-agent error was hidden at that point. Like: ?WARNING: the total path length of the gpg-agent socket is longer than 107, that may prevent it from starting?. For regular use, I guess it's fine, but I'm still looking for a practical solution for the successful run of ?gmake check?. Just the basic name takes 38 characters: ? /gnupg-2.1.1/tests/openpgp/.gpg-agent ?. The way the packaging buildfarm I'm using works, I'll have trouble to get below 107. Would it be possible to eg use a directory in /tmp? Laurent From wk at gnupg.org Thu Dec 18 21:35:53 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 18 Dec 2014 21:35:53 +0100 Subject: Most GnuPG 2.1.1 tests fail on Solaris 10 In-Reply-To: <54931FF5.4080400@elanor.org> (Laurent Blume's message of "Thu, 18 Dec 2014 19:41:57 +0100") References: <5492AC8C.3000804@elanor.org> <87oar143sm.fsf@vigenere.g10code.de> <5492CC6F.5@elanor.org> <87h9wt3x11.fsf@vigenere.g10code.de> <54931FF5.4080400@elanor.org> Message-ID: <87tx0s3dcm.fsf@vigenere.g10code.de> On Thu, 18 Dec 2014 19:41, laurent at elanor.org said: > Like: ?WARNING: the total path length of the gpg-agent socket is > longer than 107, that may prevent it from starting?. Frankly, I have not seen that error message before you reported it. Yes, this case should have a better warning. > Would it be possible to eg use a directory in /tmp? Switching just for running the tests to /tmp/somewhere could be done with some effort. However, there is an easeier way: mkdir /tmp/$USER/gnupg-build cd /tmp/$USER/gnupg-build $HOME/src/gnupg-2.1.1/configure make This does a VPATH (out-of-source-tree) build in /tmp/$USER/gnupg-build and thus the socket name should fit. Actually I am always using VPATH builds because that allows to build for different platforms and versions from the same source directory. My usual directory layout is: ~/s/gnupg/ ~/s/libgcrypt/ ~/b/gnupg ~/b-w32/gnupg ~/b/libgcrypt ~/b-w32/libgcrypt ~/b/gnupg-2.0 ~/b/gnupg-1.4 The last two are used to build the other branches (after the corresponding git checkout in s/gnupg). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From laurent at elanor.org Thu Dec 18 22:13:11 2014 From: laurent at elanor.org (Laurent Blume) Date: Thu, 18 Dec 2014 22:13:11 +0100 Subject: Most GnuPG 2.1.1 tests fail on Solaris 10 In-Reply-To: <87tx0s3dcm.fsf@vigenere.g10code.de> References: <5492AC8C.3000804@elanor.org> <87oar143sm.fsf@vigenere.g10code.de> <5492CC6F.5@elanor.org> <87h9wt3x11.fsf@vigenere.g10code.de> <54931FF5.4080400@elanor.org> <87tx0s3dcm.fsf@vigenere.g10code.de> Message-ID: <54934367.6060809@elanor.org> Le 2014/12/18 21:35 +0100, Werner Koch a ?crit: > Switching just for running the tests to /tmp/somewhere could be done > with some effort. However, there is an easeier way: > > mkdir /tmp/$USER/gnupg-build > cd /tmp/$USER/gnupg-build > $HOME/src/gnupg-2.1.1/configure > make > > This does a VPATH (out-of-source-tree) build in /tmp/$USER/gnupg-build > and thus the socket name should fit. > Sadly, I can't control that. The building & packaging process is mostly automated, witha rather strict directory architecture.I can't reduce enough the length of the path. I've tinkered with the tests a little to use /tmp, got the agent to start, more tests pass, but still a lot of failures, and one of the checks hangs. I will have to look more at them. Laurent From aheinecke at intevation.de Fri Dec 19 18:20:45 2014 From: aheinecke at intevation.de (Andre Heinecke) Date: Fri, 19 Dec 2014 18:20:45 +0100 Subject: System wide dirmngr configuration with Gnupg 2.1 Message-ID: <7757034.xtvict5H27@esus> Hi, we (at intevation) centrally configure the trusted certificates / ldap servers dirmngr should use. Our Administrators verify and decide which certificates users can trust. Now that dirmngr has moved in into gnupg and is no longer supposed to be a system demon I'm wondering how we can do this on our debian system. Ideally in a way that would also work for others (have it configurable instead of just hacking it.) My current Idea would be to have an XSession startup script that launches dirmngr on session startup similar to the old gpg-agent xsession script. The downside of that idea is that this would not work for an update on a live system with users, that it depends on an x session and that it might come out of sync if the initial process is somehow replaced by another autostarted dirmngr. Imho it should be possible to configure dirmngr system wide to use a system- wide configuration. Maybe something like If /etc/gnupg2/dirmngr.conf exists and !opt.homedir: opt.homedir = /etc/gnupg2 In dirmngr would be acceptable? Or am I missing some mechanism that currently allows to use system-wide configuration with dirmngr even when it is autostarted from gpg-agent? Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From dkg at fifthhorseman.net Fri Dec 19 22:32:10 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 19 Dec 2014 16:32:10 -0500 Subject: common/t-dns-cert takes a very long time when DNS resolver doesn't answer on TCP Message-ID: <87a92js4v9.fsf@alice.fifthhorseman.net> Testing with gnupg 2.1.1 from git: common/t-dns-cert takes a very long time to complete, and it appears to be hanging for a few minutes when trying to connect to my local DNS resolver with a TCP connection, after getting a UDP response from the local resolver. the only output is: CERT lookup on 'simon.josefsson.org' i'm not using adns, fwiw. (should i be? is adns a recommended configuration choice for gnupg?) Is anyone else seeing this delay in common/t-dns-cert? --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 Dec 19 23:12:05 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 19 Dec 2014 17:12:05 -0500 Subject: [PATCH] gpgkey2ssh: clean up varargs Message-ID: <1419027125-20684-1-git-send-email-dkg@fifthhorseman.net> * tools/gpgkey2ssh.c (key_to_blob) : ensure that va_end is called. -- stdarg(3) says: Each invocation of va_start() must be matched by a corresponding invocation of va_end() in the same function. Observed by Joshua Rogers Debian-Bug-Id: 773415 --- tools/gpgkey2ssh.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/gpgkey2ssh.c b/tools/gpgkey2ssh.c index 903fb5b..d22c5ac 100644 --- a/tools/gpgkey2ssh.c +++ b/tools/gpgkey2ssh.c @@ -224,6 +224,8 @@ key_to_blob (unsigned char **blob, size_t *blob_n, const char *identifier, ...) assert (ret == 1); } + va_end (ap); + blob_new_n = ftell (stream); rewind (stream); -- 2.1.3 From dkg at fifthhorseman.net Fri Dec 19 23:12:37 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 19 Dec 2014 17:12:37 -0500 Subject: [PATCH] avoid double-close in unusual dotlock situations Message-ID: <1419027157-20759-1-git-send-email-dkg@fifthhorseman.net> * common/dotlock.c: (dotlock_create_unix) avoid double-close() in unusual situations. -- close(2) says: close() should not be retried after an EINTR since this may cause a reused descriptor from another thread to be closed. Before this patch was applied, if close(fd) failed with EINTR, it would be closed again in the write_failed: block. It could also have been closed a second time in the case that (use_hardlinks_p (h->tname)) evaluated to something other than 0 or 1. This patch avoids both of those scenarios. Note that close() could still be called twice on the same file descriptor if the first close(fd) fails but errno is not EINTR. I'm not sure the right thing to do in that scenario. An alternate resolution could be to unequivocally set fd to -1 after the first failed close(fd), avoiding the errno == EINTR test. Debian-Bug-Id: 773423 --- common/dotlock.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/common/dotlock.c b/common/dotlock.c index c5520db..a9963d1 100644 --- a/common/dotlock.c +++ b/common/dotlock.c @@ -680,7 +680,12 @@ dotlock_create_unix (dotlock_t h, const char *file_to_lock) if ( write (fd, "\n", 1 ) != 1 ) goto write_failed; if ( close (fd) ) - goto write_failed; + { + if ( errno == EINTR ) + fd = -1; + goto write_failed; + } + fd = -1; /* Check whether we support hard links. */ switch (use_hardlinks_p (h->tname)) @@ -718,7 +723,8 @@ dotlock_create_unix (dotlock_t h, const char *file_to_lock) all_lockfiles = h->next; UNLOCK_all_lockfiles (); my_error_2 (_("error writing to '%s': %s\n"), h->tname, strerror (errno)); - close (fd); + if ( fd != -1 ) + close (fd); unlink (h->tname); jnlib_free (h->tname); jnlib_free (h); -- 2.1.3 From dkg at fifthhorseman.net Fri Dec 19 23:35:14 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 19 Dec 2014 17:35:14 -0500 Subject: tests/pkits failing on master (when building from git) In-Reply-To: <5436FB65.2000306@fifthhorseman.net> References: <5436FB65.2000306@fifthhorseman.net> Message-ID: <878ui3s1y5.fsf@alice.fifthhorseman.net> On Thu 2014-10-09 17:17:25 -0400, Daniel Kahn Gillmor wrote: > Building from the current origin/master > (2ca90f78cee91c43b8d538d1cb92728f8e1452d5) it appears that tests in > /tests/pkits are failing. > > They also take a really long time to fail. for example, the > validate-all-certs test take several seconds per certificate when doing: > > ../../sm/gpgsm -q --import --with-validation --disable-crl-checks > > > I'm attaching the logs from three tests that failed: > > tests/pkits/import-all-certs.log > tests/pkits/validate-all-certs.log > tests/pkits/signature-verification.log I'm still seeing long failures in all three of these when running "make check" off of the current master, from git 76140141699b545f7a988bf5fc101063917e8ce3. I'm trying this on a debian testing/unstable system. The build process i'm using is just the traditional: ./configure make make check I can build and "make check" from the released 2.1.1 tarball without a problem, though, probably because it skips these tests: make[3]: Entering directory '/tmp/cdtemp.j754Mx/gnupg-2.1.1/tests/pkits' Note: PKITS_data.tar.bz2 is not installed All tests will be skipped (this is not an error) SKIP: import-all-certs SKIP: validate-all-certs SKIP: signature-verification SKIP: validity-periods SKIP: verifying-name-chaining SKIP: basic-certificate-revocation SKIP: verifying-paths-self-issued SKIP: verifying-basic-constraints SKIP: key-usage SKIP: certificate-policies SKIP: require-explicit-policy SKIP: policy-mappings SKIP: inhibit-policy-mapping SKIP: inhibit-any-policy SKIP: name-constraints SKIP: distribution-points SKIP: delta-crls SKIP: private-certificate-extensions ======================= All 0 tests passed (18 tests were not run) ======================= Should they also be skipped when running "make check" from git? or do they need to be cleaned up/fixed somehow? Or is there something wrong with my environment --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 Dec 19 23:53:36 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 19 Dec 2014 17:53:36 -0500 Subject: [PATCH] avoid future chance of using uninitialized memory Message-ID: <1419029616-21558-1-git-send-email-dkg@fifthhorseman.net> * common/iobuf.c: (iobuf_open): initialize len -- In iobuf_open, IOBUFCTRL_DESC and IOBUFCTRL_INIT commands are invoked (via file_filter()) on fcx, passing in a pointer to an uninitialized len. With these two commands, file_filter doesn't actually do anything with the value of len, so there's no actual risk of use of uninitialized memory in the code as it stands. However, some static analysis tools might flag this situation with a warning, and initializing the value doesn't hurt anything, so i think this trivial cleanup is warranted. Debian-Bug-Id: 773469 --- common/iobuf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/iobuf.c b/common/iobuf.c index 3c68ce5..badbf78 100644 --- a/common/iobuf.c +++ b/common/iobuf.c @@ -1301,7 +1301,7 @@ iobuf_open (const char *fname) iobuf_t a; gnupg_fd_t fp; file_filter_ctx_t *fcx; - size_t len; + size_t len = 0; int print_only = 0; int fd; -- 2.1.3 From dkg at fifthhorseman.net Sat Dec 20 00:07:55 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 19 Dec 2014 18:07:55 -0500 Subject: [PATCH] avoid double-free on error condition in scd Message-ID: <1419030475-21790-1-git-send-email-dkg@fifthhorseman.net> * scd/command.c: (cmd_readkey) avoid double-free of cert -- When ksba_cert_new() fails, cert will be double-freed. Debian-Bug-Id: 773471 --- scd/command.c | 1 + 1 file changed, 1 insertion(+) diff --git a/scd/command.c b/scd/command.c index dd4191f..5fa8c5d 100644 --- a/scd/command.c +++ b/scd/command.c @@ -806,6 +806,7 @@ cmd_readkey (assuan_context_t ctx, char *line) if (rc) { xfree (cert); + cert = NULL; goto leave; } rc = ksba_cert_init_from_mem (kc, cert, ncert); -- 2.1.3 From dkg at fifthhorseman.net Sat Dec 20 00:53:34 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 19 Dec 2014 18:53:34 -0500 Subject: [PATCH] avoid double-free on iconv failure Message-ID: <1419033214-22840-1-git-send-email-dkg@fifthhorseman.net> * sm/minip12.c: (p12_build) if jnlib_iconv_open fails, avoid double-free of pwbuf. -- Observed by Joshua Rogers , who proposed a slightly different fix. Debian-Bug-Id: 773472 --- sm/minip12.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sm/minip12.c b/sm/minip12.c index 01b91b7..e269479 100644 --- a/sm/minip12.c +++ b/sm/minip12.c @@ -2422,6 +2422,7 @@ p12_build (gcry_mpi_t *kparms, const void *cert, size_t certlen, " requested charset '%s': %s\n", charset, strerror (errno)); gcry_free (pwbuf); + pwbuf = NULL; goto failure; } -- 2.1.3 From dkg at fifthhorseman.net Sat Dec 20 17:03:48 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 20 Dec 2014 11:03:48 -0500 Subject: [Pkg-gnupg-maint] Bug#773473: [PATCH] * sm/gpgsm.c: (parse_keyserver_line) return false on 'fail'. In-Reply-To: <1419065118-23776-1-git-send-email-git@internot.info> References: <1419065118-23776-1-git-send-email-git@internot.info> Message-ID: <54959DE4.2060203@fifthhorseman.net> Hi Joshua-- On 12/20/2014 03:45 AM, Joshua Rogers wrote: > -- > > If something in the keyserver_line failed, parse_keyserver_line would free 'server', but then return it afterwards, leading to a use-after-free. > > sm/gpgsm.c, in the function main() correctly checks whether the return of parse_keyserver_line is false. > --- > sm/gpgsm.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/sm/gpgsm.c b/sm/gpgsm.c > index 3398d17..75c0b4d 100644 > --- a/sm/gpgsm.c > +++ b/sm/gpgsm.c > @@ -862,6 +862,7 @@ parse_keyserver_line (char *line, > { > log_info (_("%s:%u: skipping this line\n"), filename, lineno); > keyserver_list_free (server); > + return 0; > } > > return server; Since the return value of parse_keyserver_line is a struct keyserver_spec *, it's probably cleaner to represent it as NULL, instead of 0. This is functionally no different, of course, but it makes it clearer what's going on. (alternately, you could just set server = NULL; and let the final line of the function return it) --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 git at internot.info Sat Dec 20 18:35:27 2014 From: git at internot.info (Joshua Rogers) Date: Sun, 21 Dec 2014 04:35:27 +1100 Subject: [PATCH] * dirmngr/ldapserver.c (ldapserver_parse_one) return NULL on 'fail'. Message-ID: <1419096927-31753-1-git-send-email-git@internot.info> -- If something inside the ldapserver_parse_one function failed, 'server' would be freed, then returned, leading to a use-after-free. This code is likely copied from sm/gpgsm.c, which was also susceptible to this bug. --- dirmngr/ldapserver.c | 1 + 1 file changed, 1 insertion(+) diff --git a/dirmngr/ldapserver.c b/dirmngr/ldapserver.c index 0752d95..318d3b0 100644 --- a/dirmngr/ldapserver.c +++ b/dirmngr/ldapserver.c @@ -125,6 +125,7 @@ ldapserver_parse_one (char *line, { log_info (_("%s:%u: skipping this line\n"), filename, lineno); ldapserver_list_free (server); + server = NULL; } return server; -- 1.9.1 From git at internot.info Sun Dec 21 19:21:28 2014 From: git at internot.info (Joshua Rogers) Date: Mon, 22 Dec 2014 05:21:28 +1100 Subject: [PATCH 1/4] * Remove un-needed check. If 'url' were not to be true, http_parse_uri(parse_uri(do_parse_uri))) would fail, leaving 'err' false. Message-ID: <1419186091-26271-1-git-send-email-git@internot.info> --- dirmngr/crlfetch.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dirmngr/crlfetch.c b/dirmngr/crlfetch.c index 2471ca2..29785d2 100644 --- a/dirmngr/crlfetch.c +++ b/dirmngr/crlfetch.c @@ -166,7 +166,7 @@ crl_fetch (ctrl_t ctrl, const char *url, ksba_reader_t *reader) once_more: err = http_parse_uri (&uri, url, 0); http_release_parsed_uri (uri); - if (err && url && !strncmp (url, "https:", 6)) + if (err && !strncmp (url, "https:", 6)) { /* Our HTTP code does not support TLS, thus we can't use this scheme and it is frankly not useful for CRL retrieval anyway. -- 1.9.1 From git at internot.info Sun Dec 21 19:21:30 2014 From: git at internot.info (Joshua Rogers) Date: Mon, 22 Dec 2014 05:21:30 +1100 Subject: [PATCH 3/4] * Free "list"'s in dirmnger/server.c to avoid memory leak. In-Reply-To: <1419186091-26271-1-git-send-email-git@internot.info> References: <1419186091-26271-1-git-send-email-git@internot.info> Message-ID: <1419186091-26271-3-git-send-email-git@internot.info> In two instances, 'list' was never freed in server.c --- dirmngr/server.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/dirmngr/server.c b/dirmngr/server.c index 58e4b64..ca1be95 100644 --- a/dirmngr/server.c +++ b/dirmngr/server.c @@ -1607,6 +1607,7 @@ cmd_ks_search (assuan_context_t ctx, char *line) } leave: + free_strlist (list); return leave_cmd (ctx, err); } @@ -1666,7 +1667,7 @@ cmd_ks_get (assuan_context_t ctx, char *line) err = ks_action_get (ctrl, list, outfp); es_fclose (outfp); } - + free_strlist (list); leave: return leave_cmd (ctx, err); } -- 1.9.1 From git at internot.info Sun Dec 21 19:21:29 2014 From: git at internot.info (Joshua Rogers) Date: Mon, 22 Dec 2014 05:21:29 +1100 Subject: [PATCH 2/4] * Remove duplicate expression in ks-engine-hkp.c In-Reply-To: <1419186091-26271-1-git-send-email-git@internot.info> References: <1419186091-26271-1-git-send-email-git@internot.info> Message-ID: <1419186091-26271-2-git-send-email-git@internot.info> There was a duplicate expression in ks-engine-hkp.c. --- dirmngr/ks-engine-hkp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dirmngr/ks-engine-hkp.c b/dirmngr/ks-engine-hkp.c index 0e812f6..deb6178 100644 --- a/dirmngr/ks-engine-hkp.c +++ b/dirmngr/ks-engine-hkp.c @@ -674,7 +674,7 @@ ks_hkp_mark_host (ctrl_t ctrl, const char *name, int alive) member in another pool. */ for (idx3=0; idx3 < hosttable_size; idx3++) { - if (hosttable[idx3] && hosttable[idx3] + if (hosttable[idx3] && hosttable[idx3]->pool && idx3 != idx && host_in_pool_p (hosttable[idx3]->pool, n)) -- 1.9.1 From git at internot.info Sun Dec 21 19:21:31 2014 From: git at internot.info (Joshua Rogers) Date: Mon, 22 Dec 2014 05:21:31 +1100 Subject: [PATCH 4/4] * free 'line' after use in yat2m.c In-Reply-To: <1419186091-26271-1-git-send-email-git@internot.info> References: <1419186091-26271-1-git-send-email-git@internot.info> Message-ID: <1419186091-26271-4-git-send-email-git@internot.info> 'line' was not freed upon printing in yat2m.c, leading to memory leaks. --- doc/yat2m.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/yat2m.c b/doc/yat2m.c index 91b551f..bcc29d7 100644 --- a/doc/yat2m.c +++ b/doc/yat2m.c @@ -656,6 +656,8 @@ write_th (FILE *fp) *p++ = 0; fprintf (fp, ".TH %s %s %s \"%s\" \"%s\"\n", name, p, isodatestring (), opt_release, opt_source); + + free (name); return 0; } -- 1.9.1 From git at internot.info Sun Dec 21 19:27:04 2014 From: git at internot.info (Joshua Rogers) Date: Mon, 22 Dec 2014 05:27:04 +1100 Subject: [PATCH] * Revision for 7902e496e09a5daac100562007ecac03a9900807 In-Reply-To: <1419186091-26271-3-git-send-email-git@internot.info> References: <1419186091-26271-3-git-send-email-git@internot.info> Message-ID: <1419186424-26384-1-git-send-email-git@internot.info> Previous commit 7902e496e09a5daac100562007ecac03a9900807 allowed for a double-free to occur under certain circumstances. --- dirmngr/server.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/dirmngr/server.c b/dirmngr/server.c index ca1be95..fff722e 100644 --- a/dirmngr/server.c +++ b/dirmngr/server.c @@ -1605,9 +1605,8 @@ cmd_ks_search (assuan_context_t ctx, char *line) err = ks_action_search (ctrl, list, outfp); es_fclose (outfp); } - + free_strlist(list); leave: - free_strlist (list); return leave_cmd (ctx, err); } -- 1.9.1 From gniibe at fsij.org Mon Dec 22 01:50:13 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 22 Dec 2014 09:50:13 +0900 Subject: scd: ECDH Support In-Reply-To: <5490ECEB.30106@fsij.org> References: <54813D71.1010507@fsij.org> <87tx1asfnb.fsf@vigenere.g10code.de> <548171DF.8030200@fsij.org> <5486A47C.2090609@fsij.org> <5490ECEB.30106@fsij.org> Message-ID: <54976AC5.2040005@fsij.org> On 12/09/2014 04:27 PM, NIIBE Yutaka wrote: > Here are changes to support ECDH by scdaemon. Since there is no conflict and no build issue, I pushed the changes today. If any problem, please let me know. That's done, I have a concern about in this specific gpg-agent protocol of ECDH, Currently, in the function get_it in g10/pubkey-enc.c, gpg frontend asks gpg-agent to decode. The format is: (enc-val(ecdh(s%m)(e%m))) Here, "s" is "secret" and "e" is ephemeral public key (let's call it Qe). Then, gpg-agent computes shared secret by [ds]Qe (ds: static private key) and replies back to gpg frontend. And it's gpg frontend to computes secret key using "secret" and shared secret by AESWrap function. It's not needed to send "secret" to gpg-agent. I wonder if it's good to send this data to gpg-agent. Well, in the change of agent/divert-scd.c, it supports both formats of (enc-val(ecdh(s%m)(e%m))) and (enc-val(ecdh(e%m))), just in case gpg frontend will be changed. -- From wk at gnupg.org Mon Dec 22 12:19:39 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 22 Dec 2014 12:19:39 +0100 Subject: [PATCH] * dirmngr/ldapserver.c (ldapserver_parse_one) return NULL on 'fail'. In-Reply-To: <1419096927-31753-1-git-send-email-git@internot.info> (Joshua Rogers's message of "Sun, 21 Dec 2014 04:35:27 +1100") References: <1419096927-31753-1-git-send-email-git@internot.info> Message-ID: <87ioh4ue2c.fsf@vigenere.g10code.de> On Sat, 20 Dec 2014 18:35, git at internot.info said: > If something inside the ldapserver_parse_one function failed, 'server' would be freed, then returned, leading to a use-after-free. > > This code is likely copied from sm/gpgsm.c, which was also susceptible to this bug. Ooops. Both fixed will push that soon. Thanks. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From git at internot.info Mon Dec 22 12:20:21 2014 From: git at internot.info (Joshua Rogers) Date: Mon, 22 Dec 2014 22:20:21 +1100 Subject: DCO submit for git@internot.info Message-ID: <5497FE75.7010503@internot.info> GnuPG Developer's Certificate of Origin. Version 1.0 ===================================================== By making a contribution to the GnuPG project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the free software license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate free software license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same free software license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the free software license(s) involved. Signed-off-by: git at internot.info -- -- Joshua Rogers -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 884 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Mon Dec 22 12:22:07 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 22 Dec 2014 12:22:07 +0100 Subject: [PATCH 1/4] * Remove un-needed check. If 'url' were not to be true, http_parse_uri(parse_uri(do_parse_uri))) would fail, leaving 'err' false. In-Reply-To: <1419186091-26271-1-git-send-email-git@internot.info> (Joshua Rogers's message of "Mon, 22 Dec 2014 05:21:28 +1100") References: <1419186091-26271-1-git-send-email-git@internot.info> Message-ID: <87egrsudy8.fsf@vigenere.g10code.de> On Sun, 21 Dec 2014 19:21, git at internot.info said: > - if (err && url && !strncmp (url, "https:", 6)) > + if (err && !strncmp (url, "https:", 6)) Well, URL is a fucntion argument and may be NULL. However, the later http_open_document would segv on NULL for URL thus the check above is not sufficient. For robustness I'll add a check for URL not beein NULL. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Dec 22 12:44:40 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 22 Dec 2014 12:44:40 +0100 Subject: [PATCH 4/4] * free 'line' after use in yat2m.c In-Reply-To: <1419186091-26271-4-git-send-email-git@internot.info> (Joshua Rogers's message of "Mon, 22 Dec 2014 05:21:31 +1100") References: <1419186091-26271-1-git-send-email-git@internot.info> <1419186091-26271-4-git-send-email-git@internot.info> Message-ID: <87a92fvrh3.fsf@vigenere.g10code.de> On Sun, 21 Dec 2014 19:21, git at internot.info said: > 'line' was not freed upon printing in yat2m.c, leading to memory leaks. Thanks. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Dec 22 12:45:09 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 22 Dec 2014 12:45:09 +0100 Subject: [PATCH] * Revision for 7902e496e09a5daac100562007ecac03a9900807 In-Reply-To: <1419186424-26384-1-git-send-email-git@internot.info> (Joshua Rogers's message of "Mon, 22 Dec 2014 05:27:04 +1100") References: <1419186091-26271-3-git-send-email-git@internot.info> <1419186424-26384-1-git-send-email-git@internot.info> Message-ID: <8761d3vrga.fsf@vigenere.g10code.de> On Sun, 21 Dec 2014 19:27, git at internot.info said: > Previous commit 7902e496e09a5daac100562007ecac03a9900807 allowed for a double-free to occur under certain circumstances. Also for cmd_ks-get ;-). Thanks. all pushed. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Dec 22 12:49:30 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 22 Dec 2014 12:49:30 +0100 Subject: [PATCH] gpgkey2ssh: clean up varargs In-Reply-To: <1419027125-20684-1-git-send-email-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 19 Dec 2014 17:12:05 -0500") References: <1419027125-20684-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <87vbl3ucol.fsf@vigenere.g10code.de> On Fri, 19 Dec 2014 23:12, dkg at fifthhorseman.net said: > * tools/gpgkey2ssh.c (key_to_blob) : ensure that va_end is called. Ah, this strange tool ;-). Thanks. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Dec 22 13:05:25 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 22 Dec 2014 13:05:25 +0100 Subject: [PATCH] avoid double-close in unusual dotlock situations In-Reply-To: <1419027157-20759-1-git-send-email-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 19 Dec 2014 17:12:37 -0500") References: <1419027157-20759-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <87oaqvuby2.fsf@vigenere.g10code.de> On Fri, 19 Dec 2014 23:12, dkg at fifthhorseman.net said: > close() should not be retried after an EINTR since this may > cause a reused descriptor from another thread to be closed. Actually that is a pretty unusal behaviour for an interrupted system call. But close is special anyway. I was not aware of that and Jim didn't mentioned that in https://www.gnu.org/ghm/2011/paris/slides/jim-meyering-goodbye-world.pdf but okay, that was just about stdio. Anyway, fix pushed and I will also backport it to the other branches. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Dec 22 13:12:36 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 22 Dec 2014 13:12:36 +0100 Subject: tests/pkits failing on master (when building from git) In-Reply-To: <878ui3s1y5.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 19 Dec 2014 17:35:14 -0500") References: <5436FB65.2000306@fifthhorseman.net> <878ui3s1y5.fsf@alice.fifthhorseman.net> Message-ID: <87k31jubm3.fsf@vigenere.g10code.de> On Fri, 19 Dec 2014 23:35, dkg at fifthhorseman.net said: > I'm still seeing long failures in all three of these when running "make > check" off of the current master, from git > 76140141699b545f7a988bf5fc101063917e8ce3. That test suite is pretty fragile and was never completed. Resolving the problems might take some time. > Should they also be skipped when running "make check" from git? or do > they need to be cleaned up/fixed somehow? Or is there something wrong > with my environment On my GIT build they are skipped. Are you using a newer automake? I guess that will be the problem. My plan was to switch to automake 1.14 with the release of Jessie but I may reconsider that and do it in January. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Dec 22 14:01:27 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 22 Dec 2014 14:01:27 +0100 Subject: [Pkg-gnupg-maint] Bug#773473: [PATCH] * sm/gpgsm.c: (parse_keyserver_line) return false on 'fail'. In-Reply-To: <54959DE4.2060203@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Sat, 20 Dec 2014 11:03:48 -0500") References: <1419065118-23776-1-git-send-email-git@internot.info> <54959DE4.2060203@fifthhorseman.net> Message-ID: <878uhzu9co.fsf@vigenere.g10code.de> On Sat, 20 Dec 2014 17:03, dkg at fifthhorseman.net said: > (alternately, you could just set > > server = NULL; > > and let the final line of the function return it) That is what I did with abd5f67. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Mon Dec 22 14:11:00 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 22 Dec 2014 22:11:00 +0900 Subject: ECC key format in gpg-agent Message-ID: <54981864.7050005@fsij.org> Hello, This is a note about current situation of ECC support in GnuPG 2.1.x (git master). I don't have patches yet, but just describing issues. During the development, in the past, we had key format in SEXP of: (ecdsa(p%m)(a%m)(b%m)(g%m)(n%m)(q%m)) (ecdh(p%m)(a%m)(b%m)(g%m)(n%m)(q%m)) but currently, it's like: (ecc(curve%s)(q%m)) (ecc(flags eddsa)(curve%s)(q%b)) (ecc(flags param)(p%m)(a%m)(b%m)(g%m)(n%m)(h%m)(q%m)) That is, curves are usually specified by its name. It can be specified by its numerical parameters, but in that case, it should have (flags param) and we now have another parameter h (as cofactor). It can have (flags eddsa) for EdDSA keys. Now, the function agent_public_key_from_file in agent/findkey.c doesn't worked well with curve name, because the function key_parms_from_sexp in agent/findkey.c only supports old formats. The constant protect_info in agent/protect.c is for old formats. Thus, the functions agent_protect and agent_unprotect doesn't work well with curve name (and optional flags). -- From wk at gnupg.org Mon Dec 22 14:32:40 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 22 Dec 2014 14:32:40 +0100 Subject: ECC key format in gpg-agent In-Reply-To: <54981864.7050005@fsij.org> (NIIBE Yutaka's message of "Mon, 22 Dec 2014 22:11:00 +0900") References: <54981864.7050005@fsij.org> Message-ID: <87wq5jstc7.fsf@vigenere.g10code.de> On Mon, 22 Dec 2014 14:11, gniibe at fsij.org said: > This is a note about current situation of ECC support in GnuPG 2.1.x > (git master). I don't have patches yet, but just describing issues. Thanks for raising this problem. > Thus, the functions agent_protect and agent_unprotect doesn't work > well with curve name (and optional flags). Indeed there is just an ad-hoc ecc_hack we use here. Are you going to work on this? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Mon Dec 22 15:39:54 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 22 Dec 2014 23:39:54 +0900 Subject: ECC key format in gpg-agent In-Reply-To: <87wq5jstc7.fsf@vigenere.g10code.de> References: <54981864.7050005@fsij.org> <87wq5jstc7.fsf@vigenere.g10code.de> Message-ID: <54982D3A.1040307@fsij.org> On 12/22/2014 10:32 PM, Werner Koch wrote: > Are you going to work on this? Yes, I'm going to work. I should have explicitly claimed. I won't try to remove old format support aggressively now, but I don't think I will be able to keep old format support well (since I don't have example keys in old format). Some months later, I will remove old format support cleanly, and I will write conversion tool when/if people will have such requests. That's my plan. -- From wk at gnupg.org Mon Dec 22 16:43:15 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 22 Dec 2014 16:43:15 +0100 Subject: common/t-dns-cert takes a very long time when DNS resolver doesn't answer on TCP In-Reply-To: <87a92js4v9.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 19 Dec 2014 16:32:10 -0500") References: <87a92js4v9.fsf@alice.fifthhorseman.net> Message-ID: <878uhzsnak.fsf@vigenere.g10code.de> On Fri, 19 Dec 2014 22:32, dkg at fifthhorseman.net said: > common/t-dns-cert takes a very long time to complete, and it appears to > be hanging for a few minutes when trying to connect to my local DNS I have not expereinced that yet. > i'm not using adns, fwiw. (should i be? is adns a recommended configuration > choice for gnupg?) I don't use if for Unix either. It is only required for Windows. BTW, beware of a possible version conflict now that Ian has taken up ADNS development again after an eternity. I have always used my own fork "1.4-g10-N" which has been modified to use autoconf/libtool and comes with v6 for some time. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From infinity0 at pwned.gg Tue Dec 23 04:14:30 2014 From: infinity0 at pwned.gg (Ximin Luo) Date: Tue, 23 Dec 2014 04:14:30 +0100 Subject: Weird behaviours in GPG 2.1 with validity In-Reply-To: <5492C1C0.1030307@pwned.gg> References: <548C5743.5060208@pwned.gg> <548DA2E5.9070403@pwned.gg> <5492C1C0.1030307@pwned.gg> Message-ID: <5498DE16.3090006@pwned.gg> I've managed to trim this down to a minimal test case: https://bugs.g10code.com/gnupg/issue1794 Would be good if others could confirm and/or comment. Pretty annoying to keep getting "KEY IS NOT VALID" warnings for my *own* key... X On 18/12/14 13:00, Ximin Luo wrote: > Ping! Did anyone else look into this yet? > > On 14/12/14 15:47, Ximin Luo wrote: >> To clarify, the below was observed in GPG 2.1. >> >> On 13/12/14 16:12, Ximin Luo wrote: >>> (new,mine) If I import my public key [1] into an empty homedir and set ownertrust to ultimate, the validity (on all UIDs) is also set to ultimate. >>> >>> (old,mine) If I do the same thing with my pre-existing homedir, the validity (on all UIDs) is set to "undef" for some reason. >>> >>> (old,other) If I do the same thing with my pre-existing homedir, but with (e.g.) dkg's key [2], some UIDs are "undef" and other UIDs are "ultimate". >>> >>> (new,other) If I do the same thing with dkg's key in an empty homedir, the validity is set to ultimate. >>> >>> The validity also remains unchanged as "undef", even if I import a masterless secret key. (But GPG 1.4 seems to set the validity to "ultimate", in the same situation.) >>> >>> All of these behaviours are pretty weird. I couldn't find a good explanation of them in the docs. >>> >>> At the end of the day, I just want GPG to recognise my own key (with secret subkeys available, secret master key not available) as "ultimate" validity. How do I do this? >>> >>> X >>> >>> [1] A405 E58A B372 5B39 6ED1 B85C 1318 EFAC 5FBB DBCE >>> [2] 0EE5 BE97 9282 D80B 9F75 40F1 CCD2 ED94 D217 39E9 >>> >>> > -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From wavexx at thregr.org Tue Dec 23 13:13:24 2014 From: wavexx at thregr.org (Yuri D'Elia) Date: Tue, 23 Dec 2014 13:13:24 +0100 Subject: [PATCH] pinentry-gtk-2 Message-ID: Hi everyone. I've submitted this patch over two years ago: https://bugs.g10code.com/gnupg/issue1453 It handles ESC (defaulting to cancel) while entering a passphrase. Any chance this gets looked at? Note that this behavior was already present in GTK1, and it works correctly in pinentry-qt. I would expect the same in the GTK2 port. From wavexx at thregr.org Tue Dec 23 18:56:58 2014 From: wavexx at thregr.org (Yuri D'Elia) Date: Tue, 23 Dec 2014 18:56:58 +0100 Subject: gpg-agent: Show PID/command line of the requesting process Message-ID: When using gpg-agent in daemon mode it's not always obvious which process is requesting authorization for unlocking a key. The agent should always show the PID/command of the requester. I filed a bug report at Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773716 and I also decided to give it a try in implementing the fix. In the attached patch I have the first crude proposal: - A new struct is introduced in the main context, adding the PID and the command line of the requesting process. - As soon as the connection is established, the fields are populated. Of note here, is that libassuan does have PID/gid/uid information already (Using various forms of SO_PEERCRED/getpeercred/etc), but it's established only later in the individual handlers once an assuan context is created. Since I'm aiming to make at least the PID *mandatory*, I think it's useless to perform this task for each handler. It's also true that copying the entire #ifdef block from libassuan is bad as well... The command line is extracted from /proc/[pid]/cmdline. Does somebody know if BSDs have something equivalent? If not, inserting the path of the executable associated with the PID would be the way to go. - When constructing the description for the ssh daemon, the PID/process is also shown in the text. - The modifiers %p/%P are introduced to insert the PID and command line into the prompt. When unlocking a secret key through the normal handler though, the prompt is generated by the calling process. It would make sense to me, similarly as done for SSH, that a minimum description (pid/program/key/operation) must be inserted by the agent itself, and not by the calling process (which could be easily faked). Having a fixed text would be easy (such as: Program [PID] [command] is requesting to unlock the secret key ...). While doing some tests, it seems to me that I don't lose anything by ignoring completely gpg's prompts. Comments? -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Show-process-PID-command-line-of-the-requesting-proc.patch Type: text/x-diff Size: 7865 bytes Desc: not available URL: From git at internot.info Tue Dec 23 21:52:15 2014 From: git at internot.info (Joshua Rogers) Date: Wed, 24 Dec 2014 07:52:15 +1100 Subject: agent: Fix memory leaks in multiple codes Message-ID: <1419367936-25738-1-git-send-email-git@internot.info> * agent/command.c free 'cache_nonce' before return * agent/protect.c free 'newlist' before return -- Signed-off-by: Joshua Rogers --- agent/command.c | 3 +++ agent/protect.c | 3 +++ 2 files changed, 6 insertions(+) diff --git a/agent/command.c b/agent/command.c index da7e508..16f2218 100644 --- a/agent/command.c +++ b/agent/command.c @@ -962,7 +962,10 @@ cmd_genkey (assuan_context_t ctx, char *line) if (!rc) rc = assuan_inquire (ctx, "KEYPARAM", &value, &valuelen, MAXLEN_KEYPARAM); if (rc) + { + xfree (cache_nonce); return rc; + } init_membuf (&outbuf, 512); diff --git a/agent/protect.c b/agent/protect.c index 01e72c2..2874365 100644 --- a/agent/protect.c +++ b/agent/protect.c @@ -750,7 +750,10 @@ merge_lists (const unsigned char *protectedkey, /* copy the cleartext */ s = cleartext; if (*s != '(' && s[1] != '(') + { + xfree (newlist); return gpg_error (GPG_ERR_BUG); /*we already checked this */ + } s += 2; startpos = s; while ( *s == '(' ) -- 1.9.1 From git at internot.info Tue Dec 23 21:52:16 2014 From: git at internot.info (Joshua Rogers) Date: Wed, 24 Dec 2014 07:52:16 +1100 Subject: agent: Further frees in regards to memory leaks In-Reply-To: <1419367936-25738-1-git-send-email-git@internot.info> References: <1419367936-25738-1-git-send-email-git@internot.info> Message-ID: <1419367936-25738-2-git-send-email-git@internot.info> * agent/command.c free 'password_nonce' before return Signed-off-by: Joshua Rogers --- agent/command.c | 1 + 1 file changed, 1 insertion(+) diff --git a/agent/command.c b/agent/command.c index 16f2218..62d1243 100644 --- a/agent/command.c +++ b/agent/command.c @@ -1788,6 +1788,7 @@ cmd_passwd (assuan_context_t ctx, char *line) gcry_sexp_release (s_skey); xfree (shadow_info); xfree (cache_nonce); + xfree (passwd_nonce); return leave_cmd (ctx, err); } -- 1.9.1 From git at internot.info Wed Dec 24 14:19:05 2014 From: git at internot.info (Joshua Rogers) Date: Thu, 25 Dec 2014 00:19:05 +1100 Subject: agent: Further frees in regards to memory leaks In-Reply-To: <1419367936-25738-2-git-send-email-git@internot.info> References: <1419367936-25738-2-git-send-email-git@internot.info> Message-ID: <1419427145-15633-1-git-send-email-git@internot.info> * agent/command.c free 'password_nonce' before return -- Signed-off-by: Joshua Rogers --- agent/command.c | 1 + 1 file changed, 1 insertion(+) diff --git a/agent/command.c b/agent/command.c index 16f2218..62d1243 100644 --- a/agent/command.c +++ b/agent/command.c @@ -1788,6 +1788,7 @@ cmd_passwd (assuan_context_t ctx, char *line) gcry_sexp_release (s_skey); xfree (shadow_info); xfree (cache_nonce); + xfree (passwd_nonce); return leave_cmd (ctx, err); } -- 1.9.1 From git at internot.info Wed Dec 24 14:41:16 2014 From: git at internot.info (Joshua Rogers) Date: Thu, 25 Dec 2014 00:41:16 +1100 Subject: Questionable / Incorrect Code Message-ID: <549AC27C.6050607@internot.info> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi guys, In scd/apdu.c on lines 2340-2344, I think there is incorrect code. Should it be if([..])? It looks like a copy and paste error since the same code from 2340 is at 2345, but the code at 2345 can never be reached, because of the code at 2340.. I probably explained that terribly. I'm very tired. But if you look at line 2340 you'll see what I mean. Thanks, - -- - -- Joshua Rogers -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUmsJ7AAoJEDFNCEijz56XtuYP/iXS4ubrCokT8UfD8PD+VMZ/ FMF5GaboxCIinJM2zq/29B9ETLE0tuggQEFSwbn6ek3ZyyyN+q+4i5LnDhV6xCV5 abzhOrKP2uAXDDz7csjUYSFM+Mw4L5MeldmKjfJCNtZ3mJLO321mKF315a0CzVZs z5LIoCJK48VN0y80ecnAsZaIj1IwN4oIZN0d4oBGpyQyHTH3ZBmWZfqC+kYrZeDz dx/sQu5GmbtkdxcoDm6gBTC8GqlOR/F8FB0xwynLs3hATS8IM22Qx14ftFZp4xsv QhXXum5+jpp+IggaOGrR6K3Hb8gCUGxTXl0YZEtlbsQG9/FME3Vcg2rakihks8js VwRKfjEJEva1Se2xqEyU7pxMjm74d5nDHOcYwxtg3037pLmeSl4sQBQY8QBuF8Y+ fBjQP2raGLN1y56GVR9Fi8uB5caSy1AJcyE/YD98xWTnHWWiTw3Kw5JTUqTtdzuI sFU5vGpHXFKTXbhAWzo5/Pr+7fyJWofsV7lEKDlq6cNY3hgM35vFOiTiMNSc/B0j ajVWF5rGcqKbqUSBYUJvxEGtl6FZWzW+I3rdKGQj0HW5vIfA789c+j1joAW3iGzX vLYmpyeBijI16PHD6rWTSfNYyf7ySXM+hfsExYdLFhLsdUz0tEQCYS9aBANKBHxy pHmNBTqvE/zv18+uPQTA =1kS2 -----END PGP SIGNATURE----- From wk at gnupg.org Wed Dec 24 21:10:02 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 24 Dec 2014 21:10:02 +0100 Subject: Questionable / Incorrect Code In-Reply-To: <549AC27C.6050607@internot.info> (Joshua Rogers's message of "Thu, 25 Dec 2014 00:41:16 +1100") References: <549AC27C.6050607@internot.info> Message-ID: <87oaqsq06d.fsf@vigenere.g10code.de> On Wed, 24 Dec 2014 14:41, git at internot.info said: > I probably explained that terribly. I'm very tired. But if you look at > line 2340 you'll see what I mean. Indeed that looks like a faulty merge. We need to go back and see why it happened. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Dec 24 21:12:00 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 24 Dec 2014 21:12:00 +0100 Subject: agent: Fix memory leaks in multiple codes In-Reply-To: <1419367936-25738-1-git-send-email-git@internot.info> (Joshua Rogers's message of "Wed, 24 Dec 2014 07:52:15 +1100") References: <1419367936-25738-1-git-send-email-git@internot.info> Message-ID: <87k31gq033.fsf@vigenere.g10code.de> On Tue, 23 Dec 2014 21:52, git at internot.info said: > if (*s != '(' && s[1] != '(') > + { > + xfree (newlist); > return gpg_error (GPG_ERR_BUG); /*we already checked this */ > + } That one was intentional. It is more an assert than a real error check and thus there is no cleanup. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From git at internot.info Thu Dec 25 02:07:48 2014 From: git at internot.info (Joshua Rogers) Date: Thu, 25 Dec 2014 12:07:48 +1100 Subject: Questionable / Incorrect Code In-Reply-To: <87oaqsq06d.fsf@vigenere.g10code.de> References: <549AC27C.6050607@internot.info> <87oaqsq06d.fsf@vigenere.g10code.de> Message-ID: <549B6364.2010507@internot.info> On 25/12/14 07:10, Werner Koch wrote: > On Wed, 24 Dec 2014 14:41, git at internot.info said: > >> > I probably explained that terribly. I'm very tired. But if you look at >> > line 2340 you'll see what I mean. > Indeed that looks like a faulty merge. We need to go back and see why > it happened. It was introduced in commit 7a7a59782766a8bde0c3e7156d14bb2b0e4a3951, by Marcus Brinkmann, just for reference. > 26b4a012 (NIIBE Yutaka 2011-11-28 16:16:38 +0900 2337) xfree > (pin_verify); > 26b4a012 (NIIBE Yutaka 2011-11-28 16:16:38 +0900 2338) if (sw || > resultlen < 2) > 7a7a5978 (Marcus Brinkmann 2012-01-03 22:12:37 +0100 2339) return > sw? sw : SW_HOST_INCOMPLETE_CARD_RESPONSE; > 7a7a5978 (Marcus Brinkmann 2012-01-03 22:12:37 +0100 2340) sw = > (result[resultlen-2] << 8) | result[resultlen-1]; > 07f20f31 (NIIBE Yutaka 2011-12-20 13:34:27 +0900 2341) { > 07f20f31 (NIIBE Yutaka 2011-12-20 13:34:27 +0900 2342) > log_error ("control_pcsc failed: %d\n", sw); I see no reason as to why a faluty merge would have caused that, though. It looks like a copy and paste gone stray to me, since the exact same code it below that. It doesn't really matter, though. The commit log is as followed: > commit 7a7a59782766a8bde0c3e7156d14bb2b0e4a3951 > Author: Marcus Brinkmann > Date: Tue Jan 3 22:12:37 2012 +0100 > > Port to npth. > > * configure.ac: Don't check for PTH but for NPTH. > (AH_BOTTOM): Remove PTH_SYSCALL_SOFT. > (have_pth): Rename to ... > (have_npth): ... this. > (USE_GNU_NPTH): Rename to ... > (USE_GNU_PTH): ... this. > * m4/npth.m4: New file. > * agent/Makefile.am, agent/cache.c, agent/call-pinentry.c, > agent/call-scd.c, agent/findkey.c, agent/gpg-agent.c, > agent/trustlist.c, common/Makefile.am, common/estream.c, > common/exechelp-posix.c, common/exechelp-w32.c, > common/exechelp-w32ce.c, common/http.c, common/init.c, > common/sysutils.c, dirmngr/Makefile.am, dirmngr/crlfetch.c, > dirmngr/dirmngr.c, dirmngr/dirmngr_ldap.c, dirmngr/ldap-wrapper-ce.c, > dirmngr/ldap-wrapper.c, dirmngr/ldap.c, g13/Makefile.am, > g13/call-gpg.c, g13/g13.c, g13/runner.c, scd/Makefile.am, > scd/apdu.c, scd/app.c, scd/ccid-driver.c, scd/command.c, > scd/scdaemon.c, tools/Makefile.am: Port to npth. Thanks, -- -- Joshua Rogers -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From gniibe at fsij.org Thu Dec 25 08:21:34 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 25 Dec 2014 16:21:34 +0900 Subject: agent: Fix agent_public_key_from_file (was: ECC key format in gpg-agent) In-Reply-To: <54982D3A.1040307@fsij.org> References: <54981864.7050005@fsij.org> <87wq5jstc7.fsf@vigenere.g10code.de> <54982D3A.1040307@fsij.org> Message-ID: <549BBAFE.8010605@fsij.org> Hello, Here is the part one of ECC key format fixes, fixing agent_public_key_from_file function. agent_public_key_from_file is the function to get public key in S-Expression from private key file. After new ECC support, it may have (curve NAME) or (flags eddsa) fields along with simple fields like: (q%m). Thus, we need to scan private key with this particular possibility in mind. Since mostly same functionality is there in the convert_to_openpgp function in cvt-openpgp.c, I factored out common thing into new extract_private_key function, and change convert_to_openpgp and agent_public_key_from_file using the extract_private_key function. With this patch, KEYTOCARD works fine, and I believe no regression. diff --git a/agent/agent.h b/agent/agent.h index c7c65af..837404d 100644 --- a/agent/agent.h +++ b/agent/agent.h @@ -496,4 +496,11 @@ int agent_card_scd (ctrl_t ctrl, const char *cmdline, int agent_handle_learn (ctrl_t ctrl, int send, void *assuan_context); +/*-- cvt-openpgp.c --*/ +gpg_error_t +extract_private_key (gcry_sexp_t s_key, int req_private_key_data, + const char **r_algoname, int *r_npkey, int *r_nskey, + const char **r_format, gcry_mpi_t *mpi_array, + gcry_sexp_t *r_curve, gcry_sexp_t *r_flags); + #endif /*AGENT_H*/ diff --git a/agent/cvt-openpgp.c b/agent/cvt-openpgp.c index 671dd4c..fc1d1e8 100644 --- a/agent/cvt-openpgp.c +++ b/agent/cvt-openpgp.c @@ -1177,36 +1177,50 @@ apply_protection (gcry_mpi_t *array, int npkey, int nskey, } -/* Convert our key S_KEY into an OpenPGP key transfer format. On - success a canonical encoded S-expression is stored at R_TRANSFERKEY - and its length at R_TRANSFERKEYLEN; this S-expression is also - padded to a multiple of 64 bits. */ +/* + * Examining S_KEY in S-Expression and extract data. + * When REQ_PRIVATE_KEY_DATA == 1, S_KEY's CAR should be 'private-key', + * but it also allows shadowed or protected versions. + * On success, it returns 0, otherwise error number. + * R_ALGONAME is static string which is no need to free by caller. + * R_NPKEY is pointer to number of public key data. + * R_NSKEY is pointer to number of private key data. + * R_ELEMS is static string which is no need to free by caller. + * ARRAY contains public and private key data. + * R_CURVE is pointer to S-Expression of the curve (can be NULL). + * R_FLAGS is pointer to S-Expression of the flags (can be NULL). + */ gpg_error_t -convert_to_openpgp (ctrl_t ctrl, gcry_sexp_t s_key, const char *passphrase, - unsigned char **r_transferkey, size_t *r_transferkeylen) +extract_private_key (gcry_sexp_t s_key, int req_private_key_data, + const char **r_algoname, int *r_npkey, int *r_nskey, + const char **r_elems, gcry_mpi_t *array, + gcry_sexp_t *r_curve, gcry_sexp_t *r_flags) { gpg_error_t err; gcry_sexp_t list, l2; char *name; - const char *algoname; + const char *algoname, *format; int npkey, nskey; - gcry_mpi_t array[10]; gcry_sexp_t curve = NULL; - char protect_iv[16]; - char salt[8]; - unsigned long s2k_count; - int i, j; + gcry_sexp_t flags = NULL; - (void)ctrl; - - *r_transferkey = NULL; - - for (i=0; i < DIM (array); i++) - array[i] = NULL; + if (!req_private_key_data) + { + list = gcry_sexp_find_token (s_key, "shadowed-private-key", 0 ); + if (!list) + list = gcry_sexp_find_token (s_key, "protected-private-key", 0 ); + if (!list) + list = gcry_sexp_find_token (s_key, "private-key", 0 ); + } + else + list = gcry_sexp_find_token (s_key, "private-key", 0); - list = gcry_sexp_find_token (s_key, "private-key", 0); if (!list) - return gpg_error (GPG_ERR_NO_OBJ); /* Does not contain a key object. */ + { + log_error ("invalid private key format\n"); + return gpg_error (GPG_ERR_BAD_SECKEY); + } + l2 = gcry_sexp_cadr (list); gcry_sexp_release (list); list = l2; @@ -1224,66 +1238,81 @@ convert_to_openpgp (ctrl_t ctrl, gcry_sexp_t s_key, const char *passphrase, if (!strcmp (name, "rsa")) { algoname = "rsa"; + format = "ned?p?q?u?"; npkey = 2; nskey = 6; - err = gcry_sexp_extract_param (list, NULL, "nedpqu", + err = gcry_sexp_extract_param (list, NULL, format, array+0, array+1, array+2, array+3, array+4, array+5, NULL); } else if (!strcmp (name, "elg")) { algoname = "elg"; + format = "pgyx?"; npkey = 3; nskey = 4; - err = gcry_sexp_extract_param (list, NULL, "pgyx", + err = gcry_sexp_extract_param (list, NULL, format, array+0, array+1, array+2, array+3, NULL); } else if (!strcmp (name, "dsa")) { algoname = "dsa"; + format = "pqgyx?"; npkey = 4; nskey = 5; - err = gcry_sexp_extract_param (list, NULL, "pqgyx", + err = gcry_sexp_extract_param (list, NULL, format, array+0, array+1, array+2, array+3, array+4, NULL); } else if (!strcmp (name, "ecc")) { - gcry_buffer_t iob; - char iobbuf[32]; - - algoname = "ecc"; /* Decide later by checking the usage. */ + algoname = "ecc"; + format = "/qd?"; npkey = 1; nskey = 2; - iob.data = iobbuf; - iob.size = sizeof iobbuf - 1; - iob.off = 0; - iob.len = 0; - err = gcry_sexp_extract_param (list, NULL, "&'curve'/qd", - &iob, array+0, array+1, NULL); - if (!err) + curve = gcry_sexp_find_token (list, "curve", 0); + flags = gcry_sexp_find_token (list, "flags", 0); + err = gcry_sexp_extract_param (list, NULL, format, + array+0, array+1, NULL); + if (flags) { - assert (iob.len < sizeof iobbuf -1); - iobbuf[iob.len] = 0; - err = gcry_sexp_build (&curve, NULL, "(curve %s)", iobbuf); + gcry_sexp_t param = gcry_sexp_find_token (flags, "param", 0); + if (param) + { + gcry_sexp_release (param); + array[6] = array[0]; + array[7] = array[1]; + err = gcry_sexp_extract_param (list, NULL, "pabgnh?", + array+0, array+1, array+2, array+3, + array+4, array+5, NULL); + if (array[5] == NULL) + { + array[5] = GCRYMPI_CONST_ONE; + npkey += 6; + nskey += 6; + } + format = "pabgnhqd?"; + } } } else if (!strcmp (name, "ecdsa")) { algoname = "ecdsa"; + format = "pabgnqd?"; npkey = 6; nskey = 7; - err = gcry_sexp_extract_param (list, NULL, "pabgnqd", + err = gcry_sexp_extract_param (list, NULL, format, array+0, array+1, array+2, array+3, array+4, array+5, array+6, NULL); } else if (!strcmp (name, "ecdh")) { algoname = "ecdh"; + format = "pabgnqd?"; npkey = 6; nskey= 7; - err = gcry_sexp_extract_param (list, NULL, "pabgnqd", + err = gcry_sexp_extract_param (list, NULL, format, array+0, array+1, array+2, array+3, array+4, array+5, array+6, NULL); } @@ -1292,12 +1321,63 @@ convert_to_openpgp (ctrl_t ctrl, gcry_sexp_t s_key, const char *passphrase, err = gpg_error (GPG_ERR_PUBKEY_ALGO); } xfree (name); - gcry_sexp_release (list); list = NULL; + gcry_sexp_release (list); if (err) { gcry_sexp_release (curve); + gcry_sexp_release (flags); return err; } + else + { + *r_algoname = algoname; + if (r_elems) + { + if (format[0] == '/') /* It is opaque data qualifier, skip it. */ + *r_elems = format+1; + else + *r_elems = format; + } + *r_npkey = npkey; + if (r_nskey) + *r_nskey = nskey; + *r_curve = curve; + *r_flags = flags; + + return 0; + } +} + +/* Convert our key S_KEY into an OpenPGP key transfer format. On + success a canonical encoded S-expression is stored at R_TRANSFERKEY + and its length at R_TRANSFERKEYLEN; this S-expression is also + padded to a multiple of 64 bits. */ +gpg_error_t +convert_to_openpgp (ctrl_t ctrl, gcry_sexp_t s_key, const char *passphrase, + unsigned char **r_transferkey, size_t *r_transferkeylen) +{ + gpg_error_t err; + const char *algoname; + int npkey, nskey; + gcry_mpi_t array[10]; + gcry_sexp_t curve = NULL; + gcry_sexp_t flags = NULL; + char protect_iv[16]; + char salt[8]; + unsigned long s2k_count; + int i, j; + + (void)ctrl; + + *r_transferkey = NULL; + + for (i=0; i < DIM (array); i++) + array[i] = NULL; + + err = extract_private_key (s_key, 1, &algoname, &npkey, &nskey, NULL, + array, &curve, &flags); + if (err) + return err; gcry_create_nonce (protect_iv, sizeof protect_iv); gcry_create_nonce (salt, sizeof salt); @@ -1363,6 +1443,7 @@ convert_to_openpgp (ctrl_t ctrl, gcry_sexp_t s_key, const char *passphrase, for (i=0; i < DIM (array); i++) gcry_mpi_release (array[i]); gcry_sexp_release (curve); + gcry_sexp_release (flags); return err; } diff --git a/agent/findkey.c b/agent/findkey.c index fbe3031..064f7d2 100644 --- a/agent/findkey.c +++ b/agent/findkey.c @@ -978,18 +978,20 @@ agent_public_key_from_file (ctrl_t ctrl, gpg_error_t err; int i, idx; gcry_sexp_t s_skey; - char algoname[6]; - char elems[7]; + const char *algoname, *elems; + int npkey; + gcry_mpi_t array[10]; + gcry_sexp_t curve = NULL; + gcry_sexp_t flags = NULL; gcry_sexp_t uri_sexp, comment_sexp; const char *uri, *comment; size_t uri_length, comment_length; char *format, *p; - void *args[4+2+2+1]; /* Size is max. # of elements + 2 for uri + 2 - for comment + end-of-list. */ + void *args[2+7+2+2+1]; /* Size is 2 + max. # of elements + 2 for uri + 2 + for comment + end-of-list. */ int argidx; - gcry_sexp_t list, l2; + gcry_sexp_t list = NULL; const char *s; - gcry_mpi_t *array; (void)ctrl; @@ -999,55 +1001,17 @@ agent_public_key_from_file (ctrl_t ctrl, if (err) return err; - err = key_parms_from_sexp (s_skey, &list, - algoname, sizeof algoname, - elems, sizeof elems); - if (err) - { - gcry_sexp_release (s_skey); - return err; - } + for (i=0; i < DIM (array); i++) + array[i] = NULL; - /* Allocate an array for the parameters and copy them out of the - secret key. FIXME: We should have a generic copy function. */ - array = xtrycalloc (strlen(elems) + 1, sizeof *array); - if (!array) + err = extract_private_key (s_skey, 0, &algoname, &npkey, NULL, &elems, + array, &curve, &flags); + if (err) { - err = gpg_error_from_syserror (); - gcry_sexp_release (list); gcry_sexp_release (s_skey); return err; } - for (idx=0, s=elems; *s; s++, idx++ ) - { - l2 = gcry_sexp_find_token (list, s, 1); - if (!l2) - { - /* Required parameter not found. */ - for (i=0; i References: <549AC27C.6050607@internot.info> <87oaqsq06d.fsf@vigenere.g10code.de> <549B6364.2010507@internot.info> Message-ID: <549BC26A.7020004@fsij.org> I don't know what was going on exactly at that time, but roughly speaking, I had pinpad related enhancement branch and Marcus had npth related branch. I think that I pushed first, and Marcus had to merge, and introduced this bug unfortunately. In the commit of 07f20f313a0b13e5c93168a8a62ff1cbb94a4514, I added log_error call. I guess that this change of mine confused Marcus, perhaps. Here is the fix. Well, we also can compare the implementation of 2.0 branch to confirm that this is the right thing. OK to commit? diff --git a/scd/apdu.c b/scd/apdu.c index 476723a..4ec6b4d 100644 --- a/scd/apdu.c +++ b/scd/apdu.c @@ -2336,8 +2336,6 @@ pcsc_pinpad_verify (int slot, int class, int ins, int p0, int p1, pin_verify, len, result, &resultlen); xfree (pin_verify); if (sw || resultlen < 2) - return sw? sw : SW_HOST_INCOMPLETE_CARD_RESPONSE; - sw = (result[resultlen-2] << 8) | result[resultlen-1]; { log_error ("control_pcsc failed: %d\n", sw); return sw? sw: SW_HOST_INCOMPLETE_CARD_RESPONSE; -- From bjk at luxsci.net Fri Dec 26 02:23:20 2014 From: bjk at luxsci.net (Ben Kibbey) Date: Thu, 25 Dec 2014 20:23:20 -0500 Subject: [PATCH] Kill the backend process during cancellation. Message-ID: <1419557042-3064224.11646022.fsBQ1NK4w007775@rs146.luxsci.com> * src/engine-gpg.c (struct engine_gpg): Add pid member. (gpg_cancel): Send SIGTERM then SIGKILL if needed. * src/posix-io.c (_gpgme_io_spawn): Obtain the child PID via pipe. * src/wait-global.c (gpgme_wait_ext): Test for cancellation before FD status. -- During gpgme_async_cancel() or gpgme_cancel() we'd normally have to wait for the operation to complete before the cancellation would succeed. This can take a long time especially when doing key generation. So after calling the cancellation functions terminate the backend process to let gpgme_wait() return quicker. Since gpgme uses the double-fork method to prevent zombie processes, the child PID of the backend process needs to be obtained in the parent process via a pipe. This has only been implemented in the gpg backend so far. --- src/engine-gpg.c | 10 ++++++++++ src/posix-io.c | 16 +++++++++++++++- src/wait-global.c | 20 ++++++++++++++++---- 3 files changed, 41 insertions(+), 5 deletions(-) diff --git a/src/engine-gpg.c b/src/engine-gpg.c index 30c3bfb..ec4f491 100644 --- a/src/engine-gpg.c +++ b/src/engine-gpg.c @@ -27,6 +27,7 @@ #include #include #include +#include #ifdef HAVE_UNISTD_H # include #endif @@ -135,6 +136,7 @@ struct engine_gpg struct gpgme_io_cbs io_cbs; gpgme_pinentry_mode_t pinentry_mode; + pid_t pid; }; typedef struct engine_gpg *engine_gpg_t; @@ -371,6 +373,13 @@ gpg_cancel (void *engine) gpg->fd_data_map = NULL; } + if (gpg->pid > 0 && kill (gpg->pid, 0) == 0) + { + kill (gpg->pid, SIGTERM); + if (kill (gpg->pid, 0) == 0) + kill (gpg->pid, SIGKILL); + } + return 0; } @@ -1389,6 +1398,7 @@ start (engine_gpg_t gpg) } /*_gpgme_register_term_handler ( closure, closure_value, pid );*/ + gpg->pid = pid; rc = add_io_cb (gpg, gpg->status.fd[0], 1, status_handler, gpg, &gpg->status.tag); diff --git a/src/posix-io.c b/src/posix-io.c index ac823fc..835a6bd 100644 --- a/src/posix-io.c +++ b/src/posix-io.c @@ -376,6 +376,7 @@ _gpgme_io_spawn (const char *path, char *const argv[], unsigned int flags, int i; int status; int signo; + int pidpipe[2]; TRACE_BEG1 (DEBUG_SYSIO, "_gpgme_io_spawn", path, "path=%s", path); @@ -391,6 +392,9 @@ _gpgme_io_spawn (const char *path, char *const argv[], unsigned int flags, else TRACE_LOG3 ("fd[%i] = 0x%x -> 0x%x", i, fd_list[i].fd, fd_list[i].dup_to); + if (pipe (pidpipe) == -1) + return TRACE_SYSRES (-1); + pid = fork (); if (pid == -1) return TRACE_SYSRES (-1); @@ -495,7 +499,12 @@ _gpgme_io_spawn (const char *path, char *const argv[], unsigned int flags, if (pid == -1) _exit (1); else - _exit (0); + { + close (pidpipe[0]); + write (pidpipe[1], &pid, sizeof(pid_t)); + close (pidpipe[1]); + _exit (0); + } } TRACE_LOG1 ("waiting for child process pid=%i", pid); @@ -503,6 +512,11 @@ _gpgme_io_spawn (const char *path, char *const argv[], unsigned int flags, if (status) return TRACE_SYSRES (-1); + close (pidpipe[1]); + if (read (pidpipe[0], &pid, sizeof (pid)) != sizeof (pid)) + pid = -1; + close (pidpipe[0]); + for (i = 0; fd_list[i].fd != -1; i++) { if (! (flags & IOSPAWN_FLAG_NOCLOSE)) diff --git a/src/wait-global.c b/src/wait-global.c index f03775e..77518e4 100644 --- a/src/wait-global.c +++ b/src/wait-global.c @@ -261,6 +261,8 @@ gpgme_wait_ext (gpgme_ctx_t ctx, gpgme_error_t *status, struct ctx_list_item *li; struct fd_table fdt; int nr; + gpgme_error_t err = 0; + gpgme_error_t local_op_err = 0; /* Collect the active file descriptors. */ LOCK (ctx_list_lock); @@ -299,13 +301,23 @@ gpgme_wait_ext (gpgme_ctx_t ctx, gpgme_error_t *status, return NULL; } - for (i = 0; i < fdt.size && nr; i++) + LOCK (ctx->lock); + if (ctx->canceled) + err = gpg_error (GPG_ERR_CANCELED); + UNLOCK (ctx->lock); + + if (err) + { + /* An error occured. Close all fds in this context, + and signal it. */ + _gpgme_cancel_with_err (ctx, err, local_op_err); + } + + for (i = 0; !err && i < fdt.size && nr; i++) { - if (fdt.fds[i].fd != -1 && fdt.fds[i].signaled) + if (fdt.fds[i].fd != -1 && (fdt.fds[i].signaled)) { gpgme_ctx_t ictx; - gpgme_error_t err = 0; - gpgme_error_t local_op_err = 0; struct wait_item_s *item; assert (nr); -- 2.1.4 From patrick at enigmail.net Fri Dec 26 13:35:47 2014 From: patrick at enigmail.net (Patrick Brunschwig) Date: Fri, 26 Dec 2014 13:35:47 +0100 Subject: gpg-agent and allow-loopback-pinentry Message-ID: <549D5623.5040602@enigmail.net> What is the reason to require gpg-agent to be started with "allow-loopback-pinentry" if "--pinentry-mode loopback" should be used? Furthermore, why can this option only be changed by modifying gpg-agent.conf (i.e. before the agent is started)? I consider this an additional hassle for external programs like Enigmail that offer key creation. The main reason for my question is that the pinentry dialog is not user-friendly enough, especially for key creation: 1. There is no explanation why a password is required (and why again) 2. There is no feedback for the user about the quality of the passphrase. I would like to be able to have the user enter type the passphrase in my application and then request gpg to do its job. But with gpg 2.1 this is simply not possible. Thanks, Patrick From dgouttegattat at incenp.org Fri Dec 26 18:13:27 2014 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Fri, 26 Dec 2014 18:13:27 +0100 Subject: Weird behaviours in GPG 2.1 with validity In-Reply-To: <5498DE16.3090006@pwned.gg> References: <548C5743.5060208@pwned.gg> <548DA2E5.9070403@pwned.gg> <5492C1C0.1030307@pwned.gg> <5498DE16.3090006@pwned.gg> Message-ID: <549D9737.7020504@incenp.org> On 12/23/2014 04:14 AM, Ximin Luo wrote: > I've managed to trim this down to a minimal test case: > > https://bugs.g10code.com/gnupg/issue1794 > > Would be good if others could confirm and/or comment. I have just observed the same problem when trying to convert my legacy pubring.gpg to the new keybox format. If that can help, here is another test case (you can find the keys and the ownertrust file attached to this message): $ mkdir test && chmod 0700 test # Importing Alice and Bob keys (each key is signed by the other) $ gpg2 --homedir ./test --import alice.asc bob.asc gpg: keybox './test/pubring.kbx' created gpg: ./test/trustdb.gpg: trustdb created gpg: key 525487D8: public key "Alice " imported gpg: key 2748ECD9: public key "Robert " imported gpg: Total number processed: 2 gpg: imported: 2 gpg: no ultimately trusted keys found # Restoring ownertrust # Alice's key is "ultimately" trusted # Bob's key is "marginally" trusted $ gpg2 --homedir ./test --import-ownertrust otrust.lst gpg: inserting ownertrust of 6 gpg: inserting ownertrust of 4 # Displaying calculated validity of both keys # Note that Alice's key is only marginally valid $ gpg2 --homedir ./test --list-options show-uid-validity --list-keys gpg: checking the trustdb gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 1 signed: 1 trust: 0-, 0q, 0n, 0m, 0f, 1u gpg: depth: 1 valid: 1 signed: 1 trust: 0-, 0q, 0n, 1m, 0f, 0u ./test/pubring.kbx ------------------ pub nistp256/525487D8 2014-12-26 uid [marginal] Alice sub nistp256/529A1EF5 2014-12-26 nistp256 pub nistp256/2748ECD9 2014-12-26 uid [ full ] Robert sub nistp256/A5D8267D 2014-12-26 nistp256 The problem only occurs when using the new keybox format. If I do the same thing as above, but this time forcing gpg2 to use the legacy pubring format (by touch'ing an empty pubring.gpg prior to importing the keys), Alice's key remains ultimately valid. The fix proposed in the BTS [1] works for me. [1] https://bugs.g10code.com/gnupg/msg5688 -------------- next part -------------- # List of assigned trustvalues, created Fri 26 Dec 2014 04:57:19 AM CET # (Use "gpg --import-ownertrust" to restore them) CF1F914B89FDE5371C258CB4DF8FE60A525487D8:6: B464CBBBBE41D6BA348CA849885CC1552748ECD9:4: -------------- next part -------------- A non-text attachment was scrubbed... Name: alice.asc Type: application/pgp-encrypted Size: 800 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bob.asc Type: application/pgp-encrypted Size: 796 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 mailinglisten at hauke-laging.de Fri Dec 26 20:23:27 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 26 Dec 2014 20:23:27 +0100 Subject: gpg-agent and allow-loopback-pinentry In-Reply-To: <549D5623.5040602@enigmail.net> References: <549D5623.5040602@enigmail.net> Message-ID: <2154467.I4d9LMobhu@inno> Am Fr 26.12.2014, 13:35:47 schrieb Patrick Brunschwig: > I would like to be able to have the user enter type the passphrase in > my application and then request gpg to do its job. But with gpg 2.1 > this is simply not possible. I have not used 2.1 yet so I am not sure whether this still applies but I assume that. You should be able to do this (see the following link): http://lists.gnupg.org/pipermail/gnupg-users/2013-December/048362.html 1) Create a temporary config dir for gpg/aga-agent. 2) Create a config file for gpg-agent which replaces pinentry with your own script / program. 3) Use this temporary config dir for creating the key (or for changing its passphrase). 4) Export the new key. 5) Import the key file to the regular gpg config dir (delete it before if you just change the passphrase). Could be easier but at least it should be possible (it is with 2.0.x). Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 603 bytes Desc: This is a digitally signed message part. URL: From patrick at enigmail.net Sat Dec 27 14:36:38 2014 From: patrick at enigmail.net (Patrick Brunschwig) Date: Sat, 27 Dec 2014 14:36:38 +0100 Subject: gpg-agent and allow-loopback-pinentry In-Reply-To: <2154467.I4d9LMobhu@inno> References: <549D5623.5040602@enigmail.net> <2154467.I4d9LMobhu@inno> Message-ID: <549EB5E6.5060306@enigmail.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 26.12.14 20:23, Hauke Laging wrote: > Am Fr 26.12.2014, 13:35:47 schrieb Patrick Brunschwig: > >> I would like to be able to have the user enter type the >> passphrase in my application and then request gpg to do its job. >> But with gpg 2.1 this is simply not possible. > > I have not used 2.1 yet so I am not sure whether this still applies > but I assume that. > > You should be able to do this (see the following link): > > http://lists.gnupg.org/pipermail/gnupg-users/2013-December/048362.html > > 1) Create a temporary config dir for gpg/aga-agent. > > 2) Create a config file for gpg-agent which replaces pinentry with > your own script / program. > > 3) Use this temporary config dir for creating the key (or for > changing its passphrase). > > 4) Export the new key. > > 5) Import the key file to the regular gpg config dir (delete it > before if you just change the passphrase). > > Could be easier but at least it should be possible (it is with > 2.0.x). Under no circumstance would I want to implement this in Enigmail. Even more as Unix scripts don't work on Windows. And I'm talking about GnuPG 2.1.x only. In GnuPG 2.0.x you can set the passphrase as part of the key specification. - -Patrick -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJUnrXlAAoJEMk25cDiHiw+8M0H/Rd+bIMbJLDtipjKHst2fz78 2FHCaKcdpSGa8xAsTnSJH+gUtCaVNDm/liuDYRjP0teBUGOsvJmWv7vxner3grPw KLEvBbaUVCzZXznEc4VhiBJ6BKyKzWAO2wMv24MrZToYYz8o2yZwf8cZlGZqten6 EcENhrWrSjORVAHXA45Tn4tYP0SaLN/2fj4nPVW3jHs3EhUOTQ98N0AGxXhHInDG exNN30bckZBU/3w5ZJmyStCniaXUF792J5NhS05IX26V7Y9l5MvcuUthLB3t3InA vxQIFnkINgQudRRnHQ1e1JVoB8NqZxHIflJqRCn+mp03Ej1HVufP5iwRStAEKiI= =Y6zd -----END PGP SIGNATURE----- From wk at gnupg.org Sat Dec 27 15:45:03 2014 From: wk at gnupg.org (Werner Koch) Date: Sat, 27 Dec 2014 15:45:03 +0100 Subject: gpg-agent and allow-loopback-pinentry In-Reply-To: <549D5623.5040602@enigmail.net> (Patrick Brunschwig's message of "Fri, 26 Dec 2014 13:35:47 +0100") References: <549D5623.5040602@enigmail.net> Message-ID: <87fvc1nocw.fsf@vigenere.g10code.de> Hi Patrick, I am too busy with other things right now but a quick note anyway: We should have a meeting of key developers asap to discuss such things. Having it during a conference (e.g. FOSDEM) is IMHO not sufficient. It would be better to have a small dedicated meeting. > 1. There is no explanation why a password is required (and why again) Okay, let's improve on that. > 2. There is no feedback for the user about the quality of the passphrase. There is one for may years - it always bugs me when using my standard test passphrase "abc". The current method is quite primitive but you can hook in other checks. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From patrick at enigmail.net Sat Dec 27 15:54:39 2014 From: patrick at enigmail.net (Patrick Brunschwig) Date: Sat, 27 Dec 2014 15:54:39 +0100 Subject: gpg-agent and allow-loopback-pinentry In-Reply-To: <87fvc1nocw.fsf@vigenere.g10code.de> References: <549D5623.5040602@enigmail.net> <87fvc1nocw.fsf@vigenere.g10code.de> Message-ID: <549EC82F.3030205@enigmail.net> On 27.12.14 15:45, Werner Koch wrote: > Hi Patrick, > > I am too busy with other things right now but a quick note anyway: > > We should have a meeting of key developers asap to discuss such things. > Having it during a conference (e.g. FOSDEM) is IMHO not sufficient. It > would be better to have a small dedicated meeting. Fully agreed, especially as I can't attend FOSDEM this time. We had a usability study on Enigmail, and the two points below were some of the feedback we got. >> 1. There is no explanation why a password is required (and why again) > > Okay, let's improve on that. > >> 2. There is no feedback for the user about the quality of the passphrase. > > There is one for may years - it always bugs me when using my standard > test passphrase "abc". The current method is quite primitive but you > can hook in other checks. True, but the current pinentry tools (at least pinentry-mac) don't do this. What I'd like to have is something like a colored progress bar such that the user can get direct feedback. -Patrick From gniibe at fsij.org Sun Dec 28 06:59:49 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Sun, 28 Dec 2014 14:59:49 +0900 Subject: gpg-agent and allow-loopback-pinentry In-Reply-To: <549D5623.5040602@enigmail.net> References: <549D5623.5040602@enigmail.net> Message-ID: <549F9C55.6010508@fsij.org> On 12/26/2014 09:35 PM, Patrick Brunschwig wrote: > I would like to be able to have the user enter type the passphrase in my > application and then request gpg to do its job. But with gpg 2.1 this is > simply not possible. Perhaps, it's due to the design of newer GnuPG as a whole. It's (partially) possible with loopback mode, though. Let me explain my understandings. Here is a figure which shows the relationship: user [some mail user agent like thunderbird] gpg frontend or gpgme library gpg agent <--------------------------------> pinentry secret handled by libgcrypt -OR- by scdaemon smartcard/token It is gpg-agent which calls pinentry, on demand. There are some use cases when PIN is not asked back through host PC. (1) A smartcard can be configured requiring PIN input at the first use only, but not requiring everytime. (2) It is also possible, for some smartcard reader, to ask user PIN input by its pinpad, not through host PC. I understand that application developers have to care controlling its passphrase input, and it's largest use cases. But, please understand there are some people who want control the input in different ways, with valid reasons. Well, smartcard reader could be compromised to spy users' pinpad input, too. -- From patrick at enigmail.net Sun Dec 28 17:06:36 2014 From: patrick at enigmail.net (Patrick Brunschwig) Date: Sun, 28 Dec 2014 17:06:36 +0100 Subject: gpg-agent and allow-loopback-pinentry In-Reply-To: <549F9C55.6010508@fsij.org> References: <549D5623.5040602@enigmail.net> <549F9C55.6010508@fsij.org> Message-ID: <54A02A8C.4060801@enigmail.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 28.12.14 06:59, NIIBE Yutaka wrote: > On 12/26/2014 09:35 PM, Patrick Brunschwig wrote: >> I would like to be able to have the user enter type the >> passphrase in my application and then request gpg to do its job. >> But with gpg 2.1 this is simply not possible. > > Perhaps, it's due to the design of newer GnuPG as a whole. It's > (partially) possible with loopback mode, though. > > Let me explain my understandings. Here is a figure which shows the > relationship: > > user [some mail user agent like thunderbird] gpg frontend or gpgme > library gpg agent <--------------------------------> pinentry > secret handled by libgcrypt -OR- by scdaemon smartcard/token > > It is gpg-agent which calls pinentry, on demand. There are some > use cases when PIN is not asked back through host PC. > > (1) A smartcard can be configured requiring PIN input at the first > use only, but not requiring everytime. > > (2) It is also possible, for some smartcard reader, to ask user > PIN input by its pinpad, not through host PC. > > I understand that application developers have to care controlling > its passphrase input, and it's largest use cases. But, please > understand there are some people who want control the input in > different ways, with valid reasons. That's all clear and understood, and I have no issue with it. My only problem is that it's difficult (and awkward) for an application that wraps GnuPG to enable the loopback mode -- it requires to modify gpg-agent.conf and restart gpg-agent. - -Patrick -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJUoCqKAAoJEMk25cDiHiw+wY8H/RlBg22MRVEmtvEnhehAl0ph NuqjpIXsPhS6Ny72a0VlFoCSHrMb26JITH+0NMIcYEds4JlIqSLrCLWdmIEwi/pH dfx3E9xTdKBOoZAJGMmDpvQnS46Gk7LfakfOYTj2DvhcoEGgbD9yQIdNJ94MqkYd 23OHINZxFtDd46jTK+c/HCgGNbt2cIUi0yATen9nAvciqDxV1Of4MSpR6oYYNhQa NqGzJYyquNuj8m5ukHsfp8Ogr0boLzYloNPpEib2BwuhjuIIoB4nziPd9Dl+swsU 9XFM13O9DCg9S+gX8pFnJQZdEi/np0Rl4GiYIBiHN1qfil8Q0AaWrTmeOJBK+Kw= =NxMT -----END PGP SIGNATURE----- From wk at gnupg.org Mon Dec 29 10:56:16 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 29 Dec 2014 10:56:16 +0100 Subject: gpg-agent and allow-loopback-pinentry In-Reply-To: <54A02A8C.4060801@enigmail.net> (Patrick Brunschwig's message of "Sun, 28 Dec 2014 17:06:36 +0100") References: <549D5623.5040602@enigmail.net> <549F9C55.6010508@fsij.org> <54A02A8C.4060801@enigmail.net> Message-ID: <87bnmmn5j3.fsf@vigenere.g10code.de> On Sun, 28 Dec 2014 17:06, patrick at enigmail.net said: > problem is that it's difficult (and awkward) for an application that > wraps GnuPG to enable the loopback mode -- it requires to modify > gpg-agent.conf and restart gpg-agent. The reason why you need to enable the loopback mode is that this breaks a design goal of only allowing the gpg-agent (+scdaemon) to handle the private keys and the passphrases for it. If a user does not want this protection he needs to explicitly disable it. I met Nico here at the 31C3 and we more or less agreed that we need to make it work by fixing the Mac pinentry and possible some other problems which arise on Windows. That will be much easier than implementing the passphrase entry in each application and thereby confusing the user with different passphrase entry systems. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From patrick at enigmail.net Mon Dec 29 15:47:08 2014 From: patrick at enigmail.net (Patrick Brunschwig) Date: Mon, 29 Dec 2014 15:47:08 +0100 Subject: gpg-agent and allow-loopback-pinentry In-Reply-To: <87bnmmn5j3.fsf@vigenere.g10code.de> References: <549D5623.5040602@enigmail.net> <549F9C55.6010508@fsij.org> <54A02A8C.4060801@enigmail.net> <87bnmmn5j3.fsf@vigenere.g10code.de> Message-ID: <54A1696C.4080502@enigmail.net> On 29.12.14 10:56, Werner Koch wrote: > On Sun, 28 Dec 2014 17:06, patrick at enigmail.net said: >> problem is that it's difficult (and awkward) for an application that >> wraps GnuPG to enable the loopback mode -- it requires to modify >> gpg-agent.conf and restart gpg-agent. > > The reason why you need to enable the loopback mode is that this breaks > a design goal of only allowing the gpg-agent (+scdaemon) to handle the > private keys and the passphrases for it. If a user does not want this > protection he needs to explicitly disable it. > > I met Nico here at the 31C3 and we more or less agreed that we need to > make it work by fixing the Mac pinentry and possible some other problems > which arise on Windows. That will be much easier than implementing the > passphrase entry in each application and thereby confusing the user with > different passphrase entry systems. I'm very happy for gpg-agent and pinentry to handle passphrases for me during normal operations. However, I disagree with you and Nico concerning key creation. I think it makes sense that the dialog presented to the user contains *all* required data, including the passphrase. That's what users are used to when registering for any service in almost all applications and on almost all web sites. And I think it's sensible not to break with this, as it will only confuse users. Furthermore, it means that I have to differentiate in the GUI between GnuPG 2.1.x and older versions. This is something I could avoid so far, i.e. any difference between GnuPG versions could be handled in the invisible core components. -Patrick From guilhem at fripost.org Mon Dec 29 14:36:56 2014 From: guilhem at fripost.org (Guilhem Moulin) Date: Mon, 29 Dec 2014 14:36:56 +0100 Subject: --secret-keyring alternative for gpg 2.1 Message-ID: <20141229133656.GA31455@localhost> Hi list, --secret-keyring has been obsoleted in the 2.1 branch, and all secret keys are stored in ${GNUPGHOME:-~/.gnupg}/private-keys-v1.d instead. Unfortunately, that breaks tools like caff(1) (from the Debian package signing-party), which have their own GnuPG Home for configuration file and public keyring but use the default secret keyring for signing. gpg --homedir=$HOME/.caff/gnupghome --secret-keyring=${GNUPGHOME:-~/.gnupg}/secring.gpg AFAICT the only fix is to symlink ~/.caff/gnupghome/private-keys-v1.d to ${GNUPGHOME:-~/.gnupg}/private-keys-v1.d . It'd be better if --secret-keyring (or a new option) could be used to specify the directory in which secret keys are stored, e.g., gpg2 --homedir=$HOME/.caff/gnupghome --secret-keydir=${GNUPGHOME:-~/.gnupg}/private-keys-v1.d Cheers, -- Guilhem. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From dkg at fifthhorseman.net Tue Dec 30 23:33:50 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 30 Dec 2014 17:33:50 -0500 Subject: gpg-agent and allow-loopback-pinentry In-Reply-To: <54A1696C.4080502@enigmail.net> References: <549D5623.5040602@enigmail.net> <549F9C55.6010508@fsij.org> <54A02A8C.4060801@enigmail.net> <87bnmmn5j3.fsf@vigenere.g10code.de> <54A1696C.4080502@enigmail.net> Message-ID: <54A3284E.6070300@fifthhorseman.net> On 12/29/2014 09:47 AM, Patrick Brunschwig wrote: > I'm very happy for gpg-agent and pinentry to handle passphrases for me > during normal operations. > > However, I disagree with you and Nico concerning key creation. I think > it makes sense that the dialog presented to the user contains *all* > required data, including the passphrase. That's what users are used to > when registering for any service in almost all applications and on > almost all web sites. And I think it's sensible not to break with this, > as it will only confuse users. I can see both sides of this issue, and i wonder if there aren't other ways to resolve it. to be honest, when i've watched users set up enigmail with GnuPG for the first time, they're often confused by the fact of a password for the key in the first place. And an OpenPGP key by default is not the same thing as a web service, either. Here's a radical (and quite possibly terrible) idea, with the hope of spurring new thinking: What about generating the key with no passphrase initially, and presenting a big "protect this key with a passphrase" button to the user when no passphrase is set? The downsides i see are: * passphraseless keys will be written to the filesystem and might not ever be erased. * some users will never click the "protect this key with a passphrase" button. * it's not clear to me whether there's an easy way for enigmail to tell whether the secret key in question has a passphrase set on it or not but there might be cognitive advantages for new users too: maybe they'd understand what they're doing more if they have to take an action explicitly? This might also make it easier to get more people to use the tools too, while still enabling people who want to follow stronger security practices to do so. yikes, though... I don't know if there are any usability studies that would help make this decision easier. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: