From bjk at luxsci.net Sun Jan 1 01:04:20 2017 From: bjk at luxsci.net (Ben Kibbey) Date: Sat, 31 Dec 2016 19:04:20 -0500 Subject: [PATCH] Add ability to specify a subkey. Message-ID: <1483229101-3908919.47615372.fv0104L03007020@rs146.luxsci.com> Hello, I'm not sure if this is the right way to go about it, but attached is a patch to allow specifying of a specific subkey to be used for signing or encryption. It allows for the use of gpg's handling of '!' at the end if a keyid or fingerprint. It's up to the user to set the .exact member of gpgme_subkey_t to have the '!' appended before calling gpg otherwise it maintains the original behavior of leaving it up to gpg to decide which key to use. Thanks, -- Ben Kibbey -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-ability-to-specify-a-subkey.patch Type: text/x-diff Size: 3956 bytes Desc: not available URL: From wk at gnupg.org Mon Jan 2 10:14:48 2017 From: wk at gnupg.org (Werner Koch) Date: Mon, 02 Jan 2017 10:14:48 +0100 Subject: Keyserver problems in 2.1.17 Message-ID: <87zij9g6wn.fsf@wheatstone.g10code.de> Hello and a happy new year. Unfortunately the recent 2.1.17 has a problem with keyserver access. The cause for the problem is the new DNS code which appends the root zone part (".") to the result of a CNAME query. Most of the other network functions don't work correctly with such a name and thus almost all keyserver access does not work. There is a simple workaround and probably one of the reasons why I missed this regression: With Tor running the default keyserver will be hkp://jirk5u4osbsr34t5.onion and that does not need any DNS. The fix has been pushed and is attached. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-dirmngr-Strip-root-zone-suffix-from-libdns-cname-res.patch Type: text/x-diff Size: 1545 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Mon Jan 2 10:37:52 2017 From: wk at gnupg.org (Werner Koch) Date: Mon, 02 Jan 2017 10:37:52 +0100 Subject: use-tor should not imply allow-version-check In-Reply-To: <8760m24dmm.fsf@stebalien.com> (Steven Allen's message of "Thu, 29 Dec 2016 13:41:21 -0800") References: <8760m24dmm.fsf@stebalien.com> Message-ID: <878tqtg5u7.fsf@wheatstone.g10code.de> Hi! On Thu, 29 Dec 2016 22:41, steven at stebalien.com said: > For some reason, dirmngr's use-tor option implies allow-version-check. Right. The reason for the --allow-version-check option is that a GnuPG should not by default leak information (here an IP address running GnuPG). With Tor being enabled, all network access goes via Tor and thus nothing should leak. BTW, the man page entry: --use-tor This option switches Dirmngr and thus GnuPG into ``Tor mode'' to route all network access via Tor (an anonymity network). WARNING: As of now this still leaks the DNS queries; e.g. to lookup the hosts in a keyserver pool. Certain other features are disabled if this mode is active. is wrong: DNS queries are meanwhile routed via Tor. > Note: These update checks are *not* made over TOR. They are. If you follow the code you get to this: err = http_open (&http, HTTP_REQ_GET, url, /* httphost */ NULL, /* fixme: AUTH */ NULL, ((opt.honor_http_proxy? HTTP_FLAG_TRY_PROXY:0) | (opt.use_tor? HTTP_FLAG_FORCE_TOR:0)), /* ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ */ ctrl->http_proxy, session, NULL, /*FIXME curl->srvtag*/NULL); and in http.c you will find: if ((hd->flags & HTTP_FLAG_FORCE_TOR)) { int mode; if (assuan_sock_get_flag (ASSUAN_INVALID_FD, "tor-mode", &mode) || !mode) { log_error ("Tor support is not available\n"); return gpg_err_make (default_errsource, GPG_ERR_NOT_IMPLEMENTED); } } which makes sure that an error is returned if Tor is not available. The assuan library has socket function call wrappers which takes care of routing connections via Tor. Tor mode itself is enabled at dirmngr startup and on reload by telling libassuan about it: static void set_tor_mode (void) { if (opt.use_tor) { if (assuan_sock_set_flag (ASSUAN_INVALID_FD, "tor-mode", 1)) { log_error ("error enabling Tor mode: %s\n", strerror (errno)); log_info ("(is your Libassuan recent enough?)\n"); } } } Shalom-Salam, 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: 227 bytes Desc: not available URL: From aheinecke at intevation.de Mon Jan 2 13:17:57 2017 From: aheinecke at intevation.de (Andre Heinecke) Date: Mon, 02 Jan 2017 13:17:57 +0100 Subject: [PATCH] GPGME: Always use --runtime for gpgconf changes Message-ID: <82435249.ItlQ9g02Eb@esus> Hi, If a tool uses GPGME for changing configuration values it needs a way to ensure that these changes take effect. Otherwise users may change and see config values and do not understand why they are not working. Kleopatra did this in the past but since switching to GPGME based gpgconf API, adding an additional --runtime is no longer possible. Instead of an Option for this I think --runtime should always be called as I can't think of a usecase where a GPGME user would want to change a configuration value and not have that change take effect immediately. 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-core-Always-use-runtime-for-gpgconf-changes.patch Type: text/x-patch Size: 968 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From aheinecke at intevation.de Mon Jan 2 15:01:52 2017 From: aheinecke at intevation.de (Andre Heinecke) Date: Mon, 02 Jan 2017 15:01:52 +0100 Subject: [PATCH] GPGME: Always use --runtime for gpgconf changes In-Reply-To: <82435249.ItlQ9g02Eb@esus> References: <82435249.ItlQ9g02Eb@esus> Message-ID: <6130775.LFEuYbrQFQ@esus> FTR: Werner agreed to the patch and I pushed it with a small fix (correcly increasing the array size). https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=commit;h=7103315829847163f1c6f52cad25d1ddb33358f0 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: 659 bytes Desc: This is a digitally signed message part. URL: From steven at stebalien.com Mon Jan 2 18:48:44 2017 From: steven at stebalien.com (Steven Allen) Date: Mon, 02 Jan 2017 09:48:44 -0800 Subject: use-tor should not imply allow-version-check In-Reply-To: <878tqtg5u7.fsf@wheatstone.g10code.de> References: <8760m24dmm.fsf@stebalien.com> <878tqtg5u7.fsf@wheatstone.g10code.de> Message-ID: <87r34l1hfn.fsf@stebalien.com> Werner Koch writes: > Right. The reason for the --allow-version-check option is that a GnuPG > should not by default leak information (here an IP address running > GnuPG). With Tor being enabled, all network access goes via Tor and > thus nothing should leak. That doesn't really explain why enabling tor *should* imply update checks. I use a GNU/Linux distribution so I get all my updates through my package manager. I'd rather not have any of my applications checking for updates. >> Note: These update checks are *not* made over TOR. > > They are. Maybe it's not the update check? Dirmngr has been periodically opening a direct TCP connections to 217.69.76.56 on port 443 even when `use-tor` is specified in `~/.gnupg/dirmngr.conf` (according to my mandatory access control system, Tomoyo). From mcrha at redhat.com Mon Jan 2 18:37:04 2017 From: mcrha at redhat.com (Milan Crha) Date: Mon, 02 Jan 2017 18:37:04 +0100 Subject: Running without pinentry (related to issue #2680) Message-ID: <1483378624.16308.2.camel@redhat.com> Hello, I've been asked to rise a concern about pinetry availability in Issue2680, https://bugs.gnupg.org/gnupg/issue2680 I've made a pretty long story in a downstream bug report [1], I can copy it here, if you prefer. In short, there's a problem when a user calls gpg/gpg2 without any pinentry implementation being installed. The error message I get with gnupg2 2.1.17-1.fc26 and pinentry 0.9.7-2.fc24 is "gpg: signing failed: Inappropriate ioctl for device". I'm pretty sure that I'll forget about it soon, thus when other users will report a similar issue it'll mean to reinvestigate it. I mean, a better error message would be useful in the situation when no pinentry implementation could be found. This is when calling gpg/gpg2 from an evolution-data-server, namely its libcamel library. While the downstream bug report [1] suggests to add a package dependency to the evolution itself, I do not think it'll work, because the libcamel can be used by anything, either through its C API, or through introspection bindings. Adding the pinentry implementation dependency into the evolution-data-server doesn't sound right, also because it is desktop environment independent (the same as the Evolution), thus it's pretty hard to choose "the right implementation", because the respective applications (including the Evolution), can run in any desktop environment, thus picking a wrong implementation would cause just a bad user experience. For example Fedora offers emacs, gnome3, gtk and qt pinentry implementations. Werner asked whether the evolution (-data-server) uses GPGME these days. The last time I tried, which is about a year ago, it didn't fit the needs of the libcamel, thus the answer is no. I do not recall what exactly was missing, I'm sorry, it's too long time. I always understood the GPGME as an interface on top of the gpg/gpg2 calls, which is a good thing to have (thus one doesn't need to reimplement the calls and the overhead on top of them), but it has also its limitations. The main difference with libcamel might be that the libcamel has its own routines on top of it done already. Anyway, the main question is what to do when there is no pinentry implementation installed. Having a better error message is a good starting point, where Werner wrote in the Issue2680 that the newer pinentry will make it better (note I had installed the proper gnupg2, but not the pinentry). The libcamel can do password prompts on its own too, thus a GET_HIDDEN or similar could be requested by the gpg2 when no pinentry implementation was found. The side effect of it would be that the pinentry will not be tight to the desktop, but it will be tight to the window which requested it, which is a good thing to do, from my point of view. Werner mentioned "--pinentry-mode=loopback", but I do not know how much backward compatible it is (the libcamel has no version limitation on the gpg itself). Having it done by default, without a need to specify the parameter, might be better, from my point of view. Another option is to deal with this on the packaging level, but it is hard to pick the right pinentry implementation and apart of many other things, it requires a coordination between distributions. Maybe I do this overcomplicated. I'm sorry if I do. It's just that I see many "easy to break" things in any implementation which would be done on the application side (a user of gpg/gpg2). Bye, Milan [1] https://bugzilla.redhat.com/show_bug.cgi?id=1362477#c37 and the next comment. From wk at gnupg.org Tue Jan 3 13:28:01 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 03 Jan 2017 13:28:01 +0100 Subject: use-tor should not imply allow-version-check In-Reply-To: <87r34l1hfn.fsf@stebalien.com> (Steven Allen's message of "Mon, 02 Jan 2017 09:48:44 -0800") References: <8760m24dmm.fsf@stebalien.com> <878tqtg5u7.fsf@wheatstone.g10code.de> <87r34l1hfn.fsf@stebalien.com> Message-ID: <874m1gfhv2.fsf@wheatstone.g10code.de> On Mon, 2 Jan 2017 18:48, steven at stebalien.com said: > That doesn't really explain why enabling tor *should* imply update > checks. I use a GNU/Linux distribution so I get all my updates through It is the other way around: GnuPG does update its copy of the software version database by default. However, for privacy reason it can do this only if that does not leak the IP address. With Tor this is asserted. Without Tor this is not possible and like we have always for done features (e.g. OCSP) the user is required to enable an option. > Maybe it's not the update check? Dirmngr has been periodically opening > a direct TCP connections to 217.69.76.56 on port 443 even when `use-tor` I can't replicate that. I tested with "use-tor" and Tor running and Tor not running. All worked as expected: I can see traffic to versions.gnupg.org ("tcpick -i eth0 -C -yP -h 'host 217.69.76.56'") only when use-tor is not active. I have not tested with running the TorBrowser only, though. Note that versions.gnupg.org is currently a CNAME to git.gnupg.org. However, while testing I noticed that when you add "use-tor" to dirmngr.conf and SIGHUP dirmngr (e.g. "gpgconf --reload dirmngr"), Tor is indeed not used for DNS. This has been fixed today. 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: 227 bytes Desc: not available URL: From dgouttegattat at incenp.org Tue Jan 3 15:52:37 2017 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Tue, 3 Jan 2017 15:52:37 +0100 Subject: [PATCH] gpg: Avoid using XDG_RUNTIME_DIR as socketdir. Message-ID: <20170103145237.11990-1-dgouttegattat@incenp.org> * common/homedir.c (_gnupg_socketdir_internal): Check that the directory under [/var]/run/user is not set as XDG_RUNTIME_DIR. * tools/gpgconf.c (main): Report avoidance of XDG_RUNTIME_DIR. -- We do not want to put the sockets in XDG_RUNTIME_DIR because the XDG Base Directory specification says the directory is to be removed when the user logs out. Unfortunately, on some GNU/Linux distributions XDG_RUNTIME_DIR happens to be set to /run/user/$UID; we should then avoid using that directory if we do not want our sockets to be forcibly removed. Signed-off-by: Damien Goutte-Gattat --- common/homedir.c | 7 +++++++ tools/gpgconf.c | 1 + 2 files changed, 8 insertions(+) diff --git a/common/homedir.c b/common/homedir.c index 6b40bb6..a57ab25 100644 --- a/common/homedir.c +++ b/common/homedir.c @@ -448,6 +448,7 @@ gnupg_default_homedir_p (void) * 32 := Non default homedir; checking subdir. * 64 := Subdir does not exist. * 128 := Using homedir as fallback. + * 256 := /run/user directory is the same as XDG_RUNTIME_DIR. */ char * _gnupg_socketdir_internal (int skip_checks, unsigned *r_info) @@ -501,6 +502,12 @@ _gnupg_socketdir_internal (int skip_checks, unsigned *r_info) goto leave; } + if ((s = getenv ("XDG_RUNTIME_DIR")) && !strcmp (s, prefix)) + { + *r_info |= 256; /* Same directory as XDG_RUNTIME_DIR. */ + goto leave; + } + if (strlen (prefix) + 7 >= sizeof prefix) { *r_info |= 1; /* Ooops: Buffer too short to append "/gnupg". */ diff --git a/tools/gpgconf.c b/tools/gpgconf.c index af65424..5f24d9c 100644 --- a/tools/gpgconf.c +++ b/tools/gpgconf.c @@ -721,6 +721,7 @@ main (int argc, char **argv) if ((flags & 32)) log_info ("\tnon-default homedir\n"); if ((flags & 64)) log_info ("\tno such subdir\n"); if ((flags & 128)) log_info ("\tusing homedir as fallback\n"); + if ((flags & 256)) log_info ("\tavoiding XDG_RUNTIME_DIR\n"); } if ((flags & ~32) && !opt.dry_run) -- 2.9.0 From ilf at zeromail.org Tue Jan 3 18:04:05 2017 From: ilf at zeromail.org (ilf) Date: Tue, 3 Jan 2017 18:04:05 +0100 Subject: release notes on website? Message-ID: <20170103170405.GA4996@zeromail.org> It seems the website has no release notes of current releases. https://gnupg.org/news.html - last update 2015-12-2 https://gnupg.org/download/release_notes.html - last update 2013-08-19 It seems the definite source is https://lists.gnupg.org/mailman/listinfo/gnupg-announce Werner: Do you think the release process could include an update to those sites? If not, do we want to remove those websites and instead link to the list? -- ilf ?ber 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes f?r Tastaturbenutzung -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From dkg at fifthhorseman.net Tue Jan 3 19:01:15 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 03 Jan 2017 13:01:15 -0500 Subject: [PATCH] gpg: Avoid using XDG_RUNTIME_DIR as socketdir. In-Reply-To: <20170103145237.11990-1-dgouttegattat@incenp.org> References: <20170103145237.11990-1-dgouttegattat@incenp.org> Message-ID: <87zij8kopg.fsf@alice.fifthhorseman.net> On Tue 2017-01-03 09:52:37 -0500, Damien Goutte-Gattat wrote: > * common/homedir.c (_gnupg_socketdir_internal): Check that the > directory under [/var]/run/user is not set as XDG_RUNTIME_DIR. > * tools/gpgconf.c (main): Report avoidance of XDG_RUNTIME_DIR. > -- > > We do not want to put the sockets in XDG_RUNTIME_DIR because > the XDG Base Directory specification says the directory is to > be removed when the user logs out. Unfortunately, on some > GNU/Linux distributions XDG_RUNTIME_DIR happens to be set to > /run/user/$UID; we should then avoid using that directory if > we do not want our sockets to be forcibly removed. I disagree with this proposal -- we actually *do* want to use the directory that gets removed when the user logs out. combined with detection of socket removal, this provides reasonably simple, automatic daemon cleanup at logout without any additional configuration or system integration work. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From dgouttegattat at incenp.org Tue Jan 3 19:12:16 2017 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Tue, 3 Jan 2017 19:12:16 +0100 Subject: [PATCH] gpg: Avoid using XDG_RUNTIME_DIR as socketdir. In-Reply-To: <87zij8kopg.fsf@alice.fifthhorseman.net> References: <20170103145237.11990-1-dgouttegattat@incenp.org> <87zij8kopg.fsf@alice.fifthhorseman.net> Message-ID: <8bf4d6d7-f1ec-b5ae-bc56-fa260a5806b6@incenp.org> On 01/03/2017 07:01 PM, Daniel Kahn Gillmor wrote: > I disagree with this proposal -- we actually *do* want to use the > directory that gets removed when the user logs out. Well, that?s not what this comment in g10/homedir.c appears to say: /* 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. */ So, either we *want* a directory that gets removed when the user logs out, and in that case we should probably use XDG_RUNTIME_DIR (if it is set) instead of hard-coding /run/user/$UID, or we do *not* want to use a directory that gets removed, and in that case I believe it would be better to make sure we do not end up accidentally using such a directory (when XDG_RUNTIME_DIR == /run/user/$UID). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue Jan 3 20:01:54 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 03 Jan 2017 20:01:54 +0100 Subject: [PATCH] gpg: Avoid using XDG_RUNTIME_DIR as socketdir. In-Reply-To: <20170103145237.11990-1-dgouttegattat@incenp.org> (Damien Goutte-Gattat's message of "Tue, 3 Jan 2017 15:52:37 +0100") References: <20170103145237.11990-1-dgouttegattat@incenp.org> Message-ID: <87r34kdl25.fsf@wheatstone.g10code.de> On Tue, 3 Jan 2017 15:52, dgouttegattat at incenp.org said: > We do not want to put the sockets in XDG_RUNTIME_DIR because > the XDG Base Directory specification says the directory is to Although I understand your reasoning I do not like this idea. > + if ((s = getenv ("XDG_RUNTIME_DIR")) && !strcmp (s, prefix)) Checking an envvar in addition to a fixed directory name removes a main advantage of the new socket location, namely a fixed name on the system independent of any user configurable parameters. Also: GnuPG is based on Posix and not on a Desktop oriented specification like XDG. Thus until today we have no dependency in GnuPG on any XDG specs. If that is required the system that uses GnuPG needs to implement this. 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: 227 bytes Desc: not available URL: From wk at gnupg.org Tue Jan 3 20:05:34 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 03 Jan 2017 20:05:34 +0100 Subject: release notes on website? In-Reply-To: <20170103170405.GA4996@zeromail.org> (ilf@zeromail.org's message of "Tue, 3 Jan 2017 18:04:05 +0100") References: <20170103170405.GA4996@zeromail.org> Message-ID: <87mvf8dkw1.fsf@wheatstone.g10code.de> On Tue, 3 Jan 2017 18:04, ilf at zeromail.org said: > Werner: Do you think the release process could include an update to > those sites? If not, do we want to remove those websites and instead Thanks for reminding me about this. I'll update the the web page and will in future take care to add links to the announcement mails. And maybe also add
 sections with the actual news.


Shalom-Salam,

   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: 227 bytes
Desc: not available
URL: 

From steven at stebalien.com  Tue Jan  3 23:27:34 2017
From: steven at stebalien.com (Steven Allen)
Date: Tue, 03 Jan 2017 14:27:34 -0800
Subject: use-tor should not imply allow-version-check
In-Reply-To: <874m1gfhv2.fsf@wheatstone.g10code.de>
References: <8760m24dmm.fsf@stebalien.com>
 <878tqtg5u7.fsf@wheatstone.g10code.de> <87r34l1hfn.fsf@stebalien.com>
 <874m1gfhv2.fsf@wheatstone.g10code.de>
Message-ID: <87eg0jlqy1.fsf@stebalien.com>


Werner Koch  writes:
> It is the other way around: GnuPG does update its copy of the software
> version database by default.  However, for privacy reason it can do this
> only if that does not leak the IP address.  With Tor this is asserted.
> Without Tor this is not possible and like we have always for done
> features (e.g. OCSP) the user is required to enable an option.

Given that `use-tor` is off by default (most users don't even have tor
installed), you can't say GnuPG updates the software version database by
default. It does so iff `use-tor' or `allow-version-check' are enabled.
Given that the user has to explicitly enable `use-tor', I see no
advantage to automatically enabling `allow-version-check' with tor
enabled. Anyways, I'd be very surprised if there are *any* users with
`use-tor` enabled that don't update gnupg through a package manager.

Also, does gnupg even use this information? As far as I can tell, this
feature isn't used internally so can't this information be fetched (and
cached) when requested (when something calls `gpgconf --query-swdb')?

Finally, gnupg is now the *only* software on my system that doesn't
allow me to disable automatic update checks and the only daemon that
even supports automatic update checks.

> I can't replicate that.  I tested with "use-tor" and Tor running and Tor
> not running.  All worked as expected: I can see traffic to
> versions.gnupg.org ("tcpick -i eth0 -C -yP -h 'host 217.69.76.56'") only
> when use-tor is not active.  I have not tested with running the
> TorBrowser only, though.


Tomoyo logs (my UID is 1000):

    #2017/01/03 19:54:45# profile=3 mode=enforcing granted=no (global-pid=2051) task={ pid=1360 ppid=389 uid=1000 gid=100 euid=1000 egid=100 suid=1000 sgid=100 fsuid=1000 fsgid=100 }
     /usr/bin/dirmngr
    network inet dgram send 217.69.76.56 443
    
    #2017/01/03 19:54:45# profile=3 mode=enforcing granted=no (global-pid=2051) task={ pid=1360 ppid=389 uid=1000 gid=100 euid=1000 egid=100 suid=1000 sgid=100 fsuid=1000 fsgid=100 }
     /usr/bin/dirmngr
    network inet dgram send 2001:aa8:fff1:2100::56 443
    
    #2017/01/03 19:54:46# profile=3 mode=enforcing granted=no (global-pid=2051) task={ pid=1360 ppid=389 uid=1000 gid=100 euid=1000 egid=100 suid=1000 sgid=100 fsuid=1000 fsgid=100 }
     /usr/bin/dirmngr
    network inet dgram send 217.69.76.56 443
    
    #2017/01/03 19:54:46# profile=3 mode=enforcing granted=no (global-pid=2051) task={ pid=1360 ppid=389 uid=1000 gid=100 euid=1000 egid=100 suid=1000 sgid=100 fsuid=1000 fsgid=100 }
     /usr/bin/dirmngr
    network inet dgram send 2001:aa8:fff1:2100::56 443

dirmngr.conf:

    use-tor
    keyserver hkp://jirk5u4osbsr34t5.onion

gpg-agent.conf:

    pinentry-program /usr/bin/pinentry-gnome3
    no-allow-loopback-pinentry
    no-allow-mark-trusted
    enable-ssh-support
    no-allow-external-cache

gpg.conf:

    # Started by systemd
    no-autostart
    use-agent
    utf8-strings
    trust-model tofu
    auto-key-locate local
    # Just in case?
    keyserver hkp://jirk5u4osbsr34t5.onion
    keyserver-options auto-key-retrieve
    default-key 5899410C

FYI, This isn't related to the TorBrowser. I've installed both tor and
gnupg through my package manager (Arch Linux, gnupg version 2.1.17).

> However, while testing I noticed that when you add "use-tor" to
> dirmngr.conf and SIGHUP dirmngr (e.g. "gpgconf --reload dirmngr"), Tor
> is indeed not used for DNS.  This has been fixed today.

This obviously isn't a DNS request.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: 

From wk at gnupg.org  Wed Jan  4 00:04:28 2017
From: wk at gnupg.org (Werner Koch)
Date: Wed, 04 Jan 2017 00:04:28 +0100
Subject: use-tor should not imply allow-version-check
In-Reply-To: <87eg0jlqy1.fsf@stebalien.com> (Steven Allen's message of "Tue,
 03 Jan 2017 14:27:34 -0800")
References: <8760m24dmm.fsf@stebalien.com>
 <878tqtg5u7.fsf@wheatstone.g10code.de> <87r34l1hfn.fsf@stebalien.com>
 <874m1gfhv2.fsf@wheatstone.g10code.de> <87eg0jlqy1.fsf@stebalien.com>
Message-ID: <87o9znd9tv.fsf@wheatstone.g10code.de>

On Tue,  3 Jan 2017 23:27, steven at stebalien.com said:

> Given that `use-tor` is off by default (most users don't even have tor
> installed), you can't say GnuPG updates the software version database by

Well, okay.

> default. It does so iff `use-tor' or `allow-version-check' are enabled.
> Given that the user has to explicitly enable `use-tor', I see no
> advantage to automatically enabling `allow-version-check' with tor

Privacy aware people will use Tor and thus they should enable --use-tor.
I assume that Tails will enable this by default ;-)

> enabled. Anyways, I'd be very surprised if there are *any* users with
> `use-tor` enabled that don't update gnupg through a package manager.

Actually the Tor support works on Linux only since 2.1.17 unless a non
standard ADNS version was used.  On Windows however, Tor support is
available for a long time and thus we can assume that there are users
who enabled this.  And on Windows we don't have distributions except for
Gpg4win which now uses the version check.

I fully agree that for a Linux distro this is not required.  But see
below.

