From ineiev at gnu.org Thu Jun 6 13:07:12 2019 From: ineiev at gnu.org (Ineiev) Date: Thu, 6 Jun 2019 11:07:12 +0000 Subject: [PINENTRY PATCH] tty button-related fixes and refinements In-Reply-To: <20170519085721.GQ25850@gnu.org> References: <20160408174738.GA26817@gnu.org> <20160927040242.GM30569@gnu.org> <4806cab2-483e-48f2-7807-9866d81ab1d2@fsij.org> <20161003154952.GK30569@gnu.org> <20170519085721.GQ25850@gnu.org> Message-ID: <20190606110712.GB2392@desdichado> On Fri, May 19, 2017 at 04:57:21AM -0400, Ineiev wrote: > On Mon, Oct 03, 2016 at 11:49:52AM -0400, Ineiev wrote: > > > > > The patch: > > > > > > 0003-tty-Show-supplied-message-when-using-default.patch > > > > > > is introducing a new feature. Let me have (more) time to review this > > > closely. > > > > It may be thought of as a new feature, but I think it's essential > > for making pinentry work reliably, especially when the translator > > doesn't care of pinentry-tty. > > Rebased against current HEAD. Rebased against current HEAD. Perhaps it's inconsistent to support non-ASCII characters in prompts and messages, but not in button labels. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-tty-Show-supplied-message-when-using-default.patch Type: text/x-diff Size: 2290 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From dgouttegattat at incenp.org Sat Jun 8 22:24:18 2019 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sat, 8 Jun 2019 21:24:18 +0100 Subject: [PATCH gnupg] dirmngr: Fix 302 redirections when using hkps. Message-ID: <20190608202418.13485-1-dgouttegattat@incenp.org> * dirmngr/ks-engine-hkp.c (send_request): Reinitialize HTTP session when following a redirection. GnuPG-bug-id: 4566 Signed-off-by: Damien Goutte-Gattat --- dirmngr/ks-engine-hkp.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/dirmngr/ks-engine-hkp.c b/dirmngr/ks-engine-hkp.c index 0a360f09f..55c9c255d 100644 --- a/dirmngr/ks-engine-hkp.c +++ b/dirmngr/ks-engine-hkp.c @@ -1217,6 +1217,7 @@ send_request (ctrl_t ctrl, const char *request, const char *hostportstr, /* FIXME: I am not sure whey we allow a downgrade for hkp requests. * Needs at least an explanation here.. */ + once_more: err = http_session_new (&session, httphost, ((ctrl->http_no_crl? HTTP_FLAG_NO_CRL : 0) | HTTP_FLAG_TRUST_DEF), @@ -1226,7 +1227,6 @@ send_request (ctrl_t ctrl, const char *request, const char *hostportstr, http_session_set_log_cb (session, cert_log_cb); http_session_set_timeout (session, ctrl->timeout); - once_more: err = http_open (ctrl, &http, post_cb? HTTP_REQ_POST : HTTP_REQ_GET, request, @@ -1306,6 +1306,7 @@ send_request (ctrl_t ctrl, const char *request, const char *hostportstr, request = request_buffer; http_close (http, 0); http = NULL; + http_session_release (session); } goto once_more; -- 2.14.5 From gniibe at fsij.org Mon Jun 10 08:50:24 2019 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 10 Jun 2019 15:50:24 +0900 Subject: [PINENTRY PATCH] tty button-related fixes and refinements In-Reply-To: <20190606110712.GB2392@desdichado> References: <20160408174738.GA26817@gnu.org> <20160927040242.GM30569@gnu.org> <4806cab2-483e-48f2-7807-9866d81ab1d2@fsij.org> <20161003154952.GK30569@gnu.org> <20170519085721.GQ25850@gnu.org> <20190606110712.GB2392@desdichado> Message-ID: <87imterl1r.fsf@iwagami.gniibe.org> Ineiev wrote: > From 96b9bd217dcfd2f9e655944aa68b99727ae7838c Mon Sep 17 00:00:00 2001 > From: Ineiev > Date: Fri, 8 Apr 2016 15:29:08 +0300 > Subject: [PATCH] tty: Show supplied message when using default > > tty/pinentry-tty.c (fputs_highlighted): New function. > tty/pinentry-tty.c (button): Display the supplied text when > falling back to default; the default text is shown in braces > and provides the accelerator. > > -- > This allows using button texts written with non-ASCII characters. > > Signed-off-by: Ineiev Thanks. Applied and pushed. -- From look at my.amazin.horse Wed Jun 12 18:53:50 2019 From: look at my.amazin.horse (Vincent Breitmoser) Date: Wed, 12 Jun 2019 18:53:50 +0200 Subject: Launching a new keyserver on keys.openpgp.org! Message-ID: <3NVU5541SFC9Z.31QCVT004UI9Z@my.amazin.horse> Hey gnupg-devel folks, the Hagrid team is pleased to announce the launch of our new keyserver, running at keys.openpgp.org! https://keys.openpgp.org Here's the short story: * Fast and reliable. No wait times, no downtimes, no inconsistencies. * Precise. Searches return only a single key, which allows for easy key discovery. * Validating. Identities are only published with consent, while non-identity information is freely distributed. * Deletable. Users can delete personal information with a simple e-mail confirmation. * Built on Rust, powered by Sequoia PGP - free and open source, running AGPLv3. Full news announcement: https://keys.openpgp.org/about/news#2019-06-12-launch Our primary motivation was to have a place where OpenPGP clients can reliably and quickly obtain updates to key material (subkeys, revocations, ...), and that also has as a simple and useful way of key discovery. Some of the things we do are a bit experimental. For some things we found that there is no good mechanism at this point, so we decided to drop them for now. Most notably this includes third party signatures on keys, because they in their current form the difficulties wrt privacy and spam outweigh their usefulness. The server implementation Hagrid (as in, "keeper of keys") is developed here: https://gitlab.com/sequoia-pgp/hagrid Feel free to file issues if you find anything out of place. Please read our FAQ first ;) Huge thanks to Kai for the initial implementation, Justus and Neal for creating Sequoia and working with me on this, dkg and Paul for testing and tons of feedback, Phil for providing us with the domain, and of course everyone who helped us test and polish this thing! Happy to hear your feedback! - V From look at my.amazin.horse Thu Jun 13 21:27:40 2019 From: look at my.amazin.horse (Vincent Breitmoser) Date: Thu, 13 Jun 2019 21:27:40 +0200 Subject: [PATCH v3 GnuPG] allow import without user ids In-Reply-To: <20190512103655.25693-1-look@my.amazin.horse> References: <20190512103655.25693-1-look@my.amazin.horse> Message-ID: <20190613192743.12991-1-look@my.amazin.horse> I integrated one more of dkg's tests. Subkey revocations are now imported even in the absence of subkey binding certificates. I believe this patch series now covers the low hanging fruit wrt import of partial keys. This makes GnuPG fully compatible with the split identity/non-identity information model of keys.openpgp.org, and fixes the issue mentioned in our FAQ: https://keys.openpgp.org/about/faq#older-gnupg Please let me know if there are any issues remaining with this patch, and I will try to resolve them. From look at my.amazin.horse Thu Jun 13 21:27:43 2019 From: look at my.amazin.horse (Vincent Breitmoser) Date: Thu, 13 Jun 2019 21:27:43 +0200 Subject: [PATCH GnuPG 3/3] gpg: accept subkeys with a good revocation but no self-sig during import In-Reply-To: <20190613192743.12991-1-look@my.amazin.horse> References: <20190512103655.25693-1-look@my.amazin.horse> <20190613192743.12991-1-look@my.amazin.horse> Message-ID: <20190613192743.12991-4-look@my.amazin.horse> * g10/import.c (chk_self_sigs): Set the NODE_GOOD_SELFSIG flag when we encounter a valid revocation signature. This allows import of subkey revocation signatures, even in the absence of a corresponding subkey binding signature. --- g10/import.c | 1 + 1 file changed, 1 insertion(+) diff --git a/g10/import.c b/g10/import.c index 2be214e63..ae2453803 100644 --- a/g10/import.c +++ b/g10/import.c @@ -3536,6 +3536,7 @@ chk_self_sigs (ctrl_t ctrl, kbnode_t keyblock, u32 *keyid, int *non_self) /* It's valid, so is it newer? */ if (sig->timestamp >= rsdate) { + knode->flag |= NODE_GOOD_SELFSIG; /* Subkey is valid. */ if (rsnode) { /* Delete the last revocation sig since -- 2.20.1 From look at my.amazin.horse Thu Jun 13 21:27:41 2019 From: look at my.amazin.horse (Vincent Breitmoser) Date: Thu, 13 Jun 2019 21:27:41 +0200 Subject: [PATCH GnuPG 1/3] tests: add test cases for import without uid In-Reply-To: <20190613192743.12991-1-look@my.amazin.horse> References: <20190512103655.25693-1-look@my.amazin.horse> <20190613192743.12991-1-look@my.amazin.horse> Message-ID: <20190613192743.12991-2-look@my.amazin.horse> This commit adds a test case that does the following, in order: - Import of a primary key plus user id - Check that import of a subkey works, without a user id present in the imported key - Check that import of a subkey revocation works, without a user id or subkey binding signature present in the imported key - Check that import of a primary key revocation works, without a user id present in the imported key --- tests/openpgp/Makefile.am | 1 + tests/openpgp/import-incomplete.scm | 68 +++++++++++++++++++ .../import-incomplete/primary+revocation.asc | 9 +++ .../primary+subkey+sub-revocation.asc | 10 +++ .../primary+subkey+sub-sig.asc | 10 +++ .../import-incomplete/primary+uid-sig.asc | 10 +++ .../openpgp/import-incomplete/primary+uid.asc | 10 +++ 7 files changed, 118 insertions(+) create mode 100755 tests/openpgp/import-incomplete.scm create mode 100644 tests/openpgp/import-incomplete/primary+revocation.asc create mode 100644 tests/openpgp/import-incomplete/primary+subkey+sub-revocation.asc create mode 100644 tests/openpgp/import-incomplete/primary+subkey+sub-sig.asc create mode 100644 tests/openpgp/import-incomplete/primary+uid-sig.asc create mode 100644 tests/openpgp/import-incomplete/primary+uid.asc diff --git a/tests/openpgp/Makefile.am b/tests/openpgp/Makefile.am index e5be42b41..d886bc8f7 100644 --- a/tests/openpgp/Makefile.am +++ b/tests/openpgp/Makefile.am @@ -78,6 +78,7 @@ XTESTS = \ gpgv-forged-keyring.scm \ armor.scm \ import.scm \ + import-incomplete.scm \ import-revocation-certificate.scm \ ecc.scm \ 4gb-packet.scm \ diff --git a/tests/openpgp/import-incomplete.scm b/tests/openpgp/import-incomplete.scm new file mode 100755 index 000000000..727a027c6 --- /dev/null +++ b/tests/openpgp/import-incomplete.scm @@ -0,0 +1,68 @@ +#!/usr/bin/env gpgscm + +;; Copyright (C) 2016 g10 Code GmbH +;; +;; This file is part of GnuPG. +;; +;; GnuPG is free software; you can redistribute it and/or modify +;; it under the terms of the GNU General Public License as published by +;; the Free Software Foundation; either version 3 of the License, or +;; (at your option) any later version. +;; +;; GnuPG is distributed in the hope that it will be useful, +;; but WITHOUT ANY WARRANTY; without even the implied warranty of +;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +;; GNU General Public License for more details. +;; +;; You should have received a copy of the GNU General Public License +;; along with this program; if not, see . + +(load (in-srcdir "tests" "openpgp" "defs.scm")) +(setup-environment) + +(call-check `(,(tool 'gpg) --import ,(in-srcdir "tests" "openpgp" "import-incomplete" "primary+uid.asc"))) + +(info "Test import of new subkey, from a certificate without uid") +(define keyid "573EA710367356BB") +(call-check `(,(tool 'gpg) --import ,(in-srcdir "tests" "openpgp" "import-incomplete" "primary+subkey+sub-sig.asc"))) +(tr:do + (tr:pipe-do + (pipe:gpg `(--list-keys --with-colons ,keyid))) + (tr:call-with-content + (lambda (c) + ;; XXX we do not have a regexp library + (unless (any (lambda (line) + (and (string-prefix? line "sub:") + (string-contains? line "573EA710367356BB"))) + (string-split-newlines c)) + (exit 1))))) + +(info "Test import of a subkey revocation, from a certificate without uid") +(define keyid "573EA710367356BB") +(call-check `(,(tool 'gpg) --import ,(in-srcdir "tests" "openpgp" "import-incomplete" "primary+subkey+sub-revocation.asc"))) +(tr:do + (tr:pipe-do + (pipe:gpg `(--list-keys --with-colons ,keyid))) + (tr:call-with-content + (lambda (c) + ;; XXX we do not have a regexp library + (unless (any (lambda (line) + (and (string-prefix? line "sub:r:") + (string-contains? line "573EA710367356BB"))) + (string-split-newlines c)) + (exit 1))))) + +(info "Test import of revocation, from a certificate without uid") +(call-check `(,(tool 'gpg) --import ,(in-srcdir "tests" "openpgp" "import-incomplete" "primary+revocation.asc"))) +(tr:do + (tr:pipe-do + (pipe:gpg `(--list-keys --with-colons ,keyid))) + (tr:call-with-content + (lambda (c) + ;; XXX we do not have a regexp library + (unless (any (lambda (line) + (and (string-prefix? line "pub:r:") + (string-contains? line "0843DA969AA8DAFB"))) + (string-split-newlines c)) + (exit 1))))) + diff --git a/tests/openpgp/import-incomplete/primary+revocation.asc b/tests/openpgp/import-incomplete/primary+revocation.asc new file mode 100644 index 000000000..6b7b60802 --- /dev/null +++ b/tests/openpgp/import-incomplete/primary+revocation.asc @@ -0,0 +1,9 @@ +-----BEGIN PGP PUBLIC KEY BLOCK----- +Comment: [E] primary key, revocation signature over primary (no user ID) + +mDMEXNmUGRYJKwYBBAHaRw8BAQdA75R8VlchvmEd2Iz/8l07RoKUaUPDB71Ao1zZ +631VAN2IeAQgFggAIBYhBLRpj5W82H/gSMzKKQhD2paaqNr7BQJc2ZQZAh0AAAoJ +EAhD2paaqNr7qAwA/2jBUpnN0BxwRO/4CrxvrLIsL+C9aSXJUOTv8XkP4lvtAQD3 +XsDFfFNgEueiTfF7HtOGt5LPmRqVvUpQSMVgJJW6CQ== +=tM90 +-----END PGP PUBLIC KEY BLOCK----- diff --git a/tests/openpgp/import-incomplete/primary+subkey+sub-revocation.asc b/tests/openpgp/import-incomplete/primary+subkey+sub-revocation.asc new file mode 100644 index 000000000..83a51a549 --- /dev/null +++ b/tests/openpgp/import-incomplete/primary+subkey+sub-revocation.asc @@ -0,0 +1,10 @@ +-----BEGIN PGP PUBLIC KEY BLOCK----- +Comment: [D] primary key, subkey, subkey revocation (no user ID) + +mDMEXNmUGRYJKwYBBAHaRw8BAQdA75R8VlchvmEd2Iz/8l07RoKUaUPDB71Ao1zZ +631VAN24OARc2ZQhEgorBgEEAZdVAQUBAQdABsd5ha0AWXdXcSmfeiWIfrNcGqQK +j++lwwWDAOlkVicDAQgHiHgEKBYIACAWIQS0aY+VvNh/4EjMyikIQ9qWmqja+wUC +XNmnkAIdAgAKCRAIQ9qWmqja+ylaAQDmIKf86BJEq4OpDqU+V9D+wn2cyuxbyWVQ +3r9LiL9qNwD/QAjyrhSN8L3Mfq+wdTHo5i0yB9ZCCpHLXSbhCqfWZwQ= +=dwx2 +-----END PGP PUBLIC KEY BLOCK----- diff --git a/tests/openpgp/import-incomplete/primary+subkey+sub-sig.asc b/tests/openpgp/import-incomplete/primary+subkey+sub-sig.asc new file mode 100644 index 000000000..dc47a02d8 --- /dev/null +++ b/tests/openpgp/import-incomplete/primary+subkey+sub-sig.asc @@ -0,0 +1,10 @@ +-----BEGIN PGP PUBLIC KEY BLOCK----- +Comment: [B] primary key, subkey, subkey binding sig (no user ID) + +mDMEXNmUGRYJKwYBBAHaRw8BAQdA75R8VlchvmEd2Iz/8l07RoKUaUPDB71Ao1zZ +631VAN24OARc2ZQhEgorBgEEAZdVAQUBAQdABsd5ha0AWXdXcSmfeiWIfrNcGqQK +j++lwwWDAOlkVicDAQgHiHgEGBYIACAWIQS0aY+VvNh/4EjMyikIQ9qWmqja+wUC +XNmUIQIbDAAKCRAIQ9qWmqja++vFAP98G1L+1/rWTGbsnxOAV2RocBYIroAvsbkR +Ly6FdP8YNwEA7jOgT05CoKIe37MstpOz23mM80AK369Ca3JMmKKCQgg= +=xuDu +-----END PGP PUBLIC KEY BLOCK----- diff --git a/tests/openpgp/import-incomplete/primary+uid-sig.asc b/tests/openpgp/import-incomplete/primary+uid-sig.asc new file mode 100644 index 000000000..134607d0e --- /dev/null +++ b/tests/openpgp/import-incomplete/primary+uid-sig.asc @@ -0,0 +1,10 @@ +-----BEGIN PGP PUBLIC KEY BLOCK----- +Comment: [C] primary key and self-sig expiring in 2024 (no user ID) + +mDMEXNmUGRYJKwYBBAHaRw8BAQdA75R8VlchvmEd2Iz/8l07RoKUaUPDB71Ao1zZ +631VAN2IlgQTFggAPgIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBLRpj5W8 +2H/gSMzKKQhD2paaqNr7BQJc2ZR1BQkJZgHcAAoJEAhD2paaqNr79soA/0lWkUsu +3NLwgbni6EzJxnTzgeNMpljqNpipHAwfix9hAP93AVtFdC8g7hdUZxawobl9lnSN +9ohXOEBWvdJgVv2YAg== +=KWIK +-----END PGP PUBLIC KEY BLOCK----- diff --git a/tests/openpgp/import-incomplete/primary+uid.asc b/tests/openpgp/import-incomplete/primary+uid.asc new file mode 100644 index 000000000..055f30086 --- /dev/null +++ b/tests/openpgp/import-incomplete/primary+uid.asc @@ -0,0 +1,10 @@ +-----BEGIN PGP PUBLIC KEY BLOCK----- +Comment: [A] primary key, user ID, and self-sig expiring in 2021 + +mDMEXNmUGRYJKwYBBAHaRw8BAQdA75R8VlchvmEd2Iz/8l07RoKUaUPDB71Ao1zZ +631VAN20CHRlc3Qga2V5iJYEExYIAD4WIQS0aY+VvNh/4EjMyikIQ9qWmqja+wUC +XNmUGQIbAwUJA8JnAAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRAIQ9qWmqja ++0G1AQDdQiwhXxjXLMqoth+D4SigVHTJK8ORwifzsy3UE7mPGwD/aZ67XbAF/lgI +kv2O1Jo0u9BL9RNNF+L0DM7rAFbfMAs= +=1eII +-----END PGP PUBLIC KEY BLOCK----- -- 2.20.1 From look at my.amazin.horse Thu Jun 13 21:27:42 2019 From: look at my.amazin.horse (Vincent Breitmoser) Date: Thu, 13 Jun 2019 21:27:42 +0200 Subject: [PATCH GnuPG 2/3] gpg: allow import of previously known keys, even without UIDs In-Reply-To: <20190613192743.12991-1-look@my.amazin.horse> References: <20190512103655.25693-1-look@my.amazin.horse> <20190613192743.12991-1-look@my.amazin.horse> Message-ID: <20190613192743.12991-3-look@my.amazin.horse> * g10/import.c (import_one): Accept an incoming OpenPGP certificate that has no user id, as long as we already have a local variant of the cert that matches the primary key. --- g10/import.c | 49 +++++++++++-------------------------------------- 1 file changed, 11 insertions(+), 38 deletions(-) diff --git a/g10/import.c b/g10/import.c index 00bc47cc1..2be214e63 100644 --- a/g10/import.c +++ b/g10/import.c @@ -1769,7 +1769,6 @@ import_one (ctrl_t ctrl, size_t an; char pkstrbuf[PUBKEY_STRING_SIZE]; int merge_keys_done = 0; - int any_filter = 0; KEYDB_HANDLE hd = NULL; if (r_valid) @@ -1806,16 +1805,6 @@ import_one (ctrl_t ctrl, log_printf ("\n"); } - - /* Unless import-drop-uids has been requested we don't allow import - * of a key without UIDs. */ - if (!uidnode && !(options & IMPORT_DROP_UIDS)) - { - if (!silent) - log_error( _("key %s: no user ID\n"), keystr_from_pk(pk)); - return 0; - } - if (screener && screener (keyblock, screener_arg)) { log_error (_("key %s: %s\n"), keystr_from_pk (pk), @@ -1887,20 +1876,10 @@ import_one (ctrl_t ctrl, } } - /* Delete invalid parts and without the drop option bail out if - * there are no user ids. */ - if (!delete_inv_parts (ctrl, keyblock, keyid, options) - && !(options & IMPORT_DROP_UIDS) ) - { - if (!silent) - { - log_error( _("key %s: no valid user IDs\n"), keystr_from_pk(pk)); - if (!opt.quiet ) - log_info(_("this may be caused by a missing self-signature\n")); - } - stats->no_user_id++; - return 0; - } + /* Delete invalid parts, and note if we have any valid ones left. + * We will later abort import if this key is new but contains + * no valid uids. */ + delete_inv_parts (ctrl, keyblock, keyid, options); /* Get rid of deleted nodes. */ commit_kbnode (&keyblock); @@ -1910,24 +1889,11 @@ import_one (ctrl_t ctrl, { apply_keep_uid_filter (ctrl, keyblock, import_filter.keep_uid); commit_kbnode (&keyblock); - any_filter = 1; } if (import_filter.drop_sig) { apply_drop_sig_filter (ctrl, keyblock, import_filter.drop_sig); commit_kbnode (&keyblock); - any_filter = 1; - } - - /* If we ran any filter we need to check that at least one user id - * is left in the keyring. Note that we do not use log_error in - * this case. */ - if (any_filter && !any_uid_left (keyblock)) - { - if (!opt.quiet ) - log_info ( _("key %s: no valid user IDs\n"), keystr_from_pk (pk)); - stats->no_user_id++; - return 0; } /* The keyblock is valid and ready for real import. */ @@ -1985,6 +1951,13 @@ import_one (ctrl_t ctrl, err = 0; stats->skipped_new_keys++; } + else if (err && !any_uid_left (keyblock) && !(options & IMPORT_DROP_UIDS) ) + { + if (!silent) + log_info( _("key %s: new key but contains no user ID - skipped\n"), keystr(keyid)); + err = 0; + stats->no_user_id++; + } else if (err) /* Insert this key. */ { /* Note: ERR can only be NO_PUBKEY or UNUSABLE_PUBKEY. */ -- 2.20.1 From wk at gnupg.org Fri Jun 14 18:06:01 2019 From: wk at gnupg.org (Werner Koch) Date: Fri, 14 Jun 2019 18:06:01 +0200 Subject: [PATCH v3 GnuPG] allow import without user ids In-Reply-To: <20190613192743.12991-1-look@my.amazin.horse> (Vincent Breitmoser's message of "Thu, 13 Jun 2019 21:27:40 +0200") References: <20190512103655.25693-1-look@my.amazin.horse> <20190613192743.12991-1-look@my.amazin.horse> Message-ID: <87k1dop2xi.fsf@wheatstone.g10code.de> On Thu, 13 Jun 2019 21:27, look at my.amazin.horse said: > I integrated one more of dkg's tests. Subkey revocations are now imported even > in the absence of subkey binding certificates. I believe this patch series now > covers the low hanging fruit wrt import of partial keys. As remarked over at the WG list I am not convinced of that whole change. The patches I have seen are pretty intrusive and change long standing behaviour of gpg. You also missed to send a DCO. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From look at my.amazin.horse Fri Jun 14 18:35:13 2019 From: look at my.amazin.horse (Vincent Breitmoser) Date: Fri, 14 Jun 2019 18:35:13 +0200 Subject: [PATCH v3 GnuPG] allow import without user ids In-Reply-To: <87k1dop2xi.fsf@wheatstone.g10code.de> References: <87k1dop2xi.fsf@wheatstone.g10code.de> <20190512103655.25693-1-look@my.amazin.horse> <20190613192743.12991-1-look@my.amazin.horse> Message-ID: <2S9R9G6O023G1.261YPRZDY73A3@my.amazin.horse> Hi, thanks for considering this patch series, > As remarked over at the WG list I am not convinced of that whole change. > The patches I have seen are pretty intrusive and change long standing > behaviour of gpg. Can you be more specific about your concerns? Surely if GnuPG encounters a valid revocation certificate and is in a position to import it without too much effort or subverting reasonable user expectations, it should do so? I understand how the patches are a little awkward, as they basically just remove checks for error cases that have existed for a long time. I can't say that I understand all the implications this might have, so a close review would be greatly appreciated. > You also missed to send a DCO. Sorry, it's been a while since I read the contribution guidelines. I'll send one. - V From look at my.amazin.horse Fri Jun 14 19:39:13 2019 From: look at my.amazin.horse (Vincent Breitmoser) Date: Fri, 14 Jun 2019 19:39:13 +0200 Subject: [PATCH v3 GnuPG] allow import without user ids In-Reply-To: <87k1dop2xi.fsf@wheatstone.g10code.de> References: <87k1dop2xi.fsf@wheatstone.g10code.de> <20190512103655.25693-1-look@my.amazin.horse> <20190613192743.12991-1-look@my.amazin.horse> Message-ID: <3LIAAK3IMRKL5.2J0V8Q0YI5LV8@my.amazin.horse> > As remarked over at the WG list I am not convinced of that whole change. I interpreted your reply "useful feature request" and triage as normal on T4393 as agreement that this is generally a desirable feature? If you are only unhappy with the method of the patch, please give some specifics and I will try to fix them. > The patches I have seen are pretty intrusive and change long standing > behaviour of gpg. Note that this patch changes behavior mostly in a way that was already achievable before through the use of "import-drop-uids". - V From dkg at fifthhorseman.net Fri Jun 14 18:06:55 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 14 Jun 2019 17:06:55 +0100 Subject: [PATCH v3 GnuPG] allow import without user ids In-Reply-To: <20190613192743.12991-1-look@my.amazin.horse> References: <20190512103655.25693-1-look@my.amazin.horse> <20190613192743.12991-1-look@my.amazin.horse> Message-ID: <87v9x8cfs0.fsf@fifthhorseman.net> On Thu 2019-06-13 21:27:40 +0200, Vincent Breitmoser wrote: > I integrated one more of dkg's tests. Subkey revocations are now imported even > in the absence of subkey binding certificates. I believe this patch series now > covers the low hanging fruit wrt import of partial keys. > > This makes GnuPG fully compatible with the split identity/non-identity > information model of keys.openpgp.org, and fixes the issue mentioned in our FAQ: > https://keys.openpgp.org/about/faq#older-gnupg > > Please let me know if there are any issues remaining with this patch, and I will > try to resolve them. I have reviewed these changes, and they look good to me. I've pushed a fix-4393 branch to the upstream git repository containing those changes with minor commit message cleanup, and my signoff on them. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dkg at fifthhorseman.net Sun Jun 16 16:27:37 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 16 Jun 2019 17:27:37 +0300 Subject: safe ephemeral GnuPG homdirs Message-ID: <87blyxd2qu.fsf@fifthhorseman.net> hi folks-- I've been looking at the notmuch test suite, which uses an ephemeral GNUPGHOME in several places. ?4.5.2 "Ephemeral home directories" of gnupg's info pages clearly state that this is the preferred way to perform isolated GnuPG actions. However, the notmuch project is having difficulty doing this safely in a robust cross-platform way. This is made more complex by the fact that test suites are frequently run in unusual system configurations (e.g. schroot, minimalist containers, etc), which may not have all the trappings of a full-blown desktop machine. The issues here revolve around sockaddr_un.sun_path size limits, arbitrary selection of hard-coded paths for runtime directories, etc, and i know that a lot of work has been put into trying to make it robust, but if even the technically-sophisticated notmuch development community is still struggling [0], it's hard to imagine that it's being used safely in other comparable contexts. (for reference, all of the notes here are related to GnuPG 2.2.16 from debian experimental, on a debian buster system) I'm wondering whether explicit signalling somehow wouldn't work better, though i'm reluctant to make the logic for socketdir selection even more complex. Is there some way to simplify this logic? Or, failing that, can we offer some portable way for a user of GnuPG to select a "safe" ephemeral homedir at runtime? or at least to get an explicit alert about what we think the problem is likely to be? Some example proposals to make things more robust (these are not mutually exclusive): a) We could offer "gpgconf --mkdir-ephemeral" -- it would make an ephemeral directory given the state of the current system and the logic of socketdir selection, such that it knows that the socket paths will fit. b) gpgconf --list-dir and gpgconf --launch could emit an explicit warning to stderr if gpgconf detects that the socketdir is likely to be unreachable due to sizeof(sun_path) limits. c) all parts of GnuPG that offer or connect to one of the sockets that are known to be too long could try to use relative paths when either bind()ing or connect()ing. Doing this safely seems pretty complicated, since the lack of bindat() or connectat() likely means we need to use chdir() or fchdir() before bind() or connect(), and of course the different current working directory has other consequences for the rest of the process. maybe this can be done safely within a fork() where a child process does socket(), chdir() and bind()/connect(), and then returns the resultant file descriptor to the parent process? The complexity of implementation here is daunting, and it doesn't account for other clients of the GnuPG daemons, who will have to figure out how to do this themselves. But it would still be more robust than the current situation. I think Justus Winter worked on something like this, but maybe it never got integrated? I don't know how portable it is to pass file descriptors between processes, or what to do on systems that don't have fork() -- maybe it's not necessary on those systems because they may not have the same limits on sun_path ? What do you think about any of the above? -------- As an aside, in reviewing the code for socket selection, i came across this comment in common/homedir.c, _gnupg_socketdir_internal(): /* It has been suggested to first check XDG_RUNTIME_DIR envvar. * However, the specs state that the lifetime of the directory MUST * be bound to the user being logged in. Now GnuPG may also be run * as a background process with no (desktop) user logged in. Thus * we better don't do that. */ I don't understand how this statement justifies the logic used here, or justifies not relying on the explicit signal of XDG_RUNTIME_DIR. A few observations: * the parenthetical aside in "no (desktop) user" isn't appropriate -- non-desktop users (e.g. remote ssh logins, virtual terminal logins, etc) can have XDG_RUNTIME_DIR set. On many systems with a typical PAM stack, XDG_RUNTIME_DIR is set appropriately (and the directory is created, if necessary) from most session initiations, whether it is ssh, virtual terminal, graphical desktop, etc. * if XDG_RUNTIME_DIR is set, then it seems legitimate to just use it directly, because we are *not* in the use case of being run as a background process with no available session. * if the concern is that XDG_RUNTIME_DIR will get cleaned up on session logout, that is *also* a concern for choosing the hard-coded paths that we choose. They too may be cleaned up on session logout. ------------- Finally, i note that even gpg-connect-agent gives oddly different error messages depending on the length of the socket paths, in a GNU/Linux system with sizeof(sun_path) == 108 anyway. I ran some tests where no gpg-agent was initially running, on a system where "/run/user/$(id -u)" is not present, and where $XDG_RUNTIME_DIR is not set. I tried varying the length (as the environment variable $SOCKLEN) of standard gpg-agent socket: echo "XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR" export GNUPGHOME=/tmp/gnupg-home-test/$(python -c "print(\"a\"*($SOCKLEN-34))") mkdir -p -m 0700 "$GNUPGHOME" echo "GNUPGHOME=$GNUPGHOME" ls -la "$(gpgconf --list-dir agent-socket)" gpgconf --list-dir agent-socket wc -c <<<"$(gpgconf --list-dir agent-socket)" gpg-connect-agent "getinfo pid" "killagent" /bye In tests where the path (including NUL terminator) is less than 100 chars, gpg-connect-agent succeeded. In tests where the path (including NUL terminator) is between 100 and 107 chars long (inclusive), gpg-connect-agent fails after a 5 second timeout with: gpg-connect-agent: can't connect to the agent: IPC connect call failed when the path (including NUL terminator) is 108 chars long, gpg-connect-agent fails after a 5 second timeout with: gpg-connect-agent: can't connect to the agent: File name too long Some questions: * why is it failing for paths between 100 and 107 ? Is that because other socket paths are longer than agent-socket, and gpg-agent is failing to launch because *any* of those sockets are too long? If so, can gpg-connect-agent be smarter about that? * why does gpg-connect-agent need to wait 5 seconds to time out if it already knows that the file name is too long? These are subtle issues that might be hard to fix immediately. I'd like to file some record of them in https://dev.gnupg.org/ to make sure they don't get lost. I'm not sure which of the many points in this message deserve their own issue reference, though. let me know if you have a preference. Regards, --dkg [0] see the thread around recent Message-ID: <87r27z63uk.fsf at ra.horus-it.com>, Subject: "[PATCH] configure: fix mktemp call for macOS" on https://notmuchmail.org/pipermail/notmuch/2019/ From look at my.amazin.horse Mon Jun 17 21:37:05 2019 From: look at my.amazin.horse (Vincent Breitmoser) Date: Mon, 17 Jun 2019 21:37:05 +0200 Subject: DCO for Vincent Breitmoser Message-ID: <2NCEJGBWJ50CC.27Q79A9TPP9LT@my.amazin.horse> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 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: Vincent Breitmoser -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE1KsZKWT3an+Pips1e9GDIN6t+hEFAl0H614ACgkQe9GDIN6t +hHxHA/+IAkiWOpqlDGiGEvy4TvJuhZeZO4TOZ2YFsygL29+bCmYQ6hh4LvpDaQ7 AB0iTe5Co5r3jHdk3538BB6CNyV6gz8fe7uQL496gOKCloRVDbVhCv8G6I+B+HTj EbFtgVKIpepJ7GlKLtHDcjO1L7a8MW8t2YrsaJ7Viqd0b33q8KxyBcOK95Qya+nz 086F1GAb8U5AR3gH51y9CJl4zVpAVOfO6xxLh/MHHcnNh+ihpf6w73YDi5/QK0Ar pSjdrzOkujk6LYTdWIkh5OnfSF8vWYvsLI9zfjRoeIzMWFumvhKsNF3/7mb0w+Cf 4r9cI/rb083Nnz9fNOcqHpSGW9L4K78i6KwVGPKHDMNBbgHW7TDBVqgvRT/X0SBo X2pyf+0hEWyy2cRgHssTfwWd1WIKCR/YktXgzahT7SlIYFhP/fNwOoRCiFHcRzWs 3oMcMa62RGHxzW7NDyYacOw0HpmrJ+9PwFt3qiV8pPBx9l8Gmrz6fDPUDm3++/Jx Ve15mSIP5h9YvczaoGRY8VfwfxZNLM2wVO8XvWFpOwol9PKRVeajiAZAgeb1OtU5 AJyz3lSU54SmFWScJdvxbh5bowqIxpTV1DtMCn58NVaMP+3o5n+DZZnrsuYVD6Kj ezGjMY6EgCvE8x8z5slsDfvzp0paIhKSVHd14qx7VWiaMyIWlbg= =szB4 -----END PGP SIGNATURE----- From dirk.gottschalk1980 at googlemail.com Tue Jun 25 13:19:24 2019 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Tue, 25 Jun 2019 13:19:24 +0200 Subject: DCO for Dirk Gottschalk Message-ID: Hello all. I don't remember if I habe already posted a DCO. But, since I am planning to make a few code contributions and share some modifications I made for myself, here comes a DCO. If I already sent one, simply take this as "renewal". :D Regards, Dirk -- Dirk Gottschalk GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380 Keybase: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 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: Dirk Gottschalk -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEQngfygNammNBZs4RdUQK2UmW84AFAl0SAiUACgkQdUQK2UmW 84CC8A//VLKzTAA/si9LO3DTnTbD/nQVuWlirokZwFm3yrX4c2vjbCmOy/hlWkLO CfQr8cOBhKIPCZ7OaKeKdg2DTIZBjKz9ZmJDfHkZ6QZrLOY0Dg3rVGTJdYt0VqR0 bDQHlRGJOC7FWpKrZ8EwIV5wjAjI3I0nvrojj4DjYhbW6c26C1KM1i2VOQvWiXVm juOvrX+7PFdmJBMhWfcq9lBKnHHTKb4W8o02oOy8jBVbEJAaBLi/0mMzMZRj+RGG CIWvBQcnx0ALBFFKmBJFV91wGDBMttczQQxzeLU/QLzwq0GmD37Y/064AUbV7SDo h7Ryzxd6jMbfylGcSfWWRza5u6NivQzLu1TFmiS2McArwGQT69D9hJgE0DuJAzX9 JrKUWO/GNmoJR8NsctEd3wYZsIqMTHhzsYLvl9VLJxb1Ud56TR+SYusuC+QsUnkX qTlCTtSpvsBsE37jSlFYE7KiNmIs3tLYtFF3RGXzppAvI6DorXOYPO63KifoL+K3 8JPaUHSctX7Ol+3aJjR79q8MEvDZKny1eO5mwAghNkubtfWsoaks+azjVqjluHGc qvCrcNRco+WCsPfC45y4ZdBhXEASEpT7W5JJbmq/EzUUFebaK2qQL9vK2YP8cB5t 5RXPTGk6hu4+MPbz0fru57u8WhuiD39sOvRsau2TGfvFu3ISJ3w= =92SF -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From gniibe at fsij.org Wed Jun 26 05:13:50 2019 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 26 Jun 2019 12:13:50 +0900 Subject: pinentry-tty: Line editing support (just like --loopback-mode)? Message-ID: <87pnn13uoh.fsf@iwagami.gniibe.org> Hello, For the bug report of https://dev.gnupg.org/T4583 , I realized that line editing of password is not supported well. I think that in pinentry-tty, line editing should be supported just like what GnuPG's does with tty_get_hidden function (only disabling echo, but keep enabling line editing by ICANON). I'm asking, because it will be a major change: it will be impossible for a user of pinentry-tty to input some (control) characters. When a user intentionally uses some (control) characters on purpose, and that's a reason why the user uses pinentry-tty, it will be a regression. Well, on a System V R3 machine, I once changed my password to include '#' character in a user session. After logout of the session... In the TTY discipline at the login prompt, '#' was the erase character. So, I lost a way to input my password. (IIRC, there was no lnext character support.) It was more than 20 years ago... -- From gusnan at librem.one Thu Jun 27 17:59:15 2019 From: gusnan at librem.one (Andreas Ronnquist) Date: Thu, 27 Jun 2019 17:59:15 +0200 Subject: DCO for Andreas =?UTF-8?B?UsO2bm5xdWlzdA==?= Message-ID: <20190627175915.72baa843@debian-i7> 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: Andreas R?nnquist -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signatur URL: From wiktor at metacode.biz Sun Jun 30 21:36:56 2019 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Sun, 30 Jun 2019 21:36:56 +0200 Subject: Order of lookup methods in --auto-key-retrieve Message-ID: <6ad755d0-55b4-07fb-0bd6-4dd664839053@metacode.biz> Hello, One of the lesser known things is that gpg can utilize Web Key Directory lookup when verifying signatures made to unknown keys: $ curl -sSL https://metacode.biz/.well-known/security.txt | gpg --auto-key-retrieve --verify gpg: Signature made Sun Jun 24 18:24:28 2018 UTC gpg: using RSA key 59A29DEA8D37388C656863DFB97A1EE09DB417EC gpg: issuer "wiktor at metacode.biz" gpg: requesting key B97A1EE09DB417EC from hkp server 127.0.0.1 gpg: key 6C8857E0D8E8F074: public key "..." imported gpg: Total number processed: 1 gpg: imported: 1 gpg: Good signature ... The code checks first the keyserver and then the WKD domain. I guess this is to limit the number of IP-leaking queries and prefer trusted keyserver. I'm wondering if reversing the order (first WKD, then keyserver) wouldn't be a better option. The current mechanism is not perfect, so that the IP-leaking could still be triggered by attacker by using a brand new key (that is not published on keyservers). On the other hand trying WKD first would allow the key holder to return a good key even if the key was spammed on keyservers to the point of not being usable. I did think about this scenario after reading SKS Keyserver Network Attack: Consequences [0] post: > What's important is my instructions told them to check the digital signature. And today, if they do this it is overwhelmingly likely they'll get a poisoned certificate from the keyserver network and their GnuPG installation will break horribly. GnuPG first trying WKD when verifying signatures would prevent this specific issue. Kind regards, Wiktor [0]: https://gist.github.com/rjhansen/f716c3ff4a7068b50f2d8896e54e4b7e -- https://metacode.biz/@wiktor