> Also, does gnupg even use this information? As far as I can tell, this
> feature isn't used internally so can't this information be fetched (and
> cached) when requested (when something calls `gpgconf --query-swdb')?

The idea behind the the SWDB is to provide the latest information of all
packages we provide - for example for users who build on their own.
Thus it can also be used to build software which depends on GnuPG or
GnuPG supported libraries.

Right now the Speedo build system of GnuPG uses the SWDB but only via a
simple script and with no easy way to route this via Tor.  This means
that the admins of versions.gnupg.org (e.g. me and my co-admins) as well
as any snooping TLA could learn the IP addresses of users who build
GnuPG on their own.  Now, as soon as this feature is widely deployed we
can update the Speedo build system to use gpgconf --query-swdb and
things would be easier.  This is why I like to have this service
available as widely as possible.

> Finally, gnupg is now the *only* software on my system that doesn't
> allow me to disable automatic update checks and the only daemon that
> even supports automatic update checks.

GnuPG is not xscreensaver and does not do any update checks on its own.
It only provides a service for other software to implement such a
service.

However, if more folks express a dislike for the
auto-update-swdb-via-tor feature, I am willing to revert this.


Now for the other topic:

>      /usr/bin/dirmngr
>     network inet dgram send 217.69.76.56 443

Okay, so it is indeed dirmngr.
>
> dirmngr.conf:
>
>     use-tor
>     keyserver hkp://jirk5u4osbsr34t5.onion


I do not understand what is going on here.  Can we take this offlist to
figure out what is going on on your box?


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: 227 bytes
Desc: not available
URL: 

From wk at gnupg.org  Wed Jan  4 18:52:38 2017
From: wk at gnupg.org (Werner Koch)
Date: Wed, 04 Jan 2017 18:52:38 +0100
Subject: release notes on website?
In-Reply-To: <20170103170405.GA4996@zeromail.org> (ilf@zeromail.org's message
 of "Tue, 3 Jan 2017 18:04:05 +0100")
References: <20170103170405.GA4996@zeromail.org>
Message-ID: <87o9zmbtll.fsf@wheatstone.g10code.de>

On Tue,  3 Jan 2017 18:04, ilf at zeromail.org said:
> It seems the website has no release notes of current releases.

I have updated https://gnupg.org/download/release_notes.html with the
release notes from master.  This also includes links to most
announcement mails.

The URLs are not final: I plan to split the page so that we have
separate pages for each project and major branch.  This will allow to
have stable URLs like

  https://gnupg.org/download/news-gnupg.html#gnupg-2.1.17

> Werner: Do you think the release process could include an update to
> those sites? If not, do we want to remove those websites and instead

My plan is to let the web builder script fetch the NEWS and render it
into HTML.  The basic render script is already there but may need some
updates for the NEWS of Libgcrypt and GPGME.


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: 227 bytes
Desc: not available
URL: 

From bernhard at intevation.de  Thu Jan  5 16:55:57 2017
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 5 Jan 2017 16:55:57 +0100
Subject: Problems with pip install gpg
In-Reply-To: 
References: 
 
Message-ID: <201701051656.01278.bernhard@intevation.de>

Hello,
for what it is worth: I agree that we should make a reasonable effort
to support standard work-flows that python devs might try.

Some background:
https://packaging.python.org/distributing/ ist the official guide
how to "configure, package and distribute your own" Python products.
The Binary Extensions section is incomplete and states
"FIXME mention the fact that Linux distros have a requirement to build from
source in their own build systems anyway, so pre-built binaries for
*nix systems currently aren't common"

pip is a standard-tool, so it is good that our python gpgme module tries to 
use its conventions for the features it is offering.

I also consider it fine for a python module to demand a larger dependency to 
be already installed. (Example 
https://github.com/pyldap/pyldap/blob/master/setup.cfg
{{{
# These defines needs OpenLDAP built with
# ./configure --with-cyrus-sasl --with-tls
}}}
)

Am Dienstag 27 Dezember 2016 00:49:44 schrieb Bjarni Runar Einarsson:
> The other option, making the wrapper backwards compatible, so you
> can download the latest wrapper from pip, but build it against
> whatever older version of libgpgme your distribution is currently
> shipping

Another alternative:
What about getting better instructions how to get a gpgme  for the platform in 
the pip message? A link to a wiki page that offers current packages for a 
number of distros would be really helpful.

For example: A gpgme build for Debian Jessie and Ubuntu 14.04 and 16.04 LTS 
(and the other included libraries) would be cool.

This seems useful not just for python users, but for all people that would 
like to use a newer gpgme.

Best Regards,
Bernhard

-- 
www.intevation.de/~bernhard ? +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 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: 473 bytes
Desc: This is a digitally signed message part.
URL: 

From bernhard at intevation.de  Thu Jan  5 17:07:58 2017
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 5 Jan 2017 17:07:58 +0100
Subject: pubkey_encrypt failed: Provided object is too short (with 2.1.11 and
 Werner's new subkeys)
Message-ID: <201701051708.02493.bernhard@intevation.de>

This is to document a difficulty.

As it is for a specific GnuPG version and Werner's new subkey
it may or may not be interesting to others. Thus I am not opening a report in 
the tracker right away.

== Observations
With gnupg 2.1.11 libgcrypt 1.6.5 using
pub   dsa2048/F2AD85AC1E42B367 2007-12-31 Werner Koch 
 Primary key fingerprint: 8061 5870 F5BA D690 3336  86D0 F2AD 85AC 1E42 B367

LANG=C gpg2 -e -v -r 29D746E5560A3555 x 
failed with 
gpg: using subkey 7F3B7ED4319BCCA8 instead of primary key F2AD85AC1E42B367
gpg: pubkey_encrypt failed: Provided object is too short
gpg: x: encryption failed: Provided object is too short
(or general error when viewing from kmail).

Using several variations of --disable-pubkey-algo=ECDSA or selecting the RSA
subject as recipient could not make the problem go away.

when using --edit the general error was seen when computing the keygrip
on the cv25519 encryption key:
gpg: error computing keygrip
gpg: error computing a keygrip: Allgemeiner Fehler
sub  cv25519/7F3B7ED4319BCCA8
     erzeugt: 2017-01-01  verf?llt: 2018-12-30  Aufruf: E   

== Workaround
deleting the problematic subkey

Using --edit
  key 7F3B7ED4319BCCA8
  delkey
could make m

== Why GnuPG 2.1.11?
On some systems I do not have  the most recent release because those release 
can be problematic on their own ways (example the keyserver and 32bit 
problems of 2.1.17). Hopefully the defect is already fixed, still I've found 
others seem to have the problem, too. 
GnuPG 2.0 worked for me, as the keygrip computing seems to be skipped
for this subkey.

== Details

LANG=C gpg2 --version
gpg (GnuPG) 2.1.11
libgcrypt 1.6.5

Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2


-- 
www.intevation.de/~bernhard ? +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 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: 473 bytes
Desc: This is a digitally signed message part.
URL: 

From wk at gnupg.org  Thu Jan  5 20:02:57 2017
From: wk at gnupg.org (Werner Koch)
Date: Thu, 05 Jan 2017 20:02:57 +0100
Subject: pubkey_encrypt failed: Provided object is too short (with 2.1.11
 and Werner's new subkeys)
In-Reply-To: <201701051708.02493.bernhard@intevation.de> (Bernhard Reiter's
 message of "Thu, 5 Jan 2017 17:07:58 +0100")
References: <201701051708.02493.bernhard@intevation.de>
Message-ID: <8760lt8h3y.fsf@wheatstone.g10code.de>

On Thu,  5 Jan 2017 17:07, bernhard at intevation.de said:

> With gnupg 2.1.11 libgcrypt 1.6.5 using

> when using --edit the general error was seen when computing the keygrip
> on the cv25519 encryption key:

These versions are too old, or better the combination does not work.
Get a recent one.

> == Why GnuPG 2.1.11?
> On some systems I do not have  the most recent release because those release 
> can be problematic on their own ways (example the keyserver and 32bit 
> problems of 2.1.17). Hopefully the defect is already fixed, still I've found 

There is not 32 bit problem in 2.1.7.  A fix for the keyserver has been
posted and 2.1.16 still works weel.


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: 227 bytes
Desc: not available
URL: 

From bernhard at intevation.de  Fri Jan  6 09:24:00 2017
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 6 Jan 2017 09:24:00 +0100
Subject: pubkey_encrypt failed: Provided object is too short (with 2.1.11
 and Werner's new subkeys)
In-Reply-To: <8760lt8h3y.fsf@wheatstone.g10code.de>
References: <201701051708.02493.bernhard@intevation.de>
 <8760lt8h3y.fsf@wheatstone.g10code.de>
Message-ID: <201701060924.00656.bernhard@intevation.de>

Am Donnerstag 05 Januar 2017 20:02:57 schrieb Werner Koch:
> > With gnupg 2.1.11 libgcrypt 1.6.5 using

I know that this combination is old and probably superceded by a better one.
(This is why I've pointed it out in two places of my post.)

> > == Why GnuPG 2.1.11?
> > On some systems I do not have  the most recent release because those
> > release can be problematic on their own ways (example the keyserver and
> > 32bit problems of 2.1.17). Hopefully the defect is already fixed, still
> > I've found
>
> There is no 32 bit problem in 2.1.17.  

Thanks for clarification, I had browsed some emails and thought I've seen 
problems with the test suite in the 2.1.17 tarball on 32 bit. But I did not 
look closely.

> A fix for the keyserver has been posted and 2.1.16 still works well.

So the current recommendation is to use 2.1.16 until 2.1.18 is out
or apply the keyserver fix...

It shows my point: sometimes (some people on some systems) cannot immedeately 
switch to the most recent version because there may be other problems with 
it. Overall this is fine as 2.1. is "modern" and we need to make progress, so 
people should switch to the latest 2.1. to give it some testing. However it 
may make my observation interesting to some folks.


-- 
www.intevation.de/~bernhard ? +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 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: 473 bytes
Desc: This is a digitally signed message part.
URL: 

From bernhard at intevation.de  Fri Jan  6 09:51:06 2017
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 6 Jan 2017 09:51:06 +0100
Subject: error computing keygrip on cv25519 for some combinations (was:
 pubkey_encrypt failed: Provided object is too short (with 2.1.11 and Werner's
 new subkeys))
In-Reply-To: <201701060924.00656.bernhard@intevation.de>
References: <201701051708.02493.bernhard@intevation.de>
 <8760lt8h3y.fsf@wheatstone.g10code.de>
 <201701060924.00656.bernhard@intevation.de>
Message-ID: <201701060951.06581.bernhard@intevation.de>

Am Freitag 06 Januar 2017 09:24:00 schrieb Bernhard Reiter:
> Am Donnerstag 05 Januar 2017 20:02:57 schrieb Werner Koch:
> > > With gnupg 2.1.11 libgcrypt 1.6.5 using
>
> I know that this combination is old and probably superceded by a better
> one. (This is why I've pointed it out in two places of my post.)

I've got a report that GnuPG 2.1.13 with libgcrypt 1.6.6 on Fedora 25
also has this problem that it believes to have the ability to cope with 
the sub  cv25519 encryption key, but fails to compute the keygrip.
Leading to an unspecific general error.

-- 
www.intevation.de/~bernhard ? +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 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: 473 bytes
Desc: This is a digitally signed message part.
URL: 

From neal at walfield.org  Fri Jan  6 11:09:10 2017
From: neal at walfield.org (Neal H. Walfield)
Date: Fri, 06 Jan 2017 11:09:10 +0100
Subject: scdaemon (possible?) lockup
In-Reply-To: <2895786.MrMUTlrYWz@calvin>
References: <7455218.qWm7FkoZvf@calvin> <1608676.0hxiHEBEbY@calvin>
 <0add0c76-e801-844d-a27f-314f3172fb01@fsij.org>
 <2895786.MrMUTlrYWz@calvin>
Message-ID: <87zij48pq1.wl-neal@walfield.org>

Hi Fabio,

On Wed, 05 Oct 2016 09:40:39 +0200,
Fabio Coatti wrote:
> In data mercoled? 5 ottobre 2016 16:32:02 CEST, NIIBE Yutaka ha scritto:
> > On 10/05/2016 04:07 PM, Fabio Coatti wrote:
> > > 1. for some reason, when scd enters the "card error status" he can't
> > > get off until reloaded.
> > 
> > Perhaps related somehow, scdaemon had a bug about card removal
> > handling.  It was fixed in:
> > 
> >     f9e49c80e706a27d5e30d4b3237ff26367a67130
> >     Author:     NIIBE Yutaka 
> >     AuthorDate: Sat Sep 3 15:27:30 2016 +0900
> > 
> > It will be included in the next release (2.1.16).
> > 
> 
> I will be happy to test it, maybe when the new version will be ready or even 
> before, if I find the time to install it.

The patch was included in 2.1.16, which was released in mid-November.
Did it resolve the issue for you?

Thanks again for reporting this!

:) Neal


From neal at walfield.org  Fri Jan  6 11:47:46 2017
From: neal at walfield.org (Neal H. Walfield)
Date: Fri, 06 Jan 2017 11:47:46 +0100
Subject: [PATCH HEAD] i18n fixes
In-Reply-To: <20161005142930.GO30569@gnu.org>
References: <20161005142930.GO30569@gnu.org>
Message-ID: <87y3yo8nxp.wl-neal@walfield.org>

Hi Ineiev,

I tried to clean up the major issues about a month ago.  Would you be
willing to have a look at tofu.c again and point out any serious
issues.

Also, I'm a bit confused about the issue with the "revoked" and
"expired" strings.  They are used as a list of attributes.  What type
of context do you want?

Thanks!

:) Neal


From neal at walfield.org  Fri Jan  6 11:58:12 2017
From: neal at walfield.org (Neal H. Walfield)
Date: Fri, 06 Jan 2017 11:58:12 +0100
Subject: Using Scute with a 4096-bit key and TLSv1.2?
In-Reply-To: <878tuc15j0.fsf@wheatstone.g10code.de>
References: <20160927102322.GB1692@eridan.ccs.ecp.fr>
 
 <20160928093938.GA2731@eridan.ccs.ecp.fr>
 <878tuc15j0.fsf@wheatstone.g10code.de>
Message-ID: <87wpe88ngb.wl-neal@walfield.org>

On Wed, 28 Sep 2016 16:08:03 +0200,
Werner Koch wrote:
> On Wed, 28 Sep 2016 11:39, nicolas.boullis at ecp.fr said:
> 
> > The other question remains: is there any plan to release Scute 1.5 
> > anytime soon?
> 
> Damien: What do you think, shall I do a release?

Ping.  Although Damien confirmed that a release would be a good idea,
it looks like a release was never done.


From neal at walfield.org  Fri Jan  6 12:45:56 2017
From: neal at walfield.org (Neal H. Walfield)
Date: Fri, 06 Jan 2017 12:45:56 +0100
Subject: read/parse pubkeys in gpgme without importing
In-Reply-To: 
References: 
Message-ID: <87vats8l8r.wl-neal@walfield.org>

I've created issue 2906 to track this.

https://bugs.gnupg.org/gnupg/issue2906

Neal


From neal at walfield.org  Fri Jan  6 12:51:19 2017
From: neal at walfield.org (Neal H. Walfield)
Date: Fri, 06 Jan 2017 12:51:19 +0100
Subject: [PATCH 1/2] doc: Typo fix
In-Reply-To: <20161025173520.GB5427@arch0.localdomain>
References: <20161025173520.GB5427@arch0.localdomain>
Message-ID: <87tw9c8kzs.wl-neal@walfield.org>

Hi Nathan,

I thought this issue was still open, but it seems that Werner applied
your patches (5210ff70), but forgot to ACK them here on the mailing
list.  Thanks for your contribution!

:) Neal

On Tue, 25 Oct 2016 19:35:20 +0200,
Nathan Musoke wrote:
> 
> [1  ]
> [1.1  ]
> [1.1.1  ]
> --
> 
> Signed-off-by: Nathan Musoke 
> ---
>   doc/gpg.texi | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/doc/gpg.texi b/doc/gpg.texi
> index 6cc35e0..1bc1f40 100644
> --- a/doc/gpg.texi
> +++ b/doc/gpg.texi
> @@ -1853,7 +1853,7 @@ Maximum depth of a certification chain (default is 5).
>   @opindex no-sig-cache
>   Do not cache the verification status of key signatures.
>   Caching gives a much better performance in key listings. However, if
> -you suspect that your public keyring is not save against write
> +you suspect that your public keyring is not safe against write
>   modifications, you can use this option to disable the caching. It
>   probably does not make sense to disable it because all kind of damage
>   can be done if someone else has write access to your public keyring.
> -- 
> 2.10.1
> 
> [1.1.2 PGP Key 0x385B75C7327E99DC. ]
> [1.2 signature.asc ]
> No public key for 6AC8B7939FADAD2F created at 2016-10-25T19:35:15+0200 using RSA
> [2  ]
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel


From neal at walfield.org  Fri Jan  6 12:57:14 2017
From: neal at walfield.org (Neal H. Walfield)
Date: Fri, 06 Jan 2017 12:57:14 +0100
Subject: Question to WKD-Feature
In-Reply-To: <87wpgfnrzv.fsf@wheatstone.g10code.de>
References: 
 <877f8jui5i.fsf@wheatstone.g10code.de>
 <1702876.boSI1JWCEu@kymo.gruen>
 <87wpgfnrzv.fsf@wheatstone.g10code.de>
Message-ID: <87show8kpx.wl-neal@walfield.org>

On Mon, 07 Nov 2016 18:01:56 +0100,
Werner Koch wrote:
> On Mon,  7 Nov 2016 09:14, bernhard at intevation.de said:
> 
> > without looking into the contents? They could just deliver the ascii 
> > armored pubkey they've gotten from the client via auth-summit.
> 
> They can't do that because they need to filter the key first.  It is
> important to remove all mail addresses  but  the one which is expected
> under this entry in the WKD.
> 
> Consider a client which imports from the WKD or DANE without filtering
> (which a client should also do that) and further does not track which
> user ID has been received via WKD.  That would spoil the local keyring
> with unverified mail addresses.

I thought you always said that the local keyring is not trusted.
Further, if the user ever refreshes the key from the key server, then
the other user ids will be imported.

(Note: for something like the automated encryption scheme [1] that
uses keys retrieved via WKD as proof of basic validity, we need to
track whether the user id, not the key, was retreived via WKD!)

[1] https://wiki.gnupg.org/EasyGpg2016/AutomatedEncryption



From neal at walfield.org  Fri Jan  6 13:03:00 2017
From: neal at walfield.org (Neal H. Walfield)
Date: Fri, 06 Jan 2017 13:03:00 +0100
Subject: dirmngr DNS resolution strategy
In-Reply-To: <87funienvm.fsf@alice.fifthhorseman.net>
References: <87funienvm.fsf@alice.fifthhorseman.net>
Message-ID: <87r34g8kgb.wl-neal@walfield.org>

Hi Daniel,

Thanks for raising this issue.  Since it was never replied to, I've
opened issue 2907 so that your comments don't get completely lost.

  https://bugs.gnupg.org/gnupg/issue2907

Thanks!

:) Neal

On Thu, 27 Oct 2016 00:39:25 +0200,
Daniel Kahn Gillmor wrote:
> 
> [1  ]
> [1.1  ]
> Hi GnuPG folks--
> 
> over in https://bugs.gnupg.org/gnupg/issue2745 i did a bit of inspection
> of dirmngr DNS traffic during a simple lookup.
> 
> I did this from a temporary GNUPGHOME, via:
> 
>     GNUPGHOME=$(mktemp -d) gpg-connect-agent --dirmngr
> 
> You can do this test yourself with:
> 
>      keyserver hkps://pool.sks-keyservers.net
>      keyserver --resolve hkps://pool.sks-keyservers.net
> 
> If you record the DNS traffic that results from this, you'll see:
> 
>  a) SRV records for the pool (_hkp._tcp.hkps.pool.sks-keyservers.net)
>     came back NXDOMAIN
>    
>  b) as soon as that response came back, dirmngr sent out a request for A
>     records for hkps.pool.sks-keyservers.net, which was fulfilled with 10
>     addresses
> 
>  c) dirmngr subsequently looked up PTR records for each of those
>     addressses
> 
>  d) dirmngr was fine continuing to use some of those 10 addresses.
> 
> 
> This is all using the adns library, which should allow for asynchronous
> DNS requests.  I'm assuming that the goal here is for dirmngr to be as
> fast as possible in its responses.
> 
> This raises several questions for me:
> 
>  0) There's no reason to have the request for A records (step b) sent
>     out *after* the SRV response comes in.  Both requests could be sent
>     concurrently, and dirmngr could update its host table with whatever
>     answers it gets.  If you prefer SRV records, then discard any A
>     responses that come in after SRV records, while overwriting any A
>     responses that are already present when SRV responses come in.
> 
>  1) Each of the PTR records looked up in step c were done one after the
>     other.  There should be no need to wait on this; if you need PTR
>     records, simply send all 10 PTR requests concurrently, and process
>     them as they come back in.  This parallelization will reduce the
>     number of round trips dramatically.
> 
>  2) More importantly -- why does dirmngr need PTR records at all?
>     what's the advantage of having them?  If the user is asking to
>     connect to a pool, doing a reverse DNS lookup just seems to be an
>     additional round trip requirement.
> 
> 
> any thoughts?
> 
>     --dkg
> [1.2 signature.asc ]
> Signature made by expired key 24ECFF5AFF68370A Daniel Kahn Gillmor 
> [2  ]
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel


From neal at walfield.org  Fri Jan  6 14:35:59 2017
From: neal at walfield.org (Neal H. Walfield)
Date: Fri, 06 Jan 2017 14:35:59 +0100
Subject: dirmngr, ldap, dirmngr_ldap, and the ldap "wrapper"
In-Reply-To: <87y40rbnle.fsf@alice.fifthhorseman.net>
References: <87y40rbnle.fsf@alice.fifthhorseman.net>
Message-ID: <87pok08g5c.wl-neal@walfield.org>

This appears to not have been addressed.  As such, I opened the
following issue so we don't forget about it:

  https://bugs.gnupg.org/gnupg/issue2908

On Thu, 10 Nov 2016 12:06:53 +0100,
Daniel Kahn Gillmor wrote:
> 
> [1  ]
> [1.1  ]
> Hi all--
> 
> dirmngr in debian used to have a weaker dependency (a "Recommends:"
> instead of "Depends:") on the libldap binary package, so users who
> wanted a smaller system and didn't need dirmngr ldap access could
> install dirmngr without installing libldap.  Of course, dirmngr_ldap
> would fail on those systems.  Currently, however, libldap is a hard
> dependency of dirmngr, because dirmngr links in ks-engine-ldap.c
> 
> Comments in the header of dirmngr/ldap-wrapper.c say:
> 
> ----------
>    We can't use LDAP directly for these reasons:
> 
>    1. On some systems the LDAP library uses (indirectly) pthreads and
>       that is not compatible with PTh.
> 
>    2. It is huge library in particular if TLS comes into play.  So
>       problems with unfreed memory might turn up and we don't want
>       this in a long running daemon.
> 
>    3. There is no easy way for timeouts. In particular the timeout
>       value does not work for DNS lookups (well, this is usual) and it
>       seems not to work while loading a large attribute like a
>       CRL. Having a separate process allows us to either tell the
>       process to commit suicide or have our own housekepping function
>       kill it after some time.  The latter also allows proper
>       cancellation of a query at any point of time.
> 
>    4. Given that we are going out to the network and usually get back
>       a long response, the fork/exec overhead is acceptable.
> ----------
> 
> The inclusion of ks-engine-ldap.c appears to have happened in
> 51341badb623927f2a358588c725a356fc77dbe7.  Has the rationale in
> ldap-wrapper.c been reconsidered or made obsolete for some reason?  If
> so, it should be updated.  If not, should we try to re-separate
> dirmngr's use of ldap back into the wrapper?
> 
> Any thoughts?
> 
>           --dkg
> [1.2 signature.asc ]
> Signature made by expired key 24ECFF5AFF68370A Daniel Kahn Gillmor 
> [2  ]
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel


From neal at walfield.org  Fri Jan  6 15:00:21 2017
From: neal at walfield.org (Neal H. Walfield)
Date: Fri, 06 Jan 2017 15:00:21 +0100
Subject: GnuPG 2.1.15 - delete-secret-keys seems not to accept loopback
 pinentry
In-Reply-To: <70587844.1123310.1479234269383@mail.yahoo.com>
References: <70587844.1123310.1479234269383.ref@mail.yahoo.com>
 <70587844.1123310.1479234269383@mail.yahoo.com>
Message-ID: <87o9zk8f0q.wl-neal@walfield.org>

To not lose track of this issue, I opened:

  https://bugs.gnupg.org/gnupg/issue2909

Thanks for reporting it!

:) Neal

On Tue, 15 Nov 2016 19:24:29 +0100,
Vinay Sajip wrote:
> 
> [1  ]
> [1.1  ]
> [1.2  ]
> I've made some progress with getting GnuPG 2.1.15 to accept
> passphrases on fd 0 - it seems to work now for e.g. decryption
> operations. However, deleting secret keys still seems to fail.
> Environment is Ubuntu 16.04.1 (64-bit), GnuPG 2.1.15 built from
> source.
> 
> $ cat keys/gpg-agent.conf 
> 
> allow-loopback-pinentry
> log-file socket:///tmp/S.my-gnupg-log
> verbose
> debug ipc
> 
> Output from watchgnupg --time-only --force /tmp/S.my-gnupg-log:
> 
> 4 - 17:46:12 gpg-agent[14900]: handler 0x7ff2ff4f6700 for fd 5 started
> 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> OK Pleased to meet you,
> process 14926
> 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 <- RESET
> 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> OK
> 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 <- OPTION
> ttytype=xterm-256color
> 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> OK
> 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 <- OPTION display=:0
> 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> OK
> 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 <- OPTION
> xauthority=/home/vinay/.Xauthority
> 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> OK
> 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 <- OPTION
> putenv=XMODIFIERS=@im=ibus
> 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> OK
> 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 <- OPTION
> putenv=GTK_IM_MODULE=ibus
> 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> OK
> 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 <- OPTION
> putenv=DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-DYgUN0UGwd
> 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> OK
> 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 <- OPTION
> putenv=QT_IM_MODULE=ibus
> 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> OK
> 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 <- GETINFO version
> 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> D 2.1.15
> 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> OK
> 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 <- OPTION
> allow-pinentry-notify
> 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> OK
> 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 <- OPTION
> agent-awareness=2.1.0
> 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> OK
> 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 <- OPTION
> pinentry-mode=loopback
> 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> OK
> 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 <- AGENT_ID
> 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> ERR 67109139 Unknown IPC
> command 
> 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 <- HAVEKEY
> E957503A4483EFA081EBF906B52DBB4B621814FF
> 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> OK
> 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 <- HAVEKEY
> E957503A4483EFA081EBF906B52DBB4B621814FF
> 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> OK
> 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 <- SETKEYDESC
> Do+you+really+want+to+permanently+delete+the+OpenPGP+secret+key:%0A%22Autogenerated+Key+%22%0A2048-bit+RSA+key,+ID+8F03D92FB77E3265,%0Acreated+2016-11-15.%0A?
> 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> OK
> 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 <- DELETE_KEY
> E957503A4483EFA081EBF906B52DBB4B621814FF
> 4 - 17:46:12 gpg-agent[14900]: command 'DELETE_KEY' failed: No
> PINentry
> 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 -> ERR 67108949 No PINentry
> 
> 4 - 17:46:12 gpg-agent[14900]: DBG: chan_5 <- [eof]
> 4 - 17:46:12 gpg-agent[14900]: handler 0x7ff2ff4f6700 for fd 5
> terminated
> 
> My test run log file:
> 
> 14926: /home/vinay/tmp/bin/gpg2 --pinentry-mode loopback --status-fd 2
> --no-tty --debug ipc --homedir /home/vinay/projects/python-gnupg/keys -
> -batch --passphrase-fd 0 --debug-quick-random --batch -
> -delete-secret-key B1743E3C7D6DC65F44720E548F03D92FB77E3265
> Wrote passphrase
> gpg: Note: no default option file
> '/home/vinay/projects/python-gnupg/keys/gpg.conf'
> gpg: enabled debug flags: ipc
> gpg: DBG: chan_6 <- OK Pleased to meet you, process 14926
> gpg: DBG: connection to agent established
> gpg: DBG: chan_6 -> RESET
> gpg: DBG: chan_6 <- OK
> gpg: DBG: chan_6 -> OPTION ttytype=xterm-256color
> gpg: DBG: chan_6 <- OK
> gpg: DBG: chan_6 -> OPTION display=:0
> gpg: DBG: chan_6 <- OK
> gpg: DBG: chan_6 -> OPTION xauthority=/home/vinay/.Xauthority
> gpg: DBG: chan_6 <- OK
> gpg: DBG: chan_6 -> OPTION putenv=XMODIFIERS=@im=ibus
> gpg: DBG: chan_6 <- OK
> gpg: DBG: chan_6 -> OPTION putenv=GTK_IM_MODULE=ibus
> gpg: DBG: chan_6 <- OK
> gpg: DBG: chan_6 -> OPTION
> putenv=DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-DYgUN0UGwd
> gpg: DBG: chan_6 <- OK
> gpg: DBG: chan_6 -> OPTION putenv=QT_IM_MODULE=ibus
> gpg: DBG: chan_6 <- OK
> gpg: DBG: chan_6 -> GETINFO version
> gpg: DBG: chan_6 <- D 2.1.15
> gpg: DBG: chan_6 <- OK
> gpg: DBG: chan_6 -> OPTION allow-pinentry-notify
> gpg: DBG: chan_6 <- OK
> gpg: DBG: chan_6 -> OPTION agent-awareness=2.1.0
> gpg: DBG: chan_6 <- OK
> gpg: DBG: chan_6 -> OPTION pinentry-mode=loopback
> gpg: DBG: chan_6 <- OK
> gpg: DBG: chan_6 -> AGENT_ID
> gpg: DBG: chan_6 <- ERR 67109139 Unknown IPC command 
> gpg: DBG: chan_6 -> HAVEKEY E957503A4483EFA081EBF906B52DBB4B621814FF
> gpg: DBG: chan_6 <- OK
> gpg: DBG: chan_6 -> HAVEKEY E957503A4483EFA081EBF906B52DBB4B621814FF
> gpg: DBG: chan_6 <- OK
> [GNUPG:] KEY_CONSIDERED B1743E3C7D6DC65F44720E548F03D92FB77E3265 0
> gpg: DBG: chan_6 -> SETKEYDESC
> Do+you+really+want+to+permanently+delete+the+OpenPGP+secret+key:%0A%22Autogenerated+Key+%22%0A2048-bit+RSA+key,+ID+8F03D92FB77E3265,%0Acreated+2016-11-15.%0A?
> gpg: DBG: chan_6 <- OK
> gpg: DBG: chan_6 -> DELETE_KEY
> E957503A4483EFA081EBF906B52DBB4B621814FF
> gpg: DBG: chan_6 <- ERR 67108949 No PINentry 
> gpg: deleting secret key failed: No PINentry
> gpg: B1743E3C7D6DC65F44720E548F03D92FB77E3265: delete key failed: No
> PINentry
> gpg: secmem usage: 224/32768 bytes in 1 blocks
> 
> The first line of my test run log indicates the PID and command line
> of the gpg process. This ties up with the watchgnupg program output.
> The "OPTION pinentry-mode=loopback" seems to have been accepted. I
> don't understand why the AGENT_ID causes the "ERR 67109139 Unknown IPC
> command " or whether it is relevant to the later failure.
> Why does DELETE_KEY fail with "No PINentry", and how can I avoid this?
> As far as I can tell, the passphrase was written successfully on fd 0
> (the 2nd line in my test run log, "Wrote passphrase").
> 
> Can anyone shed any light on this?
> 
> Regards,
> 
> Vinay Sajip
> [2  ]
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel


From neal at walfield.org  Fri Jan  6 15:02:12 2017
From: neal at walfield.org (Neal H. Walfield)
Date: Fri, 06 Jan 2017 15:02:12 +0100
Subject: gpgme 1.8 build failure
In-Reply-To: <908b8300-797c-88d4-bc79-0213203f0980@sixdemonbag.org>
References: <908b8300-797c-88d4-bc79-0213203f0980@sixdemonbag.org>
Message-ID: <87mvf48exn.wl-neal@walfield.org>

Since I think this issue is still unresolved, I've open a bug:

  https://bugs.gnupg.org/gnupg/issue2910

Thanks for reporting it!

:) Neal

On Thu, 17 Nov 2016 01:04:43 +0100,
Robert J. Hansen wrote:
> 
> Build environment: macOS Sierra, XCode 8.1.
> 
> quorra:gpgme-1.8.0 rjh$ make
> /Applications/Xcode.app/Contents/Developer/usr/bin/make  all-recursive
> Making all in src
> make[2]: Nothing to be done for `all'.
> Making all in tests
> Making all in gpg
> make[3]: Nothing to be done for `all'.
> Making all in gpgsm
> make[3]: Nothing to be done for `all'.
> Making all in opassuan
> make[3]: Nothing to be done for `all'.
> make[3]: Nothing to be done for `all-am'.
> Making all in doc
> /Applications/Xcode.app/Contents/Developer/usr/bin/make  all-am
> make[3]: Nothing to be done for `all-am'.
> Making all in lang
> Making all in cl
> make[3]: Nothing to be done for `all'.
> Making all in cpp
> Making all in src
> /bin/sh ../../../libtool  --tag=CXX   --mode=compile g++ -std=c++11
> -DHAVE_CONFIG_H -I. -I../../..  -I../../../src -I/usr/local/include
> -I/usr/local/include -DBUILDING_GPGMEPP   -g -O2 -MT
> keygenerationresult.lo -MD -MP -MF .deps/keygenerationresult.Tpo -c -o
> keygenerationresult.lo keygenerationresult.cpp
> libtool: compile:  g++ -std=c++11 -DHAVE_CONFIG_H -I. -I../../..
> -I../../../src -I/usr/local/include -I/usr/local/include
> -DBUILDING_GPGMEPP -g -O2 -MT keygenerationresult.lo -MD -MP -MF
> .deps/keygenerationresult.Tpo -c keygenerationresult.cpp  -fno-common
> -DPIC -o .libs/keygenerationresult.o
> keygenerationresult.cpp:43:23: error: use of undeclared identifier 'strdup'
>             res.fpr = strdup(res.fpr);
>                       ^
> 1 error generated.
> 
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
> 


From neal at walfield.org  Fri Jan  6 15:26:18 2017
From: neal at walfield.org (Neal H. Walfield)
Date: Fri, 06 Jan 2017 15:26:18 +0100
Subject: Key creation problem with 2.1.16
In-Reply-To: <20161129230429.B2488100B190@remailer.paranoici.org>
References: <20161129230429.B2488100B190@remailer.paranoici.org>
Message-ID: <87lguo8dth.wl-neal@walfield.org>

Since this issue is still unresolved, I've open an issue so that it
doesn't get lost:

  https://bugs.gnupg.org/gnupg/issue2911

Thanks for taking the time to report this!

:) Neal

On Wed, 30 Nov 2016 00:04:29 +0100,
Carola Grunwald wrote:
> 
> [1  ]
> Hi,
> 
> after key creation, which usually succeeds, gpg.exe sometimes returns
> error number 2, which looks like a bug.
> 
> | gpg: DBG: get_keygrip for public key
> | gpg: DBG: keygrip= C5 A4 75 9F 78 43 21 40 44 66 AC A9 47 12 E4 F8 B5 A8 8B 02
> | gpg: DBG: chan_0x00000094 -> RESET
> | gpg: DBG: chan_0x00000094 <- OK
> | gpg: DBG: chan_0x00000094 -> SIGKEY C5A4759F784321404466ACA94712E4F8B5A88B02
> | gpg: DBG: chan_0x00000094 <- OK
> | gpg: DBG: chan_0x00000094 -> SETKEYDESC Please+enter+the+passphrase+to+unlock+the+OpenPGP+secret+key:%0A%22Gpg+Test+%22%0A2048-bit+RSA+key,+ID+C738D5E556AFC7CE,%0Acreated+2016-11-24.%0A
> | gpg: DBG: chan_0x00000094 <- OK
> | gpg: DBG: chan_0x00000094 -> SETHASH 8 F682A7CB5487904584DC35C490D25ADE02BB223877C39C0398C49077E54EE6E9
> | gpg: DBG: chan_0x00000094 <- OK
> | gpg: DBG: chan_0x00000094 -> PKSIGN -- 071F0B591589B1AE96E29326
> | gpg: DBG: chan_0x00000094 <- S INQUIRE_MAXLEN 255
> | gpg: DBG: chan_0x00000094 <- INQUIRE PASSPHRASE
> | [GNUPG:] USERID_HINT C738D5E556AFC7CE Gpg Test 
> | [GNUPG:] NEED_PASSPHRASE C738D5E556AFC7CE C738D5E556AFC7CE 1 0
> | [GNUPG:] INQUIRE_MAXLEN 100
> | gpg: Sorry, we are in batchmode - can't get input
> 
> vs.
> 
> | gpg: DBG: get_keygrip for public key
> | gpg: DBG: keygrip= A5 82 DC 7B 32 E2 1A 79 82 9F 57 F7 A9 1B 2F 96 15 FB 43 C2
> | gpg: DBG: chan_0x00000094 -> RESET
> | gpg: DBG: chan_0x00000094 <- OK
> | gpg: DBG: chan_0x00000094 -> SIGKEY A582DC7B32E21A79829F57F7A91B2F9615FB43C2
> | gpg: DBG: chan_0x00000094 <- OK
> | gpg: DBG: chan_0x00000094 -> SETKEYDESC Please+enter+the+passphrase+to+unlock+the+OpenPGP+secret+key:%0A%22Gpg+Test+%22%0A2048-bit+RSA+key,+ID+682B479F1A75E8C3,%0Acreated+2016-11-24.%0A
> | gpg: DBG: chan_0x00000094 <- OK
> | gpg: DBG: chan_0x00000094 -> SETHASH 8 657C84AFB05669CA8CD7721FFD634C4226C601311453F9E5667B747F75894F38
> | gpg: DBG: chan_0x00000094 <- OK
> | gpg: DBG: chan_0x00000094 -> PKSIGN -- 744E5829E93B414D3221D01E
> | gpg: DBG: chan_00000094 <- [ 44 20 28 37 3a 73 69 67 2d 76 61 6c 28 33 3a 72 ...(273 byte(s) skipped) ]
> | gpg: DBG: chan_0x00000094 <- OK
> | gpg: DBG: build_packet() type=2
> | gpg: DBG: iobuf-7.0: close '?'
> | gpg: DBG: armor-filter: control: 4
> | gpg: DBG: armor-filter: control: 5
> | gpg: DBG: iobuf-6.1: close 'armor_filter'
> | gpg: DBG: armor-filter: control: 2
> | gpg: DBG: iobuf-6.0: close 'file_filter(fd)'
> | gpg: DBG: G:/mob/Mail/MyGnuPG/gpg/openpgp-revocs.d\81A7B5FA786C103986170348682B479F1A75E8C3.rev: close fd/handle 176
> | gpg: DBG: fd_cache_close (176) real
> | gpg: revocation certificate stored as 'G:/mob/Mail/MyGnuPG/gpg/openpgp-revocs.d\81A7B5FA786C103986170348682B479F1A75E8C3.rev'
> | [GNUPG:] KEY_CREATED P 81A7B5FA786C103986170348682B479F1A75E8C3
> | gpg: DBG: free_packet() type=6
> | gpg: DBG: free_packet() type=13
> | gpg: DBG: free_packet() type=2
> | gpg: DBG: iobuf-1.0: close '?'
> | gpg: DBG: [not enabled in the source] stop
> | gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
> |               outmix=0 getlvl1=0/0 getlvl2=0/0
> | gpg: secmem usage: 0/32768 bytes in 0 blocks
> 
> I attached .exe i/o data of erroneous (gpg_cmd_ko.log) and normal
> processing (gpg_cmd_ok.log) as well as the respective --gen-key file.
> 
> Kind regards
> 
> Caro
> [2 gpg_cmd_ko.log ]
> [3 gpg_cmd_ok.log ]
> [4 key_gen.cfg ]
> [5  ]
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel


From neal at walfield.org  Fri Jan  6 15:33:55 2017
From: neal at walfield.org (Neal H. Walfield)
Date: Fri, 06 Jan 2017 15:33:55 +0100
Subject: [PATCH] Re: command line keytocard
In-Reply-To: 
References: 
 <3D6E9070-A702-4990-8082-8C39036E0198@adviser.com>
 <08A73A20-9975-43DE-B13B-FEE01613F108@adviser.com>
 
Message-ID: <87k2a88dgs.wl-neal@walfield.org>

I've open an issue so that this doesn't get lost.

  https://bugs.gnupg.org/gnupg/issue2912

Thanks for your contribution!

:) Neal

On Fri, 02 Dec 2016 23:59:54 +0100,
Meno Abels wrote:
> 
> Now ?quick-keytocard is working for me. I can pass the passphrase
> and the adminpin down. I solved it by enabling the multiple use of
> ?passphrase-fd/file
> 
> here the patch for the passphrase change


From neal at walfield.org  Fri Jan  6 15:36:02 2017
From: neal at walfield.org (Neal H. Walfield)
Date: Fri, 06 Jan 2017 15:36:02 +0100
Subject: Key import on a machine with date moved back
In-Reply-To: <87wpfiuvuf.fsf@wheatstone.g10code.de>
References: <7e1aecff-42b9-7ed8-4094-d03de8812fa9@alec.pl>
 <874m2mv2hh.fsf@alice.fifthhorseman.net>
 <87wpfiuvuf.fsf@wheatstone.g10code.de>
Message-ID: <87inps8dd9.wl-neal@walfield.org>

On Fri, 02 Dec 2016 17:41:44 +0100,
Werner Koch wrote:
> On Fri,  2 Dec 2016 15:18, dkg at fifthhorseman.net said:
> 
> > 2.1 does have --ignore-time-conflict, but i agree with you that it might
> 
> Actually all versions have that for many years.  The RIPE requested that once.
> 
> > make more sense to tolerate a "typical" clock skew of a few seconds or
> > minutes by default.
> 
> Yes, that is useful.  There is another open bug related to too strict
> validation result for time conflicts and in the course of fixing that we
> should allow for a skew of a few minutes.

I want to make sure that this issue is explain in that bug, but after
some searching, but I couldn't find the issue.  Could you point me to
it?

Thanks!

:) Neal


From neal at walfield.org  Fri Jan  6 15:40:14 2017
From: neal at walfield.org (Neal H. Walfield)
Date: Fri, 06 Jan 2017 15:40:14 +0100
Subject: [PATCH] python: default op_keylist_start parameters.
In-Reply-To: <20161203221237.GA13139@cryptobitch.de>
References: <20161203221237.GA13139@cryptobitch.de>
Message-ID: <87h95c8d69.wl-neal@walfield.org>

Since this patch hasn't been accepted or reject, I've create the
following issue to track it:

  https://bugs.gnupg.org/gnupg/issue2913

Thanks!

:) Neal

On Sat, 03 Dec 2016 23:12:37 +0100,
Tobias Mueller wrote:
> 
> * lang/python/gpgme.i: Added gpgme_op_keylist_start with defaults
> * lang/python/tests/t-keylist.py: Added tests for default parameters
> --
> 
> To increase the ease of use, op_keylist_start
> parameters default to sensible values.
> The empty string matches all keys.
> We assume that the user wants to retrieve public keys most of the time,
> so we default to public keys rather than secret keys.
> 
> Signed-off-by: Tobias Mueller 
> ---
>  lang/python/gpgme.i            |  9 +++++++++
>  lang/python/tests/t-keylist.py | 12 ++++++++++++
>  2 files changed, 21 insertions(+)


From neal at walfield.org  Fri Jan  6 15:50:04 2017
From: neal at walfield.org (Neal H. Walfield)
Date: Fri, 06 Jan 2017 15:50:04 +0100
Subject: [PATCH] tty: Treat enter key as synonymous with OK.
In-Reply-To: <20161219001104.GA16172@zond>
References: <20161219001104.GA16172@zond>
Message-ID: <87fukw8cpv.wl-neal@walfield.org>

Hi,

On Mon, 19 Dec 2016 01:11:04 +0100,
Felix Crux wrote:
> * tty/pinentry-tty.c: Accept '\n' as equivalent to designated 'ok' key.

I understand the analogy, but I don't think it is a good idea.  (It's
too easy to make a mistake.)

Thanks anyway!

:) Neal


From daveparrish at tutanota.com  Fri Jan  6 16:22:37 2017
From: daveparrish at tutanota.com (David Parrish)
Date: Fri, 6 Jan 2017 16:22:37 +0100 (CET)
Subject: How to use gpgme to manage gpg keys remotely?
Message-ID: 

Hi,
I'm working on an application which runs GPG from a home server. The application encrypts important files and releases them if the user fails to "check in" after a certain amount of time.
I'm using GPGME and making progress with the application, but having trouble using GPGME to delete a public/private key without pinentry prompting me. I have been able to use GPGME to enter a passphrase without pinentry prompting me.

How can the delete key prompt be suppressed or responded to using GPGME?
Is a remote application like I described an appropriate use case for GPGME and GPG? I planned for the the user to "check in" using a web app or phone app, prompting them to enter their GPG key passphrase to sign a message. I know this is not very secure, but I'm doing my best to make the application easy enough for people not familiar with GPG to use it.

Here is more information on my project:?https://github.com/dmp1ce/DMSS/blob/master/DESIGN.md

-David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From wk at gnupg.org  Fri Jan  6 19:51:57 2017
From: wk at gnupg.org (Werner Koch)
Date: Fri, 06 Jan 2017 19:51:57 +0100
Subject: Question to WKD-Feature
In-Reply-To: <87show8kpx.wl-neal@walfield.org> (Neal H. Walfield's message of
 "Fri, 06 Jan 2017 12:57:14 +0100")
References: 
 <877f8jui5i.fsf@wheatstone.g10code.de> <1702876.boSI1JWCEu@kymo.gruen>
 <87wpgfnrzv.fsf@wheatstone.g10code.de>
 <87show8kpx.wl-neal@walfield.org>
Message-ID: <87lguo58du.fsf@wheatstone.g10code.de>

On Fri,  6 Jan 2017 12:57, neal at walfield.org said:

> uses keys retrieved via WKD as proof of basic validity, we need to
> track whether the user id, not the key, was retreived via WKD!)

Adding this to gpg is on my shortlist.


Shalom-Salam,

   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: 227 bytes
Desc: not available
URL: 

From wk at gnupg.org  Fri Jan  6 20:00:11 2017
From: wk at gnupg.org (Werner Koch)
Date: Fri, 06 Jan 2017 20:00:11 +0100
Subject: Key import on a machine with date moved back
In-Reply-To: <87inps8dd9.wl-neal@walfield.org> (Neal H. Walfield's message of
 "Fri, 06 Jan 2017 15:36:02 +0100")
References: <7e1aecff-42b9-7ed8-4094-d03de8812fa9@alec.pl>
 <874m2mv2hh.fsf@alice.fifthhorseman.net>
 <87wpfiuvuf.fsf@wheatstone.g10code.de>
 <87inps8dd9.wl-neal@walfield.org>
Message-ID: <87d1g05804.fsf@wheatstone.g10code.de>

On Fri,  6 Jan 2017 15:36, neal at walfield.org said:

> I want to make sure that this issue is explain in that bug, but after
> some searching, but I couldn't find the issue.  Could you point me to
> it?

Sorry, no.  It is straight from my brain.  I might have seen that in
some external bug tracker or it was orally reproted.


Shalom-Salam,

   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: 227 bytes
Desc: not available
URL: 

From neal at walfield.org  Fri Jan  6 21:25:45 2017
From: neal at walfield.org (Neal H. Walfield)
Date: Fri, 06 Jan 2017 21:25:45 +0100
Subject: Key import on a machine with date moved back
In-Reply-To: <87d1g05804.fsf@wheatstone.g10code.de>
References: <7e1aecff-42b9-7ed8-4094-d03de8812fa9@alec.pl>
 <874m2mv2hh.fsf@alice.fifthhorseman.net>
 <87wpfiuvuf.fsf@wheatstone.g10code.de>
 <87inps8dd9.wl-neal@walfield.org>
 <87d1g05804.fsf@wheatstone.g10code.de>
Message-ID: <87a8b47x6e.wl-neal@walfield.org>

On Fri, 06 Jan 2017 20:00:11 +0100,
Werner Koch wrote:
> On Fri,  6 Jan 2017 15:36, neal at walfield.org said:
> 
> > I want to make sure that this issue is explain in that bug, but after
> > some searching, but I couldn't find the issue.  Could you point me to
> > it?
> 
> Sorry, no.  It is straight from my brain.  I might have seen that in
> some external bug tracker or it was orally reproted.

Ok.  I opened this issue:

  https://bugs.gnupg.org/gnupg/issue2915

:) Neal


From dkg at fifthhorseman.net  Fri Jan  6 22:15:30 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 06 Jan 2017 16:15:30 -0500
Subject: Problems with pip install gpg
In-Reply-To: <201701051656.01278.bernhard@intevation.de>
References: 
 
 <201701051656.01278.bernhard@intevation.de>
Message-ID: <87zij3evpp.fsf@alice.fifthhorseman.net>

On Thu 2017-01-05 10:55:57 -0500, Bernhard Reiter wrote:

> for what it is worth: I agree that we should make a reasonable effort
> to support standard work-flows that python devs might try.

I agree with Bernhard here.  the GnuPG upstream adoption of the python
module, and claiming of the "gpg" namespace is a long overdue.  thanks
for doing it!

It's not surprising to me, given the complex nature of the python-gpg ?
swig ? GPGME C library ? GnuPG binary packages dependency chain that the
initial thing in pip isn't going to work everywhere, though :/

> I also consider it fine for a python module to demand a larger dependency to 
> be already installed. (Example 
> https://github.com/pyldap/pyldap/blob/master/setup.cfg
> {{{
> # These defines needs OpenLDAP built with
> # ./configure --with-cyrus-sasl --with-tls
> }}}
> )

this seems reasonable to me too, as a stopgap measure to at least let
people know what's going on.

> Another alternative:
> What about getting better instructions how to get a gpgme  for the platform in 
> the pip message? A link to a wiki page that offers current packages for a 
> number of distros would be really helpful.
>
> For example: A gpgme build for Debian Jessie and Ubuntu 14.04 and 16.04 LTS 
> (and the other included libraries) would be cool.

for Debian Jessie, the right approach would be to use jessie-backports,
but i haven't tried it.  If someone wants to try it, and propose a
"jessie-backports" patch queue based on the master branch of
https://anonscm.debian.org/git/pkg-gnupg/gpgme, i'd be happy to review
it and upload it if it's working.  I don't know the ubuntu system well
enough to know how to support folks on the LTS releases, but if having a
jessie-backport available helps there, i can try to push harder on that.

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: 

From curt at brune.net  Sat Jan  7 06:56:53 2017
From: curt at brune.net (Curt Brune)
Date: Fri,  6 Jan 2017 21:56:53 -0800
Subject: [PATCH v2 1/1] pinentry-mode: add new mode no-card-cancel-prompt
Message-ID: <1483768613-9096-2-git-send-email-curt@brune.net>

This patch adds a new pinentry-mode called 'no-card-cancel-prompt'.

The goal is to suppress unneeded pinentry prompting when the inserted
smartcard's serial number does not match the requested serial number.

When the requested smartcard serial number does not match the inserted
card's serial number, automatically skip the card without prompting
the user.  This skips the launching of pinetry and moves on, as if the
user had selected "cancel".

This is convenient when decrypting a file encrypted for multiple
smartcard recipients, but only one smartcard is available.  In this
case only one pinetry will be shown to the user (the one for the
inserted card), while the remaining pinetry prompts for unavailable
smartcards will be suppressed.

Signed-off-by: Curt Brune 
---
 agent/call-pinentry.c |  3 ++-
 agent/divert-scd.c    |  5 +++++
 common/agent-opt.c    | 11 +++++++----
 common/shareddefs.h   |  9 +++++----
 doc/gpg-agent.texi    |  4 ++++
 5 files changed, 23 insertions(+), 9 deletions(-)

diff --git a/agent/call-pinentry.c b/agent/call-pinentry.c
index 0f24086..800ccf1 100644
--- a/agent/call-pinentry.c
+++ b/agent/call-pinentry.c
@@ -826,21 +826,22 @@ agent_askpin (ctrl_t ctrl,
   char line[ASSUAN_LINELENGTH];
   struct entry_parm_s parm;
   const char *errtext = NULL;
   int is_pin = 0;
   int saveflag;
   unsigned int pinentry_status;
 
   if (opt.batch)
     return 0; /* fixme: we should return BAD PIN */
 
-  if (ctrl->pinentry_mode != PINENTRY_MODE_ASK)
+  if ((ctrl->pinentry_mode != PINENTRY_MODE_ASK) &&
+      (ctrl->pinentry_mode != PINENTRY_MODE_NO_CARD_CANCEL_PROMPT))
     {
       if (ctrl->pinentry_mode == PINENTRY_MODE_CANCEL)
         return gpg_error (GPG_ERR_CANCELED);
       if (ctrl->pinentry_mode == PINENTRY_MODE_LOOPBACK)
         {
 	  unsigned char *passphrase;
 	  size_t size;
 
 	  *pininfo->pin = 0; /* Reset the PIN. */
 	  rc = pinentry_loopback(ctrl, "PASSPHRASE", &passphrase, &size,
diff --git a/agent/divert-scd.c b/agent/divert-scd.c
index 5d3b1ef..75332ad 100644
--- a/agent/divert-scd.c
+++ b/agent/divert-scd.c
@@ -64,20 +64,25 @@ ask_for_card (ctrl_t ctrl, const unsigned char *shadow_info, char **r_kid)
           log_debug ("detected card with S/N %s\n", serialno);
           i = strcmp (serialno, want_sn);
           xfree (serialno);
           serialno = NULL;
           if (!i)
             {
               xfree (want_sn);
               *r_kid = want_kid;
               return 0; /* yes, we have the correct card */
             }
+          if (ctrl->pinentry_mode == PINENTRY_MODE_NO_CARD_CANCEL_PROMPT)
+            {
+              log_debug ("skipping card with mismatched S/N\n");
+              rc = gpg_error (GPG_ERR_CANCELED);
+            }
         }
       else if (gpg_err_code (rc) == GPG_ERR_CARD_NOT_PRESENT)
         {
           log_debug ("no card present\n");
           rc = 0;
           no_card = 1;
         }
       else
         {
           log_error ("error accessing card: %s\n", gpg_strerror (rc));
diff --git a/common/agent-opt.c b/common/agent-opt.c
index 4317ba3..3967d7e 100644
--- a/common/agent-opt.c
+++ b/common/agent-opt.c
@@ -42,30 +42,33 @@ parse_pinentry_mode (const char *value)
   int result;
 
   if (!strcmp (value, "ask") || !strcmp (value, "default"))
     result = PINENTRY_MODE_ASK;
   else if (!strcmp (value, "cancel"))
     result = PINENTRY_MODE_CANCEL;
   else if (!strcmp (value, "error"))
     result = PINENTRY_MODE_ERROR;
   else if (!strcmp (value, "loopback"))
     result = PINENTRY_MODE_LOOPBACK;
+  else if (!strcmp (value, "no-card-cancel-prompt"))
+    result = PINENTRY_MODE_NO_CARD_CANCEL_PROMPT;
   else
     result = -1;
 
   return result;
 }
 
 /* Return the string representation for the pinentry MODE.  Returns
    "?" for an invalid mode.  */
 const char *
 str_pinentry_mode (pinentry_mode_t mode)
 {
   switch (mode)
     {
-    case PINENTRY_MODE_ASK:      return "ask";
-    case PINENTRY_MODE_CANCEL:   return "cancel";
-    case PINENTRY_MODE_ERROR:    return "error";
-    case PINENTRY_MODE_LOOPBACK: return "loopback";
+    case PINENTRY_MODE_ASK:                   return "ask";
+    case PINENTRY_MODE_CANCEL:                return "cancel";
+    case PINENTRY_MODE_ERROR:                 return "error";
+    case PINENTRY_MODE_LOOPBACK:              return "loopback";
+    case PINENTRY_MODE_NO_CARD_CANCEL_PROMPT: return "no-card-cancel-prompt";
     }
  return "?";
 }
diff --git a/common/shareddefs.h b/common/shareddefs.h
index 604b7e9..59b0c9d 100644
--- a/common/shareddefs.h
+++ b/common/shareddefs.h
@@ -24,24 +24,25 @@
  * You should have received a copy of the GNU General Public License
  * along with this program; if not, see .
  */
 
 #ifndef GNUPG_COMMON_SHAREDDEFS_H
 #define GNUPG_COMMON_SHAREDDEFS_H
 
 /* Values for the pinentry mode.  */
 typedef enum
   {
-    PINENTRY_MODE_ASK = 0, /* Ask via pinentry (default).  */
-    PINENTRY_MODE_CANCEL,  /* Always return a cancel error.  */
-    PINENTRY_MODE_ERROR,   /* Return error code for no pinentry.  */
-    PINENTRY_MODE_LOOPBACK /* Use an inquiry to get the value.    */
+    PINENTRY_MODE_ASK = 0,              /* Ask via pinentry (default).  */
+    PINENTRY_MODE_CANCEL,               /* Always return a cancel error.  */
+    PINENTRY_MODE_ERROR,                /* Return error code for no pinentry.  */
+    PINENTRY_MODE_LOOPBACK,             /* Use an inquiry to get the value.    */
+    PINENTRY_MODE_NO_CARD_CANCEL_PROMPT /* Return cancel error if card is absent. */
   }
 pinentry_mode_t;
 
 
 /*-- agent-opt.c --*/
 int parse_pinentry_mode (const char *value);
 const char *str_pinentry_mode (pinentry_mode_t mode);
 
 
 
diff --git a/doc/gpg-agent.texi b/doc/gpg-agent.texi
index f4da9cf..549e3d0 100644
--- a/doc/gpg-agent.texi
+++ b/doc/gpg-agent.texi
@@ -1408,20 +1408,24 @@ This option is used to change the operation mode of the pinentry.  The
 following values are defined:
 
   @table @code
   @item ask
   This is the default mode which pops up a pinentry as needed.
 
   @item cancel
   Instead of popping up a pinentry, return the error code
   @code{GPG_ERR_CANCELED}.
 
+  @item no-card-cancel-prompt
+  When the requested smartcard serial number does not match the inserted
+  card's serial number, return the error code @code{GPG_ERR_CANCELED}.
+
   @item error
   Instead of popping up a pinentry, return the error code
   @code{GPG_ERR_NO_PIN_ENTRY}.
 
   @item loopback
   Use a loopback pinentry.  This fakes a pinentry by using inquiries
   back to the caller to ask for a passphrase.  This option may only be
   set if the agent has been configured for that.
   Use the @xref{option --allow-loopback-pinentry}.
 
-- 
2.7.4



From curt at brune.net  Sat Jan  7 06:56:52 2017
From: curt at brune.net (Curt Brune)
Date: Fri,  6 Jan 2017 21:56:52 -0800
Subject: [PATCH v2 0/1] pinentry-mode: multi-sdcard convenience option
Message-ID: <1483768613-9096-1-git-send-email-curt@brune.net>

This patch introduces a new pinetry-mode option that is convenient when
the user has encrypted data for multiple card recipients.

The patch is made against gnupg tag gnupg-2.1.11, which is the version
that comes with my Ubuntu 16.04 system.

Changes from v1:

 - instead of having the option be a gpg-agent option, add the option
   as a new pinentry-mode.

Curt Brune (1):
  pinentry-mode: add new mode no-card-cancel-prompt

 agent/call-pinentry.c |  3 ++-
 agent/divert-scd.c    |  5 +++++
 common/agent-opt.c    | 11 +++++++----
 common/shareddefs.h   |  9 +++++----
 doc/gpg-agent.texi    |  4 ++++
 5 files changed, 23 insertions(+), 9 deletions(-)

-- 
2.7.4



From ineiev at gnu.org  Sat Jan  7 16:06:34 2017
From: ineiev at gnu.org (Ineiev)
Date: Sat, 7 Jan 2017 10:06:34 -0500
Subject: [PATCH HEAD] i18n fixes
In-Reply-To: <87y3yo8nxp.wl-neal@walfield.org>
References: <20161005142930.GO30569@gnu.org> <87y3yo8nxp.wl-neal@walfield.org>
Message-ID: <20170107150633.GS10490@gnu.org>

Hello, Neal;

On Fri, Jan 06, 2017 at 11:47:46AM +0100, Neal H. Walfield wrote:
> 
> I tried to clean up the major issues about a month ago.

Thank you, it looks much better now.

> Would you be
> willing to have a look at tofu.c again and point out any serious
> issues.

Sometimes tofu_policy_str () is used in translated strings.  I think
a translated version should be used in such cases.

Lines 1630..1633,

          es_fprintf (fp, "  %s (", other_user_id);
          es_fprintf (fp, _("policy: %s"), tofu_policy_str (other_policy));
          es_fprintf (fp, ")\n");

may translate better if joint in a single message.

The ngettext on lines 3215..3228,

    (ngettext
     ("Warning: if you think you've seen more signatures "
      "by this key and user id, then this key might be a "
      "forgery!  Carefully examine the email address for small "
      "variations.  If the key is suspect, then use\n"
      "  %s\n"
      "to mark it as being bad.\n",
      "Warning: if you think you've seen more signatures "
      "by this key and these user ids, then this key might be a "
      "forgery!  Carefully examine the email addresses for small "
      "variations.  If the key is suspect, then use\n"
      "  %s\n"
      "to mark it as being bad.\n",
      strlist_length (user_id_list)),

makes little sense, the message uses no integer parameters.

> Also, I'm a bit confused about the issue with the "revoked" and
> "expired" strings.  They are used as a list of attributes.  What type
> of context do you want?

In GPG, "revoked" and "expired" may modify "signature", "binding",
"key" (and possibly more), their translations in many European
languages may have three different grammatical genders, and the form
of the adjective depends on the gender of the noun it modifies.
if the program uses _("revoked"), gettext has to substitute the same
form in all cases, so it's impossible to match different genders.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: 

From wk at gnupg.org  Mon Jan  9 11:34:24 2017
From: wk at gnupg.org (Werner Koch)
Date: Mon, 09 Jan 2017 11:34:24 +0100
Subject: gpg 2.1.15, *no* keyservers found for submit/recv,
 "DNS query returned an error or no records: No such domain (nxdomain)"
In-Reply-To: <1476027783.1522252.750391089.07374952@webmail.messagingengine.com>
 (lists@ssl-mail.com's message of "Sun, 09 Oct 2016 08:43:03 -0700")
References: <1476027783.1522252.750391089.07374952@webmail.messagingengine.com>
Message-ID: <87bmvgo72n.fsf@wheatstone.g10code.de>

Hi,

I unfortunately missed this discussion due to my vacation. So let me
mention for the records that bugs 2451 and 2745 track this discussion.

As stated in 2451 I pushed two patches today which may be the solution
to the bugs:

0cc975d dirmngr: Use "pgpkey-hkps" and "pgpkey-hkp" for SRV record lookups.
c2cbe2f dirmngr: Do not use a SRV record for HKP if a port was specified.


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: 227 bytes
Desc: not available
URL: 

From dkg at fifthhorseman.net  Tue Jan 10 22:16:15 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 10 Jan 2017 16:16:15 -0500
Subject: [PATCH] common: Avoid unnecessary ambiguity in argparse.
Message-ID: <20170110211615.19533-1-dkg@fifthhorseman.net>

* common/argparse.c (find_long_option): Avoid unnecessary ambiguity.

If two struct ARGPARSE_OPTS share a prefix in their long_opt name, but
have the exact same short_opt and flags, they are aliases and not
distinct options.  Avoid reporting this as an ambiguity, so that (for
example) both --clearsign and --clear-sign can be invoked as --clear.

Signed-off-by: Daniel Kahn Gillmor 
Debian-Bug-Id: 850475
---
 common/argparse.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/common/argparse.c b/common/argparse.c
index dce725af9..d395229ad 100644
--- a/common/argparse.c
+++ b/common/argparse.c
@@ -898,7 +898,9 @@ find_long_option( ARGPARSE_ARGS *arg,
 	    int j;
 	    for(j=i+1; opts[j].short_opt; j++ ) {
 		if( opts[j].long_opt
-		    && !strncmp( opts[j].long_opt, keyword, n ) )
+		    && !strncmp( opts[j].long_opt, keyword, n )
+                    && !(opts[j].short_opt == opts[i].short_opt
+                         && opts[j].flags == opts[i].flags ) )
 		    return -2;	/* abbreviation is ambiguous */
 	    }
 	    return i;
-- 
2.11.0



From dkg at fifthhorseman.net  Tue Jan 10 23:55:02 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 10 Jan 2017 17:55:02 -0500
Subject: [LIBGPG-ERROR PATCH] refer to --with-libgpg-error-prefix,
 instead of --with-gpg-error-prefix
In-Reply-To: <8737og3k0b.fsf@alice.fifthhorseman.net>
References: <1454956291-3542-1-git-send-email-dkg@fifthhorseman.net>
 <8737og3k0b.fsf@alice.fifthhorseman.net>
Message-ID: <87vatmseyh.fsf@alice.fifthhorseman.net>

On Mon 2016-06-13 16:35:00 -0400, Daniel Kahn Gillmor wrote:
> On Mon 2016-02-08 13:31:31 -0500, Daniel Kahn Gillmor wrote:
>> * src/gpg-error.m4: announce the preferred form of configuration,
>>   since --with-gpg-error-prefix is deprecated earlier in the file.
>> ---
>>  src/gpg-error.m4 | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/gpg-error.m4 b/src/gpg-error.m4
>> index 1661204..60c88d8 100644
>> --- a/src/gpg-error.m4
>> +++ b/src/gpg-error.m4
>> @@ -100,7 +100,7 @@ AC_DEFUN([AM_PATH_GPG_ERROR],
>>  *** The config script $GPG_ERROR_CONFIG was
>>  *** built for $gpg_error_config_host and thus may not match the
>>  *** used host $host.
>> -*** You may want to use the configure option --with-gpg-error-prefix
>> +*** You may want to use the configure option --with-libgpg-error-prefix
>>  *** to specify a matching config script or use \$SYSROOT.
>>  ***]])
>>          gpg_config_script_warn="$gpg_config_script_warn libgpg-error"
>> -- 
>
> Is there a reason to avoid applying this upstream?  In case it helps:

I've gone ahead and applied an improved version of this patch to the git
master branch.

     --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: 

From dkg at fifthhorseman.net  Wed Jan 11 00:58:55 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 10 Jan 2017 18:58:55 -0500
Subject: self-sigs with weaker hashes
Message-ID: <871swasc00.fsf@alice.fifthhorseman.net>

hey all--

please take a look at the behavior of gpg 2.1.17 with key
DC418BB65BF51BA86B845A48308B0A7BD8DEC2EC

This is a 3072-bit DSA key with two User IDs.

One of the User IDs has four self-sigs on it, two of which appear to be
SHA1 (gpg produces the error message):

 gpg: DSA key 308B0A7BD8DEC2EC requires a 256 bit or larger hash (hash is SHA1)

The "bad" ones are made between two "good" ones, according to their
timestamps.  From --check-sigs:

sig!3        308B0A7BD8DEC2EC 2015-08-09  ***User ID REDACTED***
sig%3        308B0A7BD8DEC2EC 2015-08-22  [General error] 
sig%3        308B0A7BD8DEC2EC 2015-08-22  [General error] 
sig!3        308B0A7BD8DEC2EC 2016-06-05  ***User ID REDACTED***

Should gpg just ignore or filter out the "bad" self-sigs that it doesn't
think are valid, rather than leaking warnings every time the key is
encountered?

Even if gpg wants to keep around the "bad" self-sigs, since there is a
more recent self-sig that isn't invalid, shouldn't gpg swallow that
warning?  This seems like a case of noise that is just distracting for
most users, when gpg can figure out the Right Thing to do here anyway.

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: 

From wk at gnupg.org  Wed Jan 11 08:07:20 2017
From: wk at gnupg.org (Werner Koch)
Date: Wed, 11 Jan 2017 08:07:20 +0100
Subject: [PATCH] common: Avoid unnecessary ambiguity in argparse.
In-Reply-To: <20170110211615.19533-1-dkg@fifthhorseman.net> (Daniel Kahn
 Gillmor's message of "Tue, 10 Jan 2017 16:16:15 -0500")
References: <20170110211615.19533-1-dkg@fifthhorseman.net>
Message-ID: <87d1fujcrb.fsf@wheatstone.g10code.de>

On Tue, 10 Jan 2017 22:16, dkg at fifthhorseman.net said:

> If two struct ARGPARSE_OPTS share a prefix in their long_opt name, but
> have the exact same short_opt and flags, they are aliases and not

Smart.  Please push with the usual two dashes before the free form
text.


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: 227 bytes
Desc: not available
URL: 

From wk at gnupg.org  Wed Jan 11 08:08:00 2017
From: wk at gnupg.org (Werner Koch)
Date: Wed, 11 Jan 2017 08:08:00 +0100
Subject: [LIBGPG-ERROR PATCH] refer to --with-libgpg-error-prefix,
 instead of --with-gpg-error-prefix
In-Reply-To: <87vatmseyh.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Tue, 10 Jan 2017 17:55:02 -0500")
References: <1454956291-3542-1-git-send-email-dkg@fifthhorseman.net>
 <8737og3k0b.fsf@alice.fifthhorseman.net>
 <87vatmseyh.fsf@alice.fifthhorseman.net>
Message-ID: <878tqijcq7.fsf@wheatstone.g10code.de>

On Tue, 10 Jan 2017 23:55, dkg at fifthhorseman.net said:
>> Is there a reason to avoid applying this upstream?  In case it helps:
>
> I've gone ahead and applied an improved version of this patch to the git
> master branch.

Thanks.


Shalom-Salam,

   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: 227 bytes
Desc: not available
URL: 

From wk at gnupg.org  Wed Jan 11 08:19:59 2017
From: wk at gnupg.org (Werner Koch)
Date: Wed, 11 Jan 2017 08:19:59 +0100
Subject: self-sigs with weaker hashes
In-Reply-To: <871swasc00.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Tue, 10 Jan 2017 18:58:55 -0500")
References: <871swasc00.fsf@alice.fifthhorseman.net>
Message-ID: <874m16jc68.fsf@wheatstone.g10code.de>

On Wed, 11 Jan 2017 00:58, dkg at fifthhorseman.net said:

> Should gpg just ignore or filter out the "bad" self-sigs that it doesn't
> think are valid, rather than leaking warnings every time the key is
> encountered?

I general I would say yes.  I use --check-sigs to look for such bogus
signatures and thus we would need to add a new --verify-option to allow
printing them.

Or we could try to suppress the 

  gpg: DSA key 308B0A7BD8DEC2EC requires a 256 bit or larger hash (hash is SHA1)

line and output

  sig%3        308B0A7BD8DEC2EC 2015-08-22  [Key requires a 256 bit or
  larger hash (hash is SHA1)] 

However, that  might be larger chage and too late for 2.2.


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: 227 bytes
Desc: not available
URL: 

From nathan at nathanrossi.com  Thu Jan 12 05:52:25 2017
From: nathan at nathanrossi.com (Nathan Rossi)
Date: Thu, 12 Jan 2017 14:52:25 +1000
Subject: [PATCH] configure.ac: Set 'mym4_revision' to 0 if not a git repo
Message-ID: <20170112045225.11269-1-nathan@nathanrossi.com>

---
It is possible for the source to not be located in a git repository
(e.g. source is from a tarball). In which case the git repository
information is not available. This results in the mym4_revision being an
empty string however this value is used in BUILD_FILEVERSION where it is
assumed to be 4 decimal values. Additionally BUILD_REVISION uses this
value and is also assumed to be non-empty.

In the case of BUILD_FILEVERSION it is used in versioninfo.rc.in, where
it must be populated as 4 decimal values due to the expected syntax. In
cases where it is not (e.g. when BUILD_FILEVERSION = '1,26,0,' a syntax
error is raised.

    windres: versioninfo.rc.in:21: syntax error

This patch changes mym4_revision so that if the 'git rev-parse' returns
non-zero (e.g. not in a git repository) the value falls back to '0'.
This propagates as '0' to both BUILD_FILEVERSION and BUILD_REVISION.

Signed-off-by: Nathan Rossi 
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 6d4f173d1b..149ac02b5f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -35,7 +35,7 @@ m4_define([mym4_version_minor], [27])
 # processing is done by autoconf and not during the configure run.
 m4_define([mym4_version], [mym4_version_major.mym4_version_minor])
 m4_define([mym4_revision],
-          m4_esyscmd([git rev-parse --short HEAD | tr -d '\n\r']))
+          m4_esyscmd([(git rev-parse --short HEAD || printf '0') | tr -d '\n\r']))
 m4_define([mym4_revision_dec],
           m4_esyscmd_s([echo $((0x$(echo ]mym4_revision[|head -c 4)))]))
 m4_define([mym4_betastring],
-- 
2.11.0



From nathan at nathanrossi.com  Thu Jan 12 05:56:00 2017
From: nathan at nathanrossi.com (Nathan Rossi)
Date: Thu, 12 Jan 2017 14:56:00 +1000
Subject: [PATCH] configure.ac: Set 'mym4_revision' to 0 if not a git repo
In-Reply-To: <20170112045225.11269-1-nathan@nathanrossi.com>
References: <20170112045225.11269-1-nathan@nathanrossi.com>
Message-ID: 

On 12 January 2017 at 14:52, Nathan Rossi  wrote:
> ---

Sorry, this should have "libgpg-error" in the subject. This patch is
for libgpg-error specifically.

Regards,
Nathan

> It is possible for the source to not be located in a git repository
> (e.g. source is from a tarball). In which case the git repository
> information is not available. This results in the mym4_revision being an
> empty string however this value is used in BUILD_FILEVERSION where it is
> assumed to be 4 decimal values. Additionally BUILD_REVISION uses this
> value and is also assumed to be non-empty.
>
> In the case of BUILD_FILEVERSION it is used in versioninfo.rc.in, where
> it must be populated as 4 decimal values due to the expected syntax. In
> cases where it is not (e.g. when BUILD_FILEVERSION = '1,26,0,' a syntax
> error is raised.
>
>     windres: versioninfo.rc.in:21: syntax error
>
> This patch changes mym4_revision so that if the 'git rev-parse' returns
> non-zero (e.g. not in a git repository) the value falls back to '0'.
> This propagates as '0' to both BUILD_FILEVERSION and BUILD_REVISION.
>
> Signed-off-by: Nathan Rossi 
> ---
>  configure.ac | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
> index 6d4f173d1b..149ac02b5f 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -35,7 +35,7 @@ m4_define([mym4_version_minor], [27])
>  # processing is done by autoconf and not during the configure run.
>  m4_define([mym4_version], [mym4_version_major.mym4_version_minor])
>  m4_define([mym4_revision],
> -          m4_esyscmd([git rev-parse --short HEAD | tr -d '\n\r']))
> +          m4_esyscmd([(git rev-parse --short HEAD || printf '0') | tr -d '\n\r']))
>  m4_define([mym4_revision_dec],
>            m4_esyscmd_s([echo $((0x$(echo ]mym4_revision[|head -c 4)))]))
>  m4_define([mym4_betastring],
> --
> 2.11.0
>


From gniibe at fsij.org  Fri Jan 13 06:06:43 2017
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Fri, 13 Jan 2017 14:06:43 +0900
Subject: scd: support multiple tokens simultaneously
Message-ID: <1484284003.1145.3.camel@fsij.org>

Hello,

This is an interim report which explains multiple tokens
now works for me for decryption and signing.

The gpg-agent <-> scdaemon protocol is extended to allow SERIALNO
command to have --demand= option.

(1) Query to open card readers / token, expecting the serial number of
????the card

????SERIALNO

(2) Ask matched application on a card

????SERIALNO opengpg

(3) Ask specific card/token with ?

????SERIALNO --demand=

Authentication is not yet supported.


diff --git a/agent/agent.h b/agent/agent.h
index 89dc46d..2db5a5c 100644
--- a/agent/agent.h
+++ b/agent/agent.h
@@ -532,7 +532,7 @@ int agent_card_learn (ctrl_t ctrl,
???????????????????????void (*sinfo_cb)(void*, const char *,
????????????????????????????????????????size_t, const char *),
???????????????????????void *sinfo_cb_arg);
-int agent_card_serialno (ctrl_t ctrl, char **r_serialno);
+int agent_card_serialno (ctrl_t ctrl, char **r_serialno, const char
*demand);
?int agent_card_pksign (ctrl_t ctrl,
????????????????????????const char *keyid,
????????????????????????int (*getpin_cb)(void *, const char *, char*,
size_t),
diff --git a/agent/call-scd.c b/agent/call-scd.c
index ba59c18..15a2ba5 100644
--- a/agent/call-scd.c
+++ b/agent/call-scd.c
@@ -679,16 +679,22 @@ get_serialno_cb (void *opaque, const char *line)
?/* Return the serial number of the card or an appropriate error.??The
????serial number is returned as a hexstring. */
?int
-agent_card_serialno (ctrl_t ctrl, char **r_serialno)
+agent_card_serialno (ctrl_t ctrl, char **r_serialno, const char
*demand)
?{
???int rc;
???char *serialno = NULL;
+??char line[ASSUAN_LINELENGTH];
?
???rc = start_scd (ctrl);
???if (rc)
?????return rc;
?
-??rc = assuan_transact (ctrl->scd_local->ctx, "SERIALNO",
+??if (!demand)
+????strcpy (line, "SERIALNO");
+??else
+????snprintf (line, DIM(line), "SERIALNO --demand=%s", demand);
+
+??rc = assuan_transact (ctrl->scd_local->ctx, line,
?????????????????????????NULL, NULL, NULL, NULL,
?????????????????????????get_serialno_cb, &serialno);
???if (rc)
diff --git a/agent/command-ssh.c b/agent/command-ssh.c
index 95cef41..79cb057 100644
--- a/agent/command-ssh.c
+++ b/agent/command-ssh.c
@@ -2408,7 +2408,7 @@ card_key_available (ctrl_t ctrl, gcry_sexp_t
*r_pk, char **cardsn)
???if ( gpg_err_code (err) == GPG_ERR_CARD_REMOVED )
?????{
???????/* Ask for the serial number to reset the card.??*/
-??????err = agent_card_serialno (ctrl, &serialno);
+??????err = agent_card_serialno (ctrl, &serialno, NULL);
???????if (err)
?????????{
???????????if (opt.verbose)
diff --git a/agent/divert-scd.c b/agent/divert-scd.c
index 7b07008..7331f58 100644
--- a/agent/divert-scd.c
+++ b/agent/divert-scd.c
@@ -58,7 +58,7 @@ ask_for_card (ctrl_t ctrl, const unsigned char
*shadow_info, char **r_kid)
?
???for (;;)
?????{
-??????rc = agent_card_serialno (ctrl, &serialno);
+??????rc = agent_card_serialno (ctrl, &serialno, want_sn);
???????if (!rc)
?????????{
???????????log_debug ("detected card with S/N %s\n", serialno);
@@ -72,11 +72,17 @@ ask_for_card (ctrl_t ctrl, const unsigned char
*shadow_info, char **r_kid)
???????????????return 0; /* yes, we have the correct card */
?????????????}
?????????}
+??????else if (gpg_err_code (rc) == GPG_ERR_ENODEV)
+????????{
+??????????log_debug ("no device present\n");
+??????????rc = 0;
+??????????no_card = 1;
+????????}
???????else if (gpg_err_code (rc) == GPG_ERR_CARD_NOT_PRESENT)
?????????{
???????????log_debug ("no card present\n");
???????????rc = 0;
-??????????no_card = 1;
+??????????no_card = 2;
?????????}
???????else
?????????{
diff --git a/agent/learncard.c b/agent/learncard.c
index 57bce7a..cce9c3a 100644
--- a/agent/learncard.c
+++ b/agent/learncard.c
@@ -330,7 +330,7 @@ agent_handle_learn (ctrl_t ctrl, int send, void
*assuan_context, int force)
???cparm.ctrl = ctrl;
?
???/* Check whether a card is present and get the serial number */
-??rc = agent_card_serialno (ctrl, &serialno);
+??rc = agent_card_serialno (ctrl, &serialno, NULL);
???if (rc)
?????goto leave;
?
diff --git a/scd/app-common.h b/scd/app-common.h
index 2371818..fb0fe55 100644
--- a/scd/app-common.h
+++ b/scd/app-common.h
@@ -129,7 +129,8 @@ void application_notify_card_reset (int slot);
?gpg_error_t check_application_conflict (const char *name, app_t app);
?gpg_error_t app_reset (app_t app, ctrl_t ctrl, int send_reset);
?gpg_error_t select_application (ctrl_t ctrl, const char *name, app_t
*r_app,
-????????????????????????????????int scan);
+????????????????????????????????int scan, const unsigned char
*serialno_bin,
+????????????????????????????????size_t serialno_bin_len);
?char *get_supported_applications (void);
?void release_application (app_t app);
?gpg_error_t app_munge_serialno (app_t app);
diff --git a/scd/app.c b/scd/app.c
index 6db9e27..06850d8 100644
--- a/scd/app.c
+++ b/scd/app.c
@@ -317,10 +317,12 @@ app_new_register (int slot, ctrl_t ctrl, const
char *name)
????and return a context.??Returns an error code and stores NULL at
????R_APP if no application was found or no card is present. */
?gpg_error_t
-select_application (ctrl_t ctrl, const char *name, app_t *r_app, int
scan)
+select_application (ctrl_t ctrl, const char *name, app_t *r_app,
+????????????????????int scan, const unsigned char *serialno_bin,
+????????????????????size_t serialno_bin_len)
?{
???gpg_error_t err = 0;
-??app_t app;
+??app_t a;
?
???*r_app = NULL;
?
@@ -352,33 +354,50 @@ select_application (ctrl_t ctrl, const char
*name, app_t *r_app, int scan)
?
???????????if (!sw || sw == SW_HOST_ALREADY_CONNECTED)
?????????????err = 0;
+??????????else if (sw == SW_HOST_NO_CARD)
+????????????err = gpg_error (GPG_ERR_CARD_NOT_PRESENT);
???????????else
?????????????err = gpg_error (GPG_ERR_ENODEV);
?
???????????if (!err)
?????????????err = app_new_register (slot, ctrl, name);
???????????else
-????????????apdu_close_reader (slot);
+????????????{
+??????????????/* We close a reader with no card.??*/
+??????????????apdu_close_reader (slot);
+????????????}
?????????}
?
???????apdu_dev_list_finish (l);
?????}
?
-??app = app_top;
-??if (app)
+??npth_mutex_lock (&app_list_lock);
+??for (a = app_top; a; a = a->next)
?????{
-??????lock_app (app, ctrl);
-??????err = check_conflict (app, name);
+??????lock_app (a, ctrl);
+??????if (serialno_bin == NULL)
+????????break;
+??????if (a->serialnolen == serialno_bin_len
+??????????&& !memcmp (a->serialno, serialno_bin, a->serialnolen))
+????????break;
+??????unlock_app (a);
+????}
+
+??if (a)
+????{
+??????err = check_conflict (a, name);
???????if (!err)
?????????{
-??????????app->ref_count++;
-??????????*r_app = app;
+??????????a->ref_count++;
+??????????*r_app = a;
?????????}
-??????unlock_app (app);
+??????unlock_app (a);
?????}
???else
?????err = gpg_error (GPG_ERR_ENODEV);
?
+??npth_mutex_unlock (&app_list_lock);
+
???return err;
?}
?
diff --git a/scd/command.c b/scd/command.c
index ce2be34..7592181 100644
--- a/scd/command.c
+++ b/scd/command.c
@@ -193,9 +193,11 @@ option_handler (assuan_context_t ctx, const char
*key, const char *value)
?
?/* If the card has not yet been opened, do it.??*/
?static gpg_error_t
-open_card (ctrl_t ctrl, const char *apptype, int scan)
+open_card (ctrl_t ctrl, const char *apptype, const char *demand)
?{
???gpg_error_t err;
+??unsigned char *serialno_bin;
+??size_t serialno_bin_len = 0;
?
???/* If we ever got a card not present error code, return that.??Only
??????the SERIALNO command and a reset are able to clear from that
@@ -209,21 +211,31 @@ open_card (ctrl_t ctrl, const char *apptype, int
scan)
???/* If we are already initialized for one specific application we
??????need to check that the client didn't requested a specific
??????application different from the one in use before we continue. */
-??if (!scan && ctrl->app_ctx)
+??if (!demand && ctrl->app_ctx)
?????return check_application_conflict (apptype, ctrl->app_ctx);
?
-??err = select_application (ctrl, apptype, &ctrl->app_ctx, scan);
+??if (demand && *demand)
+????serialno_bin = hex_to_buffer (demand, &serialno_bin_len);
+??else
+????serialno_bin = NULL;
+
+??err = select_application (ctrl, apptype, &ctrl->app_ctx, demand !=
NULL,
+????????????????????????????serialno_bin, serialno_bin_len);
+??xfree (serialno_bin);
?
???return err;
?}
?
?
?static const char hlp_serialno[] =
-??"SERIALNO []\n"
+??"SERIALNO [--demand=] []\n"
???"\n"
???"Return the serial number of the card using a status
response.??This\n"
???"function should be used to check for the presence of a card.\n"
???"\n"
+??"If --demand is given, an application on the card with SERIALNO
is\n"
+??"selected and an error is returned if no such card available.\n"
+??"\n"
???"If APPTYPE is given, an application of that type is selected and
an\n"
???"error is returned if the application is not supported or
available.\n"
???"The default is to auto-select the application using a hardwired\n"
@@ -245,6 +257,20 @@ cmd_serialno (assuan_context_t ctx, char *line)
???int rc = 0;
???char *serial;
???time_t stamp;
+??const char *demand;
+
+??if ((demand = has_option_name (line, "--demand")))
+????{
+??????if (*demand != '=')
+????????return set_error (GPG_ERR_ASS_PARAMETER, "missing value for
option");
+??????line = (char *)++demand;
+??????for (; *line && !spacep (line); line++)
+????????;
+??????if (*line)
+????????*line++ = 0;
+????}
+??else
+????demand = "";
?
???/* Clear the remove flag so that the open_card is able to reread
it.??*/
???if (ctrl->server_local->card_removed)
@@ -255,7 +281,7 @@ cmd_serialno (assuan_context_t ctx, char *line)
???????ctrl->server_local->card_removed = 0;
?????}
?
-??if ((rc = open_card (ctrl, *line? line:NULL, 1)))
+??if ((rc = open_card (ctrl, *line? line:NULL, demand)))
?????{
???????ctrl->server_local->card_removed = 1;
???????return rc;
@@ -270,7 +296,7 @@ cmd_serialno (assuan_context_t ctx, char *line)
?????????c->server_local->card_removed = 0;
?????}
?
-??rc = app_get_serial_and_stamp (ctrl->app_ctx, &serial, &stamp);
+??rc = app_get_serial_and_stamp (ctrl->app_ctx, &serial, &stamp);//???
???if (rc)
?????return rc;
?
@@ -357,7 +383,7 @@ cmd_learn (assuan_context_t ctx, char *line)
???int rc = 0;
???int only_keypairinfo = has_option (line, "--keypairinfo");
?
-??if ((rc = open_card (ctrl, NULL, 0)))
+??if ((rc = open_card (ctrl, NULL, NULL)))
?????return rc;
?
???/* Unless the force option is used we try a shortcut by identifying
@@ -440,7 +466,7 @@ cmd_readcert (assuan_context_t ctx, char *line)
???unsigned char *cert;
???size_t ncert;
?
-??if ((rc = open_card (ctrl, NULL, 0)))
+??if ((rc = open_card (ctrl, NULL, NULL)))
?????return rc;
?
???line = xstrdup (line); /* Need a copy of the line. */
@@ -482,7 +508,7 @@ cmd_readkey (assuan_context_t ctx, char *line)
???unsigned char *pk;
???size_t pklen;
?
-??if ((rc = open_card (ctrl, NULL, 0)))
+??if ((rc = open_card (ctrl, NULL, NULL)))
?????return rc;
?
???if (has_option (line, "--advanced"))
@@ -704,7 +730,7 @@ cmd_pksign (assuan_context_t ctx, char *line)
?
???line = skip_options (line);
?
-??if ((rc = open_card (ctrl, NULL, 0)))
+??if ((rc = open_card (ctrl, NULL, NULL)))
?????return rc;
?
???/* We have to use a copy of the key ID because the function may use
@@ -748,7 +774,7 @@ cmd_pkauth (assuan_context_t ctx, char *line)
???size_t outdatalen;
???char *keyidstr;
?
-??if ((rc = open_card (ctrl, NULL, 0)))
+??if ((rc = open_card (ctrl, NULL, NULL)))
?????return rc;
?
???if (!ctrl->app_ctx)
@@ -793,7 +819,7 @@ cmd_pkdecrypt (assuan_context_t ctx, char *line)
???char *keyidstr;
???unsigned int infoflags;
?
-??if ((rc = open_card (ctrl, NULL, 0)))
+??if ((rc = open_card (ctrl, NULL, NULL)))
?????return rc;
?
???keyidstr = xtrystrdup (line);
@@ -846,7 +872,7 @@ cmd_getattr (assuan_context_t ctx, char *line)
???int rc;
???const char *keyword;
?
-??if ((rc = open_card (ctrl, NULL, 0)))
+??if ((rc = open_card (ctrl, NULL, NULL)))
?????return rc;
?
???keyword = line;
@@ -888,7 +914,7 @@ cmd_setattr (assuan_context_t ctx, char *orig_line)
???size_t nbytes;
???char *line, *linebuf;
?
-??if ((rc = open_card (ctrl, NULL, 0)))
+??if ((rc = open_card (ctrl, NULL, NULL)))
?????return rc;
?
???/* We need to use a copy of LINE, because PIN_CB uses the same
@@ -943,7 +969,7 @@ cmd_writecert (assuan_context_t ctx, char *line)
?????line++;
???*line = 0;
?
-??if ((rc = open_card (ctrl, NULL, 0)))
+??if ((rc = open_card (ctrl, NULL, NULL)))
?????return rc;
?
???if (!ctrl->app_ctx)
@@ -1005,7 +1031,7 @@ cmd_writekey (assuan_context_t ctx, char *line)
?????line++;
???*line = 0;
?
-??if ((rc = open_card (ctrl, NULL, 0)))
+??if ((rc = open_card (ctrl, NULL, NULL)))
?????return rc;
?
???if (!ctrl->app_ctx)
@@ -1092,7 +1118,7 @@ cmd_genkey (assuan_context_t ctx, char *line)
?????line++;
???*line = 0;
?
-??if ((rc = open_card (ctrl, NULL, 0)))
+??if ((rc = open_card (ctrl, NULL, NULL)))
?????return rc;
?
???if (!ctrl->app_ctx)
@@ -1130,7 +1156,7 @@ cmd_random (assuan_context_t ctx, char *line)
???????????????????????"number of requested bytes missing");
???nbytes = strtoul (line, NULL, 0);
?
-??if ((rc = open_card (ctrl, NULL, 0)))
+??if ((rc = open_card (ctrl, NULL, NULL)))
?????return rc;
?
???if (!ctrl->app_ctx)
@@ -1183,7 +1209,7 @@ cmd_passwd (assuan_context_t ctx, char *line)
?????line++;
???*line = 0;
?
-??if ((rc = open_card (ctrl, NULL, 0)))
+??if ((rc = open_card (ctrl, NULL, NULL)))
?????return rc;
?
???if (!ctrl->app_ctx)
@@ -1240,7 +1266,7 @@ cmd_checkpin (assuan_context_t ctx, char *line)
???int rc;
???char *idstr;
?
-??if ((rc = open_card (ctrl, NULL, 0)))
+??if ((rc = open_card (ctrl, NULL, NULL)))
?????return rc;
?
???if (!ctrl->app_ctx)
@@ -1531,7 +1557,7 @@ cmd_apdu (assuan_context_t ctx, char *line)
?
???line = skip_options (line);
?
-??if ((rc = open_card (ctrl, NULL, 0)))
+??if ((rc = open_card (ctrl, NULL, NULL)))
?????return rc;
?
???app = ctrl->app_ctx;
--

From amzh at hushmail.com  Sat Jan 14 14:45:16 2017
From: amzh at hushmail.com (Andrey Mozharovskiy)
Date: Sat, 14 Jan 2017 16:45:16 +0300
Subject: Question about key generation
Message-ID: <20170114134517.3FB52200F3@smtp.hushmail.com>

Hello,
we're trying to generate a pair of Rsa keys (public/private), using
the latest release of libgcrypt sources,
we're using the following method:
	    gcry_sexp_t keyparm, key; 

	    int rc = -1; 
	    rc = gcry_sexp_new (&keyparm, 

	                        "(genkeyn" 

	                        " (rsan" 

	                        "  (nbits 4:2048)n" 

	                        " ))", 0, 1); 

	    if (rc) 

	        return boost::make_tuple("", ""); 
	    rc = gcry_pk_genkey (&key, keyparm); 
	    if (rc) 

	        return boost::make_tuple("", ""); 
	    gcry_sexp_t pubkey = gcry_sexp_find_token(key, "public-key", 0); 

	    size_t length_publ =
gcry_sexp_sprint(pubkey,GCRYSEXP_FMT_ADVANCED,NULL,0); 

	    char *buffer_publ = (char*)
gcry_malloc(length_publ*sizeof(char)); 

	    size_t offset_publ =
gcry_sexp_sprint(pubkey,GCRYSEXP_FMT_ADVANCED,buffer_publ,length_publ);

	    gcry_sexp_t privkey = gcry_sexp_find_token(key, "private-key",
0); 

	    size_t length_priv =
gcry_sexp_sprint(privkey,GCRYSEXP_FMT_ADVANCED,NULL,0); 

	    char *buffer_priv = (char*)
gcry_malloc(length_priv*sizeof(char)); 

	    size_t offset_priv =
gcry_sexp_sprint(privkey,GCRYSEXP_FMT_ADVANCED,buffer_priv,length_priv);
	Thus, we now have two keys, problem is they're both exactly identical
each time we generate them..
	E.g. both keys are:
	(char *) buffer_publ = 0x00007fddf0d0f0e0 "(public-key n (rsa n  (n
#00B30C503943A56EBD82AEC5A8CFDC49563BBD3A7E3938973F7642BAC50CA4CC26917B9DD7BF6840CF310EFB3910EE166312BA38FE8B0AC987FD2DF8D55342B6378AA49061C302A1776B897CC11A0D08558C4C0E6C1A86E7CD8A858A2D6786C29577829B8401A2DBEF8FA106F98195ED98B9745F7BC8B02048B1DBA33D12E78DC1E34F0C59E4205C8EEB5C6E0926DFD560E9EB36D42C3161FCA5C92D9C1AE64795C68D312C167803A685709C52D9FFF7914FCF1143BF9134A6ED0F30525A83DD950979D61098F953C70C2D91998F886B403295D82837BF0C9664842D92E94404A606882C326A44802E105574A7754EF073C9DC4B7593E7D429AD33DA9B5276A705#)n
 (e #010001#)n  )n )n
	(same value for buffer_priv)
	Please clarify, whether we should generate a pair of keys two times
and hence get different keys, or use a different method? 
	Regards, Andrey.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From dgouttegattat at incenp.org  Sun Jan 15 15:21:05 2017
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Sun, 15 Jan 2017 15:21:05 +0100
Subject: Using Scute with a 4096-bit key and TLSv1.2?
In-Reply-To: <87wpe88ngb.wl-neal@walfield.org>
References: <20160927102322.GB1692@eridan.ccs.ecp.fr>
 
 <20160928093938.GA2731@eridan.ccs.ecp.fr>
 <878tuc15j0.fsf@wheatstone.g10code.de> <87wpe88ngb.wl-neal@walfield.org>
Message-ID: <8170399c-bd8c-3b06-11c8-1d753245ea75@incenp.org>

On 01/06/2017 11:58 AM, Neal H. Walfield wrote:
> On Wed, 28 Sep 2016 16:08:03 +0200,
> Werner Koch wrote:
>> On Wed, 28 Sep 2016 11:39, nicolas.boullis at ecp.fr said:
>>
>>> The other question remains: is there any plan to release Scute 1.5
>>> anytime soon?
>>
>> Damien: What do you think, shall I do a release?
>
> Ping.  Although Damien confirmed that a release would be a good idea,
> it looks like a release was never done.

Hold on, I have just noticed that there's a small problem with Scute 
right now: It still relies on the GPG_AGENT_INFO environment variable to 
locate the socket of a running GnuPG Agent (even though this variable is 
obsolete since the beginning of the 2.1 branch), and when it cannot find 
this variable, it tries looking for the standard socket only under 
GnuPG's home directory and not under [/var]/run.

As a consequence, when used with GnuPG >= 2.1.13, Scute will never find 
the agent's socket and thus will never be able to connect to an already 
running agent. It will still work somehow because Scute will then launch 
an agent in "pipe server" mode (that's why I did not notice the problem 
before), but I think it would be better to update Scute so that it can 
properly locate the socket.

I am working on it, hopefully I will send a patch soon.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: 

From kroosec at gmail.com  Sun Jan 15 20:23:10 2017
From: kroosec at gmail.com (Hani Benhabiles)
Date: Sun, 15 Jan 2017 20:23:10 +0100
Subject: KSBA: Using names of OID from different sources
Message-ID: <20170115192310.3hxebmq32iwkcerm@kroosec-Inspiron-3521>

Hi all,

Is there a reason for dn.c:append_atv() being restricted to only use names for OIDs
which are in rfc2253 ?

eg. while openssl s_client converts "1.2.840.113549.1.9.1" to emailAddress:

issuer=/C=XX/ST=There is no such thing outside US/L=Everywhere/O=OCOSA/OU=Office
for Complication of Otherwise Simple
Affairs/CN=ubuntu804-base.localdomain/emailAddress=root at ubuntu804-base.localdomain

Calling ksba_cert_get_issuer() would return this:

1.2.840.113549.1.9.1=#726F6F74407562756E74753830342D626173652E6C6F63616C646F6D61696E,CN=ubuntu804-base.localdoma
in,OU=Office for Complication of Otherwise Simple
Affairs,O=OCOSA,L=Everywhere,ST=There is no such thing outside US,C=XX


Best regards,

Hani.



From gniibe at fsij.org  Mon Jan 16 09:07:01 2017
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Mon, 16 Jan 2017 17:07:01 +0900
Subject: NTBTLS: ignoring ALERT
Message-ID: <87inpftom2.fsf@iwagami.gniibe.org>

While testing NTBTLS with the keyserver hufu.ki.iif.hu, I encounter the
issue of:

    https://tls.mbed.org/discussions/bug-report-issues/mishandling-of-non-fatal-alerts-client-side

When I use following patch, it works for me.

diff --git a/src/protocol.c b/src/protocol.c
index 8e0fca5..50fa787 100644
--- a/src/protocol.c
+++ b/src/protocol.c
@@ -1529,6 +1529,7 @@ _ntbtls_read_record (ntbtls_t tls)
 
   tls->in_hslen = 0;
 
+ read_record_header:
   /*
    * Read the record header and validate it
    */
@@ -1718,6 +1719,9 @@ _ntbtls_read_record (ntbtls_t tls)
           debug_msg (2, "is a close notify message");
           return gpg_error (GPG_ERR_CLOSE_NOTIFY);
         }
+
+      tls->in_left = 0;
+      goto read_record_header;
     }
 
   tls->in_left = 0;
-- 


From wk at gnupg.org  Mon Jan 16 09:04:34 2017
From: wk at gnupg.org (Werner Koch)
Date: Mon, 16 Jan 2017 09:04:34 +0100
Subject: KSBA: Using names of OID from different sources
In-Reply-To: <20170115192310.3hxebmq32iwkcerm@kroosec-Inspiron-3521> (Hani
 Benhabiles's message of "Sun, 15 Jan 2017 20:23:10 +0100")
References: <20170115192310.3hxebmq32iwkcerm@kroosec-Inspiron-3521>
Message-ID: <87pojnfn1p.fsf@wheatstone.g10code.de>

On Sun, 15 Jan 2017 20:23, kroosec at gmail.com said:

> Is there a reason for dn.c:append_atv() being restricted to only use names for OIDs
> which are in rfc2253 ?

Yes, because that was the standard back then.  I have not checked
whether there updates in RFC4511 - they could be added in a future
versions.  Anyway, using an OID is also just fine.

We need to restrict it to the implemented standard for interoperability
purposes.


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: 227 bytes
Desc: not available
URL: 

From aheinecke at intevation.de  Mon Jan 16 09:46:56 2017
From: aheinecke at intevation.de (Andre Heinecke)
Date: Mon, 16 Jan 2017 09:46:56 +0100
Subject: NTBTLS: ignoring ALERT
In-Reply-To: <87inpftom2.fsf@iwagami.gniibe.org>
References: <87inpftom2.fsf@iwagami.gniibe.org>
Message-ID: <1854649.u2h8IUWBZt@esus>

Hi,

On Monday 16 January 2017 17:07:01 NIIBE Yutaka wrote:
> While testing NTBTLS with the keyserver hufu.ki.iif.hu, I encounter the
> issue of:
> 
>    
> https://tls.mbed.org/discussions/bug-report-issues/mishandling-of-non-fatal
> -alerts-client-side

We've encountered this problem in the past with WKS client:

It's https://bugs.gnupg.org/gnupg/issue2833

I don't feel qualified to comment on your actual patch but the idea to fix this 
gets a +1 from me :-)

Thanks and 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: 659 bytes
Desc: This is a digitally signed message part.
URL: 

From amzh at hushmail.com  Mon Jan 16 10:24:06 2017
From: amzh at hushmail.com (Andrey Mozharovskiy)
Date: Mon, 16 Jan 2017 12:24:06 +0300
Subject: Question about key generation
In-Reply-To: <20170114134517.3FB52200F3@smtp.hushmail.com>
Message-ID: <20170116092407.1D1A420138@smtp.hushmail.com>

Just to make sure, did I ask this in the right mailing list?

On 1/14/2017 at 4:45 PM, "Andrey Mozharovskiy"  wrote:Hello,
we're trying to generate a pair of Rsa keys (public/private), using
the latest release of libgcrypt sources,
we're using the following method:
	    gcry_sexp_t keyparm, key; 

	    int rc = -1; 
	    rc = gcry_sexp_new (&keyparm, 

	                        "(genkeyn" 

	                        " (rsan" 

	                        "  (nbits 4:2048)n" 

	                        " ))", 0, 1); 

	    if (rc) 

	        return boost::make_tuple("", ""); 
	    rc = gcry_pk_genkey (&key, keyparm); 
	    if (rc) 

	        return boost::make_tuple("", ""); 
	    gcry_sexp_t pubkey = gcry_sexp_find_token(key, "public-key", 0); 

	    size_t length_publ =
gcry_sexp_sprint(pubkey,GCRYSEXP_FMT_ADVANCED,NULL,0); 

	    char *buffer_publ = (char*)
gcry_malloc(length_publ*sizeof(char)); 

	    size_t offset_publ =
gcry_sexp_sprint(pubkey,GCRYSEXP_FMT_ADVANCED,buffer_publ,length_publ);

	    gcry_sexp_t privkey = gcry_sexp_find_token(key, "private-key",
0); 

	    size_t length_priv =
gcry_sexp_sprint(privkey,GCRYSEXP_FMT_ADVANCED,NULL,0); 

	    char *buffer_priv = (char*)
gcry_malloc(length_priv*sizeof(char)); 

	    size_t offset_priv =
gcry_sexp_sprint(privkey,GCRYSEXP_FMT_ADVANCED,buffer_priv,length_priv);
	Thus, we now have two keys, problem is they're both exactly identical
each time we generate them..
	E.g. both keys are:
	(char *) buffer_publ = 0x00007fddf0d0f0e0 "(public-key n (rsa n  (n
#00B30C503943A56EBD82AEC5A8CFDC49563BBD3A7E3938973F7642BAC50CA4CC26917B9DD7BF6840CF310EFB3910EE166312BA38FE8B0AC987FD2DF8D55342B6378AA49061C302A1776B897CC11A0D08558C4C0E6C1A86E7CD8A858A2D6786C29577829B8401A2DBEF8FA106F98195ED98B9745F7BC8B02048B1DBA33D12E78DC1E34F0C59E4205C8EEB5C6E0926DFD560E9EB36D42C3161FCA5C92D9C1AE64795C68D312C167803A685709C52D9FFF7914FCF1143BF9134A6ED0F30525A83DD950979D61098F953C70C2D91998F886B403295D82837BF0C9664842D92E94404A606882C326A44802E105574A7754EF073C9DC4B7593E7D429AD33DA9B5276A705#)n
 (e #010001#)n  )n )n
	(same value for buffer_priv)
	Please clarify, whether we should generate a pair of keys two times
and hence get different keys, or use a different method? 
	Regards, Andrey.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From dgouttegattat at incenp.org  Mon Jan 16 13:26:58 2017
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Mon, 16 Jan 2017 13:26:58 +0100
Subject: [RFC PATCH 0/2] Scute: Fix connection to a running agent.
Message-ID: <20170116122700.9042-1-dgouttegattat@incenp.org>

Hi,

The following patch set implements a new way for Scute to find the
socket of the GnuPG Agent.

The current code still uses a logic that was adapted to GnuPG 2.0,
based on the GPG_AGENT_INFO variable with a fallback to a standard
socket that is expected to be under $GNUPGHOME. GnuPG 2.1 no longer
uses the GPG_AGENT_INFO variable, and since 2.1.13 the standard
socket may be located under [/var]/run instead of GnuPG's home
directory. Scute may thus be unable to find the socket, and will
end up starting the GnuPG Agent itself in "pipe" mode even though
there is already an agent running.

There are several ways to fix that. The patches in that series
proposes a somewhat "radical" but, I believe, elegant solution,
which is to rely completely on the gpg-connect-agent binary to
send a 'GETINFO socket_name' to the agent.

This way, we can be sure to always use the correct logic to find
the socket, without having to duplicate any code between GnuPG
and Scute.

Comments are wellcome.

(Note, in particular, that I am not sure whether this method is
appropriate for Windows systems. I don't have a Windows machine
to do any test. Can we even rely on popen always being available
on Windows?)

Damien Goutte-Gattat (2):
  Get GPG Agent's socket directly from the agent.
  Cleanup now unused code.

 configure.ac   |  36 +++----
 src/agent.c    | 321 +++++++--------------------------------------------------
 src/get-path.c | 190 +---------------------------------
 src/support.h  |  10 +-
 4 files changed, 63 insertions(+), 494 deletions(-)

-- 
2.9.0



From dgouttegattat at incenp.org  Mon Jan 16 13:26:59 2017
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Mon, 16 Jan 2017 13:26:59 +0100
Subject: [RFC PATCH 1/2] Get GPG Agent's socket directly from the agent.
In-Reply-To: <20170116122700.9042-1-dgouttegattat@incenp.org>
References: <20170116122700.9042-1-dgouttegattat@incenp.org>
Message-ID: <20170116122700.9042-2-dgouttegattat@incenp.org>

* src/agent.c (agent_connect): Call gpg-connect-agent to get
the socket for a running agent.
* src/get-path.c (get_gpg_connect_agent_path): New function.
* src/support.h (get_gpg_connect_agent_path): New prototype.
* configure.ac: New option --with-gpg-connect-agent-path.
--

This patch replaces all the logic needed to find the socket for
a running GnuPG Agent by a single call to gpg-connect-agent.
This will ensure we will always be able to find the agent,
without having to duplicate the logic already implement in
GnuPG. Gpg-connect-agent will also take care of starting the
agent if it's not already running.

Signed-off-by: Damien Goutte-Gattat 
---
 configure.ac   |  37 +++++++++++++
 src/agent.c    | 172 ++++++++++++++-------------------------------------------
 src/get-path.c |  17 ++++++
 src/support.h  |   1 +
 4 files changed, 95 insertions(+), 132 deletions(-)

diff --git a/configure.ac b/configure.ac
index 1e4137d..8567a3a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -232,12 +232,14 @@ AM_CONDITIONAL(HAVE_LD_VERSION_SCRIPT, test "$have_ld_version_script" = "yes")
 
 GPGSM_DEFAULT=no
 GPG_AGENT_DEFAULT=no
+GPG_CONNECT_AGENT_DEFAULT=no
 have_w32_system=no
 case "${host}" in
     *-mingw32*)
         # special stuff for Windoze NT
 	GPGSM_DEFAULT='c:\\gnupg\\gpgsm.exe'
         GPG_AGENT_DEFAULT='c:\\gnupg\\gpg-agent.exe'
+        GPG_CONNECT_AGENT_DEFAULT='c:\\gnupg\\gpg-connect-agent.exe'
 	have_w32_system=yes
         ;;
     *)
@@ -406,6 +408,41 @@ else
 fi
 AM_CONDITIONAL(HAVE_GPG_AGENT, test "$GPG_AGENT" != "no")
 
+# GPG_CONNECT_AGENT
+NO_OVERRIDE=no
+AC_ARG_WITH(gpg-connect-agent,
+            AC_HELP_STRING([--with-gpg-connect-agent=PATH],
+                           [use gpg-connect-agent binary at PATH]),
+            GPG_CONNECT_AGENT=$withval, NO_OVERRIDE=yes)
+if test "$NO_OVERRIDE" = "yes" || test "$GPG_CONNECT_AGENT" = "yes"; then
+  GPG_CONNECT_AGENT=
+  NO_OVERRIDE=yes
+  if test "$cross_compiling" != "yes"; then
+    AC_PATH_PROG(GPG_CONNECT_AGENT, gpg-connect-agent)
+  fi
+  if test -z "$GPG_CONNECT_AGENT"; then
+    GPG_CONNECT_AGENT="$GPG_CONNECT_AGENT_DEFAULT"
+  fi
+fi
+if test "$GPG_CONNECT_AGENT" = no; then
+  if test "$NO_OVERRIDE" = "yes"; then
+    if test "$cross_compiling" != "yes"; then
+      AC_MSG_WARN([
+***
+*** Could not find gpg-connect-agent, use --with-gpg-connect-agent=PATH to enable it
+***])
+    else
+      AC_MSG_WARN([
+***
+*** Can not determine path to gpg-connect-agent when cross-compiling, use --with-gpg-connect-agent=PATH
+***])
+    fi
+  fi
+else
+  AC_DEFINE_UNQUOTED(GPG_CONNECT_AGENT_PATH, "$GPG_CONNECT_AGENT",
+                     [Path to the GPG_CONNECT_AGENT binary.])
+fi
+
 
 # Checks for header files.
 AC_HEADER_STDC
diff --git a/src/agent.c b/src/agent.c
index 75d4933..6ee106c 100644
--- a/src/agent.c
+++ b/src/agent.c
@@ -233,151 +233,59 @@ spawn_process_detached (const char *pgmname, const char *argv[])
 static gpg_error_t
 agent_connect (assuan_context_t *ctx_r)
 {
-  /* If we ever failed to connect via a socket we will force the use
-     of the pipe based server for the lifetime of the process.  */
-  static int force_pipe_server = 0;
-
   gpg_error_t err = 0;
-  char *infostr;
-  char *ptr;
   assuan_context_t ctx = NULL;
+  char buffer[255];
+  FILE *p;
 
-  err = assuan_new (&ctx);
-  if (err)
-    return err;
-
- restart:
-
-  infostr = force_pipe_server ? NULL : getenv ("GPG_AGENT_INFO");
-  if (!infostr || !*infostr)
-    {
-      char *sockname;
-
-      /* First check whether we can connect at the standard
-         socket.  */
-      sockname = make_filename (default_homedir (), "S.gpg-agent", NULL);
-      if (! sockname)
-	return gpg_error_from_errno (errno);
-
-      err = assuan_socket_connect (ctx, sockname, 0, 0);
-      if (err)
-        {
-	  const char *agent_program;
-
-          /* With no success start a new server.  */
-	  DEBUG (DBG_INFO, "no running GPG agent at %s, starting one\n",
-		 sockname);
-
-          agent_program = get_gpg_agent_path ();
-
+  /* Use gpg-connect-agent to obtain the socket name
+   * directly from the agent itself. */
+  snprintf (buffer, sizeof buffer, "%s 'GETINFO socket_name' /bye",
+            get_gpg_connect_agent_path ());
 #ifdef HAVE_W32_SYSTEM
-          {
-            /* Under Windows we start the server in daemon mode.  This
-               is because the default is to use the standard socket
-               and thus there is no need for the GPG_AGENT_INFO
-               envvar.  This is possible as we don't have a real unix
-               domain socket but use a plain file and thus there is no
-               need to care about non-local file systems. */
-            const char *argv[3];
-
-            argv[0] = "--daemon";
-            argv[1] = "--use-standard-socket";
-            argv[2] = NULL;
-
-            err = spawn_process_detached (agent_program, argv);
-            if (err)
-              DEBUG (DBG_CRIT, "failed to start agent `%s': %s\n",
-		     agent_program, gpg_strerror (err));
-            else
-              {
-                /* Give the agent some time to prepare itself. */
-                Sleep (3 * 1000);
-                /* Now try again to connect the agent.  */
-                err = assuan_socket_connect (ctx_r, sockname, 0, 0);
-              }
-          }
-#else /*!HAVE_W32_SYSTEM*/
-          {
-            const char *pgmname;
-            const char *argv[3];
-            int no_close_list[3];
-            int i;
-
-            if ( !(pgmname = strrchr (agent_program, '/')))
-              pgmname = agent_program;
-            else
-              pgmname++;
-
-            argv[0] = pgmname;
-            argv[1] = "--server";
-            argv[2] = NULL;
-
-            i=0;
-            no_close_list[i++] = assuan_fd_from_posix_fd (fileno (stderr));
-            no_close_list[i] = -1;
-
-            /* Connect to the agent and perform initial handshaking. */
-            err = assuan_pipe_connect (ctx, agent_program, argv,
-				       no_close_list, NULL, NULL, 0);
-          }
-#endif /*!HAVE_W32_SYSTEM*/
-        }
-      free (sockname);
-    }
-  else
+  p = _popen (buffer, "r");
+#else
+  p = popen (buffer, "r");
+#endif
+  if (p)
     {
-      int pid;
-      int protocol_version;
+      int ret;
 
-      infostr = strdup (infostr);
-      if (!infostr)
-	return gpg_error_from_errno (errno);
-
-      if (!(ptr = strchr (infostr, PATHSEP_C)) || ptr == infostr)
-	{
-	  DEBUG (DBG_CRIT, "malformed GPG_AGENT_INFO environment variable");
-	  free (infostr);
-	  force_pipe_server = 1;
-	  goto restart;
-	}
-
-      *(ptr++) = 0;
-      pid = atoi (ptr);
-      while (*ptr && *ptr != PATHSEP_C)
-	ptr++;
-      protocol_version = *ptr ? atoi (ptr + 1) : 0;
-      if (protocol_version != 1)
-	{
-	  DEBUG (DBG_CRIT, "GPG agent protocol version '%d' not supported",
-		 protocol_version);
-	  free (infostr);
-	  force_pipe_server = 1;
-	  goto restart;
-	}
+      ret = fscanf (p, "D %254s\nOK\n", buffer);
+      if (ret == EOF)       /* I/O error? */
+        err = gpg_error_from_errno (errno);
+      else if (ret != 1)    /* Unexpected reply */
+        err = gpg_error (GPG_ERR_NO_AGENT);
 
-      err = assuan_socket_connect (ctx, infostr, pid, 0);
-      free (infostr);
-      if (err)
-	{
-	  DEBUG (DBG_CRIT, "cannot connect to GPG agent: %s", gpg_strerror (err));
-	  force_pipe_server = 1;
-	  goto restart;
-	}
+      pclose (p);
     }
+  else
+    err = gpg_error_from_errno (errno);
 
-  if (err)
+  /* Then connect to the socket we got. */
+  if (!err)
     {
-      assuan_release (ctx);
-      DEBUG (DBG_CRIT, "cannot connect to GPG agent: %s", gpg_strerror (err));
-      return gpg_error (GPG_ERR_NO_AGENT);
+      err = assuan_new (&ctx);
+      if (!err)
+        {
+          err = assuan_socket_connect (ctx, buffer, 0, 0);
+          if (!err)
+            {
+              *ctx_r = ctx;
+              if (_scute_debug_flags & DBG_ASSUAN)
+                assuan_set_log_stream (*ctx_r, _scute_debug_stream);
+            }
+          else
+            assuan_release (ctx);
+        }
     }
 
-  if (_scute_debug_flags & DBG_ASSUAN)
-    assuan_set_log_stream (*ctx_r, _scute_debug_stream);
-
-  *ctx_r = ctx;
+  /* We do not try any harder. If gpg-connect-agent somehow failed
+   * to give us a suitable socket, we probably cannot do better. */
+  if (err)
+    DEBUG (DBG_CRIT, "cannot connect to GPG agent: %s", gpg_strerror (err));
 
-  return 0;
+  return err;
 }
 
 
diff --git a/src/get-path.c b/src/get-path.c
index 0abd863..cb0a136 100644
--- a/src/get-path.c
+++ b/src/get-path.c
@@ -335,6 +335,23 @@ get_gpg_agent_path (void)
 }
 
 
+const char *
+get_gpg_connect_agent_path (void)
+{
+  static const char *pgmname;
+
+#ifdef HAVE_W32_SYSTEM
+  if (!pgmname)
+    pgmname = find_program_in_inst_dir ("gpg-connect-agent.exe");
+  if (!pgmname)
+    pgmname = find_program_at_standard_place ("GNU\\GnuPG\\gpg-connect-agent.exe");
+#endif
+  if (!pgmname)
+    pgmname = GPG_CONNECT_AGENT_PATH;
+  return pgmname;
+}
+
+
 
 /* Home directory.  */
 
diff --git a/src/support.h b/src/support.h
index 3356224..739d124 100644
--- a/src/support.h
+++ b/src/support.h
@@ -85,6 +85,7 @@ stpcpy (char *a, const char *b)
 
 const char *get_gpgsm_path (void);
 const char *get_gpg_agent_path (void);
+const char *get_gpg_connect_agent_path (void);
 
 /* Set up the default home directory.  The usual --homedir option
    should be parsed later. */
-- 
2.9.0



From dgouttegattat at incenp.org  Mon Jan 16 13:27:00 2017
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Mon, 16 Jan 2017 13:27:00 +0100
Subject: [RFC PATCH 2/2] Cleanup now unused code.
In-Reply-To: <20170116122700.9042-1-dgouttegattat@incenp.org>
References: <20170116122700.9042-1-dgouttegattat@incenp.org>
Message-ID: <20170116122700.9042-3-dgouttegattat@incenp.org>

* src/agent.c (build_w32_commandline_copy): Removed.
(build_w32_commandline): Removed.
(spawn_process_detached): Removed.
* src/get-path.c (get_gpg_agent_path): Removed.
(standard_homedir): Removed.
(default_homedir): Removed.
(make_filename): Removed.
* src/support.h: Removed corresponding prototypes.
* configure.ac: Removed --with-gpg-agent option.
--

This patch removes functions that were only used to find the
socket for GnuPG Agent and that are not needed anymore.

Signed-off-by: Damien Goutte-Gattat 
---
 configure.ac   |  37 -----------
 src/agent.c    | 149 ------------------------------------------
 src/get-path.c | 199 ---------------------------------------------------------
 src/support.h  |   9 ---
 4 files changed, 394 deletions(-)

diff --git a/configure.ac b/configure.ac
index 8567a3a..d05785e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -231,14 +231,12 @@ esac
 AM_CONDITIONAL(HAVE_LD_VERSION_SCRIPT, test "$have_ld_version_script" = "yes")
 
 GPGSM_DEFAULT=no
-GPG_AGENT_DEFAULT=no
 GPG_CONNECT_AGENT_DEFAULT=no
 have_w32_system=no
 case "${host}" in
     *-mingw32*)
         # special stuff for Windoze NT
 	GPGSM_DEFAULT='c:\\gnupg\\gpgsm.exe'
-        GPG_AGENT_DEFAULT='c:\\gnupg\\gpg-agent.exe'
         GPG_CONNECT_AGENT_DEFAULT='c:\\gnupg\\gpg-connect-agent.exe'
 	have_w32_system=yes
         ;;
@@ -373,41 +371,6 @@ if test "$ok" = "maybe"; then
 fi
 gpgsm_ok="$ok"
 
-# GPG_AGENT
-NO_OVERRIDE=no
-AC_ARG_WITH(gpg-agent,
-	    AC_HELP_STRING([--with-gpg-agent=PATH], [use GPG Agent binary at PATH]),
-	    GPG_AGENT=$withval, NO_OVERRIDE=yes)
-if test "$NO_OVERRIDE" = "yes" || test "$GPG_AGENT" = "yes"; then
-  GPG_AGENT=
-  NO_OVERRIDE=yes
-  if test "$cross_compiling" != "yes"; then
-    AC_PATH_PROG(GPG_AGENT, gpg-agent)
-  fi
-  if test -z "$GPG_AGENT"; then
-    GPG_AGENT="$GPG_AGENT_DEFAULT"
-  fi
-fi
-if test "$GPG_AGENT" = no; then
-  if test "$NO_OVERRIDE" = "yes"; then
-    if test "$cross_compiling" != "yes"; then
-      AC_MSG_WARN([
-***
-*** Could not find GPG Agent, install GPG Agent or use --with-gpg-agent=PATH to enable it
-***])
-    else
-      AC_MSG_ERROR([
-***
-*** Can not determine path to GPG Agent when cross-compiling, use --with-gpg-agent=PATH
-***])
-    fi
-  fi
-else
-  AC_DEFINE_UNQUOTED(GPG_AGENT_PATH, "$GPG_AGENT", [Path to the GPG_AGENT binary.])
-  AC_DEFINE(ENABLE_GPG_AGENT,1, [Whether GPG Agent support is enabled])
-fi
-AM_CONDITIONAL(HAVE_GPG_AGENT, test "$GPG_AGENT" != "no")
-
 # GPG_CONNECT_AGENT
 NO_OVERRIDE=no
 AC_ARG_WITH(gpg-connect-agent,
diff --git a/src/agent.c b/src/agent.c
index 6ee106c..cecf570 100644
--- a/src/agent.c
+++ b/src/agent.c
@@ -79,155 +79,6 @@ gnupg_allow_set_foregound_window (pid_t pid)
 }
 
 
-#ifdef HAVE_W32_SYSTEM
-/* Helper function to build_w32_commandline. */
-static char *
-build_w32_commandline_copy (char *buffer, const char *string)
-{
-  char *p = buffer;
-  const char *s;
-
-  if (!*string) /* Empty string. */
-    p = stpcpy (p, "\"\"");
-  else if (strpbrk (string, " \t\n\v\f\""))
-    {
-      /* Need top do some kind of quoting.  */
-      p = stpcpy (p, "\"");
-      for (s=string; *s; s++)
-        {
-          *p++ = *s;
-          if (*s == '\"')
-            *p++ = *s;
-        }
-      *p++ = '\"';
-      *p = 0;
-    }
-  else
-    p = stpcpy (p, string);
-
-  return p;
-}
-
-
-/* Build a command line for use with W32's CreateProcess.  On success
-   CMDLINE gets the address of a newly allocated string.  */
-static gpg_error_t
-build_w32_commandline (const char *pgmname, const char * const *argv,
-                       char **cmdline)
-{
-  int i, n;
-  const char *s;
-  char *buf, *p;
-
-  *cmdline = NULL;
-  n = 0;
-  s = pgmname;
-  n += strlen (s) + 1 + 2;  /* (1 space, 2 quoting */
-  for (; *s; s++)
-    if (*s == '\"')
-      n++;  /* Need to double inner quotes.  */
-  for (i=0; (s=argv[i]); i++)
-    {
-      n += strlen (s) + 1 + 2;  /* (1 space, 2 quoting */
-      for (; *s; s++)
-        if (*s == '\"')
-          n++;  /* Need to double inner quotes.  */
-    }
-  n++;
-
-  buf = p = malloc (n);
-  if (!buf)
-    return gpg_error_from_syserror ();
-
-  p = build_w32_commandline_copy (p, pgmname);
-  for (i=0; argv[i]; i++)
-    {
-      *p++ = ' ';
-      p = build_w32_commandline_copy (p, argv[i]);
-    }
-
-  *cmdline= buf;
-  return 0;
-}
-
-
-/* Spawn a new process and immediately detach from it.  The name of
-   the program to exec is PGMNAME and its arguments are in ARGV (the
-   programname is automatically passed as first argument).  An error
-   is returned if pgmname is not executable; to make this work it is
-   necessary to provide an absolute file name.  All standard file
-   descriptors are connected to /dev/null.  */
-static gpg_error_t
-spawn_process_detached (const char *pgmname, const char *argv[])
-{
-  gpg_error_t err;
-  SECURITY_ATTRIBUTES sec_attr;
-  PROCESS_INFORMATION pi =
-    {
-      NULL,      /* Returns process handle.  */
-      0,         /* Returns primary thread handle.  */
-      0,         /* Returns pid.  */
-      0          /* Returns tid.  */
-    };
-  STARTUPINFO si;
-  int cr_flags;
-  char *cmdline;
-
-  if (access (pgmname, X_OK))
-    return gpg_error_from_syserror ();
-
-  /* Prepare security attributes.  */
-  memset (&sec_attr, 0, sizeof sec_attr );
-  sec_attr.nLength = sizeof sec_attr;
-  sec_attr.bInheritHandle = FALSE;
-
-  /* Build the command line.  */
-  err = build_w32_commandline (pgmname, argv, &cmdline);
-  if (err)
-    return err;
-
-  /* Start the process.  */
-  memset (&si, 0, sizeof si);
-  si.cb = sizeof (si);
-  si.dwFlags = STARTF_USESHOWWINDOW;
-  si.wShowWindow = SW_MINIMIZE;
-
-  cr_flags = (CREATE_DEFAULT_ERROR_MODE
-              | GetPriorityClass (GetCurrentProcess ())
-              | CREATE_NEW_PROCESS_GROUP
-              | DETACHED_PROCESS);
-  DEBUG (DBG_INFO, "CreateProcess(detached), path=`%s' cmdline=`%s'\n",
-	 pgmname, cmdline);
-  if (!CreateProcess (pgmname,       /* Program to start.  */
-                      cmdline,       /* Command line arguments.  */
-                      &sec_attr,     /* Process security attributes.  */
-                      &sec_attr,     /* Thread security attributes.  */
-                      FALSE,         /* Inherit handles.  */
-                      cr_flags,      /* Creation flags.  */
-                      NULL,          /* Environment.  */
-                      NULL,          /* Use current drive/directory.  */
-                      &si,           /* Startup information. */
-                      &pi            /* Returns process information.  */
-                      ))
-    {
-      DEBUG (DBG_CRIT, "CreateProcess(detached) failed: %i\n",
-	     GetLastError ());
-      free (cmdline);
-      return gpg_error (GPG_ERR_GENERAL);
-    }
-  free (cmdline);
-  cmdline = NULL;
-
-  DEBUG (DBG_INFO, "CreateProcess(detached) ready: hProcess=%p hThread=%p"
-	 " dwProcessID=%d dwThreadId=%d\n", pi.hProcess, pi.hThread,
-	 (int) pi.dwProcessId, (int) pi.dwThreadId);
-
-  CloseHandle (pi.hThread);
-
-  return 0;
-}
-#endif
-
 
 /* Establish a connection to a running GPG agent.  */
 static gpg_error_t
diff --git a/src/get-path.c b/src/get-path.c
index cb0a136..bb24b12 100644
--- a/src/get-path.c
+++ b/src/get-path.c
@@ -33,13 +33,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
 #ifdef HAVE_W32_SYSTEM
 #include 
 #include 
@@ -49,23 +42,6 @@
 #include "support.h"
 
 #ifdef HAVE_W32_SYSTEM
-#define GNUPG_DEFAULT_HOMEDIR "c:/gnupg"
-#elif defined(__VMS)
-#define GNUPG_DEFAULT_HOMEDIR "/SYS\$LOGIN/gnupg" 
-#else
-#define GNUPG_DEFAULT_HOMEDIR "~/.gnupg"
-#endif 
-
-#ifdef HAVE_DOSISH_SYSTEM
-#define DIRSEP_C '\\'
-#define DIRSEP_S "\\"
-#else
-#define DIRSEP_C '/'
-#define DIRSEP_S "/"
-#endif
-
-
-#ifdef HAVE_W32_SYSTEM
 #define RTLD_LAZY 0
 
 static __inline__ void *
@@ -319,23 +295,6 @@ get_gpgsm_path (void)
 
 
 const char *
-get_gpg_agent_path (void)
-{
-  static const char *pgmname;
-
-#ifdef HAVE_W32_SYSTEM
-  if (!pgmname)
-    pgmname = find_program_in_inst_dir ("gpg-agent.exe");
-  if (!pgmname)
-    pgmname = find_program_at_standard_place ("GNU\\GnuPG\\gpg-agent.exe");
-#endif
-  if (!pgmname)
-    pgmname = GPG_AGENT_PATH;
-  return pgmname;
-}
-
-
-const char *
 get_gpg_connect_agent_path (void)
 {
   static const char *pgmname;
@@ -350,161 +309,3 @@ get_gpg_connect_agent_path (void)
     pgmname = GPG_CONNECT_AGENT_PATH;
   return pgmname;
 }
-
-
-
-/* Home directory.  */
-
-#ifdef HAVE_W32_SYSTEM
-#ifndef CSIDL_APPDATA
-#define CSIDL_APPDATA 0x001a
-#endif
-#ifndef CSIDL_LOCAL_APPDATA
-#define CSIDL_LOCAL_APPDATA 0x001c
-#endif
-#ifndef CSIDL_COMMON_APPDATA
-#define CSIDL_COMMON_APPDATA 0x0023
-#endif
-#ifndef CSIDL_FLAG_CREATE
-#define CSIDL_FLAG_CREATE 0x8000
-#endif
-#endif /*HAVE_W32_SYSTEM*/
-
-/* Get the standard home directory.  In general this function should
-   not be used as it does not consider a registry value (under W32) or
-   the GNUPGHOME environment variable.  It is better to use
-   default_homedir(). */
-const char *
-standard_homedir (void)
-{
-#ifdef HAVE_W32_SYSTEM
-  static const char *dir;
-
-  if (!dir)
-    {
-      char path[MAX_PATH];
-      
-      /* It might be better to use LOCAL_APPDATA because this is
-         defined as "non roaming" and thus more likely to be kept
-         locally.  For private keys this is desired.  However, given
-         that many users copy private keys anyway forth and back,
-         using a system roaming services might be better than to let
-         them do it manually.  A security conscious user will anyway
-         use the registry entry to have better control.  */
-      if (w32_shgetfolderpath (NULL, CSIDL_APPDATA|CSIDL_FLAG_CREATE, 
-                               NULL, 0, path) >= 0) 
-        {
-          char *tmp = malloc (strlen (path) + 6 +1);
-	  if (tmp)
-	    {
-	      strcpy (stpcpy (tmp, path), "\\gnupg");
-	      dir = tmp;
-          
-	      /* Try to create the directory if it does not yet exists.  */
-	      if (access (dir, F_OK))
-		CreateDirectory (dir, NULL);
-	    }
-        }
-
-      if (!dir)
-        dir = GNUPG_DEFAULT_HOMEDIR;
-    }
-  return dir;
-#else/*!HAVE_W32_SYSTEM*/
-  return GNUPG_DEFAULT_HOMEDIR;
-#endif /*!HAVE_W32_SYSTEM*/
-}
-
-/* Set up the default home directory.  The usual --homedir option
-   should be parsed later. */
-const char *
-default_homedir (void)
-{
-  const char *dir;
-
-  dir = getenv ("GNUPGHOME");
-#ifdef HAVE_W32_SYSTEM
-  if (!dir || !*dir)
-    {
-      static const char *saved_dir;
-      
-      if (!saved_dir)
-        {
-          if (!dir || !*dir)
-            {
-              char *tmp;
-
-              tmp = read_w32_registry_string (NULL, "Software\\GNU\\GnuPG",
-                                              "HomeDir");
-              if (tmp && *tmp)
-                {
-                  free (tmp);
-                  tmp = NULL;
-                }
-               if (tmp)
-                saved_dir = tmp;
-            }
-          
-          if (!saved_dir)
-            saved_dir = standard_homedir ();
-        }
-      dir = saved_dir;
-    }
-#endif /*HAVE_W32_SYSTEM*/
-  if (!dir || !*dir)
-    dir = GNUPG_DEFAULT_HOMEDIR;
-
-  return dir;
-}
-
-
-/* Construct a filename from the NULL terminated list of parts.  Tilde
-   expansion is done here.  */
-char *
-make_filename (const char *first_part, ...)
-{
-  va_list arg_ptr;
-  size_t n;
-  const char *s;
-  char *name;
-  char *home;
-  char *p;
-  
-  va_start (arg_ptr, first_part);
-  n = strlen (first_part) + 1;
-  while ((s = va_arg (arg_ptr, const char *)))
-    n += strlen (s) + 1;
-  va_end (arg_ptr);
-  
-  home = NULL;
-  if (*first_part == '~' && first_part[1] == '/'
-      && (home = getenv("HOME")) && *home)
-    n += strlen (home);
-
-  name = malloc (n);
-  if (! name)
-    return NULL;
-  p = (home 
-       ? stpcpy (stpcpy (name,home), first_part + 1)
-       : stpcpy (name, first_part));
-
-  va_start (arg_ptr, first_part);
-  while ((s = va_arg(arg_ptr, const char *)))
-    p = stpcpy (stpcpy (p,"/"), s);
-  va_end (arg_ptr);
-
-#ifdef HAVE_W32_SYSTEM
-  /* We better avoid mixing slashes and backslashes and prefer
-     backslashes.  There is usual no problem with mixing them, however
-     a very few W32 API calls can't grok plain slashes.  Printing
-     filenames with mixed slashes also looks a bit strange. */
-  if (strchr (name, '\\'))
-    {
-      for (p = name; *p; p++)
-        if (*p == '/')
-          *p = '\\';
-    }
-#endif
-
-  return name;
-}
diff --git a/src/support.h b/src/support.h
index 739d124..38149ad 100644
--- a/src/support.h
+++ b/src/support.h
@@ -84,17 +84,8 @@ stpcpy (char *a, const char *b)
 
 
 const char *get_gpgsm_path (void);
-const char *get_gpg_agent_path (void);
 const char *get_gpg_connect_agent_path (void);
 
-/* Set up the default home directory.  The usual --homedir option
-   should be parsed later. */
-const char *default_homedir (void);
-
-/* Construct a filename from the NULL terminated list of parts.  Tilde
-   expansion is done here.  */
-char *make_filename (const char *first_part, ...);
-
 
     
 #endif	/* !SUPPORT_H */
-- 
2.9.0



From amzh at hushmail.com  Mon Jan 16 16:34:31 2017
From: amzh at hushmail.com (Andrey Mozharovskiy)
Date: Mon, 16 Jan 2017 18:34:31 +0300
Subject: Question about key generation
In-Reply-To: <20170114134517.3FB52200F3@smtp.hushmail.com>
Message-ID: <20170116153431.B6DCB2013F@smtp.hushmail.com>

Found the problem.
These gcry_sexp_t are being returned as modulus/exp etc. It's the
modulus part which is the same for both public and private keys.
How do I extract the keys itself?
On 1/14/2017 at 4:45 PM, "Andrey Mozharovskiy"  wrote:Hello,
we're trying to generate a pair of Rsa keys (public/private), using
the latest release of libgcrypt sources,
we're using the following method:
	    gcry_sexp_t keyparm, key; 

	    int rc = -1; 
	    rc = gcry_sexp_new (&keyparm, 

	                        "(genkeyn" 

	                        " (rsan" 

	                        "  (nbits 4:2048)n" 

	                        " ))", 0, 1); 

	    if (rc) 

	        return boost::make_tuple("", ""); 
	    rc = gcry_pk_genkey (&key, keyparm); 
	    if (rc) 

	        return boost::make_tuple("", ""); 
	    gcry_sexp_t pubkey = gcry_sexp_find_token(key, "public-key", 0); 

	    size_t length_publ =
gcry_sexp_sprint(pubkey,GCRYSEXP_FMT_ADVANCED,NULL,0); 

	    char *buffer_publ = (char*)
gcry_malloc(length_publ*sizeof(char)); 

	    size_t offset_publ =
gcry_sexp_sprint(pubkey,GCRYSEXP_FMT_ADVANCED,buffer_publ,length_publ);

	    gcry_sexp_t privkey = gcry_sexp_find_token(key, "private-key",
0); 

	    size_t length_priv =
gcry_sexp_sprint(privkey,GCRYSEXP_FMT_ADVANCED,NULL,0); 

	    char *buffer_priv = (char*)
gcry_malloc(length_priv*sizeof(char)); 

	    size_t offset_priv =
gcry_sexp_sprint(privkey,GCRYSEXP_FMT_ADVANCED,buffer_priv,length_priv);
	Thus, we now have two keys, problem is they're both exactly identical
each time we generate them..
	E.g. both keys are:
	(char *) buffer_publ = 0x00007fddf0d0f0e0 "(public-key n (rsa n  (n
#00B30C503943A56EBD82AEC5A8CFDC49563BBD3A7E3938973F7642BAC50CA4CC26917B9DD7BF6840CF310EFB3910EE166312BA38FE8B0AC987FD2DF8D55342B6378AA49061C302A1776B897CC11A0D08558C4C0E6C1A86E7CD8A858A2D6786C29577829B8401A2DBEF8FA106F98195ED98B9745F7BC8B02048B1DBA33D12E78DC1E34F0C59E4205C8EEB5C6E0926DFD560E9EB36D42C3161FCA5C92D9C1AE64795C68D312C167803A685709C52D9FFF7914FCF1143BF9134A6ED0F30525A83DD950979D61098F953C70C2D91998F886B403295D82837BF0C9664842D92E94404A606882C326A44802E105574A7754EF073C9DC4B7593E7D429AD33DA9B5276A705#)n
 (e #010001#)n  )n )n
	(same value for buffer_priv)
	Please clarify, whether we should generate a pair of keys two times
and hence get different keys, or use a different method? 
	Regards, Andrey.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From dgouttegattat at incenp.org  Tue Jan 17 20:42:09 2017
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Tue, 17 Jan 2017 20:42:09 +0100
Subject: [PATCH] gpg: Fix misleading log message when checking regexp.
Message-ID: <20170117194209.25937-1-dgouttegattat@incenp.org>

* src/trustdb.c (check_regexp): Correctly print whether the
regexp matched or not.
--

This patch fixes the log message displayed when gpg attempts to
match the regexp associated with a trust signature with an user ID.
The current message interprets the 'ret' variable backwards, and
displays 'YES' when the regexp actually fails to match.

Signed-off-by: Damien Goutte-Gattat 
---
 g10/trustdb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/g10/trustdb.c b/g10/trustdb.c
index c113b7e..75714ab 100644
--- a/g10/trustdb.c
+++ b/g10/trustdb.c
@@ -1550,14 +1550,14 @@ check_regexp(const char *expr,const char *string)
       {
 	ret=regexec(&pat,string,0,NULL,0);
 	regfree(&pat);
-	ret=(ret==0);
       }
+    ret=(ret==0);
   }
 #endif
 
   if(DBG_TRUST)
     log_debug("regexp '%s' ('%s') on '%s': %s\n",
-	      regexp,expr,string,ret==0?"YES":"NO");
+	      regexp,expr,string,ret?"YES":"NO");
 
   xfree(regexp);
 
-- 
2.9.0



From dgouttegattat at incenp.org  Tue Jan 17 23:04:45 2017
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Tue, 17 Jan 2017 23:04:45 +0100
Subject: [PATCH] gpg: Fix regexp sanitization.
Message-ID: <20170117220445.24873-1-dgouttegattat@incenp.org>

* g10/trustdb.c (sanitize_regexp): Do not escape normal characters.
--

The current sanitization code escapes ALL characters in the
regular expression, including characters that do not have any
special meaning and only match themselves. Only the dot (.)
is not escaped.

This leads to, e.g., 'example.com' being sanitized into
'\e\x\a\m\p\l\e.\c\o\m', which will then fail to match against
'alice at example.com'.

This patch updates the function to escape only the meaningful
characters (minus the dot).

Signed-off-by: Damien Goutte-Gattat 
---
 g10/trustdb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/g10/trustdb.c b/g10/trustdb.c
index c113b7e..e5f32da 100644
--- a/g10/trustdb.c
+++ b/g10/trustdb.c
@@ -1498,7 +1498,7 @@ sanitize_regexp(const char *old)
     {
       if(!escaped && old[start]=='\\')
 	escaped=1;
-      else if(!escaped && old[start]!='.')
+      else if(!escaped && strchr("[]$^()|*+?{}", old[start]))
 	new[idx++]='\\';
       else
 	escaped=0;
-- 
2.9.0



From dgouttegattat at incenp.org  Wed Jan 18 18:52:12 2017
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Wed, 18 Jan 2017 18:52:12 +0100
Subject: [PATCH] gpg: Allow to freeze faked system time.
Message-ID: <20170118175212.16066-1-dgouttegattat@incenp.org>

* g10/gpg.c (main): If the parameter for --faked-system-time
ends with a '!', freeze time at the specified point.
* common/gettime.c (gnupg_set_time): Allow to freeze the time
at an arbitrary time instead of only the current time.
* doc/gpg.texi: Update documentation for --faked-system-time.
--

This patch allows the user to modify the behavior of the
--faked-system-time option: by appending a '!' to the parameter,
time in GnuPG will be frozen at the specified time, instead of
advancing normally from that time onward.

Signed-off-by: Damien Goutte-Gattat 
---
 common/gettime.c |  2 +-
 doc/gpg.texi     |  3 +++
 g10/gpg.c        | 14 ++++++++++++--
 3 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/common/gettime.c b/common/gettime.c
index e5da4fb..3e1ee55 100644
--- a/common/gettime.c
+++ b/common/gettime.c
@@ -133,7 +133,7 @@ gnupg_set_time (time_t newtime, int freeze)
   else if (freeze)
     {
       timemode = FROZEN;
-      timewarp = current;
+      timewarp = newtime == (time_t)-1 ? current : newtime;
     }
   else if (newtime > current)
     {
diff --git a/doc/gpg.texi b/doc/gpg.texi
index 4ea2cd2..044ba37 100644
--- a/doc/gpg.texi
+++ b/doc/gpg.texi
@@ -2748,6 +2748,9 @@ forth to @var{epoch} which is the number of seconds elapsed since the year
 1970.  Alternatively @var{epoch} may be given as a full ISO time string
 (e.g. "20070924T154812").
 
+If you suffix @var{epoch} with an exclamation mark (!), the system time
+will appear to be frozen at the specified time.
+
 @item --enable-progress-filter
 @opindex enable-progress-filter
 Enable certain PROGRESS status outputs. This option allows frontends
diff --git a/g10/gpg.c b/g10/gpg.c
index 8c5b505..f9039ae 100644
--- a/g10/gpg.c
+++ b/g10/gpg.c
@@ -3493,10 +3493,20 @@ main (int argc, char **argv)
 
           case oFakedSystemTime:
             {
-              time_t faked_time = isotime2epoch (pargs.r.ret_str);
+              size_t len = strlen (pargs.r.ret_str);
+              int freeze = 0;
+              time_t faked_time;
+
+              if (len > 0 && pargs.r.ret_str[len-1] == '!')
+                {
+                  freeze = 1;
+                  pargs.r.ret_str[len-1] = '\0';
+                }
+
+              faked_time = isotime2epoch (pargs.r.ret_str);
               if (faked_time == (time_t)(-1))
                 faked_time = (time_t)strtoul (pargs.r.ret_str, NULL, 10);
-              gnupg_set_time (faked_time, 0);
+              gnupg_set_time (faked_time, freeze);
             }
             break;
 
-- 
2.9.0



From gnupg-devel at spodhuis.org  Thu Jan 19 07:12:25 2017
From: gnupg-devel at spodhuis.org (Phil Pennock)
Date: Thu, 19 Jan 2017 01:12:25 -0500
Subject: DCO for Phil Pennock
Message-ID: <20170119061225.GA26207@breadbox.private.spodhuis.org>

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: Phil Pennock 
Signed-off-by: Phil Pennock 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: 

From gnupg-devel at spodhuis.org  Thu Jan 19 07:21:42 2017
From: gnupg-devel at spodhuis.org (Phil Pennock)
Date: Thu, 19 Jan 2017 01:21:42 -0500
Subject: [PATCH] Handle missing nsswitch.conf, fallback files,dns
Message-ID: <20170119062141.GA26709@breadbox.private.spodhuis.org>

From: Phil Pennock 

Signed-off-by: Phil Pennock 
---
 dirmngr/dns-stuff.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/dirmngr/dns-stuff.c b/dirmngr/dns-stuff.c
index 28ecb18..eae888b 100644
--- a/dirmngr/dns-stuff.c
+++ b/dirmngr/dns-stuff.c
@@ -478,7 +478,16 @@ libdns_init (void)
       if (err)
         {
           log_error ("failed to load '%s': %s\n", fname, gpg_strerror (err));
-          goto leave;
+          /* not fatal, nsswitch.conf is not used on all systems; assume
+           * classic behavior instead.  Our dns library states "bf" which tries
+           * DNS then Files, which is not classic; FreeBSD
+           * /usr/src/lib/libc/net/gethostnamadr.c defines default_src[] which
+           * is Files then DNS, which is. */
+          log_debug ("dns: fallback resolution order, files then DNS");
+          ld.resolv_conf->lookup[0] = 'f';
+          ld.resolv_conf->lookup[1] = 'b';
+          ld.resolv_conf->lookup[2] = '\0';
+          err = GPG_ERR_NO_ERROR;
         }
 
 #endif /* Unix */
-- 
1.9.1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: 

From gnupg-devel at spodhuis.org  Thu Jan 19 07:30:27 2017
From: gnupg-devel at spodhuis.org (Phil Pennock)
Date: Thu, 19 Jan 2017 06:30:27 +0000
Subject: [PATCH] Handle missing nsswitch.conf, fallback files,dns
In-Reply-To: <20170119062141.GA26709@breadbox.private.spodhuis.org>
References: <20170119062141.GA26709@breadbox.private.spodhuis.org>
Message-ID: <20170119063026.GA72399@tower.spodhuis.org>

On 2017-01-19 at 01:21 -0500, Phil Pennock wrote:
> From: Phil Pennock 
> 
> Signed-off-by: Phil Pennock 
> ---
>  dirmngr/dns-stuff.c | 11 ++++++++++-
>  1 file changed, 10 insertions(+), 1 deletion(-)

The bug-report was delayed for greylisting by gnupg.org servers but was
eventually accepted, but appears to have gotten stuck; hopefully it'll
make it through at some point?

Short version: macOS doesn't include /etc/nsswitch.conf and GnuPG's
dirmngr is hard-erroring when that file is missing, such that no DNS
operations succeed and --recv-key returns ENOENT type errors to the
caller.


From gnupg-devel at spodhuis.org  Thu Jan 19 06:09:45 2017
From: gnupg-devel at spodhuis.org (Phil Pennock)
Date: Thu, 19 Jan 2017 00:09:45 -0500
Subject: gnupg 2.1.17 DNS : macOS lacks nsswitch.conf
Message-ID: <20170119050945.GA24632@breadbox.private.spodhuis.org>

Short version: macOS doesn't use nsswitch.conf, dirmngr breaks.

Longer version:

Running GnuPG 2.1.17 on macOS 10.12.2 for about a week, looks like I
must have failed to restart dirmngr and hadn't actually rebooted in that
time, only slept.  So must have been using 2.1.16's dirmngr -- that's
the only explanation I can find for why things didn't break before.

DNS failures, so I patched the homebrew-versions formula (the build
system) to apply
0001-dirmngr-Strip-root-zone-suffix-from-libdns-cname-res.patch from
Werner's email.  Rebuilt.  Still no joy.

Enabled `log-file` in dirmngr.conf (with `verbose 1024` set), `gpgconf
--kill dirmngr` and retry, to see:

2017-01-18 23:46:22 dirmngr[7945.6] failed to load '/etc/nsswitch.conf': No such file or directory
2017-01-18 23:46:22 dirmngr[7945.6] failed to load '/etc/nsswitch.conf': No such file or directory
2017-01-18 23:46:22 dirmngr[7945.6] resolving 'sks.spodhuis.org' failed: No such file or directory
2017-01-18 23:46:22 dirmngr[7945.6] can't connect to 'sks.spodhuis.org': host not found
2017-01-18 23:46:22 dirmngr[7945.6] error connecting to 'https://sks.spodhuis.org:443': Unknown host
2017-01-18 23:46:22 dirmngr[7945.6] marking host 'sks.spodhuis.org' as dead

So I created a stub `/etc/nsswitch.conf` file, containing just:
  hosts: files dns
then killed dirmngr and tried again, and things worked.

Seems like a simple fix, wondering if I should just get a DCO on file.

-Phil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: 

From john.fr.omeara at gmail.com  Thu Jan 19 07:40:58 2017
From: john.fr.omeara at gmail.com (John O'Meara)
Date: Thu, 19 Jan 2017 01:40:58 -0500
Subject: [PATCH] gpg: Fix regexp sanitization.
In-Reply-To: <20170117220445.24873-1-dgouttegattat@incenp.org>
References: <20170117220445.24873-1-dgouttegattat@incenp.org>
Message-ID: <20170119064058.NQNVOkWOX%john.fr.omeara@gmail.com>

Hi Damien and list,

I filed issue 2923, have been thinking about the trust signature domain
restrictions some more, and wanted to discuss a bit.

I don't know the original motivation for escaping everything except the dot.

The patch does fix the common use-case of a simple domain name (either not as a
regex or as gnupg creates a regex), which is all the bug report covered.
However, it does not allow more expressive uses.

Here is an example use case for supporting more of the regex: I might trust an
admin for multiple (sub)domains that they manage, and might be related, but
not for the rest of the infrastructure (or alternatively, I might trust a
senior admin for the whole company, but if the company has merged with
another, there might be multiple domains, and I don't want to trust the admin
for all of '.com'). As a concrete example, I might trust them for
sales.example.com and billing.example.com but not engineering.example.com. My
regex might then look like '<[^>]+[@.](sales|billing)\.example\.com>$'

If every special is escaped outside of the prefix/postfix, then this of course
will not work. I can't create two trust signatures, one with each domain,
because only the most recent is considered. It would feel awkward of me to
require the admin to have two UIDs, so that I could put a different tsig on
each UID, but even if they had two UIDs and I tsigned each differently, that
doesn't work (looks like gpg uses the most recent trust signature on the key
overall, not per UID in the key?). So currently (well, after this patch), I'd
need that admin to have two separate keys if I want to tsign for multiple
domains to work.


Still, we can't leave everything unescaped, because the regex in OpenPGP
doesn't match the regex in POSIX extended regex. From what I can gather
(mostly referencing the Boost documentation on POSIX extended regex and
section 8 of RFC 4880), in POSIX a backslash escape is literal in a character
set (what OpenPGP calls a range), and otherwise causes a special character to
become literal (of the set .[{()\*+?|^$ and note no ']' or '}'). A backslash
preceding any other character is undefined.

OpenPGP regex, on the other hand, states that a backslash makes the next char
literal no matter what (though doesn't discuss how backslash operates in a
range), and OpenPGP doesn't have character class, collating elements,
equivalence classes, or ranged repeats (using curly braces '{' and '}').

A simple converter then, I think, would be to add an escape before a '{'
unless there is one already, and remove any escapes in front of non-special
chars. I think it is unlikely that a legitimate OpenPGP regex would
accidentally look like a character class/collater/equivalence, so we might not
have to worry about that. I don't know what to do about backslashes in a range
(this might be covered in the book on regular expressions mentioned in the
informative references section of rfc 4880)


Of course, for all of this to be generally useful, there'd also need to be a
(non-default) mode when making a trust signature to prevent gnupg from
escaping those characters when saving.



Does this seem reasonable? I can take a stab at a patch if desired, but I
didn't want to work on that if I'm way off here.

Thanks,

John O'Meara


Damien Goutte-Gattat  wrote:

> * g10/trustdb.c (sanitize_regexp): Do not escape normal characters.
> --
> 
> The current sanitization code escapes ALL characters in the
> regular expression, including characters that do not have any
> special meaning and only match themselves. Only the dot (.)
> is not escaped.
> 
> This leads to, e.g., 'example.com' being sanitized into
> '\e\x\a\m\p\l\e.\c\o\m', which will then fail to match against
> 'alice at example.com'.
> 
> This patch updates the function to escape only the meaningful
> characters (minus the dot).
> 
> Signed-off-by: Damien Goutte-Gattat 
> ---
>  g10/trustdb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/g10/trustdb.c b/g10/trustdb.c
> index c113b7e..e5f32da 100644
> --- a/g10/trustdb.c
> +++ b/g10/trustdb.c
> @@ -1498,7 +1498,7 @@ sanitize_regexp(const char *old)
>      {
>        if(!escaped && old[start]=='\\')
>  	escaped=1;
> -      else if(!escaped && old[start]!='.')
> +      else if(!escaped && strchr("[]$^()|*+?{}", old[start]))
>  	new[idx++]='\\';
>        else
>  	escaped=0;
> -- 
> 2.9.0
> 


From justus at g10code.com  Thu Jan 19 10:42:27 2017
From: justus at g10code.com (Justus Winter)
Date: Thu, 19 Jan 2017 10:42:27 +0100
Subject: [PATCH] gpg: Allow to freeze faked system time.
In-Reply-To: <20170118175212.16066-1-dgouttegattat@incenp.org>
References: <20170118175212.16066-1-dgouttegattat@incenp.org>
Message-ID: <87wpdr8jy4.fsf@europa.jade-hamburg.de>

Damien Goutte-Gattat  writes:

> * g10/gpg.c (main): If the parameter for --faked-system-time
> ends with a '!', freeze time at the specified point.
> * common/gettime.c (gnupg_set_time): Allow to freeze the time
> at an arbitrary time instead of only the current time.
> * doc/gpg.texi: Update documentation for --faked-system-time.
> --
>
> This patch allows the user to modify the behavior of the
> --faked-system-time option: by appending a '!' to the parameter,
> time in GnuPG will be frozen at the specified time, instead of
> advancing normally from that time onward.

Merged, thanks!

Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: 

From bisson at archlinux.org  Thu Jan 19 10:51:55 2017
From: bisson at archlinux.org (Gaetan Bisson)
Date: Wed, 18 Jan 2017 23:51:55 -1000
Subject: Parsing of negation statements in nsswitch.conf currently not
 implemented
Message-ID: <20170119095155.GA7580@fugu.vesath.org>

Hi,

We've been having issues over at Arch Linux with the new libdns code.
Our /etc/nsswitch.conf contains the following line:

	hosts: files mymachines resolve [!UNAVAIL=return] dns myhostname

And it turns out dirmngr fails to parse the negation statement (the bang
in !UNAVAIL). This results in gnupg not being able to resolve any name.

Looking at dirmngr/dns.c it was unclear to me how to properly handle
such negations. The dns_anyconf_scan calls used in dns_nssconf_loadfile
do not allow to store a negation bit easily...

In the meantime, I wrote the attached patch which ignores those
statements altogether. It makes libdns work as expected for us.

Cheers.

-- 
Gaetan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: negation.patch
Type: text/x-diff
Size: 771 bytes
Desc: not available
URL: 

From dgouttegattat at incenp.org  Thu Jan 19 16:53:51 2017
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Thu, 19 Jan 2017 16:53:51 +0100
Subject: [PATCH] gpg: Fix regexp sanitization.
In-Reply-To: <20170119064058.NQNVOkWOX%john.fr.omeara@gmail.com>
References: <20170117220445.24873-1-dgouttegattat@incenp.org>
 <20170119064058.NQNVOkWOX%john.fr.omeara@gmail.com>
Message-ID: 

On 01/19/2017 07:40 AM, John O'Meara wrote:
> I filed issue 2923

I wish I had thought to look at the bug tracker before working on the
problem... ;)


> The patch does fix the common use-case of a simple domain name
> (either not as a regex or as gnupg creates a regex), which is all the
> bug report covered. However, it does not allow more expressive uses.
> [...]My regex might then look like
> '<[^>]+[@.](sales|billing)\.example\.com>$'

Agreed. "More expressive uses" like your example are allowed by RFC
4880, but GnuPG does not support them.

I believe the original PGP did not support them either (at least
according to the user manuals I found, having never used PGP myself).

> In POSIX [...] a backslash preceding any other character is
> undefined.

Yes, and that's the root cause of the bug we're talking about: the
original code in sanitize_regexp obviously assumed the regex
implementation would treat an escaped non-special character as if it
were not escaped. Some regex packages do behave that way, but it seems
the GNU Libc's regcomp/regexec does not.


> Of course, for all of this to be generally useful, there'd also need
> to be a (non-default) mode when making a trust signature to prevent
> gnupg from escaping those characters when saving.

A possibility would be to use the --expert flag to enable such a mode.
Without that flag, we stick to the current behavior. With --expert mode
enabled, we let the user enter a regular expression of its own choosing,
and we don't touch it (no escaping and no bracketing with <[^>]+[@.] and 
 >$).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: 

From gniibe at fsij.org  Fri Jan 20 11:19:43 2017
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Fri, 20 Jan 2017 19:19:43 +0900
Subject: NTBTLS: verification of certificate
Message-ID: <87efzyrq2o.fsf@fsij.org>

Hello,

I am testing following code with dirmngr in master (and ntbtls of
master).

I confirmed that two hosts work fine.

    https://host-37-191-238-78.lynet.no
    https://gpg.nebrwesleyan.edu

==========================
diff --git a/src/pkglue.c b/src/pkglue.c
index 45f388b..33613d3 100644
--- a/src/pkglue.c
+++ b/src/pkglue.c
@@ -77,6 +77,156 @@ pk_algo_from_sexp (gcry_sexp_t pkey)
 }
 
 
+/* Copied from gpgsm */
+/* Hash function used with libksba. */
+#define HASH_FNC ((void (*)(void *, const void*,size_t))gcry_md_write)
+
+static int
+do_encode_md (gcry_md_hd_t md, int algo, int pkalgo, unsigned int nbits,
+              gcry_sexp_t pkey, gcry_mpi_t *r_val)
+{
+  int n;
+  size_t nframe;
+  unsigned char *frame;
+
+  if (pkalgo == GCRY_PK_DSA || pkalgo == GCRY_PK_ECDSA)
+    return gpg_error (GPG_ERR_INTERNAL);
+  else
+    {
+      int i;
+      unsigned char asn[100];
+      size_t asnlen;
+      size_t len;
+
+      nframe = (nbits+7) / 8;
+
+      asnlen = DIM(asn);
+      if (!algo || gcry_md_test_algo (algo))
+        return gpg_error (GPG_ERR_DIGEST_ALGO);
+      if (gcry_md_algo_info (algo, GCRYCTL_GET_ASNOID, asn, &asnlen))
+        {
+          return gpg_error (GPG_ERR_INTERNAL);
+        }
+
+      len = gcry_md_get_algo_dlen (algo);
+
+      if ( len + asnlen + 4  > nframe )
+        {
+          return gpg_error (GPG_ERR_INTERNAL);
+        }
+
+      /* We encode the MD in this way:
+       *
+       *	   0  A PAD(n bytes)   0  ASN(asnlen bytes)  MD(len bytes)
+       *
+       * PAD consists of FF bytes.
+       */
+      frame = malloc (nframe);
+      if (!frame)
+        return gpg_error (GPG_ERR_INTERNAL);
+      n = 0;
+      frame[n++] = 0;
+      frame[n++] = 1; /* block type */
+      i = nframe - len - asnlen -3 ;
+      // assert ( i > 1 );
+      memset ( frame+n, 0xff, i ); n += i;
+      frame[n++] = 0;
+      memcpy ( frame+n, asn, asnlen ); n += asnlen;
+      memcpy ( frame+n, gcry_md_read(md, algo), len ); n += len;
+      // assert ( n == nframe );
+    }
+
+  gcry_mpi_scan (r_val, GCRYMPI_FMT_USG, frame, n, &nframe);
+  free (frame);
+  return 0;
+}
+
+/* Copied from gpgsm */
+gpg_error_t
+_ntbtls_x509_check_cert_sig (ksba_cert_t issuer_cert, ksba_cert_t cert)
+{
+  gpg_error_t err;
+  const char *algoid;
+  gcry_md_hd_t md;
+  int algo;
+  gcry_mpi_t frame;
+  ksba_sexp_t p;
+  size_t n;
+  gcry_sexp_t s_sig, s_hash, s_pkey;
+
+  algo = gcry_md_map_name ( (algoid=ksba_cert_get_digest_algo (cert)));
+  if (!algo)
+    return gpg_error (GPG_ERR_GENERAL);
+
+  err = gcry_md_open (&md, algo, 0);
+  if (err)
+    return err;
+
+  err = ksba_cert_hash (cert, 1, HASH_FNC, md);
+  if (err)
+    {
+      gcry_md_close (md);
+      return err;
+    }
+  gcry_md_final (md);
+
+  p = ksba_cert_get_sig_val (cert);
+  n = gcry_sexp_canon_len (p, 0, NULL, NULL);
+  if (!n)
+    {
+      gcry_md_close (md);
+      ksba_free (p);
+      return gpg_error (GPG_ERR_BUG);
+    }
+
+  err = gcry_sexp_sscan ( &s_sig, NULL, (char*)p, n);
+  ksba_free (p);
+  if (err)
+    {
+      gcry_md_close (md);
+      return err;
+    }
+
+  p = ksba_cert_get_public_key (issuer_cert);
+  n = gcry_sexp_canon_len (p, 0, NULL, NULL);
+  if (!n)
+    {
+      gcry_md_close (md);
+      ksba_free (p);
+      gcry_sexp_release (s_sig);
+      return gpg_error (GPG_ERR_BUG);
+    }
+  err = gcry_sexp_sscan ( &s_pkey, NULL, (char*)p, n);
+  ksba_free (p);
+  if (err)
+    {
+      gcry_md_close (md);
+      gcry_sexp_release (s_sig);
+      return err;
+    }
+
+  err = do_encode_md (md, algo, pk_algo_from_sexp (s_pkey),
+		      gcry_pk_get_nbits (s_pkey), s_pkey, &frame);
+  if (err)
+    {
+      gcry_md_close (md);
+      gcry_sexp_release (s_sig);
+      gcry_sexp_release (s_pkey);
+      return err;
+    }
+
+  /* put hash into the S-Exp s_hash */
+  gcry_sexp_build (&s_hash, NULL, "%m", frame);
+  gcry_mpi_release (frame);
+
+  err = gcry_pk_verify (s_sig, s_hash, s_pkey);
+  gcry_md_close (md);
+  gcry_sexp_release (s_sig);
+  gcry_sexp_release (s_hash);
+  gcry_sexp_release (s_pkey);
+  return err;
+}
+
 gpg_error_t
 _ntbtls_pk_verify (x509_cert_t chain, pk_algo_t pk_alg, md_algo_t md_alg,
                    const unsigned char *hash, size_t hashlen,
diff --git a/src/protocol.c b/src/protocol.c
index f616bca..9b5659d 100644
--- a/src/protocol.c
+++ b/src/protocol.c
@@ -2007,7 +2007,7 @@ _ntbtls_read_certificate (ntbtls_t tls)
                                  tls->ca_chain, tls->ca_crl,
                                  tls->hostname,
                                  &tls->session_negotiate->verify_result);
-      if (err)
+      if (1 || err)
         {
           debug_ret (1, "x509_verify", err);
         }
@@ -2036,9 +2036,6 @@ _ntbtls_read_certificate (ntbtls_t tls)
       /*     if (!err) */
       /*       err = gpg_error (GPG_ERR_BAD_HS_CERT); */
       /*   } */
-
-      if (tls->authmode != TLS_VERIFY_REQUIRED)
-        err = 0;
     }
 
   return err;
@@ -2635,6 +2632,8 @@ _ntbtls_new (ntbtls_t *r_tls, unsigned int flags)
   if (!tls)
     return gpg_error_from_syserror ();  /* Return immediately.  */
 
+  ssl_set_authmode (tls, TLS_VERIFY_OPTIONAL);
+
   tls->min_major_ver = TLS_MIN_MAJOR_VERSION;
   tls->min_minor_ver = TLS_MIN_MINOR_VERSION;
   tls->max_major_ver = TLS_MAX_MAJOR_VERSION;
diff --git a/src/x509.c b/src/x509.c
index 595839d..70d063c 100644
--- a/src/x509.c
+++ b/src/x509.c
@@ -187,14 +187,71 @@ _ntbtls_x509_get_pk (x509_cert_t cert, int idx, gcry_sexp_t *r_pk)
 }
 
 
+/* Check if PARENT verifies CHILD */
+static gpg_error_t
+check_parent (x509_cert_t child, x509_cert_t parent)
+{
+  gpg_error_t err = 0;
+  char *issuer = ksba_cert_get_issuer (child->crt, 0);
+  char *subject = ksba_cert_get_subject (parent->crt, 0);
+
+  /* Parent must be the issuer */
+  if (strcmp (issuer, subject) != 0)
+    err = gpg_error (GPG_ERR_BAD_CERT_CHAIN);
+
+  if (!err)
+    debug_msg (2, "checking signature by: %s", issuer);
+
+  free (issuer);
+  free (subject);
+
+  if (!err)
+    {
+      /* FIXME: Expired? Future? */
+
+      err = _ntbtls_x509_check_cert_sig (parent->crt, child->crt);
+    }
+
+  return err;
+}
+
 
 gpg_error_t
 _ntbtls_x509_verify (x509_cert_t chain, x509_cert_t trust_ca, x509_crl_t ca_crl,
                      const char *cn, int *r_flags)
 {
-  //FIXME:
+  gpg_error_t err;
+  x509_cert_t cert, cert_prev;
+  x509_cert_t ca;
+  int flag, chainlen;
 
-  return 0;
+  *r_flags = 0;
+
+  // FIXME: with peer hostname, check it.
+  //if (cn)
+  //  {
+  //  }
+
+  cert_prev = NULL;
+  for (cert = chain; cert->next; cert_prev = cert, cert = cert->next)
+    if ((err = check_parent (cert, cert->next)))
+      return err;
+
+  if (ksba_cert_is_ca (cert->crt, &flag, &chainlen))
+    cert = cert_prev;
+
+  if (cert == NULL)
+    return gpg_error (GPG_ERR_INTERNAL);
+
+  for (ca = trust_ca; ca; ca = ca->next)
+    if (check_parent (cert, ca) == 0)
+      {
+	/* FIXME: More check/validation ? */
+	return 0;
+      }
+
+  /* No CA found.  */
+  return gpg_error (GPG_ERR_NOT_FOUND);
 }
 
 
-- 


From wk at gnupg.org  Mon Jan 23 10:50:06 2017
From: wk at gnupg.org (Werner Koch)
Date: Mon, 23 Jan 2017 10:50:06 +0100
Subject: [PATCH] gpg: Fix misleading log message when checking regexp.
In-Reply-To: <20170117194209.25937-1-dgouttegattat@incenp.org> (Damien
 Goutte-Gattat's message of "Tue, 17 Jan 2017 20:42:09 +0100")
References: <20170117194209.25937-1-dgouttegattat@incenp.org>
Message-ID: <87d1fe9kc1.fsf@wheatstone.g10code.de>

Thanks,


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: 227 bytes
Desc: not available
URL: 

From wk at gnupg.org  Mon Jan 23 11:43:58 2017
From: wk at gnupg.org (Werner Koch)
Date: Mon, 23 Jan 2017 11:43:58 +0100
Subject: [PATCH] Handle missing nsswitch.conf, fallback files,dns
In-Reply-To: <20170119062141.GA26709@breadbox.private.spodhuis.org> (Phil
 Pennock's message of "Thu, 19 Jan 2017 01:21:42 -0500")
References: <20170119062141.GA26709@breadbox.private.spodhuis.org>
Message-ID: <878tq29hu9.fsf@wheatstone.g10code.de>

Hi Phil,

Thanks for the patch.  I pushed it and registerd your DCO.  Please write
a ChangeLog style commit logs for future patches (see doc/HACKING) so
that we do not need to add them.


Shalom-Salam,

   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: 227 bytes
Desc: not available
URL: 

From wk at gnupg.org  Mon Jan 23 13:10:38 2017
From: wk at gnupg.org (Werner Koch)
Date: Mon, 23 Jan 2017 13:10:38 +0100
Subject: Parsing of negation statements in nsswitch.conf currently not
 implemented
In-Reply-To: <20170119095155.GA7580@fugu.vesath.org> (Gaetan Bisson's message
 of "Wed, 18 Jan 2017 23:51:55 -1000")
References: <20170119095155.GA7580@fugu.vesath.org>
Message-ID: <87poje7z9d.fsf@wheatstone.g10code.de>

On Thu, 19 Jan 2017 10:51, bisson at archlinux.org said:

> In the meantime, I wrote the attached patch which ignores those
> statements altogether. It makes libdns work as expected for us.

I applied your patch.  It is small enough to go without a DCI.
Thanks,


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: 227 bytes
Desc: not available
URL: 

From patrick at enigmail.net  Mon Jan 23 15:04:53 2017
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Mon, 23 Jan 2017 15:04:53 +0100
Subject: Crashes with gpg-agent 2.1.17
Message-ID: <83c60b0f-9694-84fe-c30a-91f5a8546af7@enigmail.net>

I got quite frequent crashes with gpg-agent on Mac OS X, and thus
started to investigate what happens.

Here is the debug output:

gpg-agent[30807]: DBG: chan_19 -> OK Pleased to meet you
gpg-agent[30807]: DBG: chan_19 <- RESET
gpg-agent[30807]: DBG: chan_19 -> OK
gpg-agent[30807]: DBG: chan_19 <- OPTION
display=/private/tmp/com.apple.launchd.V3yERuMgKg/org.macosforge.xquartz:0
gpg-agent[30807]: DBG: chan_19 -> OK
gpg-agent[30807]: DBG: chan_19 <- GETINFO version
gpg-agent[30807]: DBG: chan_19 -> D 2.1.17
gpg-agent[30807]: DBG: chan_19 -> OK
gpg-agent[30807]: DBG: chan_19 <- OPTION allow-pinentry-notify
gpg-agent[30807]: DBG: chan_19 -> OK
gpg-agent[30807]: DBG: chan_19 <- OPTION agent-awareness=2.1.0
gpg-agent[30807]: DBG: chan_19 -> OK
gpg-agent[30807]: DBG: chan_19 <- HAVEKEY
E0935FE2D7829F0CA7580D98F58ECD6EF0A9DE25
gpg-agent[30807]: DBG: chan_19 -> OK
gpg-agent[30807]: DBG: chan_19 <- HAVEKEY
D9E76BE9ECE8DD29D9DFCB9CF54CB6D50244721B
E0935FE2D7829F0CA7580D98F58ECD6EF0A9DE25
gpg-agent[30807]: DBG: chan_19 -> OK
gpg-agent[30807]: DBG: chan_19 <- HAVEKEY
E0935FE2D7829F0CA7580D98F58ECD6EF0A9DE25
gpg-agent[30807]: DBG: chan_19 -> OK
gpg-agent[30807]: DBG: chan_19 <- RESET
gpg-agent[30807]: DBG: chan_19 -> OK
gpg-agent[30807]: DBG: chan_19 <- SETKEY
E0935FE2D7829F0CA7580D98F58ECD6EF0A9DE25
gpg-agent[30807]: DBG: chan_19 -> OK
gpg-agent[30807]: DBG: chan_19 <- SETKEYDESC
Please+enter+the+passphrase+to+unlock+the+OpenPGP+secret+key:%0A%22Patrick+Brunschwig+%22%0A4096-bit+RSA+key,+ID+91426DC14E4953D8,%0Acreated+2015-01-17+(main+key+ID+DB1187B9DD5F693B).%0A
gpg-agent[30807]: DBG: chan_19 -> OK
gpg-agent[30807]: DBG: chan_19 <- PKDECRYPT
gpg-agent[30807]: DBG: chan_19 -> S INQUIRE_MAXLEN 4096
gpg-agent[30807]: DBG: chan_19 -> INQUIRE CIPHERTEXT
gpg-agent[30807]: DBG: chan_19 <- [ 44 20 28 37 3a 65 6e 63 2d 76 61 6c
28 33 3a 72 ...(541 byte(s) skipped) ]
gpg-agent[30807]: DBG: chan_19 <- END
gpg-agent[30807]: DBG: keygrip: E0 93 5F E2 D7 82 9F 0C A7 58 0D 98 F5
8E CD 6E F0 A9 DE 25
gpg-agent[30807]: DBG: cipher:  28 37 3A 65 6E 63 2D 76 61 6C 28 33 3A
72 73 61 28 31 3A 61 35 31 32 3A 05 68 7A 18 A9 AA 65 C4 4C E3 35 87 3B
5F 20 05 BE 7E 0A 03 BF D7 0B C1 66 84 3A 6B BB B3 94 17 FE C7 5D CD 45
B7 B0 79 DA 7D 82 AE 75 FF 19 82 D4 5D D4 1D 58 16 D3 E8 52 1F 1D 72 EC
86 A8 B6 ED 98 52 AA D3 02 A2 8B A0 5C 1F 76 B8 1B 50 C8 61 4C F2 D6 01
42 5A AA BB 99 B6 9F 32 57 E2 F0 DC 16 73 7D AC 6D 53 24 86 C0 83 61 4A
5D 20 03 AB 46 01 0E 40 52 2A 93 28 78 87 58 04 8A 4D A8 EB 50 B2 3F A6
C7 2D 72 DE 0B 72 F7 D2 31 9F 06 3F 9D B0 14 3D D2 7F D3 05 63 AB 70 79
57 6A E9 48 A8 2C 5E 3E 8C A8 F1 C9 93 A1 E0 72 54 DF 17 08 E9 36 B7 F4
F9 95 3F 79 C2 B9 B0 64 63 4B CF DD AB 0B 25 DF 0D 38 C1 CD 96 04 F5 56
FB 1D 35 8C 2F 64 CF E8 1F 11 D5 78 FC 21 11 D1 4D 57 0D 23 59 6A 35 E5
99 BF 37 92 63 9C C9 AA 94 0A 6D 35 92 AA 86 68 D5 41 2E B0 A6 9B D7 1E
8E DA 27 67 C6 58 29 2B 1A D4 79 C4 93 99 62 DD E7 EE 51 E2 E5 69 25 3B
AC 14 4C 4F E4 D3 25 E5 1C 35 A2 C0 46 26 DD 36 3E 75 93 B4 8A DC D0 5F
3E 6A 90 5F 6A F2 F9 DA 74 30 8D 4D 38 41 2E E7 42 53 71 FC F0 91 F2 9A
F5 52 A6 7A FC 41 37 D5 0B FB BB 9F AC 77 63 71 22 38 18 2A 75 83 44 29
4F 32 57 4A 00 E2 88 9A 81 E4 04 0D 01 0E A7 91 D1 81 B8 6A 42 ED 09 58
50 06 B3 E1 73 CA 90 2B CD 82 B6 15 82 D3 E1 79 C6 17 61 91 E6 DA F9 B3
C8 F4 DB 58 49 86 8C 09 CA A7 EE E2 FD 65 3E CA 86 F0 5A 90 38 76 99 F3
3D 0E 42 7C D6 0F 6C B1 97 BA CD 81 9E 61 A6 E0 F1 FF DF 21 CF 2C AD C5
36 77 8C 13 D9 EE E4 31 47 84 AF F4 EE C8 A7 06 6E F2 B7 7B 68 24 E6 45
74 B8 E1 78 BF 01 4C 94 A8 5E 6C CF D7 C2 0B 91 A9 2F 90 EC DC D0 B8 63
DD A2 7A 64 EF 73 1C 1A 6D 9A A4 3C 4C 07 BC 90 AB B6 A0 29 29 29
gpg-agent[30807]: DBG: agent_get_cache
'E0935FE2D7829F0CA7580D98F58ECD6EF0A9DE25' (mode 2) ...
gpg-agent[30807]: DBG: ... hit
gpg-agent[30807]: retrieving cache entry
'E0935FE2D7829F0CA7580D98F58ECD6EF0A9DE25' failed: Cannot allocate memory
gpg-agent[30807]: DBG: agent_get_cache
'E0935FE2D7829F0CA7580D98F58ECD6EF0A9DE25' (mode 2) (stored cache key) ...
gpg-agent[30807]: DBG: ... hit
gpg-agent[30807]: retrieving cache entry
'E0935FE2D7829F0CA7580D98F58ECD6EF0A9DE25' failed: Cannot allocate memory
gpg-agent[30807]: failed to unprotect the secret key: Cannot allocate memory
gpg-agent[30807]: failed to read the secret key
gpg-agent[30807]: command 'PKDECRYPT' failed: Cannot allocate memory
gpg-agent[30807]: DBG: chan_19 -> ERR 67141718 Cannot allocate memory

gpg-agent[30807]: DBG: chan_19 <- HAVEKEY
06799B633E043A7665BBE85BDD883A71166B80B7
gpg-agent[30807]: DBG: chan_19 -> ERR 67108881 No secret key 
gpg-agent[30807]: DBG: rsa_decrypt  res: [out of core]
gpg-agent[30807]: Ohhhh jeeee: ... this is a bug
(sexp.c:1433:do_vsexp_sscan)

Is this a bug, or is it a config/setup error on my side?

Thanks,
Patrick


From wk at gnupg.org  Mon Jan 23 22:46:23 2017
From: wk at gnupg.org (Werner Koch)
Date: Mon, 23 Jan 2017 22:46:23 +0100
Subject: [Announce] GnuPG 2.1.18 released
Message-ID: <87d1fd8n68.fsf@wheatstone.g10code.de>

Hello!

The GnuPG team is pleased to announce the availability of a new release
of GnuPG: Version 2.1.18.  See below for a list of new features and bug
fixes.


About GnuPG
=============

The GNU Privacy Guard (GnuPG) is a complete and free implementation
of the OpenPGP standard which is commonly abbreviated as PGP.

GnuPG 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 branches of GnuPG are actively maintained:

- GnuPG "modern" (2.1) comes with the latest features and is suggested
  for most users.  This announcement is about this branch.

- GnuPG "stable" (2.0) is the currently mostly used branch which will be
  maintain until 2017-12-31.

- GnuPG "classic" (1.4) is a simplified version of GnuPG, required on
  very old platforms or to decrypt data created with PGP-2 keys.

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.


Noteworthy changes in version 2.1.18
====================================

  * gpg: Remove bogus subkey signature while cleaning a key (with
    export-clean, import-clean, or --edit-key's sub-command clean)

  * gpg: Allow freezing the clock with --faked-system-time.

  * gpg: New --export-option flag "backup", new --import-option flag
    "restore".

  * gpg-agent: Fixed long delay due to a regression in the progress
    callback code.

  * scd: Lots of code cleanup and internal changes.

  * scd: Improved the internal CCID driver.

  * dirmngr: Fixed problem with the DNS glue code (removal of the
    trailing dot in domain names).

  * dirmngr: Make sure that Tor is actually enabled after changing the
    conf file and sending SIGHUP or "gpgconf --reload dirmngr".

  * dirmngr: Fixed Tor access to IPv6 addresses.  Note that current
    versions of Tor may require that the flag "IPv6Traffic" is used
    with the option "SocksPort" in torrc to actually allow IPv6
    traffic.

  * dirmngr: Fixed HKP for literally given IPv6 addresses.

  * dirmngr: Enabled reverse DNS lookups via Tor.

  * dirmngr: Added experimental SRV record lookup for WKD.
    See commit 88dc3af3d4ae1afe1d5e136bc4c38bc4e7d4cd10 for details.

  * dirmngr: For HKP use "pgpkey-hkps" and "pgpkey-hkp" in SRV record
    lookups.  Avoid SRV record lookup when a port is explicitly
    specified.  This fixes a regression from the 1.4 and 2.0 behavior.

  * dirmngr: Gracefully handle a missing /etc/nsswitch.conf.  Ignore
    negation terms (e.g. "[!UNAVAIL=return]" instead of bailing out.

  * dirmngr: Better debug output for flags "dns" and "network".

  * dirmngr: On reload mark all known HKP servers alive.

  * gpgconf: Allow keyword "all" for --launch, --kill, and --reload.

  * tools: gpg-wks-client now ignores a missing policy file on the
    server.

  * Avoid unnecessary ambiguity error message in the option parsing.

  * Further improvements of the regression test suite.

  * Fixed building with --disable-libdns configure option.

  * Fixed a crash running the tests on 32 bit architectures.

  * Fixed spurious failures on BSD system in the spawn functions.
    This affected for example gpg-wks-client and gpgconf.

A detailed description of the changes found in this 2.1 branch can be
found at .


Getting the Software
====================

Please follow the instructions found at  or
read on:

GnuPG 2.1.18 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
.  Note that GnuPG is not
available at ftp.gnu.org.

The GnuPG source code compressed using BZIP2 and its OpenPGP signature
are available here:

 ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.18.tar.bz2  (6160k)
 ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.18.tar.bz2.sig
or here:
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.18.tar.bz2
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.18.tar.bz2.sig

An installer for Windows without any graphical frontend except for a
very minimal Pinentry tool is available here:

 ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.18_20170123.exe  (3670k)
 ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.18_20170123.exe.sig
or here
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.18_20170123.exe
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.18_20170123.exe.sig

The source used to build the Windows installer can be found in the same
directory with a ".tar.xz" suffix.  This Windows installer comes with
TOFU support, translations, and support for Tor; it is still missing
HKPS and Web Key Directory support, though.


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.18.tar.bz2 you would use this command:

     gpg --verify gnupg-2.1.18.tar.bz2.sig gnupg-2.1.18.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 the end of this mail 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.18.tar.bz2, you run the command like this:

     sha1sum gnupg-2.1.18.tar.bz2

   and check that the output matches the next line:

b698012cc2d77c2652afd168a15e679d1394fa89  gnupg-2.1.18.tar.bz2
8d068811acef74619ca435b8bb7e77135bc4277b  gnupg-w32-2.1.18_20170123.exe
744ddb22719262006945bbe36229dedc5d6f94e1  gnupg-w32-2.1.18_20170123.tar.xz


Internationalization
====================

This version of GnuPG has support for 26 languages with Chinese, Czech,
French, German, Japanese, Norwegian, Russian, and Ukrainian being almost
completely translated.  Due to expected changes in forthcoming releases
some strings pertaining to the TOFU code are not yet translated.


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 our postings at 
and .


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 .  If you need commercial
support check out .

If you are a developer and you need a certain feature for your project,
please do not hesitate to bring it to the gnupg-devel mailing list for
discussion.

Maintenance and development of GnuPG is mostly financed by donations.
The GnuPG project employs 3 full-time developers, one part-timer, and
one contractor.  They all work exclusivly on GnuPG and closely related
software like Libgcrypt, GPGME, and GPA.  Please consider to donate via:

                  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, answering questions on the mailing
lists, and donating money.


The GnuPG hackers,

   Andre, dkg, gniibe, Justus, Neal, and Werner


p.s.
This is an announcement only mailing list.  Please send replies only to
the gnupg-users'at'gnupg.org mailing list.

p.p.s
List of 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: 2020-10-30]
  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 keys from a keyserver using this command

  gpg --keyserver hkp://keys.gnupg.net --recv-keys  \
                  249B39D24F25E3B6 04376F3EE0856959 \
                  2071B08A33BD3F06 8A861B1C7EFD60D9

The keys are also available at https://gnupg.org/signature_key.html and
in any recently released GnuPG tarball in the file g10/distsigkey.gpg .
Note that this mail has been signed by a different key.


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 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  Mon Jan 23 21:20:23 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 23 Jan 2017 15:20:23 -0500
Subject: Crashes with gpg-agent 2.1.17
In-Reply-To: <83c60b0f-9694-84fe-c30a-91f5a8546af7@enigmail.net>
References: <83c60b0f-9694-84fe-c30a-91f5a8546af7@enigmail.net>
Message-ID: <87fuk9tto8.fsf@alice.fifthhorseman.net>

On Mon 2017-01-23 09:04:53 -0500, Patrick Brunschwig wrote:
> I got quite frequent crashes with gpg-agent on Mac OS X, and thus
> started to investigate what happens.
 [...]
> gpg-agent[30807]: retrieving cache entry
> 'E0935FE2D7829F0CA7580D98F58ECD6EF0A9DE25' failed: Cannot allocate memory
> gpg-agent[30807]: DBG: agent_get_cache
> 'E0935FE2D7829F0CA7580D98F58ECD6EF0A9DE25' (mode 2) (stored cache key) ...
> gpg-agent[30807]: DBG: ... hit
> gpg-agent[30807]: retrieving cache entry
> 'E0935FE2D7829F0CA7580D98F58ECD6EF0A9DE25' failed: Cannot allocate memory
> gpg-agent[30807]: failed to unprotect the secret key: Cannot allocate memory
> gpg-agent[30807]: failed to read the secret key
> gpg-agent[30807]: command 'PKDECRYPT' failed: Cannot allocate memory
> gpg-agent[30807]: DBG: chan_19 -> ERR 67141718 Cannot allocate memory
> 
> gpg-agent[30807]: DBG: chan_19 <- HAVEKEY
> 06799B633E043A7665BBE85BDD883A71166B80B7
> gpg-agent[30807]: DBG: chan_19 -> ERR 67108881 No secret key 
> gpg-agent[30807]: DBG: rsa_decrypt  res: [out of core]
> gpg-agent[30807]: Ohhhh jeeee: ... this is a bug
> (sexp.c:1433:do_vsexp_sscan)
>
> Is this a bug, or is it a config/setup error on my side?

What version of libgcrypt are you building against?  aiui, 1.7.4 and
later include a pretty major overhaul of the secmem pool handling, which
affects gpg-agent's ability to handle larger (or multiple) keys
concurrently.  So if gnupg is built against newer versions of libgcrypt,
maybe that would fix your issue?

hth,

      --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: 

From patrick at enigmail.net  Tue Jan 24 09:14:53 2017
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Tue, 24 Jan 2017 09:14:53 +0100
Subject: Crashes with gpg-agent 2.1.17
In-Reply-To: <87fuk9tto8.fsf@alice.fifthhorseman.net>
References: <83c60b0f-9694-84fe-c30a-91f5a8546af7@enigmail.net>
 <87fuk9tto8.fsf@alice.fifthhorseman.net>
Message-ID: <4948e1b6-2a5c-627d-22de-bf019022b7bd@enigmail.net>

On 23.01.17 21:20, Daniel Kahn Gillmor wrote:
> On Mon 2017-01-23 09:04:53 -0500, Patrick Brunschwig wrote:
>> I got quite frequent crashes with gpg-agent on Mac OS X, and thus
>> started to investigate what happens.
>  [...]
>> gpg-agent[30807]: retrieving cache entry
>> 'E0935FE2D7829F0CA7580D98F58ECD6EF0A9DE25' failed: Cannot allocate memory
>> gpg-agent[30807]: DBG: agent_get_cache
>> 'E0935FE2D7829F0CA7580D98F58ECD6EF0A9DE25' (mode 2) (stored cache key) ...
>> gpg-agent[30807]: DBG: ... hit
>> gpg-agent[30807]: retrieving cache entry
>> 'E0935FE2D7829F0CA7580D98F58ECD6EF0A9DE25' failed: Cannot allocate memory
>> gpg-agent[30807]: failed to unprotect the secret key: Cannot allocate memory
>> gpg-agent[30807]: failed to read the secret key
>> gpg-agent[30807]: command 'PKDECRYPT' failed: Cannot allocate memory
>> gpg-agent[30807]: DBG: chan_19 -> ERR 67141718 Cannot allocate memory
>> 
>> gpg-agent[30807]: DBG: chan_19 <- HAVEKEY
>> 06799B633E043A7665BBE85BDD883A71166B80B7
>> gpg-agent[30807]: DBG: chan_19 -> ERR 67108881 No secret key 
>> gpg-agent[30807]: DBG: rsa_decrypt  res: [out of core]
>> gpg-agent[30807]: Ohhhh jeeee: ... this is a bug
>> (sexp.c:1433:do_vsexp_sscan)
>>
>> Is this a bug, or is it a config/setup error on my side?
> 
> What version of libgcrypt are you building against?  aiui, 1.7.4 and
> later include a pretty major overhaul of the secmem pool handling, which
> affects gpg-agent's ability to handle larger (or multiple) keys
> concurrently.  So if gnupg is built against newer versions of libgcrypt,
> maybe that would fix your issue?

I used libgcrypt 1.7.5.

Meanwhile I upgraded to gpg 2.1.18 and libgcrypt 1.7.6, and I still can
reproduce the issue:

gpg-agent[58725]: DBG: chan_38 -> OK
 3A 42 F2
gpg-agent[58725]: DBG: agent_get_cache
'E0935FE2D7829F0CA7580D98F58ECD6EF0A9DE25' (mode 2) ...
b7 5F
gpg-agent[58725]: DBG: agent_get_cache
'E0935FE2D7829F0CA7580D98F58ECD6EF0A9DE25' (mode 2) ...
 65 B6 42 42
gpg-agent[58725]: DBG: ... hit
 42 5A 29 5A19 42 D6
gpg-agent[58725]: DBG: ... hit
 A0 42 5A4d 42 42 F2 F294 61 5A D6
gpg-agent[58725]: DBG: ... hit
 E2
gpg-agent[58725]: DBG: ... hit
 C4 9Fb0 5A 5A 5A
gpg-agent[58725]: DBG: chan_38 <- HAVEKEY
E0935FE2D7829F0CA7580D98F58ECD6EF0A9DE25
 AA 29
gpg-agent[58725]: DBG: chan_39 -> OK Pleased to meet you
 AA82 5A 01 29 5A AAa8 5A 5A D6 D617 35 AA 01 D7 4C 32 AA AA AA BB79
 BB
gpg-agent[58725]: DBG: chan_38 -> OK
d4 AA 42 29 AA BB \
gpg-agent(58725,0x70000f710000) malloc: *** error for object
0x7f99f9703250: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

-Patrick



From ineiev at gnu.org  Tue Jan 24 11:35:17 2017
From: ineiev at gnu.org (Ineiev)
Date: Tue, 24 Jan 2017 05:35:17 -0500
Subject: [PATCH HEAD] i18n fixes
In-Reply-To: <20170107150633.GS10490@gnu.org>
References: <20161005142930.GO30569@gnu.org> <87y3yo8nxp.wl-neal@walfield.org>
 <20170107150633.GS10490@gnu.org>
Message-ID: <20170124103516.GL10490@gnu.org>

On Sat, Jan 07, 2017 at 10:06:34AM -0500, Ineiev wrote:
> 
> > Also, I'm a bit confused about the issue with the "revoked" and
> > "expired" strings.  They are used as a list of attributes.  What type
> > of context do you want?
> 
> In GPG, "revoked" and "expired" may modify "signature", "binding",
> "key" (and possibly more), their translations in many European
> languages may have three different grammatical genders, and the form
> of the adjective depends on the gender of the noun it modifies.
> if the program uses _("revoked"), gettext has to substitute the same
> form in all cases, so it's impossible to match different genders.

By the way, this apply to time_ago_str (): "past years" may need
the "past" different from that of "past seconds".  Currently the
translators may move "past" to the strings of time_ago_str
by convention, but if time_ago_str is used in a different context,
the language may become incorrect.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: 

From justus at g10code.com  Tue Jan 24 12:10:52 2017
From: justus at g10code.com (Justus Winter)
Date: Tue, 24 Jan 2017 12:10:52 +0100
Subject: [PINENTRY PATCH] add efl-based frontend
In-Reply-To: <20161019100137.66563eb7@Sir.Pimpleton>
References: 
 <20161012113515.675d5a30@Sir.Pimpleton>
 <87y41swi1i.fsf@europa.jade-hamburg.de>
 
 <87inso1r02.fsf@europa.jade-hamburg.de>
 <20161019100137.66563eb7@Sir.Pimpleton>
Message-ID: <877f5kzpab.fsf@europa.jade-hamburg.de>

Mike Blumenkrantz  writes:

> Thanks for your clarification. I've attached a new version of the patch
> which I believe addresses all the issues you have cited in both the
> contents of the patch and the commit log.

Thanks.  In the mean time, I was finally able to build the pinentry.  I
have some remarks:

1/ the window is very small, there is no margin around the widgets at
all, it looks crowded.

2/ as soon as I enter a character, the text input field is resized
(enlarged), and as a consequence so is the dialog window.

3/ the buttons have no logos, yet the text is off-center.

> Since we are being very technical about the commit log, and you
> specifically cited the docs, I'd like to point out that nowhere in the
> docs/HACKING file
> (https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/HACKING#l21)
> does it say anything about capitalization or punctuation. The prefixing
> that you've mentioned, while common in commit messages, is referred to
> something that is "usually" present, and it has no example for the
> addition of new components. Furthermore, listing files with their
> changes is also not in this document, nor is it done in every commit:
> the top-most commit that I was working off in the tree is
> https://git.gnupg.org/cgi-bin/gitweb.cgi?p=pinentry.git;a=commit;h=a383ddeb76463ddcf5aca2fb38847ea3158c42a7 and does not include it.
> Based on this disconnect, it's easy to see why someone like
> me who has been working off very direct RFC-style specifications
> recently would produce a commit log which "stands out" :)
>
> I'd be happy to submit a patch for the docs/HACKING file which
> addresses these discrepancies to avoid any potential confusion
> with future contributors.

Documentation patches are very welcome :)


Thanks,
Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: 

From aranea at aixah.de  Tue Jan 24 17:49:15 2017
From: aranea at aixah.de (Luis Ressel)
Date: Tue, 24 Jan 2017 17:49:15 +0100
Subject: DCO for Luis Ressel
Message-ID: <20170124174915.4080f445@gentp.lnet>

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: Luis Ressel 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: 

From aranea at aixah.de  Tue Jan 24 17:45:50 2017
From: aranea at aixah.de (Luis Ressel)
Date: Tue, 24 Jan 2017 17:45:50 +0100
Subject: [PATCH] gpg: Actually allow generation of 8192-bit rsa keys
Message-ID: <20170124164550.10970-1-aranea@aixah.de>

Currently, get_keysize_range() returns 4096 as an upper bound for the
size of RSA keys even if the option --enable-large-rsa is in use.
Therefore, interactive generation of 8192-bit RSA keys is currently
impossible.

Signed-off-by: Luis Ressel 
---
 g10/keygen.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/g10/keygen.c b/g10/keygen.c
index 98ef29efb..ecbf80578 100644
--- a/g10/keygen.c
+++ b/g10/keygen.c
@@ -2104,7 +2104,7 @@ get_keysize_range (int algo, unsigned int *min, unsigned int *max)
 
     default:
       *min = opt.compliance == CO_DE_VS ? 2048: 1024;
-      *max = 4096;
+      *max = opt.flags.large_rsa ? 8192 : 4096;
       def = 2048;
       break;
     }
-- 
2.11.0



From wk at gnupg.org  Tue Jan 24 21:04:27 2017
From: wk at gnupg.org (Werner Koch)
Date: Tue, 24 Jan 2017 21:04:27 +0100
Subject: [PATCH] gpg: Actually allow generation of 8192-bit rsa keys
In-Reply-To: <20170124164550.10970-1-aranea@aixah.de> (Luis Ressel's message
 of "Tue, 24 Jan 2017 17:45:50 +0100")
References: <20170124164550.10970-1-aranea@aixah.de>
Message-ID: <87ziig5ino.fsf@wheatstone.g10code.de>

On Tue, 24 Jan 2017 17:45, aranea at aixah.de said:
> Currently, get_keysize_range() returns 4096 as an upper bound for the
> size of RSA keys even if the option --enable-large-rsa is in use.
> Therefore, interactive generation of 8192-bit RSA keys is currently

Right, that is by design.  Read
 to read
why we even don't default to 4096.

If you somehow have a demand for RSA > 4096 bit you will also have the
experts at hand which can figure out how to create such keys with GnuPG
and how are able to implement the OPSEC which you surely need with such
demands.


Shalom-Salam,

   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: 227 bytes
Desc: not available
URL: 

From aranea at aixah.de  Tue Jan 24 21:46:05 2017
From: aranea at aixah.de (Luis Ressel)
Date: Tue, 24 Jan 2017 21:46:05 +0100
Subject: [PATCH] gpg: Actually allow generation of 8192-bit rsa keys
In-Reply-To: <87ziig5ino.fsf@wheatstone.g10code.de>
References: <20170124164550.10970-1-aranea@aixah.de>
 <87ziig5ino.fsf@wheatstone.g10code.de>
Message-ID: <20170124214605.6f290c98@gentp.lnet>

On Tue, 24 Jan 2017 21:04:27 +0100
Werner Koch  wrote:

> On Tue, 24 Jan 2017 17:45, aranea at aixah.de said:
> > Currently, get_keysize_range() returns 4096 as an upper bound for
> > the size of RSA keys even if the option --enable-large-rsa is in
> > use. Therefore, interactive generation of 8192-bit RSA keys is
> > currently  
> 
> Right, that is by design.  Read
>  to
> read why we even don't default to 4096.
> 
> If you somehow have a demand for RSA > 4096 bit you will also have the
> experts at hand which can figure out how to create such keys with
> GnuPG and how are able to implement the OPSEC which you surely need
> with such demands.

Well, I am aware that the get_keysize_range() restriction does not
apply to batch mode; but I had assumed it was a simple oversight that
get_keysize_range() does not check the large_rsa flag.

In the meantime, I've been informed the same patch has been submitted
previously by others; apologies for not doing any research on this
first. (By the way, it might be a good idea to add a comment to
get_keysize_range() to inform readers that this is a conscious UI
decision and not a bug.)

Regards,
Luis


From dkg at fifthhorseman.net  Tue Jan 24 22:08:41 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 24 Jan 2017 16:08:41 -0500
Subject: gpgme_op_genkey() parms parameter: really XML? (escaping ampersands
 and angle brackets)
Message-ID: <87ziignp2e.fsf@alice.fifthhorseman.net>

Hey GnuPG folks--

gpgme_op_genkey() takes a parms parameter that is supposed to be a
textual XML object:

   https://www.gnupg.org/documentation/manuals/gpgme/Generating-Keys.html#index-gpgme_005fop_005fgenkey

the canonical example is this:

    
    Key-Type: default
    Subkey-Type: default
    Name-Real: Joe Tester
    Name-Comment: with stupid passphrase
    Name-Email: joe at foo.bar
    Expire-Date: 0
    Passphrase: abc
    

however, it's not clear to me that this is really XML -- it just looks
like plaintext with XML-ish lines on the top and bottom.

In particular, i want to know what happens if i want to include
ampersands or angle-brackets in any of the text (e.g. in the passphrase,
the comment field, the name, etc).

If it's really XML, i'd use & and < and >

But in practice, if i use those, they are passed through as literals:


     
     Key-Type: RSA
     Key-Length: 2048
     Subkey-Type: RSA
     Subkey-Length: 2048
     Name-Real: Joe & his dog
     Passphrase: Crypt0<R0cks
     Expire-Date: 2020-12-31
     

On the flip side, if i put actual angle-brackets in there, it doesn't
seem to treat them as anything special (i haven't tried to make a key
with "Name-Real: " yet).

So, i know how to stuff angle-brackets and ampersands into the strings
directly, but i don't know if that will somehow break if one day in the
future gpgme actually treats this as real XML.

What should someone who wants to use angle-brackets and ampersands in
these fields do?

     --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: 

From patrick at enigmail.net  Wed Jan 25 11:51:27 2017
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Wed, 25 Jan 2017 11:51:27 +0100
Subject: Crashes with gpg-agent 2.1.18
In-Reply-To: <4948e1b6-2a5c-627d-22de-bf019022b7bd@enigmail.net>
References: <83c60b0f-9694-84fe-c30a-91f5a8546af7@enigmail.net>
 <87fuk9tto8.fsf@alice.fifthhorseman.net>
 <4948e1b6-2a5c-627d-22de-bf019022b7bd@enigmail.net>
Message-ID: 

On 24.01.17 09:14, Patrick Brunschwig wrote:
> On 23.01.17 21:20, Daniel Kahn Gillmor wrote:

> gpg-agent(58725,0x70000f710000) malloc: *** error for object
> 0x7f99f9703250: pointer being freed was not allocated
> *** set a breakpoint in malloc_error_break to debug


Here is how I can reproduce the issue on Mac OS X
1. create a small encrypted file (e.g. x.asc)

2. Make sure gpg-agent currently caches your password

3. run the following loop:
for i in $(seq 1 20); do (gpg2 -d x.asc &) ; done

This will crash gpg-agent almost certainly.

-Patrick


From justus at g10code.com  Wed Jan 25 11:58:31 2017
From: justus at g10code.com (Justus Winter)
Date: Wed, 25 Jan 2017 11:58:31 +0100
Subject: Crashes with gpg-agent 2.1.18
In-Reply-To: 
References: <83c60b0f-9694-84fe-c30a-91f5a8546af7@enigmail.net>
 <87fuk9tto8.fsf@alice.fifthhorseman.net>
 <4948e1b6-2a5c-627d-22de-bf019022b7bd@enigmail.net>
 
Message-ID: <87wpdjh0dk.fsf@europa.jade-hamburg.de>

Patrick Brunschwig  writes:

> On 24.01.17 09:14, Patrick Brunschwig wrote:
>> On 23.01.17 21:20, Daniel Kahn Gillmor wrote:
>
>> gpg-agent(58725,0x70000f710000) malloc: *** error for object
>> 0x7f99f9703250: pointer being freed was not allocated
>> *** set a breakpoint in malloc_error_break to debug
>
>
> Here is how I can reproduce the issue on Mac OS X
> 1. create a small encrypted file (e.g. x.asc)
>
> 2. Make sure gpg-agent currently caches your password
>
> 3. run the following loop:
> for i in $(seq 1 20); do (gpg2 -d x.asc &) ; done
>
> This will crash gpg-agent almost certainly.

Ugh.  I can reproduce this on Linux as well.  I'll look into that.


Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: 

From justus at g10code.com  Wed Jan 25 13:58:18 2017
From: justus at g10code.com (Justus Winter)
Date: Wed, 25 Jan 2017 13:58:18 +0100
Subject: Crashes with gpg-agent 2.1.18
In-Reply-To: <87wpdjh0dk.fsf@europa.jade-hamburg.de>
References: <83c60b0f-9694-84fe-c30a-91f5a8546af7@enigmail.net>
 <87fuk9tto8.fsf@alice.fifthhorseman.net>
 <4948e1b6-2a5c-627d-22de-bf019022b7bd@enigmail.net>
 
 <87wpdjh0dk.fsf@europa.jade-hamburg.de>
Message-ID: <87tw8ngutx.fsf@europa.jade-hamburg.de>

Justus Winter  writes:

> [ Unknown signature status ]
> Patrick Brunschwig  writes:
>
>> On 24.01.17 09:14, Patrick Brunschwig wrote:
>>> On 23.01.17 21:20, Daniel Kahn Gillmor wrote:
>>
>>> gpg-agent(58725,0x70000f710000) malloc: *** error for object
>>> 0x7f99f9703250: pointer being freed was not allocated
>>> *** set a breakpoint in malloc_error_break to debug
>>
>>
>> Here is how I can reproduce the issue on Mac OS X
>> 1. create a small encrypted file (e.g. x.asc)
>>
>> 2. Make sure gpg-agent currently caches your password
>>
>> 3. run the following loop:
>> for i in $(seq 1 20); do (gpg2 -d x.asc &) ; done
>>
>> This will crash gpg-agent almost certainly.
>
> Ugh.  I can reproduce this on Linux as well.  I'll look into that.

It was a double free.  Fixed in
e175152ef7515921635bf1e00383e812668d13fc.

Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: 

From zmike at samsung.com  Wed Jan 25 14:12:19 2017
From: zmike at samsung.com (Mike Blumenkrantz)
Date: Wed, 25 Jan 2017 08:12:19 -0500
Subject: [PINENTRY PATCH] add efl-based frontend
In-Reply-To: <877f5kzpab.fsf@europa.jade-hamburg.de>
References: 
 <20161012113515.675d5a30@Sir.Pimpleton>
 <87y41swi1i.fsf@europa.jade-hamburg.de>
 
 <87inso1r02.fsf@europa.jade-hamburg.de>
 <20161019100137.66563eb7@Sir.Pimpleton>
 <877f5kzpab.fsf@europa.jade-hamburg.de>
Message-ID: <20170125081219.4d666e71@Sir.Pimpleton>

On Tue, 24 Jan 2017 12:10:52 +0100
Justus Winter  wrote:

> Mike Blumenkrantz  writes:
> 
> > Thanks for your clarification. I've attached a new version of the patch
> > which I believe addresses all the issues you have cited in both the
> > contents of the patch and the commit log.  
> 
> Thanks.  In the mean time, I was finally able to build the pinentry.  I
> have some remarks:
> 
> 1/ the window is very small, there is no margin around the widgets at
> all, it looks crowded.
> 
> 2/ as soon as I enter a character, the text input field is resized
> (enlarged), and as a consequence so is the dialog window.
> 
> 3/ the buttons have no logos, yet the text is off-center.

Thanks for checking, I'll look into these items.

> 
> > Since we are being very technical about the commit log, and you
> > specifically cited the docs, I'd like to point out that nowhere in the
> > docs/HACKING file
> > (https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/HACKING#l21)
> > does it say anything about capitalization or punctuation. The prefixing
> > that you've mentioned, while common in commit messages, is referred to
> > something that is "usually" present, and it has no example for the
> > addition of new components. Furthermore, listing files with their
> > changes is also not in this document, nor is it done in every commit:
> > the top-most commit that I was working off in the tree is
> > https://git.gnupg.org/cgi-bin/gitweb.cgi?p=pinentry.git;a=commit;h=a383ddeb76463ddcf5aca2fb38847ea3158c42a7 and does not include it.
> > Based on this disconnect, it's easy to see why someone like
> > me who has been working off very direct RFC-style specifications
> > recently would produce a commit log which "stands out" :)
> >
> > I'd be happy to submit a patch for the docs/HACKING file which
> > addresses these discrepancies to avoid any potential confusion
> > with future contributors.  
> 
> Documentation patches are very welcome :)
> 
> 
> Thanks,
> Justus

I'll follow up on this as well.

Regards,
Mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 

From patrick at enigmail.net  Wed Jan 25 16:01:11 2017
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Wed, 25 Jan 2017 16:01:11 +0100
Subject: Crashes with gpg-agent 2.1.18
In-Reply-To: <87tw8ngutx.fsf@europa.jade-hamburg.de>
References: <83c60b0f-9694-84fe-c30a-91f5a8546af7@enigmail.net>
 <87fuk9tto8.fsf@alice.fifthhorseman.net>
 <4948e1b6-2a5c-627d-22de-bf019022b7bd@enigmail.net>
 
 <87wpdjh0dk.fsf@europa.jade-hamburg.de>
 <87tw8ngutx.fsf@europa.jade-hamburg.de>
Message-ID: <0ea30e2b-4642-93f5-06fe-25b4a8f2581a@enigmail.net>

On 25.01.17 13:58, Justus Winter wrote:
> Justus Winter  writes:
> 
>> [ Unknown signature status ]
>> Patrick Brunschwig  writes:
>>
>>> On 24.01.17 09:14, Patrick Brunschwig wrote:
>>>> On 23.01.17 21:20, Daniel Kahn Gillmor wrote:
>>>
>>>> gpg-agent(58725,0x70000f710000) malloc: *** error for object
>>>> 0x7f99f9703250: pointer being freed was not allocated
>>>> *** set a breakpoint in malloc_error_break to debug
>>>
>>>
>>> Here is how I can reproduce the issue on Mac OS X
>>> 1. create a small encrypted file (e.g. x.asc)
>>>
>>> 2. Make sure gpg-agent currently caches your password
>>>
>>> 3. run the following loop:
>>> for i in $(seq 1 20); do (gpg2 -d x.asc &) ; done
>>>
>>> This will crash gpg-agent almost certainly.
>>
>> Ugh.  I can reproduce this on Linux as well.  I'll look into that.
> 
> It was a double free.  Fixed in
> e175152ef7515921635bf1e00383e812668d13fc.

Yes, this fixes the crash.

Thanks,
Patrick



From kristian.fiskerstrand at sumptuouscapital.com  Wed Jan 25 22:25:36 2017
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Wed, 25 Jan 2017 22:25:36 +0100
Subject: [PATCH] * random/random-drbg.c (drbg_hmac_update): Don't memset if,
 length is zero
In-Reply-To: <535150f6-bfbc-e2bb-c1c8-fa3bc48b5efe@gentoo.org>
References: <535150f6-bfbc-e2bb-c1c8-fa3bc48b5efe@gentoo.org>
Message-ID: <0a745afe-432d-2e3f-9e13-010c4e2fe4b0@sumptuouscapital.com>

[resending as previous message was sent using a non-subscribed addresse,
please excuse any duplicate]

* random/random-drbg.c (drbg_hmac_update): Don't memset if length is zero

--
A zero length memset triggers __warn_memset_zero_len() in glibc, so
only invoking memset if non-zero value

A user reported an issue in
https://bugs.gentoo.org/show_bug.cgi?id=606740

/usr/include/bits/string3.h:86:7: warning: call to
'__warn_memset_zero_len' declared with attribute warning: memset used
with constant zero length parameter; this could be due to transposed
parameters
       __warn_memset_zero_len ();

which subsequently resulted in linking error for
./.libs/libgcrypt.so: undefined reference to `__warn_memset_zero_len'

-- 
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
"Money is better than poverty, if only for financial reasons."
(Woody Allen)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-random-random-drbg.c-drbg_hmac_update-Don-t-memset-i.patch
Type: text/x-patch
Size: 1469 bytes
Desc: not available
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: 

From gniibe at fsij.org  Thu Jan 26 02:23:14 2017
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 26 Jan 2017 10:23:14 +0900
Subject: GPGME: double fork...
Message-ID: <87o9yuzkal.fsf@iwagami.gniibe.org>

Hello,

Sorry for my confusion about threads and fork, this week.

I am not sure if this patch is worth to apply, but I noticed an issue (a
minor issue, or non-issue).

So, here is a report to describe the possible issue, in the form of patch.
-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Use-POSIX-spawn-fix.patch
Type: text/x-diff
Size: 2146 bytes
Desc: Double fork issue
URL: 

From wk at gnupg.org  Thu Jan 26 18:44:47 2017
From: wk at gnupg.org (Werner Koch)
Date: Thu, 26 Jan 2017 18:44:47 +0100
Subject: [PATCH] * random/random-drbg.c (drbg_hmac_update): Don't memset
 if, length is zero
In-Reply-To: <0a745afe-432d-2e3f-9e13-010c4e2fe4b0@sumptuouscapital.com>
 (Kristian Fiskerstrand's message of "Wed, 25 Jan 2017 22:25:36 +0100")
References: <535150f6-bfbc-e2bb-c1c8-fa3bc48b5efe@gentoo.org>
 <0a745afe-432d-2e3f-9e13-010c4e2fe4b0@sumptuouscapital.com>
Message-ID: <87poj9btrk.fsf@wheatstone.g10code.de>

On Wed, 25 Jan 2017 22:25, kristian.fiskerstrand at sumptuouscapital.com
said:

> A zero length memset triggers __warn_memset_zero_len() in glibc, so
> only invoking memset if non-zero value

The glibc folks are starting to get as crazy as the gcc folks.  Now they
want us to add complexity (an additional condition) and thus bugs to
perfectly valid code =:-)


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: 227 bytes
Desc: not available
URL: 

From wk at gnupg.org  Thu Jan 26 18:40:55 2017
From: wk at gnupg.org (Werner Koch)
Date: Thu, 26 Jan 2017 18:40:55 +0100
Subject: GPGME: double fork...
In-Reply-To: <87o9yuzkal.fsf@iwagami.gniibe.org> (NIIBE Yutaka's message of
 "Thu, 26 Jan 2017 10:23:14 +0900")
References: <87o9yuzkal.fsf@iwagami.gniibe.org>
Message-ID: <87tw8lbty0.fsf@wheatstone.g10code.de>

On Thu, 26 Jan 2017 02:23, gniibe at fsij.org said:

> GPGME can be used with Pthreads.  Users may use pthread_atfork to
> clean up things at fork.

Moving the atfork callback before the second fork seems is a good idea.

Using vfork is questionable because of the weird semantics of vfork -
with any modern system there should be no penalty between fork and
vfork.  Using vfork as a way to smart out pthread_atfork may bring more
trouble than it solves.

> Unfortunately with Pthreads, there is no way to pop the ATFORK callback.
> So, the callback added by pthread_atfork was called twice by the double

Such callbacks are anyway very fragile constructs and should be avoided
if anyhow possible.

A real problem we have in gpgme is that some time ago I changed
get_max_fd() to utilize /proc to find the highest fd.  That involves
opendir which unfortunately uses malloc which in turn uses a mutex and
may thus create a deadlock between parent and child.  In a multithreaded
program we should only use async-safe functions between fork and exec.
For safely reasons we better drop that code.  For BSD systems we can
use closefrom to speed up closing of fds - a pitty that this is not
possible on Linux without resorting to running a helper process.

A straightforward solution for both problems would be a helper program
which takes care of closing fds and exec-ing the real program.  It is a
bit funny that we had to do that for Windows for related reasons but
recent Windows systems seem to allow to do without a helper.

What about testing a helper approach and run some benchmark (on single
threaded and multithreaded Linux and BSD systems)?


Shalom-Salam,

   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: 227 bytes
Desc: not available
URL: 

From wk at gnupg.org  Thu Jan 26 19:01:57 2017
From: wk at gnupg.org (Werner Koch)
Date: Thu, 26 Jan 2017 19:01:57 +0100
Subject: Crashes with gpg-agent 2.1.18
In-Reply-To: <87tw8ngutx.fsf@europa.jade-hamburg.de> (Justus Winter's message
 of "Wed, 25 Jan 2017 13:58:18 +0100")
References: <83c60b0f-9694-84fe-c30a-91f5a8546af7@enigmail.net>
 <87fuk9tto8.fsf@alice.fifthhorseman.net>
 <4948e1b6-2a5c-627d-22de-bf019022b7bd@enigmail.net>
 
 <87wpdjh0dk.fsf@europa.jade-hamburg.de>
 <87tw8ngutx.fsf@europa.jade-hamburg.de>
Message-ID: <87inp1bsyy.fsf@wheatstone.g10code.de>

On Wed, 25 Jan 2017 13:58, justus at g10code.com said:

> It was a double free.  Fixed in

Can you please describe in a code comment how xtrystrdup relinquishes
control to another thread.  That is not easy to see:

xtrystrdup used gcry_strdup which may use the secure memory allocator of
Libgcrypt.  That allocator takes locks and since Libgpg-error 1.14
libgpg-error can be nPth aware and thus the lock may switch threads.

It would also be useful to check other parts of gpg-agent and scdaemon
which do secure memory allocations and may be prone to the same
problem.


Shalom-Salam,

   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: 227 bytes
Desc: not available
URL: 

From wk at gnupg.org  Thu Jan 26 19:11:43 2017
From: wk at gnupg.org (Werner Koch)
Date: Thu, 26 Jan 2017 19:11:43 +0100
Subject: gpgme_op_genkey() parms parameter: really XML? (escaping
 ampersands and angle brackets)
In-Reply-To: <87ziignp2e.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Tue, 24 Jan 2017 16:08:41 -0500")
References: <87ziignp2e.fsf@alice.fifthhorseman.net>
Message-ID: <87efzpbsio.fsf@wheatstone.g10code.de>

On Tue, 24 Jan 2017 22:08, dkg at fifthhorseman.net said:

> however, it's not clear to me that this is really XML -- it just looks
> like plaintext with XML-ish lines on the top and bottom.

Not really.  It was a quick hack to not specify anything.  We should
have written SGML so that it is clear that the users need to ask for the
DTD - which could be anything of course ;-).  I would propose to change
the doc to say XML-like and explain your questions.

> What should someone who wants to use angle-brackets and ampersands in
> these fields do?

Use gpgme_op_create_key instead.  Not as flexible as gpgme_op_genkey and
works only with 2.1 and (right now) OpenPGP but a much cleaner
interface.


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: 227 bytes
Desc: not available
URL: 

From dkg at fifthhorseman.net  Fri Jan 27 00:39:12 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 26 Jan 2017 18:39:12 -0500
Subject: [GPGME PATCH] doc: Document that gpgme_op_genkey() parms parameter is
 not XML.
In-Reply-To: <87efzpbsio.fsf@wheatstone.g10code.de>
References: <87efzpbsio.fsf@wheatstone.g10code.de>
Message-ID: <20170126233912.8136-1-dkg@fifthhorseman.net>

* doc/gpgme.texi (GnupgKeyParms): document that input format is not
true XML.

--

Please see discussion at
https://lists.gnupg.org/pipermail/gnupg-devel/2017-January/032507.html

Signed-off-by: Daniel Kahn Gillmor 
---
 doc/gpgme.texi | 24 ++++++++++++++++--------
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/doc/gpgme.texi b/doc/gpgme.texi
index 511384f9..47ab71e9 100644
--- a/doc/gpgme.texi
+++ b/doc/gpgme.texi
@@ -3851,11 +3851,18 @@ and return a certificate request in @var{public}, which then needs to
 be signed by the certification authority and imported before it can be
 used.  GpgSM does not make the fingerprint available.
 
-The argument @var{parms} specifies parameters for the key in an XML
-string.  The details about the format of @var{parms} are specific to
-the crypto engine used by @var{ctx}.  Here is an example for GnuPG as
-the crypto engine (all parameters of OpenPGP key generation are
-documented in the GPG manual):
+The argument @var{parms} specifies parameters for the key in an string
+that looks something like XML.  The details about the format of
+ at var{parms} are specific to the crypto engine used by @var{ctx}.  The
+first line of the parameters must be @code{} and the last line must be
+ at code{}.  Every line in between the first and last
+lines is treated as a Header: Value pair.  In particular, no XML
+escaping is necessary if you need to include the characters @code{<},
+ at code{>}, or @code{&}.
+
+Here is an example for GnuPG as the crypto engine (all parameters of
+OpenPGP key generation are documented in the GPG manual):
 
 @example
 
@@ -3891,9 +3898,10 @@ retrieved with @code{gpgme_op_genkey_result}.
 
 The function returns the error code @code{GPG_ERR_NO_ERROR} if the
 operation could be started successfully, @code{GPG_ERR_INV_VALUE} if
- at var{parms} is not a valid XML string, @code{GPG_ERR_NOT_SUPPORTED} if
- at var{public} or @var{secret} is not valid, and @code{GPG_ERR_GENERAL}
-if no key was created by the backend.
+ at var{parms} is not a well-formed string (e.g. does not have the
+expected tag-like headers and footers), @code{GPG_ERR_NOT_SUPPORTED}
+if @var{public} or @var{secret} is not valid, and
+ at code{GPG_ERR_GENERAL} if no key was created by the backend.
 @end deftypefun
 
 @deftypefun gpgme_error_t gpgme_op_genkey_start (@w{gpgme_ctx_t @var{ctx}}, @w{const char *@var{parms}}, @w{gpgme_data_t @var{public}}, @w{gpgme_data_t @var{secret}})
-- 
2.11.0



From john.fr.omeara at gmail.com  Fri Jan 27 08:38:47 2017
From: john.fr.omeara at gmail.com (=?utf-8?q?John_O=C2=B4Meara?=)
Date: Fri, 27 Jan 2017 02:38:47 -0500
Subject: DCO for John O'Meara
Message-ID: <148550272711.28193.1854012158361960531.mailnex@john-laptop-bonb>

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: John O'Meara 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: 

From john.fr.omeara at gmail.com  Sat Jan 28 07:25:13 2017
From: john.fr.omeara at gmail.com (John O'Meara)
Date: Sat, 28 Jan 2017 01:25:13 -0500
Subject: [PATCH] gpg: Fix regexp sanitization.
In-Reply-To: 
References: <20170117220445.24873-1-dgouttegattat@incenp.org>
 <20170119064058.NQNVOkWOX%john.fr.omeara@gmail.com>
 
Message-ID: <148558471343.6956.10813027514614235066.mailnex@john-laptop-bonb>

Quoth Damien Goutte-Gattat  on Thu, 19 Jan 2017 16:53:51 +0100:

> On 01/19/2017 07:40 AM, John O'Meara wrote:
> 
>> In POSIX [...] a backslash preceding any other character is
>> undefined.
> 
> Yes, and that's the root cause of the bug we're talking about: the
> original code in sanitize_regexp obviously assumed the regex
> implementation would treat an escaped non-special character as if it
> were not escaped. Some regex packages do behave that way, but it seems
> the GNU Libc's regcomp/regexec does not.
> 

Attached is my first pass at this. I tested with a bunch of permutations,
though possibly still not thoroughly enough. I wasn't sure what to do with
some of the original comments, so in this pass they are just removed. Since
this is now more of a converter than a sanitizer, I adjusted the name of the
function as well.

Does this look about right? Any suggestions?

Here are the tests I did (represented as c-strings):

-------------------------------------------  -----------------------------------------
input to converter                           output from converter
-------------------------------------------  -----------------------------------------
"<[^]+[@.](a|b)\\.example\\.com>$"           "<[^]+[@.](a|b)\\.example\\.com>$"
"ex\\a\\mple\\.com"                          "example\\.com"
"test{ing}"                                  "test\\{ing}"
"test\\{ing}"                                "test\\{ing}"
"test\\\\ing"                                "test\\\\ing"
"testing\\$"                                 "testing\\$"
"this is [a\\range]"                         "this is [a\\range]"
"[ran\\ge$] at start"                        "[ran\\ge$] at start"
"close in []ran\\ge]"                        "close in []ran\\ge]"
"close in neg [^]ran\\ge]"                   "close in neg [^]ran\\ge]"
"\\a\\b\\(\\|\\)\\.\\{{\\\\\\*\\+\\?\\^\\$"  "ab\\(\\|\\)\\.\\{\\{\\\\\\*\\+\\?\\^\\$"
-------------------------------------------  -----------------------------------------


>> Of course, for all of this to be generally useful, there'd also need
>> to be a (non-default) mode when making a trust signature to prevent
>> gnupg from escaping those characters when saving.
> 
> A possibility would be to use the --expert flag to enable such a mode.
> Without that flag, we stick to the current behavior. With --expert mode
> enabled, we let the user enter a regular expression of its own choosing,
> and we don't touch it (no escaping and no bracketing with <[^>]+[@.] and 
>  >$).

Attached also is a pass at allowing the --expert flag to put a raw regexp in
the trust sig.

Is using the strdup here ok, or should I instead assign p to *regex, not free
p, print the newline, and return early?


Thanks in advance for your comments.
-- John O'Meara
-------------- next part --------------
A non-text attachment was scrubbed...
Name: regexp_convert.patch
Type: text/x-diff
Size: 4843 bytes
Desc: not available
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: expert_edit_regexp.patch
Type: text/x-diff
Size: 1278 bytes
Desc: not available
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: 

From andrew.p.clausen at gmail.com  Sat Jan 28 11:48:56 2017
From: andrew.p.clausen at gmail.com (Andrew Clausen)
Date: Sat, 28 Jan 2017 10:48:56 +0000
Subject: GPG security documentation
Message-ID: 

Hi all,

GPG sometimes asks the user to make security judgments, such as how
long a key to use, or which cipher he prefers.  Does GPG supply any
documentation to help the user make informed choices?  The FAQ [0] has
a limited amount of discussion, but this probably is not the best way
to organise this important information for users.  I'd be happy to
help improve the documentation.

Examples of information that users might find helpful:

 * Key size recommendations, e.g. from NIST.[1]  This ought to explain
why RSA-4096 (or RSA-65536) is typically not recommended.

 * GPG's protections from side-channel attacks.  Specifically,
security researchers have provided patches to previous versions of GPG
to eliminate the leakage of private information through timing and
radiation from CPUs.  Which of GPG's implemented ciphers are most
robust to protecting against these attacks?  See [2] for an
introduction to the issue.

 * Limitations.  For example, to my knowledge, none of GPG's modes of
operation support forward secrecy (like OTR does [3]).  (Specifically,
the standard way to get forward secrecy involves a Diffie-Hellman key
agreement, which requires a round-trip of conversation before any
plaintext is encrypted.  GPG is not currently organised to support
such conversations.)

 * What metadata is publicly visible in GPG messages?  Is it possible
to remove some of this metadata?

Kind regards,
Andrew

[0] https://www.gnupg.org/faq/gnupg-faq.html
[1] Section 5.6 of
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf
[2] https://safecurves.cr.yp.to/
[3] https://en.wikipedia.org/wiki/Off-the-Record_Messaging


From caro at nymph.paranoici.org  Sun Jan 29 04:29:54 2017
From: caro at nymph.paranoici.org (Carola Grunwald)
Date: Sun, 29 Jan 2017 03:29:54 +0000 (UTC)
Subject: Key creation problem with 2.1.16
References: <20161129230429.B2488100B190@remailer.paranoici.org>
 <8760mxoghi.fsf@alice.fifthhorseman.net>
 <20161206124120.A4B1A1032319@remailer.paranoici.org>
 <87fum1m24x.fsf@alice.fifthhorseman.net>
 <20161208032707.B84771025BE0@remailer.paranoici.org>
Message-ID: <20170129032954.3C67A1032248@remailer.paranoici.org>

Hello,

on Thu,  8 Dec 2016 03:27:07 +0000 (UTC), I wrote:

>And there's a probably different problem with a likely broken IPC, where
>I get 259/$103 in return for the current and all following commands
>until another agent instance appears in the Task Manager after about 2
>minutes.

These 2 minutes were my gpg.exe call timeout interval.

The cause of the frozen gpg-agent.exe instance may be a mutex deadlock,
possibly a problem within the Windows nPth implementation. With a frozen
agent the call stack dump always looks the same as shown below. Here it
usually takes less than 2 hours to get such a glitch with 5+ broken
gpg-agent.exe processes added to the task list overnight, resulting in
periodical server failures.

GnuPG 2.1.17, libgcrypt 1.7.5, Windows 7 (32 and 64 bit)


Normal idle situation:

Stack for thread gpg-agent.exe+0x14e0
-------------------------------------------------
ntoskrnl.exe!SeAccessCheckWithHint+0xb4a
ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x7d2
ntoskrnl.exe!KeWaitForMutexObject+0x19f
ntoskrnl.exe!PsIsSystemProcess+0x94
ntoskrnl.exe!KeStackAttachProcess+0x11c1
ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x9dd
ntoskrnl.exe!KeWaitForMultipleObjects+0x26b
ntoskrnl.exe!MmCreateSection+0xe23
ntoskrnl.exe!NtOpenResourceManager+0x599
ntoskrnl.exe!KeSynchronizeExecution+0x3a43
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x690
wow64cpu.dll!TurboDispatchJumpAddressEnd+0xe3
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x429
ntdll.dll!RtlResetRtlTranslations+0x1b08
ntdll.dll!RtlResetRtlTranslations+0xc63
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!NtWaitForMultipleObjects+0x15
kernel32.dll!WaitForMultipleObjectsEx+0x8e
kernel32.dll!WaitForMultipleObjects+0x18
ntdll.dll!RtlQueryInformationActivationContext+0x12d
gpg-agent.exe+0x375b

TCP/IP
Protocol Local Address Remote Address State
-------------------------------------------------
TCP      mypc:49237    mypc:0         LISTENING
TCP      mypc:49238    mypc:0         LISTENING
TCP      mypc:49239    mypc:0         LISTENING
TCP      mypc:49240    mypc:0         LISTENING


Frozen agent:

Stack for thread gpg-agent.exe+0x14e0
-------------------------------------------------
ntoskrnl.exe!SeAccessCheckWithHint+0xb4a
ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x7d2
ntoskrnl.exe!KeWaitForMutexObject+0x19f
ntoskrnl.exe!PsIsSystemProcess+0x94
ntoskrnl.exe!KeStackAttachProcess+0x11c1
ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x9dd
ntoskrnl.exe!KeWaitForMutexObject+0x19f
ntoskrnl.exe!NtWaitForSingleObject+0xb2
ntoskrnl.exe!KeSynchronizeExecution+0x3a43
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x690
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x484
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x429
ntdll.dll!RtlResetRtlTranslations+0x1b08
ntdll.dll!RtlResetRtlTranslations+0xc63
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!NtWaitForSingleObject+0x15
ntdll.dll!RtlIntegerToUnicodeString+0x20b
libnpth-0.dll!npth_clock_gettime+0x18f
libnpth-0.dll!npth_eselect+0x485
gpg-agent.exe+0x375b

TCP/IP
Protocol Local Address Remote Address State
-------------------------------------------------
TCP      mypc:49237    mypc:0         LISTENING
TCP      mypc:49237    mypc:49854     ESTABLISHED
TCP      mypc:49237    mypc:50065     ESTABLISHED (-> gpg.exe)
TCP      mypc:49238    mypc:0         LISTENING
TCP      mypc:49239    mypc:0         LISTENING
TCP      mypc:49240    mypc:0         LISTENING
TCP      mypc:49854    mypc:49237     ESTABLISHED


HTH.

With kind regards

Caro


From caro at nymph.paranoici.org  Sun Jan 29 14:28:37 2017
From: caro at nymph.paranoici.org (Carola Grunwald)
Date: Sun, 29 Jan 2017 13:28:37 +0000 (UTC)
Subject: Key creation problem with 2.1.16
References: <20161129230429.B2488100B190@remailer.paranoici.org>
 <8760mxoghi.fsf@alice.fifthhorseman.net>
 <20161206124120.A4B1A1032319@remailer.paranoici.org>
 <87fum1m24x.fsf@alice.fifthhorseman.net>
 <20161208032707.B84771025BE0@remailer.paranoici.org>
 <20170129032954.3C67A1032248@remailer.paranoici.org>
Message-ID: <20170129132837.4CD95103224A@remailer.paranoici.org>

Hello,

on Sun, 29 Jan 2017 03:29:54 +0000 (UTC), I wrote:

>on Thu,  8 Dec 2016 03:27:07 +0000 (UTC), I wrote:
>
>>And there's a probably different problem with a likely broken IPC, where
>>I get 259/$103 in return for the current and all following commands
>>until another agent instance appears in the Task Manager after about 2
>>minutes.
>
>These 2 minutes were my gpg.exe call timeout interval.
>
>The cause of the frozen gpg-agent.exe instance may be a mutex deadlock,
>possibly a problem within the Windows nPth implementation. With a frozen
>agent the call stack dump always looks the same as shown below. Here it
>usually takes less than 2 hours to get such a glitch with 5+ broken
>gpg-agent.exe processes added to the task list overnight, resulting in
>periodical server failures.
>
>GnuPG 2.1.17, libgcrypt 1.7.5, Windows 7 (32 and 64 bit)
>
>
>Normal idle situation:
>
>Stack for thread gpg-agent.exe+0x14e0
>-------------------------------------------------
>ntoskrnl.exe!SeAccessCheckWithHint+0xb4a
>ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x7d2
>ntoskrnl.exe!KeWaitForMutexObject+0x19f
>ntoskrnl.exe!PsIsSystemProcess+0x94
>ntoskrnl.exe!KeStackAttachProcess+0x11c1
>ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x9dd
>ntoskrnl.exe!KeWaitForMultipleObjects+0x26b
>ntoskrnl.exe!MmCreateSection+0xe23
>ntoskrnl.exe!NtOpenResourceManager+0x599
>ntoskrnl.exe!KeSynchronizeExecution+0x3a43
>wow64cpu.dll!TurboDispatchJumpAddressEnd+0x690
>wow64cpu.dll!TurboDispatchJumpAddressEnd+0xe3
>wow64.dll!Wow64SystemServiceEx+0x1ce
>wow64.dll!Wow64LdrpInitialize+0x429
>ntdll.dll!RtlResetRtlTranslations+0x1b08
>ntdll.dll!RtlResetRtlTranslations+0xc63
>ntdll.dll!LdrInitializeThunk+0xe
>ntdll.dll!NtWaitForMultipleObjects+0x15
>kernel32.dll!WaitForMultipleObjectsEx+0x8e
>kernel32.dll!WaitForMultipleObjects+0x18
>ntdll.dll!RtlQueryInformationActivationContext+0x12d
>gpg-agent.exe+0x375b
>
>TCP/IP
>Protocol Local Address Remote Address State
>-------------------------------------------------
>TCP      mypc:49237    mypc:0         LISTENING
>TCP      mypc:49238    mypc:0         LISTENING
>TCP      mypc:49239    mypc:0         LISTENING
>TCP      mypc:49240    mypc:0         LISTENING
>
>
>Frozen agent:
>
>Stack for thread gpg-agent.exe+0x14e0
>-------------------------------------------------
>ntoskrnl.exe!SeAccessCheckWithHint+0xb4a
>ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x7d2
>ntoskrnl.exe!KeWaitForMutexObject+0x19f
>ntoskrnl.exe!PsIsSystemProcess+0x94
>ntoskrnl.exe!KeStackAttachProcess+0x11c1
>ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x9dd
>ntoskrnl.exe!KeWaitForMutexObject+0x19f
>ntoskrnl.exe!NtWaitForSingleObject+0xb2
>ntoskrnl.exe!KeSynchronizeExecution+0x3a43
>wow64cpu.dll!TurboDispatchJumpAddressEnd+0x690
>wow64cpu.dll!TurboDispatchJumpAddressEnd+0x484
>wow64.dll!Wow64SystemServiceEx+0x1ce
>wow64.dll!Wow64LdrpInitialize+0x429
>ntdll.dll!RtlResetRtlTranslations+0x1b08
>ntdll.dll!RtlResetRtlTranslations+0xc63
>ntdll.dll!LdrInitializeThunk+0xe
>ntdll.dll!NtWaitForSingleObject+0x15
>ntdll.dll!RtlIntegerToUnicodeString+0x20b
>libnpth-0.dll!npth_clock_gettime+0x18f
>libnpth-0.dll!npth_eselect+0x485
>gpg-agent.exe+0x375b

with two additional (dead) gpg agent threads listed:

TID   Start Address
----------------------------------------
4528  gpg-agent.exe+0x14e0
...
5240  libnpth-0.dll!npth_setname_np+0x59
4924  libnpth-0.dll!npth_setname_np+0x59

>
>TCP/IP
>Protocol Local Address Remote Address State
>-------------------------------------------------
>TCP      mypc:49237    mypc:0         LISTENING
>TCP      mypc:49237    mypc:49854     ESTABLISHED
>TCP      mypc:49237    mypc:50065     ESTABLISHED (-> gpg.exe)
>TCP      mypc:49238    mypc:0         LISTENING
>TCP      mypc:49239    mypc:0         LISTENING
>TCP      mypc:49240    mypc:0         LISTENING
>TCP      mypc:49854    mypc:49237     ESTABLISHED

Kind regards

Caro


From gniibe at fsij.org  Mon Jan 30 05:54:41 2017
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Mon, 30 Jan 2017 13:54:41 +0900
Subject: [LIBGPG-ERROR] Add Base64 decoder
Message-ID: <87efzl171q.fsf@fsij.org>

A non-text attachment was scrubbed...
Name: 0001-Add-Base64-decoder.patch
Type: text/x-diff
Size: 11829 bytes
Desc: Add Base64 decoder
URL: 
-------------- next part --------------
Hello,

NTBTLS will require base64 decoder for new API (registering certificate
in PEM format).  Currently, in dirmngr, the caller decodes the PEM
format (in base64) and gives it to NTBTLS library.  Since base64
decoding is also needed in GPGME, it is good for libgpg-error to
have the decoder.

Here is an attempt of mine.
-- 

From justus at g10code.com  Mon Jan 30 10:50:53 2017
From: justus at g10code.com (Justus Winter)
Date: Mon, 30 Jan 2017 10:50:53 +0100
Subject: Key creation problem with 2.1.16
In-Reply-To: <20170129032954.3C67A1032248@remailer.paranoici.org>
References: <20161129230429.B2488100B190@remailer.paranoici.org>
 <8760mxoghi.fsf@alice.fifthhorseman.net>
 <20161206124120.A4B1A1032319@remailer.paranoici.org>
 <87fum1m24x.fsf@alice.fifthhorseman.net>
 <20161208032707.B84771025BE0@remailer.paranoici.org>
 <20170129032954.3C67A1032248@remailer.paranoici.org>
Message-ID: <87tw8gx4ea.fsf@europa.jade-hamburg.de>

Hi :)

Carola Grunwald  writes:

> agent the call stack dump always looks the same as shown below. Here it
[...]
> Stack for thread gpg-agent.exe+0x14e0
> -------------------------------------------------
> ntoskrnl.exe!SeAccessCheckWithHint+0xb4a

May I ask how you create these stack traces?


Many thanks,
Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: 

From justus at g10code.com  Mon Jan 30 11:03:08 2017
From: justus at g10code.com (Justus Winter)
Date: Mon, 30 Jan 2017 11:03:08 +0100
Subject: Crashes with gpg-agent 2.1.18
In-Reply-To: <87inp1bsyy.fsf@wheatstone.g10code.de>
References: <83c60b0f-9694-84fe-c30a-91f5a8546af7@enigmail.net>
 <87fuk9tto8.fsf@alice.fifthhorseman.net>
 <4948e1b6-2a5c-627d-22de-bf019022b7bd@enigmail.net>
 
 <87wpdjh0dk.fsf@europa.jade-hamburg.de>
 <87tw8ngutx.fsf@europa.jade-hamburg.de>
 <87inp1bsyy.fsf@wheatstone.g10code.de>
Message-ID: <87r33kx3tv.fsf@europa.jade-hamburg.de>

Werner Koch  writes:

> [ Unknown signature status ]
> On Wed, 25 Jan 2017 13:58, justus at g10code.com said:
>
>> It was a double free.  Fixed in
>
> Can you please describe in a code comment how xtrystrdup relinquishes
> control to another thread.  That is not easy to see:

No.  Because I wasn't able to see why it would, even though I did trace
it to gcrypt, and I did saw that it may use the secmem facilities.  I
was, however, sufficiently sure that I found and fixed the problem, and
I did add verbose comments to both the code and the commit message.

> It would also be useful to check other parts of gpg-agent and scdaemon
> which do secure memory allocations and may be prone to the same
> problem.

That occured to me as well.


Cheers,
Justus

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: 

From caro at nymph.paranoici.org  Mon Jan 30 16:42:08 2017
From: caro at nymph.paranoici.org (Carola Grunwald)
Date: Mon, 30 Jan 2017 15:42:08 +0000 (UTC)
Subject: Key creation problem with 2.1.16
References: <20161129230429.B2488100B190@remailer.paranoici.org>
 <8760mxoghi.fsf@alice.fifthhorseman.net>
 <20161206124120.A4B1A1032319@remailer.paranoici.org>
 <87fum1m24x.fsf@alice.fifthhorseman.net>
 <20161208032707.B84771025BE0@remailer.paranoici.org>
 <20170129032954.3C67A1032248@remailer.paranoici.org>
 <87tw8gx4ea.fsf@europa.jade-hamburg.de>
Message-ID: <20170130154208.038BF1013311@remailer.paranoici.org>

Hi Justus,

on Mon, 30 Jan 2017 10:50:53 +0100, you wrote:

>Carola Grunwald  writes:
>
>> agent the call stack dump always looks the same as shown below. Here it
>[...]
>> Stack for thread gpg-agent.exe+0x14e0
>> -------------------------------------------------
>> ntoskrnl.exe!SeAccessCheckWithHint+0xb4a
>
>May I ask how you create these stack traces?

Sysinternals Process Explorer v16.20
https://technet.microsoft.com/en-us/sysinternals/processexplorer

You know of anything more accurate I could use?

BTW, the problem persists after updating to 2.1.18, same dumps.

Kind regards

Caro


From michael.blumenkrantz at gmail.com  Mon Jan 30 15:59:18 2017
From: michael.blumenkrantz at gmail.com (Mike Blumenkrantz)
Date: Mon, 30 Jan 2017 14:59:18 +0000
Subject: [PINENTRY PATCH] add efl-based frontend
In-Reply-To: <20170125081219.4d666e71@Sir.Pimpleton>
References: 
 <20161012113515.675d5a30@Sir.Pimpleton>
 <87y41swi1i.fsf@europa.jade-hamburg.de>
 
 <87inso1r02.fsf@europa.jade-hamburg.de>
 <20161019100137.66563eb7@Sir.Pimpleton>
 <877f5kzpab.fsf@europa.jade-hamburg.de>
 <20170125081219.4d666e71@Sir.Pimpleton>
Message-ID: 

Hi,

I've sent a new version of the implementation to the list, but it's caught
in moderation because the patch size is 41kb which exceeds the mailing list
limit of 40kb.

Regards,
Mike

On Wed, Jan 25, 2017 at 9:42 AM Mike Blumenkrantz  wrote:

> On Tue, 24 Jan 2017 12:10:52 +0100
> Justus Winter  wrote:
>
> > Mike Blumenkrantz  writes:
> >
> > > Thanks for your clarification. I've attached a new version of the patch
> > > which I believe addresses all the issues you have cited in both the
> > > contents of the patch and the commit log.
> >
> > Thanks.  In the mean time, I was finally able to build the pinentry.  I
> > have some remarks:
> >
> > 1/ the window is very small, there is no margin around the widgets at
> > all, it looks crowded.
> >
> > 2/ as soon as I enter a character, the text input field is resized
> > (enlarged), and as a consequence so is the dialog window.
> >
> > 3/ the buttons have no logos, yet the text is off-center.
>
> Thanks for checking, I'll look into these items.
>
> >
> > > Since we are being very technical about the commit log, and you
> > > specifically cited the docs, I'd like to point out that nowhere in the
> > > docs/HACKING file
> > > (
> https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/HACKING#l21
> )
> > > does it say anything about capitalization or punctuation. The prefixing
> > > that you've mentioned, while common in commit messages, is referred to
> > > something that is "usually" present, and it has no example for the
> > > addition of new components. Furthermore, listing files with their
> > > changes is also not in this document, nor is it done in every commit:
> > > the top-most commit that I was working off in the tree is
> > >
> https://git.gnupg.org/cgi-bin/gitweb.cgi?p=pinentry.git;a=commit;h=a383ddeb76463ddcf5aca2fb38847ea3158c42a7
> and does not include it.
> > > Based on this disconnect, it's easy to see why someone like
> > > me who has been working off very direct RFC-style specifications
> > > recently would produce a commit log which "stands out" :)
> > >
> > > I'd be happy to submit a patch for the docs/HACKING file which
> > > addresses these discrepancies to avoid any potential confusion
> > > with future contributors.
> >
> > Documentation patches are very welcome :)
> >
> >
> > Thanks,
> > Justus
>
> I'll follow up on this as well.
>
> Regards,
> Mike
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From justus at g10code.com  Mon Jan 30 17:52:44 2017
From: justus at g10code.com (Justus Winter)
Date: Mon, 30 Jan 2017 17:52:44 +0100
Subject: Key creation problem with 2.1.16
In-Reply-To: <20170130154208.038BF1013311@remailer.paranoici.org>
References: <20161129230429.B2488100B190@remailer.paranoici.org>
 <8760mxoghi.fsf@alice.fifthhorseman.net>
 <20161206124120.A4B1A1032319@remailer.paranoici.org>
 <87fum1m24x.fsf@alice.fifthhorseman.net>
 <20161208032707.B84771025BE0@remailer.paranoici.org>
 <20170129032954.3C67A1032248@remailer.paranoici.org>
 <87tw8gx4ea.fsf@europa.jade-hamburg.de>
 <20170130154208.038BF1013311@remailer.paranoici.org>
Message-ID: <87o9yowkv7.fsf@europa.jade-hamburg.de>

Hi,

Carola Grunwald  writes:

> on Mon, 30 Jan 2017 10:50:53 +0100, you wrote:
>
>>Carola Grunwald  writes:
>>
>>> agent the call stack dump always looks the same as shown below. Here it
>>[...]
>>> Stack for thread gpg-agent.exe+0x14e0
>>> -------------------------------------------------
>>> ntoskrnl.exe!SeAccessCheckWithHint+0xb4a
>>
>>May I ask how you create these stack traces?
>
> Sysinternals Process Explorer v16.20
> https://technet.microsoft.com/en-us/sysinternals/processexplorer

How did you get it to resolve symbols?  I never figured that out :/

> You know of anything more accurate I could use?

Well, you can attach a gdbserver to the process, and use gdb on a remote
Linux box with the sources, that is really nice, albeit a bit slow.

> BTW, the problem persists after updating to 2.1.18, same dumps.

:/

Fwiw, I saw gpg-agents hanging on Windows XP, it regularly happened
while running the test suite.  I don't see those kind of problems with
our current Windows 8.1 test box.

Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: 

From wk at gnupg.org  Mon Jan 30 18:36:46 2017
From: wk at gnupg.org (Werner Koch)
Date: Mon, 30 Jan 2017 18:36:46 +0100
Subject: Key creation problem with 2.1.16
In-Reply-To: <87o9yowkv7.fsf@europa.jade-hamburg.de> (Justus Winter's message
 of "Mon, 30 Jan 2017 17:52:44 +0100")
References: <20161129230429.B2488100B190@remailer.paranoici.org>
 <8760mxoghi.fsf@alice.fifthhorseman.net>
 <20161206124120.A4B1A1032319@remailer.paranoici.org>
 <87fum1m24x.fsf@alice.fifthhorseman.net>
 <20161208032707.B84771025BE0@remailer.paranoici.org>
 <20170129032954.3C67A1032248@remailer.paranoici.org>
 <87tw8gx4ea.fsf@europa.jade-hamburg.de>
 <20170130154208.038BF1013311@remailer.paranoici.org>
 <87o9yowkv7.fsf@europa.jade-hamburg.de>
Message-ID: <87inow4fgx.fsf@wheatstone.g10code.de>

On Mon, 30 Jan 2017 17:52, justus at g10code.com said:

> Fwiw, I saw gpg-agents hanging on Windows XP, it regularly happened
> while running the test suite.  I don't see those kind of problems with
> our current Windows 8.1 test box.

That might be possible also I never experienced that in the past.  For
quite some time I have stopped test on XP, though.


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: 227 bytes
Desc: not available
URL: 

From wk at gnupg.org  Mon Jan 30 18:39:26 2017
From: wk at gnupg.org (Werner Koch)
Date: Mon, 30 Jan 2017 18:39:26 +0100
Subject: [LIBGPG-ERROR] Add Base64 decoder
In-Reply-To: <87efzl171q.fsf@fsij.org> (NIIBE Yutaka's message of "Mon, 30 Jan
 2017 13:54:41 +0900")
References: <87efzl171q.fsf@fsij.org>
Message-ID: <87efzk4fch.fsf@wheatstone.g10code.de>

On Mon, 30 Jan 2017 05:54, gniibe at fsij.org said:

> +++ b/src/gpg-error.h.in

> +struct b64state
> +{
> +  int idx;
> +  int quad_count;
> +  char *title;
> +  unsigned char radbuf[4];
> +  int stop_seen:1;
> +  int invalid_encoding:1;
> +  gpg_error_t lasterr;
> +};

We should hide that structure form the public API.  I did this in GnuPG
only for simplicity.


Shalom-Salam,

   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: 227 bytes
Desc: not available
URL: 

From kristian.fiskerstrand at sumptuouscapital.com  Mon Jan 30 19:13:05 2017
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Mon, 30 Jan 2017 19:13:05 +0100
Subject: Key creation problem with 2.1.16
In-Reply-To: <87inow4fgx.fsf@wheatstone.g10code.de>
References: <20161129230429.B2488100B190@remailer.paranoici.org>
 <8760mxoghi.fsf@alice.fifthhorseman.net>
 <20161206124120.A4B1A1032319@remailer.paranoici.org>
 <87fum1m24x.fsf@alice.fifthhorseman.net>
 <20161208032707.B84771025BE0@remailer.paranoici.org>
 <20170129032954.3C67A1032248@remailer.paranoici.org>
 <87tw8gx4ea.fsf@europa.jade-hamburg.de>
 <20170130154208.038BF1013311@remailer.paranoici.org>
 <87o9yowkv7.fsf@europa.jade-hamburg.de>
 <87inow4fgx.fsf@wheatstone.g10code.de>
Message-ID: <90173c2d-8ac5-f0ab-6efe-d5ed3ac13e17@sumptuouscapital.com>

On 01/30/2017 06:36 PM, Werner Koch wrote:
>> Fwiw, I saw gpg-agents hanging on Windows XP, it regularly happened
>> while running the test suite.  I don't see those kind of problems with
>> our current Windows 8.1 test box.
> That might be possible also I never experienced that in the past.  For
> quite some time I have stopped test on XP, though.

This might also relate to our downstream issues in

Bug 605806 - app-crypt/gnupg-2.1.17-r1: test hangs
https://bugs.gentoo.org/show_bug.cgi?id=605806
strace of gpg-agent shows
futex(0x7f921a2c9200, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0,
NULL, 0xffffffff) = 0
futex(0x7f921a2c9200, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0,
NULL, 0xffffffff) = 0
futex(0x7f921a2c9200, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0,
NULL, 0xffffffff) = 0
and backtrace in gdb included


Bug 595808 - app-crypt/gnupg-2.1.15: gpg-agent hangs after pinentry
https://bugs.gentoo.org/show_bug.cgi?id=595808
this one seemed related to specific kernel version behavior, so might
provide some insight into changes, we were unable to properly reproduce
it at the time (but it is a precursor to the above bug).

-- 
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
"History is a gallery of pictures in which there are few originals and
many copies."
(Alexis de Tocqueville)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: 

From gabrielfrancosouza at gmail.com  Tue Jan 31 04:22:28 2017
From: gabrielfrancosouza at gmail.com (Gabriel Souza Franco)
Date: Tue, 31 Jan 2017 01:22:28 -0200
Subject: Can't resolve DNS since 2.1.17
Message-ID: 

Hello,

With the new backend introduced in 2.1.17 I can no longer resolve
keyserver urls, and I've traced it back to a failing SRV lookup.
For some unfathomable reason, my ISP provided router responds with
FORMERR instead of NXDOMAIN (but not for .localdomain queries,
interestingly). The failed SRV query then bubbles up, resulting in
Server indicated failure/No keyserver available errors. The old
backend seems to treat any failures as no response instead.

As a quick hack, I added FORMERR alongside every NXDOMAIN case I found,
and it seemed to work just fine. Would this be an acceptable solution?


From wk at gnupg.org  Tue Jan 31 08:57:49 2017
From: wk at gnupg.org (Werner Koch)
Date: Tue, 31 Jan 2017 08:57:49 +0100
Subject: Can't resolve DNS since 2.1.17
In-Reply-To: 
 (Gabriel Souza Franco's message of "Tue, 31 Jan 2017 01:22:28 -0200")
References: 
Message-ID: <87tw8f3blu.fsf@wheatstone.g10code.de>

On Tue, 31 Jan 2017 04:22, gabrielfrancosouza at gmail.com said:

> With the new backend introduced in 2.1.17 I can no longer resolve
> keyserver urls, and I've traced it back to a failing SRV lookup.

Have your tried 2.1.18 which should fix the DNS bugs?


Shalom-Salam,

   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: 227 bytes
Desc: not available
URL: 

From gniibe at fsij.org  Tue Jan 31 09:27:14 2017
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 31 Jan 2017 17:27:14 +0900
Subject: [LIBGPG-ERROR] Add Base64 decoder
In-Reply-To: <87efzk4fch.fsf@wheatstone.g10code.de>
References: <87efzl171q.fsf@fsij.org> <87efzk4fch.fsf@wheatstone.g10code.de>
Message-ID: <87vasvy6ql.fsf@fsij.org>

Werner Koch  wrote:
> We should hide that structure form the public API.  I did this in GnuPG
> only for simplicity.

OK.  Here is my second attempt, hiding the structure.

Interestingly, the size of the patch is exactly same as the version I
submitted yesterday.  If this is OK, I also copy&modify
gnupg/common/t-b64.c into libgpg-error.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-Base64-decoder.patch
Type: text/x-diff
Size: 11829 bytes
Desc: 2017-01-31 version of Base64 patch
URL: 
-------------- next part --------------
-- 

From wk at gnupg.org  Tue Jan 31 10:17:04 2017
From: wk at gnupg.org (Werner Koch)
Date: Tue, 31 Jan 2017 10:17:04 +0100
Subject: [LIBGPG-ERROR] Add Base64 decoder
In-Reply-To: <87vasvy6ql.fsf@fsij.org> (NIIBE Yutaka's message of "Tue, 31 Jan
 2017 17:27:14 +0900")
References: <87efzl171q.fsf@fsij.org> <87efzk4fch.fsf@wheatstone.g10code.de>
 <87vasvy6ql.fsf@fsij.org>
Message-ID: <87fujz37xr.fsf@wheatstone.g10code.de>

On Tue, 31 Jan 2017 09:27, gniibe at fsij.org said:

> submitted yesterday.  If this is OK, I also copy&modify
> gnupg/common/t-b64.c into libgpg-error.

That will be good. I have one last suggestion, though:

> diff --git a/src/gpg-error.h.in b/src/gpg-error.h.in

> +struct b64state;
> +typedef struct b64state *b64state_t;

That pollutes the names space and might clash with symbols defined by
other libraries.  So what about:

--8<---------------cut here---------------start------------->8---
struct _gpgrt_b64state;
typedef struct _gpgrt_b64state *gpgrt_b64state_t;
--8<---------------cut here---------------end--------------->8---

or if you want it shorter, 

--8<---------------cut here---------------start------------->8---
struct _gpgrt_b64;
typedef struct _gpgrt_b64 *gpgrt_b64_t;
--8<---------------cut here---------------end--------------->8---

might also be okay.  I would prefer the first version as it is more
explicit.


Shalom-Salam,

   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: 227 bytes
Desc: not available
URL: 

From caro at nymph.paranoici.org  Tue Jan 31 10:50:45 2017
From: caro at nymph.paranoici.org (Carola Grunwald)
Date: Tue, 31 Jan 2017 09:50:45 +0000 (UTC)
Subject: Key creation problem with 2.1.16
References: <20161129230429.B2488100B190@remailer.paranoici.org>
 <8760mxoghi.fsf@alice.fifthhorseman.net>
 <20161208032707.B84771025BE0@remailer.paranoici.org>
 <20170129032954.3C67A1032248@remailer.paranoici.org>
 <87tw8gx4ea.fsf@europa.jade-hamburg.de>
 <20170130154208.038BF1013311@remailer.paranoici.org>
 <87o9yowkv7.fsf@europa.jade-hamburg.de>
Message-ID: <20170131095045.718D8103201B@remailer.paranoici.org>

Hi!

On Mon, 30 Jan 2017 17:52:44 +0100, Justus Winter wrote:

>Carola Grunwald  writes:
>
>> on Mon, 30 Jan 2017 10:50:53 +0100, you wrote:
>>
>>>Carola Grunwald  writes:
>>>
>>>> agent the call stack dump always looks the same as shown below. Here it
>>>[...]
>>>> Stack for thread gpg-agent.exe+0x14e0
>>>> -------------------------------------------------
>>>> ntoskrnl.exe!SeAccessCheckWithHint+0xb4a
>>>
>>>May I ask how you create these stack traces?
>>
>> Sysinternals Process Explorer v16.20
>> https://technet.microsoft.com/en-us/sysinternals/processexplorer
>
>How did you get it to resolve symbols?  I never figured that out :/

These are the out-of-the-box results. There are no further Windows
debugging tools or symbol packages installed.

>
>> You know of anything more accurate I could use?
>
>Well, you can attach a gdbserver to the process, and use gdb on a remote
>Linux box with the sources, that is really nice, albeit a bit slow.

I think that's beyond my skills. Let that do those who know about gpg's
internals.

>
>> BTW, the problem persists after updating to 2.1.18, same dumps.
>
>:/
>
>Fwiw, I saw gpg-agents hanging on Windows XP, it regularly happened
>while running the test suite.  I don't see those kind of problems with
>our current Windows 8.1 test box.

Sorry, for privacy reasons I banned Windows 8 ff. here. I can't imagine
why it should do any better.

And there's no reason to run any test suite. Just start the agent and
wait. In the end there'll be two blocked libnpth-0 dlls.

Their threads' call stack dumps:

ntoskrnl.exe!SeAccessCheckWithHint+0xb4a
ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x7d2
ntoskrnl.exe!KeWaitForMutexObject+0x19f
ntoskrnl.exe!PsIsSystemProcess+0x94
ntoskrnl.exe!KeStackAttachProcess+0x11c1
ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x9dd
ntoskrnl.exe!KeWaitForMutexObject+0x19f
ntoskrnl.exe!NtWaitForSingleObject+0xb2
ntoskrnl.exe!KeSynchronizeExecution+0x3a43
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x690
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x484
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x429
ntdll.dll!LdrGetProcedureAddress+0x24127
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!NtWaitForSingleObject+0x15
ntdll.dll!RtlIntegerToUnicodeString+0x20b
libnpth-0.dll!npth_clock_gettime+0x18f
libnpth-0.dll!npth_protect+0x1b
gpg-agent.exe+0x1594
libassuan-0.dll!assuan_get_assuan_log_prefix+0x169b
libassuan-0.dll!assuan_socket_connect+0x47e
gpg-agent.exe+0x1e5c
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36

and

ntoskrnl.exe!SeAccessCheckWithHint+0xb4a
ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x7d2
ntoskrnl.exe!KeWaitForMutexObject+0x19f
ntoskrnl.exe!PsIsSystemProcess+0x94
ntoskrnl.exe!KeStackAttachProcess+0x11c1
ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x9dd
ntoskrnl.exe!KeWaitForMutexObject+0x19f
ntoskrnl.exe!NtWaitForSingleObject+0xb2
ntoskrnl.exe!KeSynchronizeExecution+0x3a43
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x690
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x484
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x429
ntdll.dll!LdrGetProcedureAddress+0x24127
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!NtWaitForSingleObject+0x15
mswsock.dll+0x678c
mswsock.dll+0x461c
libassuan-0.dll!__assuan_read+0x11f
libassuan-0.dll!assuan_free+0x3a2
libassuan-0.dll!assuan_get_assuan_log_prefix+0xd4f
libassuan-0.dll!assuan_get_assuan_log_prefix+0x1dc9
libassuan-0.dll!assuan_sock_check_nonce+0x21
gpg-agent.exe+0x2bfc
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36

with gpg-agent.exe:

ntoskrnl.exe!SeAccessCheckWithHint+0xb4a
ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x7d2
ntoskrnl.exe!KeWaitForMutexObject+0x19f
ntoskrnl.exe!PsIsSystemProcess+0x94
ntoskrnl.exe!KeStackAttachProcess+0x11c1
ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x9dd
ntoskrnl.exe!KeWaitForMutexObject+0x19f
ntoskrnl.exe!NtWaitForSingleObject+0xb2
ntoskrnl.exe!KeSynchronizeExecution+0x3a43
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x690
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x484
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x429
ntdll.dll!RtlResetRtlTranslations+0x1b08
ntdll.dll!RtlResetRtlTranslations+0xc63
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!NtWaitForSingleObject+0x15
ntdll.dll!RtlIntegerToUnicodeString+0x20b
libnpth-0.dll!npth_clock_gettime+0x18f
libnpth-0.dll!npth_eselect+0x485
gpg-agent.exe+0x374b

A thread safety problem with the Assuan library?
Just guessing. ;)

Kind regards

Caro


From justus at g10code.com  Tue Jan 31 11:20:58 2017
From: justus at g10code.com (Justus Winter)
Date: Tue, 31 Jan 2017 11:20:58 +0100
Subject: Key creation problem with 2.1.16
In-Reply-To: <90173c2d-8ac5-f0ab-6efe-d5ed3ac13e17@sumptuouscapital.com>
References: <20161129230429.B2488100B190@remailer.paranoici.org>
 <8760mxoghi.fsf@alice.fifthhorseman.net>
 <20161206124120.A4B1A1032319@remailer.paranoici.org>
 <87fum1m24x.fsf@alice.fifthhorseman.net>
 <20161208032707.B84771025BE0@remailer.paranoici.org>
 <20170129032954.3C67A1032248@remailer.paranoici.org>
 <87tw8gx4ea.fsf@europa.jade-hamburg.de>
 <20170130154208.038BF1013311@remailer.paranoici.org>
 <87o9yowkv7.fsf@europa.jade-hamburg.de>
 <87inow4fgx.fsf@wheatstone.g10code.de>
 <90173c2d-8ac5-f0ab-6efe-d5ed3ac13e17@sumptuouscapital.com>
Message-ID: <87r33jttrp.fsf@europa.jade-hamburg.de>

Kristian Fiskerstrand 
writes:

> [ Unknown signature status ]
> On 01/30/2017 06:36 PM, Werner Koch wrote:
>>> Fwiw, I saw gpg-agents hanging on Windows XP, it regularly happened
>>> while running the test suite.  I don't see those kind of problems with
>>> our current Windows 8.1 test box.
>> That might be possible also I never experienced that in the past.  For
>> quite some time I have stopped test on XP, though.
>
> This might also relate to our downstream issues in
>
> Bug 605806 - app-crypt/gnupg-2.1.17-r1: test hangs
> https://bugs.gentoo.org/show_bug.cgi?id=605806
> strace of gpg-agent shows
> futex(0x7f921a2c9200, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0,
> NULL, 0xffffffff) = 0
> futex(0x7f921a2c9200, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0,
> NULL, 0xffffffff) = 0
> futex(0x7f921a2c9200, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0,
> NULL, 0xffffffff) = 0
> and backtrace in gdb included

Err.  From the log it doesn't seem like a test is run at all.  Please
ask the reporter to figure out what is actually happening.  The log ends
in

make  check-TESTS
make[2]: Entering directory
'/var/tmp/portage/app-crypt/gnupg-2.1.17-r1/work/gnupg-2.1.17/agent'

however, there are no tests in agent/ that actually spawn the agent.
So, what agent process are we even looking at?

Further,  from the stack trace I see that npth is trying to acquire the
global npth lock.  This suggests that more threads are running.  Please
ask the reporter to do 'thread apply all bt'.


Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: 

From justus at g10code.com  Tue Jan 31 11:38:08 2017
From: justus at g10code.com (Justus Winter)
Date: Tue, 31 Jan 2017 11:38:08 +0100
Subject: Key creation problem with 2.1.16
In-Reply-To: <20170131095045.718D8103201B@remailer.paranoici.org>
References: <20161129230429.B2488100B190@remailer.paranoici.org>
 <8760mxoghi.fsf@alice.fifthhorseman.net>
 <20161208032707.B84771025BE0@remailer.paranoici.org>
 <20170129032954.3C67A1032248@remailer.paranoici.org>
 <87tw8gx4ea.fsf@europa.jade-hamburg.de>
 <20170130154208.038BF1013311@remailer.paranoici.org>
 <87o9yowkv7.fsf@europa.jade-hamburg.de>
 <20170131095045.718D8103201B@remailer.paranoici.org>
Message-ID: <87o9yntsz3.fsf@europa.jade-hamburg.de>

Carola Grunwald  writes:

> And there's no reason to run any test suite. Just start the agent and
> wait. In the end there'll be two blocked libnpth-0 dlls.

"Two blocked libnpth-0 dlls"?  Do you mean two threads within the
gpg-agent.exe process?

> Their threads' call stack dumps:
>
> ntoskrnl.exe!SeAccessCheckWithHint+0xb4a
> ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x7d2
> ntoskrnl.exe!KeWaitForMutexObject+0x19f
> ntoskrnl.exe!PsIsSystemProcess+0x94
> ntoskrnl.exe!KeStackAttachProcess+0x11c1
> ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x9dd
> ntoskrnl.exe!KeWaitForMutexObject+0x19f
> ntoskrnl.exe!NtWaitForSingleObject+0xb2
> ntoskrnl.exe!KeSynchronizeExecution+0x3a43
> wow64cpu.dll!TurboDispatchJumpAddressEnd+0x690
> wow64cpu.dll!TurboDispatchJumpAddressEnd+0x484
> wow64.dll!Wow64SystemServiceEx+0x1ce
> wow64.dll!Wow64LdrpInitialize+0x429
> ntdll.dll!LdrGetProcedureAddress+0x24127
> ntdll.dll!LdrInitializeThunk+0xe
> ntdll.dll!NtWaitForSingleObject+0x15
> ntdll.dll!RtlIntegerToUnicodeString+0x20b
> libnpth-0.dll!npth_clock_gettime+0x18f
> libnpth-0.dll!npth_protect+0x1b
> gpg-agent.exe+0x1594
> libassuan-0.dll!assuan_get_assuan_log_prefix+0x169b
> libassuan-0.dll!assuan_socket_connect+0x47e
> gpg-agent.exe+0x1e5c
> ntdll.dll!RtlInitializeExceptionChain+0x63
> ntdll.dll!RtlInitializeExceptionChain+0x36
>
> and
>
> ntoskrnl.exe!SeAccessCheckWithHint+0xb4a
> ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x7d2
> ntoskrnl.exe!KeWaitForMutexObject+0x19f
> ntoskrnl.exe!PsIsSystemProcess+0x94
> ntoskrnl.exe!KeStackAttachProcess+0x11c1
> ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x9dd
> ntoskrnl.exe!KeWaitForMutexObject+0x19f
> ntoskrnl.exe!NtWaitForSingleObject+0xb2
> ntoskrnl.exe!KeSynchronizeExecution+0x3a43
> wow64cpu.dll!TurboDispatchJumpAddressEnd+0x690
> wow64cpu.dll!TurboDispatchJumpAddressEnd+0x484
> wow64.dll!Wow64SystemServiceEx+0x1ce
> wow64.dll!Wow64LdrpInitialize+0x429
> ntdll.dll!LdrGetProcedureAddress+0x24127
> ntdll.dll!LdrInitializeThunk+0xe
> ntdll.dll!NtWaitForSingleObject+0x15
> mswsock.dll+0x678c
> mswsock.dll+0x461c
> libassuan-0.dll!__assuan_read+0x11f
> libassuan-0.dll!assuan_free+0x3a2
> libassuan-0.dll!assuan_get_assuan_log_prefix+0xd4f
> libassuan-0.dll!assuan_get_assuan_log_prefix+0x1dc9
> libassuan-0.dll!assuan_sock_check_nonce+0x21
> gpg-agent.exe+0x2bfc
> ntdll.dll!RtlInitializeExceptionChain+0x63
> ntdll.dll!RtlInitializeExceptionChain+0x36
>
> with gpg-agent.exe:

I am lost here.  What do you mean by "with gpg-agent.exe" here?  Another
thread within the same process?

> ntoskrnl.exe!SeAccessCheckWithHint+0xb4a
> ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x7d2
> ntoskrnl.exe!KeWaitForMutexObject+0x19f
> ntoskrnl.exe!PsIsSystemProcess+0x94
> ntoskrnl.exe!KeStackAttachProcess+0x11c1
> ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x9dd
> ntoskrnl.exe!KeWaitForMutexObject+0x19f
> ntoskrnl.exe!NtWaitForSingleObject+0xb2
> ntoskrnl.exe!KeSynchronizeExecution+0x3a43
> wow64cpu.dll!TurboDispatchJumpAddressEnd+0x690
> wow64cpu.dll!TurboDispatchJumpAddressEnd+0x484
> wow64.dll!Wow64SystemServiceEx+0x1ce
> wow64.dll!Wow64LdrpInitialize+0x429
> ntdll.dll!RtlResetRtlTranslations+0x1b08
> ntdll.dll!RtlResetRtlTranslations+0xc63
> ntdll.dll!LdrInitializeThunk+0xe
> ntdll.dll!NtWaitForSingleObject+0x15
> ntdll.dll!RtlIntegerToUnicodeString+0x20b
> libnpth-0.dll!npth_clock_gettime+0x18f
> libnpth-0.dll!npth_eselect+0x485
> gpg-agent.exe+0x374b
>
> A thread safety problem with the Assuan library?
> Just guessing. ;)

Maybe.  Or in gpg-agent.

So the first thread seems to do an assuan connect, and the second is in
the process of accepting a connection.  This looks like the periodic
check that gpg-agent does.  It tries to connect to its own socket to see
if it has been deleted (to shut down in that case).  This is also what I
observed.

Assuan emulates unix sockets with tcp on Windows, exchanging an magic
number at the beginning that is stored in the file pretending to be a
unix socket.  This makes sure that only clients able to read the file
can connect.

What happens here is that the server waits for the client to send the
token, but that doesn't seem to happen.  Both threads seem to be doing
some kind of synchronization.


Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: 

From amzh at hushmail.com  Tue Jan 31 13:01:12 2017
From: amzh at hushmail.com (Andrey Mozharovskiy)
Date: Tue, 31 Jan 2017 15:01:12 +0300
Subject: Best way to import a public key from libgcrypt to gpgme?
Message-ID: <20170131120112.B77BF40176@smtp.hushmail.com>

Hello,
We 're using libgcrypt to generate a key pair, and to encrypt/decrypt
data. However, we also need to upload our public keys to server, and
because of that public key must be Ascii armored. 
Since libgcrypt doesn't have any functionality to do that, we decided
on using gpgme for the Ascii Armor part.
Could someone please describe the best way to import a public key from
libgcrypt to gpgme? Should that involve gpgme_op_import (gpgme_ctx_t
ctx, gpgme_data_t keydata) ?
Regards.  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From wk at gnupg.org  Tue Jan 31 13:17:10 2017
From: wk at gnupg.org (Werner Koch)
Date: Tue, 31 Jan 2017 13:17:10 +0100
Subject: Best way to import a public key from libgcrypt to gpgme?
In-Reply-To: <20170131120112.B77BF40176@smtp.hushmail.com> (Andrey
 Mozharovskiy's message of "Tue, 31 Jan 2017 15:01:12 +0300")
References: <20170131120112.B77BF40176@smtp.hushmail.com>
Message-ID: <87lgtr1l15.fsf@wheatstone.g10code.de>

On Tue, 31 Jan 2017 13:01, amzh at hushmail.com said:

> We 're using libgcrypt to generate a key pair, and to encrypt/decrypt
> data. However, we also need to upload our public keys to server, and
> because of that public key must be Ascii armored. 

Libgcrypt does not implement any protocol; it provides building blocks
which other software can use to implement a protocol or data format.

> libgcrypt to gpgme? Should that involve gpgme_op_import (gpgme_ctx_t
> ctx, gpgme_data_t keydata) ?

gpgme supports the S/MIME and the OpenPGP protocol.  Thus you need to
make keys compliant with these protocol specifications.  Libgcrypt can't
do that - gpg or gpgsm are examples of software which can do that.


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: 227 bytes
Desc: not available
URL: 

From gabrielfrancosouza at gmail.com  Tue Jan 31 14:28:14 2017
From: gabrielfrancosouza at gmail.com (Gabriel Souza Franco)
Date: Tue, 31 Jan 2017 11:28:14 -0200
Subject: Can't resolve DNS since 2.1.17
In-Reply-To: <87tw8f3blu.fsf@wheatstone.g10code.de>
References: 
 <87tw8f3blu.fsf@wheatstone.g10code.de>
Message-ID: 

On Tue, Jan 31, 2017 at 5:57 AM, Werner Koch  wrote:
> On Tue, 31 Jan 2017 04:22, gabrielfrancosouza at gmail.com said:
>
>> With the new backend introduced in 2.1.17 I can no longer resolve
>> keyserver urls, and I've traced it back to a failing SRV lookup.
>
> Have your tried 2.1.18 which should fix the DNS bugs?

Yes, those fixes haven't solved my problem.


From caro at nymph.paranoici.org  Tue Jan 31 14:35:59 2017
From: caro at nymph.paranoici.org (Carola Grunwald)
Date: Tue, 31 Jan 2017 13:35:59 +0000 (UTC)
Subject: Key creation problem with 2.1.16
References: <20161129230429.B2488100B190@remailer.paranoici.org>
 <8760mxoghi.fsf@alice.fifthhorseman.net>
 <87tw8gx4ea.fsf@europa.jade-hamburg.de>
 <20170130154208.038BF1013311@remailer.paranoici.org>
 <87o9yowkv7.fsf@europa.jade-hamburg.de>
 <20170131095045.718D8103201B@remailer.paranoici.org>
 <87o9yntsz3.fsf@europa.jade-hamburg.de>
Message-ID: <20170131133559.4DEDC103201B@remailer.paranoici.org>

Hi!

On Tue, 31 Jan 2017 11:38:08 +0100, Justus Winter wrote:

>Carola Grunwald  writes:
>
>> And there's no reason to run any test suite. Just start the agent and
>> wait. In the end there'll be two blocked libnpth-0 dlls.
>
>"Two blocked libnpth-0 dlls"?  Do you mean two threads within the
>gpg-agent.exe process?

Correct.

Normally in the threads list I see

TID   Start Address
2192  gpg-agent.exe+0x14e0
5224  ntdll.dll!TpCallbackIndependent+0x238
4696  ntdll.dll!EtwDeliverDataBlock+0x453

With a broken agent two libnpth-0.dll threads remain active infinitely

TID   Start Address
4816  gpg-agent.exe+0x14e0
5884  ntdll.dll!TpCallbackIndependent+0x238
5256  ntdll.dll!EtwDeliverDataBlock+0x453
2716  libnpth-0.dll!npth_setname_np+0x59
5776  libnpth-0.dll!npth_setname_np+0x59

>
>> Their threads' call stack dumps:
>>
>> ntoskrnl.exe!SeAccessCheckWithHint+0xb4a
>> ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x7d2
>> ntoskrnl.exe!KeWaitForMutexObject+0x19f
>> ntoskrnl.exe!PsIsSystemProcess+0x94
>> ntoskrnl.exe!KeStackAttachProcess+0x11c1
>> ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x9dd
>> ntoskrnl.exe!KeWaitForMutexObject+0x19f
>> ntoskrnl.exe!NtWaitForSingleObject+0xb2
>> ntoskrnl.exe!KeSynchronizeExecution+0x3a43
>> wow64cpu.dll!TurboDispatchJumpAddressEnd+0x690
>> wow64cpu.dll!TurboDispatchJumpAddressEnd+0x484
>> wow64.dll!Wow64SystemServiceEx+0x1ce
>> wow64.dll!Wow64LdrpInitialize+0x429
>> ntdll.dll!LdrGetProcedureAddress+0x24127
>> ntdll.dll!LdrInitializeThunk+0xe
>> ntdll.dll!NtWaitForSingleObject+0x15
>> ntdll.dll!RtlIntegerToUnicodeString+0x20b
>> libnpth-0.dll!npth_clock_gettime+0x18f
>> libnpth-0.dll!npth_protect+0x1b
>> gpg-agent.exe+0x1594
>> libassuan-0.dll!assuan_get_assuan_log_prefix+0x169b
>> libassuan-0.dll!assuan_socket_connect+0x47e
>> gpg-agent.exe+0x1e5c
>> ntdll.dll!RtlInitializeExceptionChain+0x63
>> ntdll.dll!RtlInitializeExceptionChain+0x36
>>
>> and
>>
>> ntoskrnl.exe!SeAccessCheckWithHint+0xb4a
>> ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x7d2
>> ntoskrnl.exe!KeWaitForMutexObject+0x19f
>> ntoskrnl.exe!PsIsSystemProcess+0x94
>> ntoskrnl.exe!KeStackAttachProcess+0x11c1
>> ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x9dd
>> ntoskrnl.exe!KeWaitForMutexObject+0x19f
>> ntoskrnl.exe!NtWaitForSingleObject+0xb2
>> ntoskrnl.exe!KeSynchronizeExecution+0x3a43
>> wow64cpu.dll!TurboDispatchJumpAddressEnd+0x690
>> wow64cpu.dll!TurboDispatchJumpAddressEnd+0x484
>> wow64.dll!Wow64SystemServiceEx+0x1ce
>> wow64.dll!Wow64LdrpInitialize+0x429
>> ntdll.dll!LdrGetProcedureAddress+0x24127
>> ntdll.dll!LdrInitializeThunk+0xe
>> ntdll.dll!NtWaitForSingleObject+0x15
>> mswsock.dll+0x678c
>> mswsock.dll+0x461c
>> libassuan-0.dll!__assuan_read+0x11f
>> libassuan-0.dll!assuan_free+0x3a2
>> libassuan-0.dll!assuan_get_assuan_log_prefix+0xd4f
>> libassuan-0.dll!assuan_get_assuan_log_prefix+0x1dc9
>> libassuan-0.dll!assuan_sock_check_nonce+0x21
>> gpg-agent.exe+0x2bfc
>> ntdll.dll!RtlInitializeExceptionChain+0x63
>> ntdll.dll!RtlInitializeExceptionChain+0x36
>>
>> with gpg-agent.exe:
>
>I am lost here.  What do you mean by "with gpg-agent.exe" here?  Another
>thread within the same process?

The main thread of the process.

>
>> ntoskrnl.exe!SeAccessCheckWithHint+0xb4a
>> ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x7d2
>> ntoskrnl.exe!KeWaitForMutexObject+0x19f
>> ntoskrnl.exe!PsIsSystemProcess+0x94
>> ntoskrnl.exe!KeStackAttachProcess+0x11c1
>> ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x9dd
>> ntoskrnl.exe!KeWaitForMutexObject+0x19f
>> ntoskrnl.exe!NtWaitForSingleObject+0xb2
>> ntoskrnl.exe!KeSynchronizeExecution+0x3a43
>> wow64cpu.dll!TurboDispatchJumpAddressEnd+0x690
>> wow64cpu.dll!TurboDispatchJumpAddressEnd+0x484
>> wow64.dll!Wow64SystemServiceEx+0x1ce
>> wow64.dll!Wow64LdrpInitialize+0x429
>> ntdll.dll!RtlResetRtlTranslations+0x1b08
>> ntdll.dll!RtlResetRtlTranslations+0xc63
>> ntdll.dll!LdrInitializeThunk+0xe
>> ntdll.dll!NtWaitForSingleObject+0x15
>> ntdll.dll!RtlIntegerToUnicodeString+0x20b
>> libnpth-0.dll!npth_clock_gettime+0x18f
>> libnpth-0.dll!npth_eselect+0x485
>> gpg-agent.exe+0x374b

Kind regards

Caro


From amzh at hushmail.com  Tue Jan 31 15:57:55 2017
From: amzh at hushmail.com (Andrey Mozharovskiy)
Date: Tue, 31 Jan 2017 17:57:55 +0300
Subject: Best way to import a public key from libgcrypt to gpgme?
In-Reply-To: <87lgtr1l15.fsf@wheatstone.g10code.de>
References: <20170131120112.B77BF40176@smtp.hushmail.com>
 <87lgtr1l15.fsf@wheatstone.g10code.de> 
Message-ID: <20170131145755.5DF6740176@smtp.hushmail.com>

I see, thank you.
Cheers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From zmike at samsung.com  Thu Jan 26 17:52:02 2017
From: zmike at samsung.com (Mike Blumenkrantz)
Date: Thu, 26 Jan 2017 11:52:02 -0500
Subject: [PINENTRY PATCH] add efl-based frontend
In-Reply-To: <20170125081219.4d666e71@Sir.Pimpleton>
References: 
 <20161012113515.675d5a30@Sir.Pimpleton>
 <87y41swi1i.fsf@europa.jade-hamburg.de>
 
 <87inso1r02.fsf@europa.jade-hamburg.de>
 <20161019100137.66563eb7@Sir.Pimpleton>
 <877f5kzpab.fsf@europa.jade-hamburg.de>
 <20170125081219.4d666e71@Sir.Pimpleton>
Message-ID: <20170126115202.6466a166@Sir.Pimpleton>

On Wed, 25 Jan 2017 08:12:19 -0500
Mike Blumenkrantz  wrote:

> On Tue, 24 Jan 2017 12:10:52 +0100
> Justus Winter  wrote:
> 
> > Mike Blumenkrantz  writes:
> >   
> > > Thanks for your clarification. I've attached a new version of the patch
> > > which I believe addresses all the issues you have cited in both the
> > > contents of the patch and the commit log.    
> > 
> > Thanks.  In the mean time, I was finally able to build the pinentry.  I
> > have some remarks:
> > 
> > 1/ the window is very small, there is no margin around the widgets at
> > all, it looks crowded.
> > 
> > 2/ as soon as I enter a character, the text input field is resized
> > (enlarged), and as a consequence so is the dialog window.
> > 
> > 3/ the buttons have no logos, yet the text is off-center.  
> 
> Thanks for checking, I'll look into these items.
> 
> >   
> > > Since we are being very technical about the commit log, and you
> > > specifically cited the docs, I'd like to point out that nowhere in the
> > > docs/HACKING file
> > > (https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/HACKING#l21)
> > > does it say anything about capitalization or punctuation. The prefixing
> > > that you've mentioned, while common in commit messages, is referred to
> > > something that is "usually" present, and it has no example for the
> > > addition of new components. Furthermore, listing files with their
> > > changes is also not in this document, nor is it done in every commit:
> > > the top-most commit that I was working off in the tree is
> > > https://git.gnupg.org/cgi-bin/gitweb.cgi?p=pinentry.git;a=commit;h=a383ddeb76463ddcf5aca2fb38847ea3158c42a7 and does not include it.
> > > Based on this disconnect, it's easy to see why someone like
> > > me who has been working off very direct RFC-style specifications
> > > recently would produce a commit log which "stands out" :)
> > >
> > > I'd be happy to submit a patch for the docs/HACKING file which
> > > addresses these discrepancies to avoid any potential confusion
> > > with future contributors.    
> > 
> > Documentation patches are very welcome :)
> > 
> > 
> > Thanks,
> > Justus  
> 
> I'll follow up on this as well.
> 
> Regards,
> Mike

Hi,

I've attached a revision of the patch which should address your comments:

1/ I've added some padding around the sides of the window

2/ Resizing is resolved, however there's currently a bug in EFL HEAD where initial window focus is broken; if you experience this while testing, it is not an application bug

3/ It sounds like you don't have an icon theme configured in efl, and no default is set. I've added some checks to prevent unusual alignments, but in the end it's a toolkit issue

Regards,
Mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-efl-Add-an-efl-based-frontend-for-pinentry.patch
Type: text/x-patch
Size: 26463 bytes
Desc: not available
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: