From alon.barlev at gmail.com Fri Sep 1 08:24:49 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Fri, 1 Sep 2017 09:24:49 +0300 Subject: [PATCH GNUPG] sm: Search for qualified.txt at sysconfdir first Message-ID: <20170901062449.32475-1-alon.barlev@gmail.com> * sm/qualified.c (read_list): Search for qualified.txt in sysconfdir and fallback to datadir. * doc/gpgsm.texi (qualified.txt): Document behavior. -- The qualified.txt may be modified by the Administrator, hence this artifact is a configuration. A product may provide sane defaults, however, it should be possible for the Administrator to manage configuration at sysconfdir. The qualified.txt at sysconfdir takes precedence over the one in datadir. Signed-off-by: Alon Bar-Lev --- doc/gpgsm.texi | 14 +++++++------- sm/qualified.c | 23 ++++++++++++++++++++--- 2 files changed, 27 insertions(+), 10 deletions(-) diff --git a/doc/gpgsm.texi b/doc/gpgsm.texi index 5d79ce5..a1a9ea7 100644 --- a/doc/gpgsm.texi +++ b/doc/gpgsm.texi @@ -845,13 +845,13 @@ Note that even if a certificate is listed in this file, this does not mean that the certificate is trusted; in general the certificates listed in this file need to be listed also in @file{trustlist.txt}. -This is a global file an installed in the data directory -(e.g. @file{@value{DATADIR}/qualified.txt}). GnuPG installs a suitable -file with root certificates as used in Germany. As new Root-CA -certificates may be issued over time, these entries may need to be -updated; new distributions of this software should come with an updated -list but it is still the responsibility of the Administrator to check -that this list is correct. +This is a global file searched in the sysconf first and then in the data +directory (e.g. @file{@value{SYSCONFDIR}/qualified.txt} + at file{@value{DATADIR}/qualified.txt}). GnuPG installs a suitable file with +root certificates as used in Germany. As new Root-CA certificates may be +issued over time, these entries may need to be updated; new distributions +of this software should come with an updated list but it is still the +responsibility of the Administrator to check that this list is correct. Every time @command{gpgsm} uses a certificate for signing or verification this file will be consulted to check whether the certificate under diff --git a/sm/qualified.c b/sm/qualified.c index 564e779..fe5567a 100644 --- a/sm/qualified.c +++ b/sm/qualified.c @@ -52,20 +52,37 @@ read_list (char *key, char *country, int *lnr) gpg_error_t err; int c, i, j; char *p, line[256]; + char *listname_candidate; *key = 0; *country = 0; if (!listname) { - listname = make_filename (gnupg_datadir (), "qualified.txt", NULL); - listfp = fopen (listname, "r"); + listname_candidate = make_filename (gnupg_sysconfdir (), "qualified.txt", NULL); + listfp = fopen (listname_candidate, "r"); if (!listfp && errno != ENOENT) { + xfree (listname_candidate); err = gpg_error_from_syserror (); - log_error (_("can't open '%s': %s\n"), listname, gpg_strerror (err)); + log_error (_("can't open '%s': %s\n"), listname_candidate, gpg_strerror (err)); return err; } + + if (!listfp) + { + listname_candidate = make_filename (gnupg_datadir (), "qualified.txt", NULL); + listfp = fopen (listname_candidate, "r"); + if (!listfp && errno != ENOENT) + { + xfree (listname_candidate); + err = gpg_error_from_syserror (); + log_error (_("can't open '%s': %s\n"), listname_candidate, gpg_strerror (err)); + return err; + } + } + + listname = listname_candidate; } if (!listfp) -- 2.13.5 From wk at gnupg.org Fri Sep 1 12:39:00 2017 From: wk at gnupg.org (Werner Koch) Date: Fri, 01 Sep 2017 12:39:00 +0200 Subject: [PATCH GNUPG] sm: Search for qualified.txt at sysconfdir first In-Reply-To: <20170901062449.32475-1-alon.barlev@gmail.com> (Alon Bar-Lev's message of "Fri, 1 Sep 2017 09:24:49 +0300") References: <20170901062449.32475-1-alon.barlev@gmail.com> Message-ID: <87ziaebt4r.fsf@wheatstone.g10code.de> On Fri, 1 Sep 2017 08:24, alon.barlev at gmail.com said: > The qualified.txt may be modified by the Administrator, hence this > artifact is a configuration. A product may provide sane defaults, > however, it should be possible for the Administrator to manage The idea behind the qualified.txt is to cope with German signature law which originally demanded that all valid root certificates are at least registered at a federal agency (Bundesnetzagentur). So this should be a pretty static thing and could be updated by updating the gnupg package. Later it turned out that getting hold of the actual list is in a secure way is impossible. For example calling the support desk of one of the CA to ask for verification of the root certificate's fingerprint ended up in the support person reading to me the very same website I had in front of me - a web site I had directed that person to. I conclude that this whole system is entirely bogus and, for other reasons; limited also by the the security of https certificates. Enough of a rant. Given that the current qualified.txt has only expired certificates and I do not want to maintain this file anymore, I think it is better to move this entirely to sysconfdir and have no fallback. So we would distribute only an explample explaining the format. What do you think? 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 dirkx at webweaving.org Fri Sep 1 13:19:23 2017 From: dirkx at webweaving.org (Dirk-Willem van Gulik) Date: Fri, 1 Sep 2017 13:19:23 +0200 Subject: [PATCH GNUPG] sm: Search for qualified.txt at sysconfdir first In-Reply-To: <87ziaebt4r.fsf@wheatstone.g10code.de> References: <20170901062449.32475-1-alon.barlev@gmail.com> <87ziaebt4r.fsf@wheatstone.g10code.de> Message-ID: On 1 Sep 2017, at 12:39, Werner Koch wrote: > On Fri, 1 Sep 2017 08:24, alon.barlev at gmail.com said: > >> The qualified.txt may be modified by the Administrator, hence this >> artifact is a configuration. A product may provide sane defaults, >> however, it should be possible for the Administrator to manage > > The idea behind the qualified.txt is to cope with German signature law > which originally demanded that all valid root certificates are at least > registered at a federal agency (Bundesnetzagentur). So this should be a > pretty static thing and could be updated by updating the gnupg package. > Later it turned out that getting hold of the actual list is in a secure > way is impossible. For example calling the support desk of one of the > CA to ask for verification of the root certificate's fingerprint ended > up in the support person reading to me the very same website I had in > front of me - a web site I had directed that person to. I conclude that > this whole system is entirely bogus and, for other reasons; limited also > by the the security of https certificates. FWIIW - and limiting this to Germany - I?ve had considerable more luck with the Bundesambt for Sicherheir in der Informationstechnik (BSI) and extracting lists from the Bundesnetzagentur via that route. So that may be worth a try - especially as one establshed - things work like clock work for years. Mind you - these were *context* specific lists (e.g. for the Artz ausweiss) - rather than the sort of generic one needed by GPG. I suspect that the ?trust is not transitive? issue may get in the way for the latter. Dw. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 223 bytes Desc: Message signed with OpenPGP URL: From alon.barlev at gmail.com Fri Sep 1 14:19:34 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Fri, 1 Sep 2017 15:19:34 +0300 Subject: [PATCH GNUPG] sm: Search for qualified.txt at sysconfdir first In-Reply-To: <87ziaebt4r.fsf@wheatstone.g10code.de> References: <20170901062449.32475-1-alon.barlev@gmail.com> <87ziaebt4r.fsf@wheatstone.g10code.de> Message-ID: On 1 September 2017 at 13:39, Werner Koch wrote: > On Fri, 1 Sep 2017 08:24, alon.barlev at gmail.com said: > Given that the current qualified.txt has only expired certificates and I > do not want to maintain this file anymore, I think it is better to move > this entirely to sysconfdir and have no fallback. So we would > distribute only an explample explaining the format. > > What do you think? No problem... I will prepare a patch. What about backward compatibility? Will announcement be enough? Thanks! From wk at gnupg.org Fri Sep 1 20:08:19 2017 From: wk at gnupg.org (Werner Koch) Date: Fri, 01 Sep 2017 20:08:19 +0200 Subject: [PATCH GNUPG] sm: Search for qualified.txt at sysconfdir first In-Reply-To: (Alon Bar-Lev's message of "Fri, 1 Sep 2017 15:19:34 +0300") References: <20170901062449.32475-1-alon.barlev@gmail.com> <87ziaebt4r.fsf@wheatstone.g10code.de> Message-ID: <87o9qub8bw.fsf@wheatstone.g10code.de> On Fri, 1 Sep 2017 14:19, alon.barlev at gmail.com said: > No problem... I will prepare a patch. Thanks. > What about backward compatibility? Will announcement be enough? I has to go to the new development branch anyway and thus some minor chnages are not a real problem. In particular in this case. 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 Sep 1 20:14:12 2017 From: wk at gnupg.org (Werner Koch) Date: Fri, 01 Sep 2017 20:14:12 +0200 Subject: [PATCH GNUPG] sm: Search for qualified.txt at sysconfdir first In-Reply-To: (Dirk-Willem van Gulik's message of "Fri, 1 Sep 2017 13:19:23 +0200") References: <20170901062449.32475-1-alon.barlev@gmail.com> <87ziaebt4r.fsf@wheatstone.g10code.de> Message-ID: <87k21ib823.fsf@wheatstone.g10code.de> On Fri, 1 Sep 2017 13:19, dirkx at webweaving.org said: > FWIIW - and limiting this to Germany - I?ve had considerable more luck with the Bundesambt for Sicherheir in der Informationstechnik (BSI) and extracting lists from the Bundesnetzagentur via that route. So that may be worth a try - especially as one establshed - things work like clock work for years. Frankly, I am not really interested in getting GnuPG approbated as qualified signature processing software. Those who want to this can relatively easily create a fork. ./configure can easily be used to change the displayed name of GnuPG. 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 alon.barlev at gmail.com Fri Sep 1 21:19:26 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Fri, 1 Sep 2017 22:19:26 +0300 Subject: [PATCH GNUPG] sm: Move qualified.txt from datadir into sysconfdir In-Reply-To: <87o9qub8bw.fsf@wheatstone.g10code.de> References: <87o9qub8bw.fsf@wheatstone.g10code.de> Message-ID: <20170901191926.6408-1-alon.barlev@gmail.com> * doc/Makefile.am: Move qualified.txt into examples. * doc/qualified.txt: Move into examples, remove trailing spaces. * doc/examples/README: Document qualified.txt. * doc/gpgsm.texi: Move qualified.txt from datadir into sysconfdir. * sm/qualified.c (read_list): Move qualified.txt from datadir into sysconfdir. -- The qualified.txt is maintained by Administrator it is a configuration file. In the past it was a hybrid, provided by package and controlled by the Administrator, however, it is no longer maintained by package. Signed-off-by: Alon Bar-Lev --- doc/Makefile.am | 4 ++-- doc/examples/README | 2 ++ doc/{ => examples}/qualified.txt | 12 ++++++------ doc/gpgsm.texi | 12 +++--------- sm/qualified.c | 2 +- 5 files changed, 14 insertions(+), 18 deletions(-) rename doc/{ => examples}/qualified.txt (98%) diff --git a/doc/Makefile.am b/doc/Makefile.am index 89079b3..c0c7fd0 100644 --- a/doc/Makefile.am +++ b/doc/Makefile.am @@ -22,7 +22,7 @@ AM_CPPFLAGS = include $(top_srcdir)/am/cmacros.am examples = examples/README examples/scd-event examples/trustlist.txt \ - examples/vsnfd.prf examples/debug.prf \ + examples/vsnfd.prf examples/debug.prf examples/qualified.txt \ examples/systemd-user/README \ examples/systemd-user/dirmngr.service \ examples/systemd-user/dirmngr.socket \ @@ -43,7 +43,7 @@ helpfiles = help.txt help.be.txt help.ca.txt help.cs.txt \ profiles = -EXTRA_DIST = samplekeys.asc mksamplekeys com-certs.pem qualified.txt \ +EXTRA_DIST = samplekeys.asc mksamplekeys com-certs.pem \ gnupg-logo.eps gnupg-logo.pdf gnupg-logo.png gnupg-logo-tr.png \ gnupg-module-overview.png gnupg-module-overview.pdf \ gnupg-card-architecture.png gnupg-card-architecture.pdf \ diff --git a/doc/examples/README b/doc/examples/README index 77ee807..4d6a5be 100644 --- a/doc/examples/README +++ b/doc/examples/README @@ -9,3 +9,5 @@ trustlist.txt A list of trustworthy root certificates gpgconf.conf A sample configuration file for gpgconf. systemd-user Sample files for a Linux-only init system. + +qualified.txt Sample file for qualified.txt. diff --git a/doc/qualified.txt b/doc/examples/qualified.txt similarity index 98% rename from doc/qualified.txt rename to doc/examples/qualified.txt index c0e4da5..eba11f2 100644 --- a/doc/qualified.txt +++ b/doc/examples/qualified.txt @@ -29,7 +29,7 @@ # # Germany # -# The information for Germany is available +# The information for Germany is available # at http://www.bundesnetzagentur.de #******************************************* @@ -74,7 +74,7 @@ DB:45:3D:1B:B0:1A:F3:23:10:6B:DE:D0:09:61:57:AA:F4:25:E0:5B de #Serial number: 02 # Issuer: /CN=9R-CA 1:PN/O=Regulierungsbeh?rde f?r # Telekommunikation und Post/C=DE -# Subject: /CN=9R-CA 1:PN/O=Regulierungsbeh?rde f?r +# Subject: /CN=9R-CA 1:PN/O=Regulierungsbeh?rde f?r # Telekommunikation und Post/C=DE # validity: 2004-11-25 14:59:11 through 2007-12-31 14:56:59 # key type: 1024 bit RSA @@ -118,7 +118,7 @@ A0:8B:DF:3B:AA:EE:3F:9D:64:6C:47:81:23:21:D4:A6:18:81:67:1D de # key usage: certSign # policies: 1.3.36.8.1.1:N: # chain length: unlimited -# [checked: 2008-06-25] +# [checked: 2008-06-25] 44:7E:D4:E3:9A:D7:92:E2:07:FA:53:1A:2E:F5:B8:02:5B:47:57:B0 de # ID: 0x46A2CC8A @@ -130,7 +130,7 @@ A0:8B:DF:3B:AA:EE:3F:9D:64:6C:47:81:23:21:D4:A6:18:81:67:1D de # key usage: certSign # policies: 1.3.36.8.1.1:N: # chain length: unlimited -# [checked: 2008-06-25] +# [checked: 2008-06-25] AC:A7:BE:45:1F:A6:BF:09:F2:D1:3F:08:7B:BC:EB:7F:46:A2:CC:8A de @@ -215,7 +215,7 @@ E0:BF:1B:91:91:6B:88:E4:F1:15:92:22:CE:37:23:96:B1:4A:2E:5C de # key type: 2048 bit RSA # key usage: certSign crlSign # chain length: 1 -#[checked: 2007-12-13 via received ZIP file with qualified signature from +#[checked: 2007-12-13 via received ZIP file with qualified signature from # /CN=Dr. Matthias Stehle/O=Deutscher Sparkassenverlag # /C=DE/SerialNumber=DSV0000000008/SN=Stehle/GN=Matthias Georg] C9:2F:E6:50:DB:32:59:E0:CE:65:55:F3:8C:76:E0:B8:A8:FE:A3:CA de @@ -230,7 +230,7 @@ C9:2F:E6:50:DB:32:59:E0:CE:65:55:F3:8C:76:E0:B8:A8:FE:A3:CA de # key type: 2048 bit RSA # key usage: certSign crlSign # chain length: 1 -#[checked: 2007-12-13 via received ZIP file with qualified signature from +#[checked: 2007-12-13 via received ZIP file with qualified signature from # /CN=Dr. Matthias Stehle/O=Deutscher Sparkassenverlag # /C=DE/SerialNumber=DSV0000000008/SN=Stehle/GN=Matthias Georg"] D5:C7:50:F2:FE:4E:EE:D7:C7:B1:E4:13:7B:FB:54:84:3A:7D:97:9B de diff --git a/doc/gpgsm.texi b/doc/gpgsm.texi index 5d79ce5..76ef58b 100644 --- a/doc/gpgsm.texi +++ b/doc/gpgsm.texi @@ -843,15 +843,9 @@ purposes. Note that even if a certificate is listed in this file, this does not mean that the certificate is trusted; in general the certificates listed -in this file need to be listed also in @file{trustlist.txt}. - -This is a global file an installed in the data directory -(e.g. @file{@value{DATADIR}/qualified.txt}). GnuPG installs a suitable -file with root certificates as used in Germany. As new Root-CA -certificates may be issued over time, these entries may need to be -updated; new distributions of this software should come with an updated -list but it is still the responsibility of the Administrator to check -that this list is correct. +in this file need to be listed also in @file{trustlist.txt}. This is a global +file an installed in the sysconf directory (e.g. + at file{@value{SYSCONFDIR}/qualified.txt}). Every time @command{gpgsm} uses a certificate for signing or verification this file will be consulted to check whether the certificate under diff --git a/sm/qualified.c b/sm/qualified.c index 564e779..6a7b473 100644 --- a/sm/qualified.c +++ b/sm/qualified.c @@ -58,7 +58,7 @@ read_list (char *key, char *country, int *lnr) if (!listname) { - listname = make_filename (gnupg_datadir (), "qualified.txt", NULL); + listname = make_filename (gnupg_sysconfdir (), "qualified.txt", NULL); listfp = fopen (listname, "r"); if (!listfp && errno != ENOENT) { -- 2.13.5 From aterik at outlook.com Fri Sep 1 19:44:35 2017 From: aterik at outlook.com (TErik Ashfolk) Date: Fri, 1 Sep 2017 17:44:35 +0000 Subject: libgcrypt 1.8.1 nPth Build Fails, macOS 10.12.6 Message-ID: Hi. libgcrypt 1.8.1, nPth build/compile fails in macOS 10.12.6 Sierra MBA. libgcrypt 1.8.0 was built fine in same machine. The "./configure" succeeds. But in "make", warning appears for global.c & gcrypt-testapi.h, case value not in enumerated type 'enum gcry_ctl_cmds'... And ERROR appears for /ur/local/include/pthread.h:286:42: typedef redefinition with different types ('struct pthread_attr_st *' vs '_darwin_pthread_attr_t'... Neither "./configire --disable-threads" or "./configure --enable-threads=no" worked/recognized ! :( Pth (pthread) native/local builds ok. nPth does not. And it seems, after i re-build Pth then some other src succeeds in build, otherwise not, So maybe something often replacing Pth libs?! Loaded Pth, nPth using MacPorts, but seems to have no affect. (i avoid using HomeBrew for their data-sharing anti-privacy policies). If i load the build related Env Vars which have dir locations of MacPorts & other libs, build-tools, etc, then build does not succeed often, so i kept build related Env Vars empty, but compile/build tools seems to be still able to locate necessary libs/headers without specifying into build Env Vars. btw, MacPorts' lib/include directories are different than native local build's lib/include dirs. afair, i attempt to build in these sequence: libgpg-error, libassuan, nPth/Pth, libksba, libgcrypt, ntbtls, gpgme, gnupg. gnupg-2.1.23 build succeeded ok, on same 10.12.6 Sierra, mba. let me know if/which info needed. thanks in advance. Erik. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnupg-devel at spodhuis.org Tue Sep 5 07:17:38 2017 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Tue, 5 Sep 2017 01:17:38 -0400 Subject: swdb.lst, gnupg21 and gnupg-2.2.0 Message-ID: <20170905051737.GA2512@breadbox.private.spodhuis.org> Folks, is this intended? gnupg21_ver 2.2.0 gnupg21_date 2017-08-28 I have build scripts creating packages for a couple of OS variants which I care about, using the "latest upstream", and testing the changes to dual-build gnupg21 and gnupg22 I was "somewhat perplexed" at the results until I tracked that down. gnupg22_ver 2.2.0 gnupg21_ver 2.2.0 gnupg20_ver 2.0.30 gnupg_ver 2.0.30 gnupg1_ver 1.4.22 I would naively expect that `gnupg21_ver` would refer to the last release in the 2.1.x series and that at some point in the future a `gnupg23_ver` entry would appear. If the above _is_ intended, then will `gnupg21` just be an alias for `gnupg22` in perpetuity? Thanks, -Phil -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 996 bytes Desc: Digital signature URL: From wk at gnupg.org Tue Sep 5 10:05:16 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 05 Sep 2017 10:05:16 +0200 Subject: GnuPG e.V. is looking for members Message-ID: <87d1758tab.fsf@wheatstone.g10code.de> Hi! back in February we founded the GnuPG e.V. (aka the Verein) which is a charitable German organization with the goal to foster data protection and help with the development of GnuPG. The idea is that the Verein will be the legal entity for the GnuPG project, so that my company can eventually step back from that. The founding members were Andre Heinecke, me, Yutaka Niibe, Justus Winter, Neal Walfied, Marcus Brinkmann, and Kai Michaelis. Soon Kristian Fiskerstrand and Daniel Kahn Gillmor joined us. The elected board are Andre, me, and Marcus. Unfortunately Marcus resigned as board member (he was treasurer) 4 weeks ago at the very time we planned to get the Verein actually alive. See the mail copied below. Although the original plan was to first discuss rules for membership, Andre and me agreed that we should invite active GnuPG people right now. If you contributed to GnuPG, be it code, documentation, user education, or whatever you think it makes you a contributor, please feel invited to apply for membership by sending mail to board at gnupg.org. We do not need a snail address, but it would be good if you at least tell us the city you are living and a permanent mail address. We expect an OpenPGP encrypted mail and some words on the kind of ypur activity. An English translation of our constitution is available at the Verein's repo: . Note that we will eventually propose the setup of a nominal membership fee (say 12 EUR/year) to satisfy demands from the tax office. Finally, we have a vacant position on the board which needs to be filled soonish. If anyone is interested to run for the position of the treasurer, please let us know. Being able to read German would be helpful; however, we plan to source out most of every day's work so that the job would require reading and writing some mails, attending telcos every now and then, and ink-signing a bunch of donation receipts in January. I would be glad to eventually see many active people from our community as members of the Verein. Shalom-Salam, Werner --8<---------------cut here---------------start------------->8--- From: Andre Heinecke Subject: Status update / planning for membership assembly To: verein at gnupg org Date: Thu, 03 Aug 2017 10:02:32 +0200 Hi, So it's been quiet here for quite a while. Time to get some activity :-) We (the Board) had a Meeting yesterday [1] to discuss how to move forward. Mostly we would like to discuss some topics (see below) on this mailing list and hold a first Membership assembly around FOSDEM next year (somewhere in February). Likely in D?sseldorf. So, the Verein now has a Bank Account, a postal address, a bitcoin wallet and some funds. Thanks to the Wau Holland Foundation the Verein obtained the funds which were donated to the Wau Holland Foundation for GnuPG since 2015. (~60k ?). Additionally the Verein got around 26 BTC [2] from the current fundraising campaign that was financed by and focused on g10code. That's the good news. Now we need to get this Verein really set up to do something. :-) While the assembly will be the ultimate place for decisions and discussions, we should probably try to prepare something and start to discuss topics beforehand. Some points that I think we need to discuss: - More concrete long / short term goals for the Verein apart from the general goals outlined in our constitution. - Resulting from that: How should we spend the funds we received (or will receive) and how do we control that the funds are spent according to our goals. - Membership rules -- Who should be accepted as a member? -- How do we want to concretly handle supporting members? -- Membership fees. -- How do we actually implement this, which infrastructure etc. - What our activities as a Verein (apart from collecting and spending money) should be, and who would like to contribute what. Feel free to propose / discuss anything else you think related, of course. Best Regards, Andre 1: https://dev.gnupg.org/T3301 2: https://blockchain.info/address/1EAw3RnaALKiES8Ap93SwwDx4fsoY12wzF --8<---------------cut here---------------end--------------->8--- -- 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 Sep 5 10:14:36 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 05 Sep 2017 10:14:36 +0200 Subject: swdb.lst, gnupg21 and gnupg-2.2.0 In-Reply-To: <20170905051737.GA2512@breadbox.private.spodhuis.org> (Phil Pennock's message of "Tue, 5 Sep 2017 01:17:38 -0400") References: <20170905051737.GA2512@breadbox.private.spodhuis.org> Message-ID: <877exd8sur.fsf@wheatstone.g10code.de> On Tue, 5 Sep 2017 07:17, gnupg-devel at spodhuis.org said: > I have build scripts creating packages for a couple of OS variants which > I care about, using the "latest upstream", and testing the changes to > dual-build gnupg21 and gnupg22 I was "somewhat perplexed" at the results Actually I tried to avoid any possible breakage by keeping gnupg21_ as an alias for gnupg22_. For example the older speedo build scripts used gnupg21_ and I expected that other scripts might to it similar. Here is a comment from swdb/mac, which is the source of swdb.lst: # temporary keep it as "gnupg21". In the future we will use the name of # the stable branch even for the development versions. There is also a new "gnupg20_" for the old stable branch with an alias of "gnupg_" because that is how we did it in the past. We will eventually remove those aliases. The next development branch will be 2.3 but its swdb prefix will be "gnupg24_". Sorry for the trouble but frankly I am glad to see that the swdb.lst is used beyond speedo.mk and the website. 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 Tue Sep 5 10:38:10 2017 From: aheinecke at intevation.de (Andre Heinecke) Date: Tue, 05 Sep 2017 10:38:10 +0200 Subject: swdb.lst, gnupg21 and gnupg-2.2.0 In-Reply-To: <877exd8sur.fsf@wheatstone.g10code.de> References: <20170905051737.GA2512@breadbox.private.spodhuis.org> <877exd8sur.fsf@wheatstone.g10code.de> Message-ID: <3075022.tvBRuhbrBG@esus> Hi, On Tuesday, September 5, 2017 10:14:36 AM CEST Werner Koch wrote: > On Tue, 5 Sep 2017 07:17, gnupg-devel at spodhuis.org said: > > > I have build scripts creating packages for a couple of OS variants which > > I care about, using the "latest upstream", and testing the changes to > > dual-build gnupg21 and gnupg22 I was "somewhat perplexed" at the results > > Actually I tried to avoid any possible breakage by keeping gnupg21_ as > an alias for gnupg22_. For example the older speedo build scripts used > gnupg21_ and I expected that other scripts might to it similar. > > Here is a comment from swdb/mac, which is the source of swdb.lst: > > # temporary keep it as "gnupg21". In the future we will use the name of > # the stable branch even for the development versions. IMO we should declare the swdb.lst as an internal format and request users to use gpgconf --query-swdb. With adding --homedir you can point it to an arbitrary directory containing an swdb.lst. This should be the stable interface and uses the common "with colons" output which is easier to parse and better to extend. This is also the way GPGME uses this. > There is also a new "gnupg20_" for the old stable branch with an alias > of "gnupg_" because that is how we did it in the past. We will > eventually remove those aliases. I think the following aliases would make sense to keep: gnupg_lts (for an lts branch, currently 2.2) gnupg (for the latest release, 2.3.0 in the future) gnupg1 (for gnupg 1.x) How we call them internally would then be up to us (provided we keep some compatibility with older gpgconf versions) Best 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: 228 bytes Desc: This is a digitally signed message part. URL: From gnupg-devel at spodhuis.org Tue Sep 5 17:45:40 2017 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Tue, 5 Sep 2017 11:45:40 -0400 Subject: swdb.lst, gnupg21 and gnupg-2.2.0 In-Reply-To: <3075022.tvBRuhbrBG@esus> References: <20170905051737.GA2512@breadbox.private.spodhuis.org> <877exd8sur.fsf@wheatstone.g10code.de> <3075022.tvBRuhbrBG@esus> Message-ID: <20170905154540.GA6184@breadbox.private.spodhuis.org> On 2017-09-05 at 10:38 +0200, Andre Heinecke wrote: > IMO we should declare the swdb.lst as an internal format and request users to > use gpgconf --query-swdb. Doesn't help when you're building the packages which would provide gpgconf and want to get and verify the current versions automatically. Ubuntu Xenial ships with `gpgconf (GnuPG) 2.1.11` which does not support the `--query-swdb` flag. That's the current Long Term Support release. Ubuntu Trusty is still supported until 2019, but ships with `gpgconf (GnuPG) 2.0.22` in its `gnupg2` package. The tooling I have is creating/maintaining packages which install into /opt/gnupg and leave the OS vendor's packages alone (to avoid breaking system scripts) while providing "current upstream with as few patches as possible" for Xenial, Trusty and Debian Jessie. So this is used in scripts run inside Vagrant-managed VMs to create the packages (with `fpm`) which end up at: https://public-packages.pennock.tech/ -Phil -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 996 bytes Desc: Digital signature URL: From wk at gnupg.org Wed Sep 6 09:27:37 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 06 Sep 2017 09:27:37 +0200 Subject: swdb.lst, gnupg21 and gnupg-2.2.0 In-Reply-To: <3075022.tvBRuhbrBG@esus> (Andre Heinecke's message of "Tue, 05 Sep 2017 10:38:10 +0200") References: <20170905051737.GA2512@breadbox.private.spodhuis.org> <877exd8sur.fsf@wheatstone.g10code.de> <3075022.tvBRuhbrBG@esus> Message-ID: <87vakw4786.fsf@wheatstone.g10code.de> On Tue, 5 Sep 2017 10:38, aheinecke at intevation.de said: > IMO we should declare the swdb.lst as an internal format and request users to > use gpgconf --query-swdb. With adding --homedir you can point it to an I see two problems with this approach: - Old versions of GnuPG may want to access the current swdb. How, an internal format, implicates that we can update it at will. Obviously older version of GnuPG can't cope with that. - The build-aux/getswdb.sh is used by the speedo build system. Thus dirmngr is not the only user of swdb, In general I agree that using dirmngr/gpgconf to access it is a better approach than to use one own's script. However, It will take some years until the new dirmngr will be in general use. IIRC, Debian even removed the automatic refresh and thus gpg-connect-agent needs to be used to trigger a refresh. > I think the following aliases would make sense to keep: > gnupg_lts (for an lts branch, currently 2.2) > gnupg (for the latest release, 2.3.0 in the future) > gnupg1 (for gnupg 1.x) We could implement this as aliases in gpgconf but I doubt that this is a general solution: Switching to a newer major version (technical minor version number, like 2.2. to 2.4) may require more than a simple software update. BTW, we already have two aliases implemented in gpgcponf: if (!strcmp (name, "gnupg")) search_name = GNUPG_SWDB_TAG; /* current value is "gnupg22" */ else if (!strcmp (name, "gnupg1")) search_name = "gnupg1"; else search_name = name; 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 Sep 6 17:10:10 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 06 Sep 2017 17:10:10 +0200 Subject: GnuPG defaults: changing back to --no-auto-key-retrieve In-Reply-To: (Patrick Brunschwig's message of "Sat, 12 Aug 2017 12:17:48 +0200") References: <87shgxmzjl.fsf@fifthhorseman.net> Message-ID: <87k21bzwvh.fsf@wheatstone.g10code.de> Hi Patrick, On Sat, 12 Aug 2017 12:17, patrick at enigmail.net said: > same concerns that you you raised here - I implemented functionality in > Enigmail to add --no-auto-key-retrieve to all commands if gpg 2.1.23 or > newer is detected (and the user did not explicitly opt in to can you change this so that it is only done for 2.1.23? We reverted this in 2.2.0 and explicitly overriding this in Enigmail makes changes to the gpg.conf surprising. For example. Kmail and Enigaml will behave different. We just had some fun in a presentation ;-) 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 Sep 6 23:33:18 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 06 Sep 2017 23:33:18 +0200 Subject: Importing ed25519 subkeys from SKS < 1.1.6 Message-ID: <87fubzzf4x.fsf@wheatstone.g10code.de> Hi! while doing a presentation which includes showing the effect of --auto-key-retrieve, I got hit by a gpg: key F2AD85AC1E42B367: rejected by import screener That is my own key! Here I tried to verify a signature made with my ed25519 subkey. gpg then asked the keyserver to return the key for that subkey by sending this to dirmngr: KS_GET --quick -- 0xD7FFC063B40A2294B966DB47FF80AE9D1DEC358D The keyserver (SKS 1.1.5) returned the corresponding main key 80615870F5BAD690333686D0F2AD85AC1E42B367 including all of the RSA and DSA subkeys. But not the original requested ed25519 key. It seems SKS 1.1.5 partly supports ed25519 keys but for example does not return them. Hopefully the remaining SKS 1.1.5 installations will soon update to 1.1.6 which does not have this 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 kristian.fiskerstrand at sumptuouscapital.com Wed Sep 6 23:46:59 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 6 Sep 2017 23:46:59 +0200 Subject: Importing ed25519 subkeys from SKS < 1.1.6 In-Reply-To: <87fubzzf4x.fsf@wheatstone.g10code.de> References: <87fubzzf4x.fsf@wheatstone.g10code.de> Message-ID: <65354c8a-61ce-9d9d-aa49-d4ebbf755e60@sumptuouscapital.com> On 09/06/2017 11:33 PM, Werner Koch wrote: > including all of the RSA and DSA subkeys. But not the original > requested ed25519 key. It seems SKS 1.1.5 partly supports ed25519 keys > but for example does not return them. No, 1.1.5 supports RFC6637 but not the ed25519/curve25519 variants > Hopefully the remaining SKS 1.1.5 installations will soon update to > 1.1.6 which does not have this problem. hkp://subset.pool.sks-keyservers.net requires SKS 1.1.6, I've been pondering requiring the main pool to use this , which can be discussed if we want to push ed25510/curve25519 that said, you can download the full key using &clean=off in the query to keyservers, as that removes any filtering by trying to read the packets of the keyservers for SKS < 1.1.6. http://pgp.mit.edu:11371/pks/lookup?op=get&options=mr&clean=off&search=0xD7FFC063B40A2294B966DB47FF80AE9D1DEC358D -- ---------------------------- 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 ---------------------------- Aquila non capit muscas The eagle does not hunt flies -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Thu Sep 7 00:10:18 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Thu, 7 Sep 2017 00:10:18 +0200 Subject: Importing ed25519 subkeys from SKS < 1.1.6 In-Reply-To: <65354c8a-61ce-9d9d-aa49-d4ebbf755e60@sumptuouscapital.com> References: <87fubzzf4x.fsf@wheatstone.g10code.de> <65354c8a-61ce-9d9d-aa49-d4ebbf755e60@sumptuouscapital.com> Message-ID: On 09/06/2017 11:46 PM, Kristian Fiskerstrand wrote: > hkp://subset.pool.sks-keyservers.net requires SKS 1.1.6, I've been > pondering requiring the main pool to use this , which can be discussed > if we want to push ed25510/curve25519 I've just increased the min requirement to 1.1.6 for the main pool, so this should not be an issue any longer -- ---------------------------- 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 ---------------------------- "If the facts don't fit the theory, change the facts" (Albert Einstein) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Thu Sep 7 00:16:38 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 06 Sep 2017 18:16:38 -0400 Subject: Raising the floor for the pool to SKS version 1.1.6 [was: Re: Importing ed25519 subkeys from SKS < 1.1.6] In-Reply-To: <65354c8a-61ce-9d9d-aa49-d4ebbf755e60@sumptuouscapital.com> References: <87fubzzf4x.fsf@wheatstone.g10code.de> <65354c8a-61ce-9d9d-aa49-d4ebbf755e60@sumptuouscapital.com> Message-ID: <878thra2wp.fsf@fifthhorseman.net> (adding sks-devel to this thread since it discussies changing the minimum bar for the pool) On Wed 2017-09-06 23:46:59 +0200, Kristian Fiskerstrand wrote: > On 09/06/2017 11:33 PM, Werner Koch wrote: > >> including all of the RSA and DSA subkeys. But not the original >> requested ed25519 key. It seems SKS 1.1.5 partly supports ed25519 keys >> but for example does not return them. > > No, 1.1.5 supports RFC6637 but not the ed25519/curve25519 variants > >> Hopefully the remaining SKS 1.1.5 installations will soon update to >> 1.1.6 which does not have this problem. > > hkp://subset.pool.sks-keyservers.net requires SKS 1.1.6, I've been > pondering requiring the main pool to use this , which can be discussed > if we want to push ed25510/curve25519 SKS 1.1.6 was released over 1 year ago (on 2016-08-07). It is well tested and widely deployed. looking at https://sks-keyservers.net/status/ -- i'd say we can afford to move to SKS 1.1.6 for the main pool. We will (temporarily) go from 116 members of the main pool to 85 -- a loss of about 25%. But we also provide an incentive for those members to upgrade to 1.1.6, so i expect we'll make some of that back. We only lose 3 members from the hkps pool, and 2 members from the onionbalance, so i'd recommend making it a minimum there too. About feasibility of upgrades: version-wise, people tend to treat debian as the "old, out of date distro", and for debian: * Debian stable (stretch) has SKS 1.1.6. * people running debian oldstable (jessie) can install 1.1.6 from jessie-backports. People running keyservers on ubuntu LTS will need to find a PPA or some other alternative (xenial offers only 1.1.5 in universe), but so it goes :/ (I note that a previous attempt to get a backport into an ubuntu LTS appears to have gone unresolved: https://bugs.launchpad.net/trusty-backports/+bug/1435397 -- but perhaps micahg can be convinced to update his ppa in a similar way at least) I recommend requiring at least SKS 1.1.6 for membership in all the pools. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From kristian.fiskerstrand at sumptuouscapital.com Thu Sep 7 00:33:51 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Thu, 7 Sep 2017 00:33:51 +0200 Subject: Raising the floor for the pool to SKS version 1.1.6 [was: Re: Importing ed25519 subkeys from SKS < 1.1.6] In-Reply-To: <878thra2wp.fsf@fifthhorseman.net> References: <87fubzzf4x.fsf@wheatstone.g10code.de> <65354c8a-61ce-9d9d-aa49-d4ebbf755e60@sumptuouscapital.com> <878thra2wp.fsf@fifthhorseman.net> Message-ID: <608e43cb-51ca-8550-3019-54aaa9880d78@sumptuouscapital.com> On 09/07/2017 12:16 AM, Daniel Kahn Gillmor wrote: 4 > We will (temporarily) go from 116 members of the main pool to 85 -- a > loss of about 25%. But we also provide an incentive for those members > to upgrade to 1.1.6, so i expect we'll make some of that back. > > We only lose 3 members from the hkps pool, and 2 members from the > onionbalance, so i'd recommend making it a minimum there too. > Yup, already executed, and with a few renewals of HKPS executed for 1.1.6 servers we're net -1 on HKPS. > > I recommend requiring at least SKS 1.1.6 for membership in all the > pools. already done -- ---------------------------- 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 ---------------------------- "I disapprove of what you say, but I will defend to the death your right to say it." Evelyn Beatrice Hall (summarizing Voltaire -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Thu Sep 7 00:41:53 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Thu, 7 Sep 2017 00:41:53 +0200 Subject: Raising the floor for the pool to SKS version 1.1.6 [was: Re: Importing ed25519 subkeys from SKS < 1.1.6] In-Reply-To: <878thra2wp.fsf@fifthhorseman.net> References: <87fubzzf4x.fsf@wheatstone.g10code.de> <65354c8a-61ce-9d9d-aa49-d4ebbf755e60@sumptuouscapital.com> <878thra2wp.fsf@fifthhorseman.net> Message-ID: <376ce0d3-af46-331c-075b-0421e31dfc9d@sumptuouscapital.com> On 09/07/2017 12:16 AM, Daniel Kahn Gillmor wrote: > We only lose 3 members from the hkps pool, and 2 members from the > onionbalance, so i'd recommend making it a minimum there too. Just for clarification, main pool will always be a superset of both HKPS and onionbalance, so any increase in requirement in main pool will automatically affect the subpools. -- ---------------------------- 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 ---------------------------- Aquila non capit muscas The eagle does not hunt flies -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From patrick at enigmail.net Thu Sep 7 08:36:57 2017 From: patrick at enigmail.net (Patrick Brunschwig) Date: Thu, 7 Sep 2017 08:36:57 +0200 Subject: GnuPG defaults: changing back to --no-auto-key-retrieve In-Reply-To: <87k21bzwvh.fsf@wheatstone.g10code.de> References: <87shgxmzjl.fsf@fifthhorseman.net> <87k21bzwvh.fsf@wheatstone.g10code.de> Message-ID: On 06.09.17 17:10, Werner Koch wrote: > Hi Patrick, > > On Sat, 12 Aug 2017 12:17, patrick at enigmail.net said: > >> same concerns that you you raised here - I implemented functionality in >> Enigmail to add --no-auto-key-retrieve to all commands if gpg 2.1.23 or >> newer is detected (and the user did not explicitly opt in to > > can you change this so that it is only done for 2.1.23? > > We reverted this in 2.2.0 and explicitly overriding this in Enigmail > makes changes to the gpg.conf surprising. For example. Kmail and > Enigaml will behave different. We just had some fun in a presentation ;-) That's interesting. I reverted the change entirely on Aug. 21. That is, it's not in the latest Enigmail release v1.9.8.2, nor in nightly builds since then. -Patrick From wk at gnupg.org Thu Sep 7 09:18:22 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 Sep 2017 09:18:22 +0200 Subject: Importing ed25519 subkeys from SKS < 1.1.6 In-Reply-To: <65354c8a-61ce-9d9d-aa49-d4ebbf755e60@sumptuouscapital.com> (Kristian Fiskerstrand's message of "Wed, 6 Sep 2017 23:46:59 +0200") References: <87fubzzf4x.fsf@wheatstone.g10code.de> <65354c8a-61ce-9d9d-aa49-d4ebbf755e60@sumptuouscapital.com> Message-ID: <87zia7x9hd.fsf@wheatstone.g10code.de> On Wed, 6 Sep 2017 23:46, kristian.fiskerstrand at sumptuouscapital.com said: > that said, you can download the full key using &clean=off in the query > to keyservers, as that removes any filtering by trying to read the Okay, that explains the behaviour. Thanks for updating the pools. 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 Sep 7 09:55:21 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 Sep 2017 09:55:21 +0200 Subject: GnuPG defaults: changing back to --no-auto-key-retrieve In-Reply-To: (Patrick Brunschwig's message of "Thu, 7 Sep 2017 08:36:57 +0200") References: <87shgxmzjl.fsf@fifthhorseman.net> <87k21bzwvh.fsf@wheatstone.g10code.de> Message-ID: <87tw0fx7rq.fsf@wheatstone.g10code.de> On Thu, 7 Sep 2017 08:36, patrick at enigmail.net said: > That's interesting. I reverted the change entirely on Aug. 21. That is, > it's not in the latest Enigmail release v1.9.8.2, nor in nightly builds Right, Kai meanwhile told me that too. I found the real cuplrit in the 1.1.5 SKS keyservers. Sorry for the trouble. 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 deloptes at gmail.com Sat Sep 9 23:09:37 2017 From: deloptes at gmail.com (deloptes) Date: Sat, 9 Sep 2017 23:09:37 +0200 Subject: pinentry In-Reply-To: <26f6889f-dd4f-0547-bdbd-7dc68a02987b@incenp.org> References: <26f6889f-dd4f-0547-bdbd-7dc68a02987b@incenp.org> Message-ID: Hi Damien, thank you for the answer - unfortunately your reply landed in the spam ( (c)by google). Good that I checked it now. In case you are not aware, there is a project called "Trinity Desktop Environment" (TDE). It maintains the old KDE3 code in favor of many users that like simplicity and stability. Now our problem is that since Qt5 came out pinentry-qt is based on Qt5, while it was based on Qt3 before. In the meantime TDE team changed Qt3 to TQt3. So I spent some time to port the old pinentry-qt3 to the TQt3 code and make it work. I think and would love to see it as part of the code under the name of pinentry-tqt. I just can't/ am not able to do all needed changes to the autotools part. I hope someone from your end could accept the modified source code and integrate it as conditional build, so that TDE can easily provide its own packages with pinentry-tqt based on the official code. Sorry if I do not use the proper terminology to describe my goal and query. thanks in advance regards On Sun, Aug 20, 2017 at 5:19 PM, Damien Goutte-Gattat < dgouttegattat at incenp.org> wrote: > On 08/20/2017 02:33 AM, deloptes wrote: > >> I have a request to the pinentry developers. Where is the right place to >> ask? >> > > Well, you found it. :) This list is for development-related discussions > about GnuPG and most of its components, including Pinentries (except > Libgcrypt, which has its own dedicated mailing-list gcrypt-devel). > > Alternatively, if you already have a precise feature request in mind, you > may open a new ticket (tagged with the "Pinentry" label) in the GnuPG bug > tracker [1]. But it is usually best to discuss it here beforehand. > > Damien > > [1] https://bugs.gnupg.org/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gniibe at fsij.org Tue Sep 12 07:59:46 2017 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 12 Sep 2017 14:59:46 +0900 Subject: expiration time in ISO-8801 format Message-ID: <87h8w8xxrh.fsf@iwagami.gniibe.org> Hello, I'm trying to fix this issue: https://dev.gnupg.org/T3278 When a user specify expiration date and time by ISO-8801, GnuPG currently interprets as UTC, which is not as same as ISO-8801 interpretation. In ISO-8801, time is interpreted as local time if there is no "Z" or timezone. I think that GnuPG should be fixed, following the interpretation of ISO-8801. Perhaps, it is better to modify in multiple steps. If so, it's like these steps: (1) Firstly, modify GnuPG to accept format with timezone ("Z", and possibly +hh:mm, +hhmm, +hh or -hh:mm, -hhmm, and -hh). Time with no timezone will be interpreted as local time, as before. (2) Secondly (after some releases?), modify GnuPG to output its data always with "Z". (3) Thirdly (after some more releases?), modify GnuPG to interpret time with no timezone as UTC. Existing scripts and programs will be needed to change if it assume local time. And, since gpg-agent stores privete key with protected-at attribute by ISO timestamp, modification affects passphrase expiration time. While looking around the code, the deepest one is in libksba. Here is to show fixing libksba, (1) partially, (2), (3) at once. -- diff --git a/src/certreq.c b/src/certreq.c index 46fca44..575ca9d 100644 --- a/src/certreq.c +++ b/src/certreq.c @@ -747,7 +747,7 @@ build_cri (ksba_certreq_t cr) *tp++ = 15; if (cr->x509.not_before[0]) { - if (_ksba_cmp_time (cr->x509.not_before, "20500101T000000") >= 0) + if (_ksba_cmp_time (cr->x509.not_before, "20500101T000000Z") >= 0) { memcpy (tp, cr->x509.not_before, 8); tp += 8; @@ -777,7 +777,7 @@ build_cri (ksba_certreq_t cr) *tp++ = 15; if (cr->x509.not_after[0]) { - if (_ksba_cmp_time (cr->x509.not_after, "20500101T000000") >= 0) + if (_ksba_cmp_time (cr->x509.not_after, "20500101T000000Z") >= 0) { memcpy (tp, cr->x509.not_after, 8); tp += 8; diff --git a/src/der-encoder.c b/src/der-encoder.c index 9592123..71eeb4e 100644 --- a/src/der-encoder.c +++ b/src/der-encoder.c @@ -261,11 +261,11 @@ _ksba_der_store_time (AsnNode node, const ksba_isotime_t atime) return err; memcpy (buf, atime, 8); - memcpy (buf+8, atime+9, 6); + memcpy (buf+8, atime+9, 6); /* Also accept format with no 'Z'. */ strcpy (buf+14, "Z"); /* We need to use generalized time beginning with the year 2050. */ - need_gen = (_ksba_cmp_time (atime, "20500101T000000") >= 0); + need_gen = (_ksba_cmp_time (atime, "20500101T000000Z") >= 0); if (node->type == TYPE_ANY) node->type = need_gen? TYPE_GENERALIZED_TIME : TYPE_UTC_TIME; diff --git a/src/ksba.h b/src/ksba.h index 955dc06..cb5d441 100644 --- a/src/ksba.h +++ b/src/ksba.h @@ -150,9 +150,8 @@ typedef enum ksba_key_usage_t; typedef ksba_key_usage_t KsbaKeyUsage _KSBA_DEPRECATED; -/* ISO format, e.g. "19610711T172059", assumed to be UTC. */ -typedef char ksba_isotime_t[16]; - +/* ISO format, e.g. "19610711T172059Z" in UTC. */ +typedef char ksba_isotime_t[17]; /* X.509 certificates are represented by this object. ksba_cert_new() creates such an object */ diff --git a/src/time.c b/src/time.c index d793476..cb4767b 100644 --- a/src/time.c +++ b/src/time.c @@ -91,13 +91,14 @@ _ksba_asntime_to_iso (const char *buffer, size_t length, int is_utctime, { memcpy (timebuf+9, s, 6); } - timebuf[15] = 0; + timebuf[15] = 'Z'; + timebuf[16] = 0; return 0; } -/* Return 0 if ATIME has the proper format (e.g. "19660205T131415"). */ +/* Return 0 if ATIME has the proper format (e.g. "19660205T131415Z"). */ gpg_error_t _ksba_assert_time_format (const ksba_isotime_t atime) { @@ -111,12 +112,15 @@ _ksba_assert_time_format (const ksba_isotime_t atime) if (!digitp (s)) return gpg_error (GPG_ERR_BUG); if (*s != 'T') - return gpg_error (GPG_ERR_BUG); + return gpg_error (GPG_ERR_BUG); for (s++, i=9; i < 15; i++, s++) if (!digitp (s)) return gpg_error (GPG_ERR_BUG); - if (*s) - return gpg_error (GPG_ERR_BUG); + if (*s == 0) + /* For backward compatibility, accept format with no 'Z' at the end. */ + return 0; + else if (*s++ != 'Z' || *s) + return gpg_error (GPG_ERR_BUG); return 0; } @@ -127,14 +131,17 @@ void _ksba_copy_time (ksba_isotime_t d, const ksba_isotime_t s) { if (!*s) - memset (d, 0, 16); + memset (d, 0, 17); else if ( _ksba_assert_time_format (s) ) { fprintf (stderr, "BUG: invalid isotime buffer\n"); abort (); } else - strcpy (d, s); + { + strncpy (d, s, 16); + d[16] = 'Z'; + } } @@ -144,7 +151,7 @@ _ksba_copy_time (ksba_isotime_t d, const ksba_isotime_t s) int _ksba_cmp_time (const ksba_isotime_t a, const ksba_isotime_t b) { - return strcmp (a, b); + return strncmp (a, b, 16); } /* Fill the TIMEBUF with the current time (UTC of course). */ @@ -160,7 +167,7 @@ _ksba_current_time (ksba_isotime_t timebuf) #else tp = gmtime ( &epoch ); #endif - sprintf (timebuf,"%04d%02d%02dT%02d%02d%02d", + sprintf (timebuf, "%04d%02d%02dT%02d%02d%02dZ", 1900 + tp->tm_year, tp->tm_mon+1, tp->tm_mday, tp->tm_hour, tp->tm_min, tp->tm_sec); } diff --git a/tests/t-common.h b/tests/t-common.h index cf82f3e..bd6db69 100644 --- a/tests/t-common.h +++ b/tests/t-common.h @@ -225,5 +225,5 @@ print_time (ksba_isotime_t t) if (!t || !*t) fputs ("none", stdout); else - printf ("%.4s-%.2s-%.2s %.2s:%.2s:%s", t, t+4, t+6, t+9, t+11, t+13); + printf ("%.4s-%.2s-%.2s %.2s:%.2s:%.2s", t, t+4, t+6, t+9, t+11, t+13); } ================ From wk at gnupg.org Tue Sep 12 09:01:35 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 12 Sep 2017 09:01:35 +0200 Subject: expiration time in ISO-8801 format In-Reply-To: <87h8w8xxrh.fsf@iwagami.gniibe.org> (NIIBE Yutaka's message of "Tue, 12 Sep 2017 14:59:46 +0900") References: <87h8w8xxrh.fsf@iwagami.gniibe.org> Message-ID: <87mv60mmcw.fsf@wheatstone.g10code.de> Hi! I only now had the time to look at the bug report. I probably misunderstood the problem when you mentioned it during yesterday's telco [1]. The undocumented way to enter a timestamp instead of an interval was introduced a long time ago and the time format reflects the internal format already used by gpgsm. It was never intended as a way for humans to enter a timestamp but for scripts using the machine interface (i.e. using --command-fd/--with-colons). Thus, similiar to the fixed UTF-8 encoding in this interface, all times are also expressed in UTC. For example in GPGME we do this #ifdef HAVE_TIMEGM return timegm (&buf); #else { /* Ugly HACK for systems without timegm. */ time_t tim; putenv ("TZ=UTC"); tim = mktime (&buf); #endif which shows that the --with-colons interface is expected to return UTC. IT is obvious that entering a date also requires UTC in the machine interface - on the command line it can be different of course. > (3) Thirdly (after some more releases?), modify GnuPG to interpret > time with no timezone as UTC. This is already the case. Now, why do we use the compact 8601 format for timestamps? Around 2003 I wrote gpgsm and figured that there are already X.509 certificates with expiration times after 2038-01-19. Thus on the common 32 bit systems it was impossible to express them as time_t. I had a meeting with Uli Drepper in Karlsruhe to convince him to change time_t in glibc to 64 bit similar to how this was done with LFS. That was not successful because he rejected the idea to express wall time with time_t (?time_t was never been intended to express wall time?). We then tried to implement a second time interface using a state of the art suggestion on how to express times in a computer. However that failed because the time interface too much interweaves with other libc services and we could not come up with a solid and portable solution. The way out was to do use something similar to what X.509 does: the ASN.1 GeneralizedTime type. Thus the internal time format in gpgsm is "YYYYMMDDTHHMMSS". For convenience and better alignment a 16 byte buffer is used so that it is always a C string: /* A type to hold the ISO time. Note that this is the same as the KSBA type ksba_isotime_t. */ typedef char gnupg_isotime_t[16]; This is meanwhile also partly used in gpg. The advantage of this format is that it can easily be sorted and compared, much similar to an integer. And it has the real thing: No year 2038 problem in the internal processing (displaying in human readable format is a different story, though). Carrying a timezone indicator would be bad because then the gnupg_isotime_t can't be used as a time_t replacement. The bottom line is that there should be no change in the representation of the time. In particular not in libksba. What could be added are more smart parsers in the human interface. Accepting UTC (i.e. a Z or +0000 suffix in the machine interface would also be okay as long as any other timezone would be rejected because the machine interface requires UTC. Double timezone conversion of time values is one of the most annoying bugs and thus (similar to standardizing on UTF-8), there shall be only UTC in the machine interface and internal representation. Shalom-Salam, Werner [1] We do a Mumble telco each Monday at 10:00 UTC (8:00 during DST). Feel free to join at the gnunet.org server. -- 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 Sep 12 17:40:38 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 12 Sep 2017 11:40:38 -0400 Subject: expiration time in ISO-8801 format In-Reply-To: <87mv60mmcw.fsf@wheatstone.g10code.de> References: <87h8w8xxrh.fsf@iwagami.gniibe.org> <87mv60mmcw.fsf@wheatstone.g10code.de> Message-ID: <87shfsylft.fsf@fifthhorseman.net> On Tue 2017-09-12 09:01:35 +0200, Werner Koch wrote: > [1] We do a Mumble telco each Monday at 10:00 UTC (8:00 during DST). > Feel free to join at the gnunet.org server. thanks for the public invite -- speaking of time zones, different places enter DST ("daylight savings time") at different times, so saying "8:00 during DST" isn't particularly helpful. Could you be more specific? Regards, --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 Tue Sep 12 19:24:40 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 12 Sep 2017 19:24:40 +0200 Subject: expiration time in ISO-8801 format In-Reply-To: <87shfsylft.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 12 Sep 2017 11:40:38 -0400") References: <87h8w8xxrh.fsf@iwagami.gniibe.org> <87mv60mmcw.fsf@wheatstone.g10code.de> <87shfsylft.fsf@fifthhorseman.net> Message-ID: <874ls7ltif.fsf@wheatstone.g10code.de> On Tue, 12 Sep 2017 17:40, dkg at fifthhorseman.net said: > thanks for the public invite -- speaking of time zones, different places > enter DST ("daylight savings time") at different times, so saying "8:00 > during DST" isn't particularly helpful. Could you be more specific? Oh yes. Actually Japan has no DST and this is reason why we changed it with the German DST. Anyway, right now it is on Monday 08:00 UTC and I will announce a change at gnupg-devel@ 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 Sep 12 19:51:09 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 12 Sep 2017 13:51:09 -0400 Subject: expiration time in ISO-8801 format In-Reply-To: <874ls7ltif.fsf@wheatstone.g10code.de> References: <87h8w8xxrh.fsf@iwagami.gniibe.org> <87mv60mmcw.fsf@wheatstone.g10code.de> <87shfsylft.fsf@fifthhorseman.net> <874ls7ltif.fsf@wheatstone.g10code.de> Message-ID: <87zi9zyfea.fsf@fifthhorseman.net> On Tue 2017-09-12 19:24:40 +0200, Werner Koch wrote: > Oh yes. Actually Japan has no DST and this is reason why we changed it > with the German DST. Anyway, right now it is on Monday 08:00 UTC and I > will announce a change at gnupg-devel@ perhaps you should just announce it as based on whatever localtime is in TZ=Europe/Berlin (or wherever your reference TZ is), and then let people calculate their own local time with their own tools? Announcing a recurring meeting as though it was UTC without it actually being scheduled in UTC is a bit misleading. Also, many calendaring programs (including the "Lightning" extension to Thunderbird) have a way that you can input recurring events with their own time zone, which then get displayed according to your local system's TZ just fine. --dkg PS kudos to Japan for not buying into the DST nonsense! -------------- 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 Sep 13 09:22:49 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 13 Sep 2017 09:22:49 +0200 Subject: expiration time in ISO-8801 format In-Reply-To: <87zi9zyfea.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 12 Sep 2017 13:51:09 -0400") References: <87h8w8xxrh.fsf@iwagami.gniibe.org> <87mv60mmcw.fsf@wheatstone.g10code.de> <87shfsylft.fsf@fifthhorseman.net> <874ls7ltif.fsf@wheatstone.g10code.de> <87zi9zyfea.fsf@fifthhorseman.net> Message-ID: <87lgljjc52.fsf@wheatstone.g10code.de> On Tue, 12 Sep 2017 19:51, dkg at fifthhorseman.net said: > calculate their own local time with their own tools? Announcing a > recurring meeting as though it was UTC without it actually being > scheduled in UTC is a bit misleading. My use of UTC is probably due my former activity as a Ham ;-) 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 dkg at fifthhorseman.net Wed Sep 13 17:25:24 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 13 Sep 2017 11:25:24 -0400 Subject: digest preferences [was: Re: diverging from upstream defaults] In-Reply-To: <87h8wd3smr.fsf@fifthhorseman.net> References: <877exa6oo0.fsf@fifthhorseman.net> <87pob1wxro.fsf@wheatstone.g10code.de> <87a825687u.fsf@fifthhorseman.net> <87lglpwubw.fsf@wheatstone.g10code.de> <87vakt42d4.fsf@fifthhorseman.net> <87ingttay2.fsf@wheatstone.g10code.de> <87h8wd3smr.fsf@fifthhorseman.net> Message-ID: <87ingmy61n.fsf@fifthhorseman.net> now cc'ing and setting M-F-T to gnupg-devel, since this is now a discussion about changes to GnuPG upstream; for those just joining the thread, see the background here: https://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/2017-September/005961.html On Fri 2017-09-08 15:19:40 -0400, Daniel Kahn Gillmor wrote: > Werner Koch wrote: >>> SHA-256 vs: SHA-512: There has been a heated debate in the OpenPGP WG on >> [...] >>> devices (IoT), who would be the most likely use case for curve 25519, so >>> i have a hard time imagining who we're protecting with this, though. >> >> Indeed that is a problem with ed25519 - but at least they can use cv25519. >> >> To avoid source code chnages, would a configure option be useful to >> switch the preferences? > > that'd be great, but there are two different decisions here: > > a) DEFAULT_DIGEST_ALGO (--cert-digest-algo and --digest-algo both > inherit it by default) -- should it be SHA256 or SHA512? > > b) order of the default preferences embedded in OpenPGP certificates > (should it go "SHA512,SHA384,SHA256" or "SHA256,SHA384,SHA512"?) I'd like to take these two questions separately, and see whether we can answer them separately first. I'll start with (b) in this e-mail, in particular with --default-preference-list. --default-preference-list indicates what algorithms to advertise in a newly-generated key. For most modern 64-bit computers, sha-512 is faster to compute at any reasonable size, so it looks to me like the published preference order should be changed to indicate a preference for SHA512 by default. People with special hardware or custom needs can always edit their configuration. Can we get consensus on this change, if its implementation has no effect on --personal-digest-preferences, --digest-algo, or --cert-digest-algo? Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From rjh at sixdemonbag.org Wed Sep 13 18:13:15 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 13 Sep 2017 12:13:15 -0400 Subject: digest preferences [was: Re: diverging from upstream defaults] In-Reply-To: <87ingmy61n.fsf@fifthhorseman.net> References: <877exa6oo0.fsf@fifthhorseman.net> <87pob1wxro.fsf@wheatstone.g10code.de> <87a825687u.fsf@fifthhorseman.net> <87lglpwubw.fsf@wheatstone.g10code.de> <87vakt42d4.fsf@fifthhorseman.net> <87ingttay2.fsf@wheatstone.g10code.de> <87h8wd3smr.fsf@fifthhorseman.net> <87ingmy61n.fsf@fifthhorseman.net> Message-ID: <25c85fd9-4a16-d8c5-1f11-fa60be9c8ceb@sixdemonbag.org> > --default-preference-list indicates what algorithms to advertise in a > newly-generated key. For most modern 64-bit computers, sha-512 is > faster to compute at any reasonable size, so it looks to me like the > published preference order should be changed to indicate a preference > for SHA512 by default. People with special hardware or custom needs can > always edit their configuration. Begging pardon, but this seems like a very weak justification to me. SHA512 versus SHA256 timings will be significant only for people doing lots of signatures on extremely large files in soft-realtime environments. Outside of that, really, who cares if SHA512 is a millisecond quicker when signing an email if you're handling under a thousand documents a day? I'm not saying SHA512 is a poor choice, mind you: I think it's probably the right choice. But I think this justification is pretty weak. "People with special hardware or custom needs" describes people who would benefit from SHA512's speed edge as much as it describes people who would benefit from SHA256. From look at my.amazin.horse Wed Sep 13 20:42:06 2017 From: look at my.amazin.horse (Vincent Breitmoser) Date: Wed, 13 Sep 2017 20:42:06 +0200 Subject: diverging from upstream defaults In-Reply-To: <87ingmy61n.fsf@fifthhorseman.net> References: <877exa6oo0.fsf@fifthhorseman.net> <87pob1wxro.fsf@wheatstone.g10code.de> <87a825687u.fsf@fifthhorseman.net> <87lglpwubw.fsf@wheatstone.g10code.de> <87vakt42d4.fsf@fifthhorseman.net> <87ingttay2.fsf@wheatstone.g10code.de> <87h8wd3smr.fsf@fifthhorseman.net> <87ingmy61n.fsf@fifthhorseman.net> Message-ID: <20170913184206.zsjuxvvsiybofnf4@calamity> Picking up on the s2k default: >> I am not sure about the 100ms vs. 300ms change for S2K. > I hope someone will speak up if they have that use case. I don't have "that" use case, but it's probably worth mentioning that moving a 100ms-adjusted key from a desktop machine to a smartphone can already be problematic even with 100ms. Particularly if the desktop machine is relatively newer than the phone, the difference in speed can become a factor 10 or more. Not making a statement about whether to go for 100ms or 300ms here, it's just a loosely related point that has caused us a few confused users in the past and might be non obvious to people who don't use OpenPGP on a phone. - V From bernhard at intevation.de Thu Sep 14 17:20:50 2017 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 14 Sep 2017 17:20:50 +0200 Subject: GnuPG e.V. is looking for members In-Reply-To: <87d1758tab.fsf@wheatstone.g10code.de> References: <87d1758tab.fsf@wheatstone.g10code.de> Message-ID: <201709141720.50763.bernhard@intevation.de> Am Dienstag, 5. September 2017 10:05:16 schrieb Werner Koch: > If you contributed to GnuPG, be it code, documentation, user education, > or whatever you think it makes you a contributor, please feel invited to > apply for membership by sending mail to board at gnupg.org. Today I've applied for membership. Werner asked me to help out. My company offers services around GnuPG, so there is a potential conflict of interest. However it may be necessary now to help the verein to ensure a stable future of GnuPG as Free Software. > We do not need a snail address, but it would be good if you at least > tell us the city you are living and a permanent mail address. ?We expect > an OpenPGP encrypted mail and some words on the kind of your activity. This probably is a test to do something like gpg2 --locate-keys board at gnupg.org (WKD? :)) The webpage seems to be https://gnupg.org/verein/ 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 dkg at fifthhorseman.net Fri Sep 15 01:43:01 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 14 Sep 2017 19:43:01 -0400 Subject: digest preferences [was: Re: diverging from upstream defaults] In-Reply-To: <25c85fd9-4a16-d8c5-1f11-fa60be9c8ceb@sixdemonbag.org> References: <877exa6oo0.fsf@fifthhorseman.net> <87pob1wxro.fsf@wheatstone.g10code.de> <87a825687u.fsf@fifthhorseman.net> <87lglpwubw.fsf@wheatstone.g10code.de> <87vakt42d4.fsf@fifthhorseman.net> <87ingttay2.fsf@wheatstone.g10code.de> <87h8wd3smr.fsf@fifthhorseman.net> <87ingmy61n.fsf@fifthhorseman.net> <25c85fd9-4a16-d8c5-1f11-fa60be9c8ceb@sixdemonbag.org> Message-ID: <87wp50voca.fsf@fifthhorseman.net> On Wed 2017-09-13 12:13:15 -0400, Robert J. Hansen wrote: >> --default-preference-list indicates what algorithms to advertise in a >> newly-generated key. For most modern 64-bit computers, sha-512 is >> faster to compute at any reasonable size, so it looks to me like the >> published preference order should be changed to indicate a preference >> for SHA512 by default. People with special hardware or custom needs can >> always edit their configuration. > > Begging pardon, but this seems like a very weak justification to me. > SHA512 versus SHA256 timings will be significant only for people doing > lots of signatures on extremely large files in soft-realtime > environments. Outside of that, really, who cares if SHA512 is a > millisecond quicker when signing an email if you're handling under a > thousand documents a day? I agree that an argument about SHA512 being more performant isn't a great one. However, there's often an assumption that the larger security margin an algorithm has, the more expensive it is. In this case, the argument for stating a preference for SHA-512 is "larger security margin *and* a (slight) reduction in cost". There is no change in the size of messages on the wire here. So the move to stating a preference for SHA-512 seems like win-win to me. Any other feedback on this suggestion? should i publish a change for review? --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 Fri Sep 15 01:46:23 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 14 Sep 2017 19:46:23 -0400 Subject: diverging from upstream defaults In-Reply-To: <20170913184206.zsjuxvvsiybofnf4@calamity> References: <877exa6oo0.fsf@fifthhorseman.net> <87pob1wxro.fsf@wheatstone.g10code.de> <87a825687u.fsf@fifthhorseman.net> <87lglpwubw.fsf@wheatstone.g10code.de> <87vakt42d4.fsf@fifthhorseman.net> <87ingttay2.fsf@wheatstone.g10code.de> <87h8wd3smr.fsf@fifthhorseman.net> <87ingmy61n.fsf@fifthhorseman.net> <20170913184206.zsjuxvvsiybofnf4@calamity> Message-ID: <87tw04vo6o.fsf@fifthhorseman.net> On Wed 2017-09-13 20:42:06 +0200, Vincent Breitmoser wrote: > Picking up on the s2k default: > >>> I am not sure about the 100ms vs. 300ms change for S2K. >> I hope someone will speak up if they have that use case. > > I don't have "that" use case, but it's probably worth mentioning that > moving a 100ms-adjusted key from a desktop machine to a smartphone can > already be problematic even with 100ms. Particularly if the desktop > machine is relatively newer than the phone, the difference in speed can > become a factor 10 or more. The workflow for importing a secret key to a new device should include an import step that adjusts the cryptographic protection on the key to match something sensible for that device (and to verify that the user actually can unlock the key in the first place). if the one-time import of a secret key to a new device costs 5 seconds instead of 500ms, i'm not particularly troubled by that change. If some piece of software imports a key without either: * a checking that the user can control the key, or * that the cryptographic protection for the key makes sense for the platform then i don't think the problem is with gpg-agent's key-stretching calibration, is it? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From cjwatson at debian.org Sat Sep 16 05:14:28 2017 From: cjwatson at debian.org (Colin Watson) Date: Sat, 16 Sep 2017 04:14:28 +0100 Subject: DCO for Colin Watson Message-ID: <20170916031428.uypfrdojquvjteor@riva.ucam.org> GPGME Developer's Certificate of Origin. Version 1.0 ===================================================== By making a contribution to the GPGME 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: Colin Watson -- Colin Watson [cjwatson at debian.org] -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 897 bytes Desc: not available URL: From cjwatson at debian.org Sat Sep 16 05:16:45 2017 From: cjwatson at debian.org (Colin Watson) Date: Sat, 16 Sep 2017 04:16:45 +0100 Subject: [GPGME PATCH] core: Restore get_max_fds optimization on Linux Message-ID: <20170916031644.gqkho4ow7kbrfdsf@riva.ucam.org> * src/posix-io.c (get_max_fds): Restore Linux optimization, this time using open/getdents/close rather than opendir/readdir/closedir. -- opendir/readdir/closedir may allocate/free memory, and aren't required to do so in an async-signal-safe way. On the other hand, opening /proc/self/fd directly and iterating over it using getdents is safe. (getdents is not strictly speaking documented to be async-signal-safe because it's not in POSIX. However, the Linux implementation is essentially just a souped-up read. Python >= 3.2.3 makes the same assumption.) Signed-off-by: Colin Watson --- src/posix-io.c | 99 ++++++++++++++++++++++++++++++++++++++-------------------- 1 file changed, 66 insertions(+), 33 deletions(-) diff --git a/src/posix-io.c b/src/posix-io.c index 14856df..4267713 100644 --- a/src/posix-io.c +++ b/src/posix-io.c @@ -48,6 +48,7 @@ #include #if __linux__ +# include # include # include #endif /*__linux__ */ @@ -279,6 +280,20 @@ _gpgme_io_set_nonblocking (int fd) } +#ifdef __linux__ +/* This is not declared in public headers; getdents(2) says that we must + * define it ourselves. */ +struct linux_dirent +{ + unsigned long d_ino; + unsigned long d_off; + unsigned short d_reclen; + char d_name[]; +}; + +# define DIR_BUF_SIZE 1024 +#endif /* __linux__ */ + static long int get_max_fds (void) { @@ -291,39 +306,57 @@ get_max_fds (void) * than for example doing 4096 close calls where almost all of them * will fail. * - * Unfortunately we can't call opendir between fork and exec in a - * multi-threaded process because opendir uses malloc and thus a - * mutex which may deadlock with a malloc in another thread. Thus - * the code is not used until we can have a opendir variant which - * does not use malloc. */ -/* #ifdef __linux__ */ -/* { */ -/* DIR *dir = NULL; */ -/* struct dirent *dir_entry; */ -/* const char *s; */ -/* int x; */ - -/* dir = opendir ("/proc/self/fd"); */ -/* if (dir) */ -/* { */ -/* while ((dir_entry = readdir (dir))) */ -/* { */ -/* s = dir_entry->d_name; */ -/* if ( *s < '0' || *s > '9') */ -/* continue; */ -/* x = atoi (s); */ -/* if (x > fds) */ -/* fds = x; */ -/* } */ -/* closedir (dir); */ -/* } */ -/* if (fds != -1) */ -/* { */ -/* fds++; */ -/* source = "/proc"; */ -/* } */ -/* } */ -/* #endif /\* __linux__ *\/ */ + * We can't use the normal opendir/readdir/closedir interface between + * fork and exec in a multi-threaded process because opendir uses + * malloc and thus a mutex which may deadlock with a malloc in another + * thread. However, the underlying getdents system call is safe. */ +#ifdef __linux__ + { + int dir_fd; + char dir_buf[DIR_BUF_SIZE]; + struct linux_dirent *dir_entry; + int r, pos; + const char *s; + int x; + + dir_fd = open ("/proc/self/fd", O_RDONLY | O_DIRECTORY); + if (dir_fd != -1) + { + for (;;) + { + r = syscall(SYS_getdents, dir_fd, dir_buf, DIR_BUF_SIZE); + if (r == -1) + { + /* Fall back to other methods. */ + fds = -1; + break; + } + if (r == 0) + break; + + for (pos = 0; pos < r; pos += dir_entry->d_reclen) + { + dir_entry = (struct linux_dirent *) (dir_buf + pos); + s = dir_entry->d_name; + if (*s < '0' || *s > '9') + continue; + /* atoi is not guaranteed to be async-signal-safe. */ + for (x = 0; *s >= '0' && *s <= '9'; s++) + x = x * 10 + (*s - '0'); + if (!*s && x > fds && x != dir_fd) + fds = x; + } + } + + close (dir_fd); + } + if (fds != -1) + { + fds++; + source = "/proc"; + } + } +#endif /* __linux__ */ #ifdef RLIMIT_NOFILE if (fds == -1) -- 2.7.4 -- Colin Watson [cjwatson at debian.org] -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 897 bytes Desc: not available URL: From cjwatson at debian.org Sat Sep 16 05:17:19 2017 From: cjwatson at debian.org (Colin Watson) Date: Sat, 16 Sep 2017 04:17:19 +0100 Subject: [GPGME PATCH] core: Restore get_max_fds optimization on Linux In-Reply-To: <20170916031644.gqkho4ow7kbrfdsf@riva.ucam.org> References: <20170916031644.gqkho4ow7kbrfdsf@riva.ucam.org> Message-ID: <20170916031719.6hqy5vruhbwrb7h6@riva.ucam.org> On Sat, Sep 16, 2017 at 04:16:44AM +0100, Colin Watson wrote: > * src/posix-io.c (get_max_fds): Restore Linux optimization, this time > using open/getdents/close rather than opendir/readdir/closedir. > -- > > opendir/readdir/closedir may allocate/free memory, and aren't required > to do so in an async-signal-safe way. On the other hand, opening > /proc/self/fd directly and iterating over it using getdents is safe. > > (getdents is not strictly speaking documented to be async-signal-safe > because it's not in POSIX. However, the Linux implementation is > essentially just a souped-up read. Python >= 3.2.3 makes the same > assumption.) Incidentally, on my system, this reduces the time required for "make -C tests/gpg -j4 check" from 42 seconds to 6 seconds. How dramatic this difference is will of course depend on the value of the hard limit for RLIMIT_NOFILE ("ulimit -Hn"), which on my system is 1048576 by default, although I haven't bothered to hunt down where that default is set; with a more traditional hard limit of 4096 the difference is negligible. I noticed this because some tests of the launchpad.net codebase that exercise GPGME were timing out in my test container. I thought about capping our hard limit for RLIMIT_NOFILE to something more reasonable, and that might still make sense, but I think there's more global benefit in improving GPGME. -- Colin Watson [cjwatson at debian.org] -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 897 bytes Desc: not available URL: From myonium at gmail.com Mon Sep 18 18:25:53 2017 From: myonium at gmail.com (Myonium) Date: Mon, 18 Sep 2017 18:25:53 +0200 Subject: Fwd: card_status - change-request to update allways References: <87zidmc1wq.fsf@fsij.org> Message-ID: <92939132-CE14-4B41-95F4-12478AD85E74@gmail.com> Hi Niibe Could you please advise how to get the change below pushed in the next release? It is a very small change which makes the world for many of the smart card user much easier. Thanks, Ben > Begin forwarded message: > > From: NIIBE Yutaka > Subject: Re: Fwd: card_status - change-request to update allways > Date: June 5, 2017 at 09:46:29 GMT+2 > To: Myonium , gnupg-devel at gnupg.org > > Myonium wrote: >> Any chance to get this change pushed into the next build? >> ----------------------snip------------------------- >> diff --git a/g10/card-util.c b/g10/card-util.c >> index 78cd52b..950b76f 100644 >> --- a/g10/card-util.c >> +++ b/g10/card-util.c >> @@ -376,7 +376,7 @@ current_card_status (ctrl_t ctrl, estream_t fp, >> if (serialno && serialnobuflen) >> *serialno = 0; >> >> - rc = agent_scd_learn (&info, 0); >> + rc = agent_scd_learn (&info, 1); >> if (rc) >> { >> if (opt.with_colons) >> ----------------------snip???????????? > > FYI, we have a ticket: > > https://dev.gnupg.org/T2898 > > under this parent ticket: > > https://dev.gnupg.org/T2291 > -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Tue Sep 19 13:10:46 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 19 Sep 2017 13:10:46 +0200 Subject: [Announce] GnuPG 2.2.1 released Message-ID: <87poankkp5.fsf@wheatstone.g10code.de> Hello! We are is pleased to announce the availability of a new GnuPG release: version 2.2.1. This is a maintenance release; see below for a list of fixed bugs. 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. As an Universal Crypto Engine 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. Noteworthy changes in version 2.2.1 =================================== * gpg: Fix formatting of the user id in batch mode key generation if only "name-email" is given. * gpgv: Fix annoying "not suitable for" warnings. * wks: Convey only the newest user id to the provider. This is the case if different names are used with the same addr-spec. * wks: Create a complying user id for provider policy mailbox-only. * wks: Add workaround for posteo.de. * scd: Fix the use of large ECC keys with an OpenPGP card. * dirmngr: Use system provided root certificates if no specific HKP certificates are configured. If build with GNUTLS, this was already the case. Further, the Windows installer has been built against an updated NTBTLS libary which does now support ECC curves secp384r1, secp521r1, as well as brainpool curves. Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.2.1 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.1.tar.bz2 (6385k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.1.tar.bz2.sig An installer for Windows without any graphical frontend except for a very minimal Pinentry tool is available here: https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.1_20170919.exe (3799k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.1_20170919.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. The new Gpg4win 3.0 installer featuring this version of GnuPG will be available in a few days. 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.2.1.tar.bz2 you would use this command: gpg --verify gnupg-2.2.1.tar.bz2.sig gnupg-2.2.1.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See 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.2.1.tar.bz2, you run the command like this: sha1sum gnupg-2.2.1.tar.bz2 and check that the output matches the next line: 5455373fd7208b787f319027de2464721cdd4413 gnupg-2.2.1.tar.bz2 bcf1905655e52e2eec794bcbba72485f7b9ed2d3 gnupg-w32-2.2.1_20170919.exe 72ab40a7336be7b2c9fb4f6ff1f15e5c5b8cdb6f gnupg-w32-2.2.1_20170919.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. 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 reference manual of the system. Separate man pages are included as well but they miss some of the details availabale only in thee manual. The manual is also available online at https://gnupg.org/documentation/manuals/gnupg/ or can be downloaded as PDF 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 list for advise on how to solve problems. Most of the new features are around for several years and thus enough public experience is available. Support ======== Please consult the archive of the gnupg-users mailing list before reporting a bug: . We suggest to send bug reports for a new release to this list in favor of filing a bug at . 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 2 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 for financing the project. Happy hacking, Your GnuPG Team 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 five keys: 2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048/E0856959 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31] Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 Werner Koch (Release Signing Key) rsa3072/4B092E28 2017-03-17 [expires: 2027-03-15] Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (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 BCEF7E294B092E28 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: 227 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 Tue Sep 19 17:42:22 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 19 Sep 2017 11:42:22 -0400 Subject: [GPGME PATCH] core: Restore get_max_fds optimization on Linux In-Reply-To: <20170916031719.6hqy5vruhbwrb7h6@riva.ucam.org> References: <20170916031644.gqkho4ow7kbrfdsf@riva.ucam.org> <20170916031719.6hqy5vruhbwrb7h6@riva.ucam.org> Message-ID: <877ewuzodd.fsf@fifthhorseman.net> On Sat 2017-09-16 04:17:19 +0100, Colin Watson wrote: > On Sat, Sep 16, 2017 at 04:16:44AM +0100, Colin Watson wrote: >> * src/posix-io.c (get_max_fds): Restore Linux optimization, this time >> using open/getdents/close rather than opendir/readdir/closedir. >> -- >> >> opendir/readdir/closedir may allocate/free memory, and aren't required >> to do so in an async-signal-safe way. On the other hand, opening >> /proc/self/fd directly and iterating over it using getdents is safe. >> >> (getdents is not strictly speaking documented to be async-signal-safe >> because it's not in POSIX. However, the Linux implementation is >> essentially just a souped-up read. Python >= 3.2.3 makes the same >> assumption.) > > Incidentally, on my system, this reduces the time required for "make -C > tests/gpg -j4 check" from 42 seconds to 6 seconds. How dramatic this > difference is will of course depend on the value of the hard limit for > RLIMIT_NOFILE ("ulimit -Hn"), which on my system is 1048576 by default, > although I haven't bothered to hunt down where that default is set; with > a more traditional hard limit of 4096 the difference is negligible. I support adoption of this patch in GPGME upstream. It addresses a pretty severe performance degradation in GPGME on Linux platforms that was introduced between version 1.8.0 and 1.9.0. Colin and i most likely use similar systems or , but i've got 1Mi as the RLIMIT_NOFILE as well. This patch looks good to me, since it reduces the number of spurious close() calls invoked at every _gpgme_io_spawn by about 5 orders of magnitude (from ~1M to ~10). In particular, on my Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz CPU running Linux 4.12, my system consumes over 60ms doing 1Mi spurious close() calls (about half in the kernel, half in userland), as compared with 2ms or 3ms for doing basic process initialization itself. That's a lot of unnecessary overhead! Another data point ------------------ i ran "notmuch show --decrypt --format=json" on a thread of 16 encrypted messages, with session keys already cached, built against gmime 3.0, which uses gpgme. without this patch, the above command took ~4.5s wall-clock time. with this patch, the same command took ~1.6s. (fwiw, i still think 1.6s is too long for a 16-message thread, esp. with no asymmetric crypto involved, but i'm happy for the improvement) source clarity -------------- It might be nice to have a clearer comment above get_max_fds(), to indicate that the goal is to return the value of the highest open file descriptor, but on systems where that is not available, it just returns the highest possible file descriptor value. This particular patch won't help for processes which do something perverse like: getrlimit(RLIMIT_NOFILE, &rl) || dup2(0, rl.rlim_max-1); but it will help the overwhelming majority of processes. If we find that such processes exist, we can optimize this further, but this looks like an unmitigated win to me. > I noticed this because some tests of the launchpad.net codebase that > exercise GPGME were timing out in my test container. I thought about > capping our hard limit for RLIMIT_NOFILE to something more reasonable, > and that might still make sense, but I think there's more global benefit > in improving GPGME. Agreed. I've included this in debian for our Linux-based architectures in gpgme 1.9.0-5. I think it should really be adopted by upstream, though. It'd be great if there was something comparable for the BSD and Hurd ports too, but that can come later. Thanks for finding this and proposing the improvement, Colin! --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From alon.barlev at gmail.com Tue Sep 19 17:53:56 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 19 Sep 2017 18:53:56 +0300 Subject: [GPGME PATCH] core: Restore get_max_fds optimization on Linux In-Reply-To: <877ewuzodd.fsf@fifthhorseman.net> References: <20170916031644.gqkho4ow7kbrfdsf@riva.ucam.org> <20170916031719.6hqy5vruhbwrb7h6@riva.ucam.org> <877ewuzodd.fsf@fifthhorseman.net> Message-ID: On 19 September 2017 at 18:42, Daniel Kahn Gillmor wrote: > > On Sat 2017-09-16 04:17:19 +0100, Colin Watson wrote: > > On Sat, Sep 16, 2017 at 04:16:44AM +0100, Colin Watson wrote: > >> * src/posix-io.c (get_max_fds): Restore Linux optimization, this time > >> using open/getdents/close rather than opendir/readdir/closedir. > >> -- > >> > >> opendir/readdir/closedir may allocate/free memory, and aren't required > >> to do so in an async-signal-safe way. On the other hand, opening > >> /proc/self/fd directly and iterating over it using getdents is safe. > >> > >> (getdents is not strictly speaking documented to be async-signal-safe > >> because it's not in POSIX. However, the Linux implementation is > >> essentially just a souped-up read. Python >= 3.2.3 makes the same > >> assumption.) > > > > Incidentally, on my system, this reduces the time required for "make -C > > tests/gpg -j4 check" from 42 seconds to 6 seconds. How dramatic this > > difference is will of course depend on the value of the hard limit for > > RLIMIT_NOFILE ("ulimit -Hn"), which on my system is 1048576 by default, > > although I haven't bothered to hunt down where that default is set; with > > a more traditional hard limit of 4096 the difference is negligible. > > I support adoption of this patch in GPGME upstream. It addresses a > pretty severe performance degradation in GPGME on Linux platforms that > was introduced between version 1.8.0 and 1.9.0. Hi, Just a question... What about of a solution of fork/exec a wrapper that closes handles then exec the actual binary? This wrapper may be considered as "trusted" and as it is exec-ed it can use any library call. Regards, Alon From ilf at zeromail.org Tue Sep 19 17:37:51 2017 From: ilf at zeromail.org (ilf) Date: Tue, 19 Sep 2017 17:37:51 +0200 Subject: [Announce] GnuPG 2.2.1 released In-Reply-To: <87poankkp5.fsf@wheatstone.g10code.de> References: <87poankkp5.fsf@wheatstone.g10code.de> Message-ID: <20170919153751.GI1026@zeromail.org> Thanks for the release! Werner Koch: > Noteworthy changes in version 2.2.1 Is there a reason the changes defaulting to 3072-bit RSA keys [1] and AES-256 [2] from refs/heads/master did not make it into refs/heads/STABLE-BRANCH-2-2? 1. https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=909fbca19678e6e36968607e8a2348381da39d8c 2. https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=73ff075204df09db5248170a049f06498cdbb7aa I would really love to see these changes in wide use - and I fear waiting for 2.3 will push this back for years for many users. I really see no argument against making those changes default in 2.2. OTOH, the NSA is apparently developing a new supercomputer named "WindsorGreen" believed to attack crypto, probably even "breaking older/weaker (1024 bit) RSA keys". [3] Now obviously, this is no proof, and 2048 bit RSA is still good, but it seems a good reminder to put some more safety margin between us and powerful attackers. Especially since these changes apply to newly generated keys, which are often used for many years to come. 3. https://theintercept.com/2017/05/11/nyu-accidentally-exposed-military-code-breaking-computer-project-to-entire-internet/ On a sidenote, https://git.gnupg.org/ still links to 1.4, 2.0 and 2.1, but not 2.2. This could probably be adjusted. -- 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 rjh at sixdemonbag.org Tue Sep 19 19:55:21 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 19 Sep 2017 13:55:21 -0400 Subject: [Announce] GnuPG 2.2.1 released In-Reply-To: <20170919153751.GI1026@zeromail.org> References: <87poankkp5.fsf@wheatstone.g10code.de> <20170919153751.GI1026@zeromail.org> Message-ID: > Is there a reason the changes defaulting to 3072-bit RSA keys [1] and > AES-256 [2] from refs/heads/master did not make it into > refs/heads/STABLE-BRANCH-2-2? No comment on the reasons -- it's not my bailiwick. However, > OTOH, the NSA is apparently developing a new supercomputer named > "WindsorGreen" believed to attack crypto, probably even "breaking > older/weaker (1024 bit) RSA keys". This one, I feel the need to shed some caution on. Breaking 1024-bit keys is *hard*: it's estimated to be a work factor of about 2**80. Breaking 2048-bit keys is a work factor of about 2**112, or over a billion times harder. If we're just now reaching the point where 1024-bit keys are in serious jeopardy, it's hard for me to imagine 2048-bit keys will be in jeopardy any time soon absent some technological development that's indistinguishable from magic. NIST's guidance is that by 2020 we should switch over to 3072-bit keys. We're still in the zone of safety. The 3072-bit switchover needs to happen and it needs to be a priority item, but it's not urgent that it happen now, or even within the next six months. We have time. With respect to AES-256, the real issue to me is one of block size, not key length. All of the symmetric ciphers in OpenPGP are completely impractical to brute force. The real risk comes from the continued use of 64-bit block ciphers, which run the possibility of repeating state after only a few gigabytes are encrypted. So if users are encrypting multi-gigabyte files with CAST5, BLOWFISH, 3DES, or IDEA, that's a *far* greater risk than using AES128. I, personally, would like to see GnuPG refuse to use 64-bit block ciphers for encryption unless an option was set (--allow-old-ciphers, perhaps). Leave the algorithms in there for RFC conformance, let them decrypt without a warning, but require an option to be set for using them. From cjwatson at debian.org Tue Sep 19 21:36:53 2017 From: cjwatson at debian.org (Colin Watson) Date: Tue, 19 Sep 2017 20:36:53 +0100 Subject: [GPGME PATCH] core: Restore get_max_fds optimization on Linux In-Reply-To: References: <20170916031644.gqkho4ow7kbrfdsf@riva.ucam.org> <20170916031719.6hqy5vruhbwrb7h6@riva.ucam.org> <877ewuzodd.fsf@fifthhorseman.net> Message-ID: <20170919193652.7eonup34c5zs35cg@riva.ucam.org> On Tue, Sep 19, 2017 at 06:53:56PM +0300, Alon Bar-Lev wrote: > On 19 September 2017 at 18:42, Daniel Kahn Gillmor > wrote: > > I support adoption of this patch in GPGME upstream. It addresses a > > pretty severe performance degradation in GPGME on Linux platforms that > > was introduced between version 1.8.0 and 1.9.0. > > Hi, > > Just a question... > What about of a solution of fork/exec a wrapper that closes handles > then exec the actual binary? > This wrapper may be considered as "trusted" and as it is exec-ed it > can use any library call. I did see that suggestion in earlier mailing list threads about this problem, but it seemed quite a bit fiddlier than just doing it pre-exec the way I did: building and installing a new program, sorting out paths for it, and so forth looked likely to be more effort than (in this case, and IMO) the relatively small amount of effort required to be async-signal-safe. It's obviously not my project and I don't object if somebody else wants to put together a version involving an extra child process, but in all honesty I'm not going to get round to it myself. Thanks, -- Colin Watson [cjwatson at debian.org] From dkg at fifthhorseman.net Tue Sep 19 22:55:59 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 19 Sep 2017 16:55:59 -0400 Subject: [Announce] GnuPG 2.2.1 released In-Reply-To: <20170919153751.GI1026@zeromail.org> References: <87poankkp5.fsf@wheatstone.g10code.de> <20170919153751.GI1026@zeromail.org> Message-ID: <87poamxva8.fsf@fifthhorseman.net> On Tue 2017-09-19 17:37:51 +0200, ilf wrote: > Is there a reason the changes defaulting to 3072-bit RSA keys [1] and > AES-256 [2] from refs/heads/master did not make it into > refs/heads/STABLE-BRANCH-2-2? > > 1. https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=909fbca19678e6e36968607e8a2348381da39d8c > 2. https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=73ff075204df09db5248170a049f06498cdbb7aa > > I would really love to see these changes in wide use - and I fear > waiting for 2.3 will push this back for years for many users. I agree that these adjustments to the defaults should be made in the 2.2 branch. The defaults for 2.2 are likely to be with us for many years, so we need to be thinking about the future security landscape. they are not particularly radical changes to the defaults, but they give an increased security margin, which we should take. We're shipping these changes (plus some others) in the Debian packaging for 2.2, fwiw. --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 Tue Sep 19 22:53:41 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 19 Sep 2017 16:53:41 -0400 Subject: [Announce] GnuPG 2.2.1 released In-Reply-To: References: <87poankkp5.fsf@wheatstone.g10code.de> <20170919153751.GI1026@zeromail.org> Message-ID: <87shfixve2.fsf@fifthhorseman.net> On Tue 2017-09-19 13:55:21 -0400, Robert J. Hansen wrote: > I, personally, would like to see GnuPG refuse to use 64-bit block > ciphers for encryption unless an option was set (--allow-old-ciphers, > perhaps). Leave the algorithms in there for RFC conformance, let them > decrypt without a warning, but require an option to be set for using them. Good idea, Robert. I've opened a bug report about it to track that suggestion here: https://dev.gnupg.org/T3415 Regards, --dkg From dkg at fifthhorseman.net Tue Sep 19 23:56:22 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 19 Sep 2017 17:56:22 -0400 Subject: [GPGME PATCH] core: Restore get_max_fds optimization on Linux In-Reply-To: <877ewuzodd.fsf@fifthhorseman.net> References: <20170916031644.gqkho4ow7kbrfdsf@riva.ucam.org> <20170916031719.6hqy5vruhbwrb7h6@riva.ucam.org> <877ewuzodd.fsf@fifthhorseman.net> Message-ID: <87fubixshl.fsf@fifthhorseman.net> On Tue 2017-09-19 11:42:22 -0400, Daniel Kahn Gillmor wrote: > I've included this in debian for our Linux-based architectures in > gpgme 1.9.0-5. https://buildd.debian.org/status/fetch.php?pkg=gpgme1.0&arch=arm64&ver=1.9.0-5&stamp=1505837536&raw=0 shows that on arm64 we get this failure: -------- libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wcast-align -Wshadow -Wstrict-prototypes -c posix-util.c -o posix-util.o >/dev/null 2>&1 posix-io.c: In function 'get_max_fds': posix-io.c:327:25: error: 'SYS_getdents' undeclared (first use in this function); did you mean 'SYS_getdents64'? r = syscall(SYS_getdents, dir_fd, dir_buf, DIR_BUF_SIZE); ^~~~~~~~~~~~ SYS_getdents64 posix-io.c:327:25: note: each undeclared identifier is reported only once for each function it appears in Makefile:926: recipe for target 'posix-io.lo' failed -------- i guess arm64 is new enough that it doesn't support the 32-bit SYS_getdents at all? Colin, do you want to propose a change to the patch so that it'll build on that platform? should we just move it to getdents64 for all platforms? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From gniibe at fsij.org Wed Sep 20 07:25:30 2017 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 20 Sep 2017 14:25:30 +0900 Subject: Fwd: card_status - change-request to update allways In-Reply-To: <92939132-CE14-4B41-95F4-12478AD85E74@gmail.com> References: <87zidmc1wq.fsf@fsij.org> <92939132-CE14-4B41-95F4-12478AD85E74@gmail.com> Message-ID: <87h8vy9c1h.fsf@iwagami.gniibe.org> Myonium wrote: > Could you please advise how to get the change below pushed in the next release? Sorry, it won't get in. Yes, I understand your use case; You want to replace private key stub in .gnupg/private-keys-v1.d. For this use case, please remove your .gnupg/private-keys-v1.d/.key manually, and do "gpg --card-status". The change you proposed has an impact to existing behavior, that is, it always modifies the privat key file when 'gpg --card-status' is invoked. Currently, GnuPG doesn't assume same key can be mutiple cards with possiblly different serial number. -- From wk at gnupg.org Wed Sep 20 08:32:04 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 20 Sep 2017 08:32:04 +0200 Subject: [Announce] GnuPG 2.2.1 released In-Reply-To: <20170919153751.GI1026@zeromail.org> (ilf@zeromail.org's message of "Tue, 19 Sep 2017 17:37:51 +0200") References: <87poankkp5.fsf@wheatstone.g10code.de> <20170919153751.GI1026@zeromail.org> Message-ID: <877ewtkhi3.fsf@wheatstone.g10code.de> On Tue, 19 Sep 2017 17:37, ilf at zeromail.org said: > Is there a reason the changes defaulting to 3072-bit RSA keys [1] and > AES-256 [2] from refs/heads/master did not make it into > refs/heads/STABLE-BRANCH-2-2? That is not a bug fix and thus this won't go into 2.2 unless there is a security problem or regulations require the use of rsa3072. Those who feel the need for longer keys can create longer keys. Changing the default does not increase security in any way. With stronger security requirements you need to tweak a lot of other things, for example it would be paramount to use at least an airgapped box for such requirements. > I would really love to see these changes in wide use - and I fear > waiting for 2.3 will push this back for years for many users. Nope. We will anyway switch to ECC as soon as we can expect that most users are ready to use ECC. You can already create a key like this gpg --quick-generate-key foo at example.org future-default > 2.2. OTOH, the NSA is apparently developing a new supercomputer named > "WindsorGreen" believed to attack crypto, probably even "breaking Maybe. But that is irrelevant for most people: The real threat are pr?t-?-porter access methods: mass infection of all networked machines are much cheaper and a more effective way than to break crypto. That needs to be addressed elsewhere but in crypto software. Given the the sad state of software security we can only hope for political solutions against the use of government malware. 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 Sep 20 08:40:54 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 20 Sep 2017 08:40:54 +0200 Subject: [Announce] GnuPG 2.2.1 released In-Reply-To: (Robert J. Hansen's message of "Tue, 19 Sep 2017 13:55:21 -0400") References: <87poankkp5.fsf@wheatstone.g10code.de> <20170919153751.GI1026@zeromail.org> Message-ID: <87377hkh3d.fsf@wheatstone.g10code.de> On Tue, 19 Sep 2017 19:55, rjh at sixdemonbag.org said: > I, personally, would like to see GnuPG refuse to use 64-bit block > ciphers for encryption unless an option was set (--allow-old-ciphers, > perhaps). Leave the algorithms in there for RFC conformance, let them We can't do that in 2.2 but printing a warning to raise awareness is okay. Frankly, I doubt that this is a real world risk, because mails are too short. For backups and other large data encryption tasks, I assume that AES will anyway be used due to the very noticiable performance advantages. And AES is the default anyway. 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 Sep 20 08:52:22 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 20 Sep 2017 08:52:22 +0200 Subject: [GPGME PATCH] core: Restore get_max_fds optimization on Linux In-Reply-To: <877ewuzodd.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 19 Sep 2017 11:42:22 -0400") References: <20170916031644.gqkho4ow7kbrfdsf@riva.ucam.org> <20170916031719.6hqy5vruhbwrb7h6@riva.ucam.org> <877ewuzodd.fsf@fifthhorseman.net> Message-ID: <87y3p9j1zt.fsf@wheatstone.g10code.de> On Tue, 19 Sep 2017 17:42, dkg at fifthhorseman.net said: > I support adoption of this patch in GPGME upstream. It addresses a No question, it is on my shortlist and will be part of the next release. Colin: Thanks for coming up with the method. We might need a test or at least a configure option to disable it for older linux kernels. I also need to see whether it needas to be ported to other components of GnuPG. > pretty severe performance degradation in GPGME on Linux platforms that > was introduced between version 1.8.0 and 1.9.0. Actually the Linux specific optimization was only introduced with 1.7.0 on 2016-09-21 and disabled in 1.9.0 on 2017-03-28. I didn't liked to disable it but had to do it because of a real world race condition. 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 Sep 20 08:58:27 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 20 Sep 2017 08:58:27 +0200 Subject: [GPGME PATCH] core: Restore get_max_fds optimization on Linux In-Reply-To: (Alon Bar-Lev's message of "Tue, 19 Sep 2017 18:53:56 +0300") References: <20170916031644.gqkho4ow7kbrfdsf@riva.ucam.org> <20170916031719.6hqy5vruhbwrb7h6@riva.ucam.org> <877ewuzodd.fsf@fifthhorseman.net> Message-ID: <87tvzxj1po.fsf@wheatstone.g10code.de> On Tue, 19 Sep 2017 17:53, alon.barlev at gmail.com said: > What about of a solution of fork/exec a wrapper that closes handles > then exec the actual binary? We do this on Windows since the very beginning and I am glad that we can eventually can get rid of it due to a new API in Windows-7. Adding one to Unix makes me sad. However, for non-Linux a wrapper might be the most portable solution (and it would also help to get rid of a double-fork 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 dkg at fifthhorseman.net Wed Sep 20 15:38:55 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 20 Sep 2017 09:38:55 -0400 Subject: [GPGME PATCH] core: Restore get_max_fds optimization on Linux In-Reply-To: <87y3p9j1zt.fsf@wheatstone.g10code.de> References: <20170916031644.gqkho4ow7kbrfdsf@riva.ucam.org> <20170916031719.6hqy5vruhbwrb7h6@riva.ucam.org> <877ewuzodd.fsf@fifthhorseman.net> <87y3p9j1zt.fsf@wheatstone.g10code.de> Message-ID: <87lgl9wkuo.fsf@fifthhorseman.net> On Wed 2017-09-20 08:52:22 +0200, Werner Koch wrote: > No question, it is on my shortlist and will be part of the next release. great! Should we open a ticket to keep track of it? > Colin: Thanks for coming up with the method. We might need a test or at > least a configure option to disable it for older linux kernels. I also > need to see whether it needas to be ported to other components of GnuPG. If we make it optional, a configure option should be sufficient, and it should default to using this optimization. Please *don't* make the build choose a default based on the features of the currently-running kernel interface, most people who run GnuPG run it on a different machine than they build it on. >> pretty severe performance degradation in GPGME on Linux platforms that >> was introduced between version 1.8.0 and 1.9.0. > > Actually the Linux specific optimization was only introduced with 1.7.0 > on 2016-09-21 and disabled in 1.9.0 on 2017-03-28. I didn't liked to > disable it but had to do it because of a real world race condition. is there an explicit example of this race condition? debian stable is currently shipping gpgme 1.8.0, and if there's a real risk here i might want to backport this for a future point release. --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 Sep 20 18:59:09 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 20 Sep 2017 12:59:09 -0400 Subject: GnuPG cryptographic defaults on the 2.2 branch [was: Re: [Announce] GnuPG 2.2.1 released] In-Reply-To: <877ewtkhi3.fsf@wheatstone.g10code.de> References: <87poankkp5.fsf@wheatstone.g10code.de> <20170919153751.GI1026@zeromail.org> <877ewtkhi3.fsf@wheatstone.g10code.de> Message-ID: <87a81p5msi.fsf@fifthhorseman.net> On Wed 2017-09-20 08:32:04 +0200, Werner Koch wrote: > That is not a bug fix and thus this won't go into 2.2 unless there is a > security problem or regulations require the use of rsa3072. What kind of "security problem" are you thinking of that would trigger the change? afaict, the contract promise of the 2.2 branch for --gen-key should be "make a default key with reasonable parameters", not "make a default key with parameters that were considered reasonable when 2.1.0 was released". If the former interpretation is correct, i don't see what's stopping 2.2 from updating the defaults to reflect the current threat environment if it's generally understood to be a sensible improvement. As Robert points out, NIST recommends switching over to 3072-bit keys by 2020. Do we expect people who mint keys with the GnuPG stable branch today to be using those keys in 2020 (28 months from now)? Do we expect people to be using the GnuPG 2.2 branch in 2020? If so, the time to change the defaults for long-term key generation is *before* the suggested date. By default with 2.2.1, new keys are generated with a 24-month expiration date, so keys generated today are marked for expiration before 2020. But in 4 months from now, new keys generated by GnuPG 2.2.1 will claim usefulness into 2020. Do we want those keys to be 3072-bit keys? > Those who feel the need for longer keys can create longer keys. > Changing the default does not increase security in any way. For a single, experienced user, i'd agree with you. For the ecosystem as a whole, and for non-experienced users who don't want to know how it all works, changing the default does indeed have an impact. > With stronger security requirements you need to tweak a lot of other > things, for example it would be paramount to use at least an airgapped > box for such requirements. This statement seems to mix two different types of security requirements -- security against malware or system compromise vs. security against cryptanalytic attack. The goal of cryptographic software is to defend against cryptanalytic attack, to make it *more* expensive than, say, physical compromise. Put another way, GnuPG needs to take care against cryptanalytic attack so that the folks who are taking care of the other avenues of security don't find their work obviated by cryptanalytic attack. There is something to be said in favor of trying to raise the weakest link first, or to raise all bars at once, but when one tool doesn't control all the avenues of possible defense (e.g. gpg can't force people to use airgapped machiens) it can become an argument for inaction on all sides :( OTOH it can be useful to consider the "raise the weakest link" argument *within* the cryptographic defenses (which GnuPG *does* control all of in its context): raising the default RSA key length to 3072 actually puts it more on par with "128-bit" symmetric levels of security, so that the asymmetric crypto isn't the weak link compared (for example) to using AES128 as a symmetric cipher. 2048-bit RSA is widely estimated to have roughly the same defensive power as 112-bit symmetric crypto (see the Ecrypt-II recommendations, for example), so it is currently the weakest link. > Maybe. But that is irrelevant for most people: The real threat are > pr?t-?-porter access methods: mass infection of all networked machines > are much cheaper and a more effective way than to break crypto. That > needs to be addressed elsewhere but in crypto software. Given the the > sad state of software security we can only hope for political solutions > against the use of government malware. I agree we need to work on all of these fronts as a society to ensure that people can have robust, private, non-surveilled communications, and remain in control of their own data. That's why i'm happy that GnuPG is pushing on the cryptographic front :) All the best, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From myonium at gmail.com Thu Sep 21 07:55:49 2017 From: myonium at gmail.com (Myonium) Date: Thu, 21 Sep 2017 07:55:49 +0200 Subject: card_status - change-request to update allways In-Reply-To: <87h8vy9c1h.fsf@iwagami.gniibe.org> References: <87zidmc1wq.fsf@fsij.org> <92939132-CE14-4B41-95F4-12478AD85E74@gmail.com> <87h8vy9c1h.fsf@iwagami.gniibe.org> Message-ID: > On Sep 20, 2017, at 07:25, NIIBE Yutaka wrote: > > Myonium wrote: >> Could you please advise how to get the change below pushed in the next release? > > Sorry, it won't get in. Yes, I understand your use case; You want to > replace private key stub in .gnupg/private-keys-v1.d. > Yes correct. On "?card-status? I want to update the stubs to whatever there is on the card ? I want the use the keys on the attached smart card if possible. > For this use case, please remove your .gnupg/private-keys-v1.d/.key > manually, and do "gpg --card-status?. Yes that?s what I keep on doing all the time ? > > The change you proposed has an impact to existing behavior, that is, it > always modifies the privat key file when 'gpg --card-status' is invoked. You are right. However that is exactly what I would expect on a ??card-status?. I cannot think of any situation where this could result in a unwanted conflict. Would you prefer modifying stubs only in case the card changed? Or are you questioning replacing a key stub at all. To my understanding stubs are -in case of smart cards- only pointers indicating where to find the private key ?. updating these pointers on a ??card-status? seems to be a reasonable thing to me. > > Currently, GnuPG doesn't assume same key can be mutiple cards with > possiblly different serial number. This is definitely true for keys generated on the card. Fine for authentication keys. However when it comes to encryption this might not be a wise decision. A card might brake and who wants to loose all encrypted documents if a card breaks? To my understanding encryption keys need "a offline backup?: I case a card beaks the encryption key can be pushed on the replacement card. If you use different form factors (?Smart cards, Yubikey USB dongles, NFC enabled cards for mobiles) having the same keys on multiple cards makes totally sense ... If you think ?modifying stubs only in case the card changed? would be an acceptable solution I would be volunteer to work on it ... From ineiev at gnu.org Thu Sep 21 09:07:04 2017 From: ineiev at gnu.org (Ineiev) Date: Thu, 21 Sep 2017 03:07:04 -0400 Subject: GnuPG cryptographic defaults on the 2.2 branch [was: Re: [Announce] GnuPG 2.2.1 released] In-Reply-To: <87a81p5msi.fsf@fifthhorseman.net> References: <87poankkp5.fsf@wheatstone.g10code.de> <20170919153751.GI1026@zeromail.org> <877ewtkhi3.fsf@wheatstone.g10code.de> <87a81p5msi.fsf@fifthhorseman.net> Message-ID: <20170921070703.GR5966@gnu.org> On Wed, Sep 20, 2017 at 12:59:09PM -0400, Daniel Kahn Gillmor wrote: > The goal of cryptographic software is to defend against cryptanalytic > attack, to make it *more* expensive than, say, physical compromise. In many cases I'd prefer a cryptanalitic attack against my key to a physical attack aganist my person---if I were able to choose. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Digital signature URL: From peter at digitalbrains.com Thu Sep 21 11:43:10 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 21 Sep 2017 11:43:10 +0200 Subject: GnuPG cryptographic defaults on the 2.2 branch In-Reply-To: <87a81p5msi.fsf@fifthhorseman.net> References: <87poankkp5.fsf@wheatstone.g10code.de> <20170919153751.GI1026@zeromail.org> <877ewtkhi3.fsf@wheatstone.g10code.de> <87a81p5msi.fsf@fifthhorseman.net> Message-ID: <650d6944-b003-9982-950e-34299ed8cfee@digitalbrains.com> On 20/09/17 18:59, Daniel Kahn Gillmor wrote: > This statement seems to mix two different types of security requirements > -- security against malware or system compromise vs. security against > cryptanalytic attack. But if you're really up against people with that much cryptanalysis power, wouldn't they also be very advanced in different ways of attack? I think the NIST "by 2020" argument is much stronger than a worry about a super advanced machine that is in the worst scenario still a factor one billion removed from actually posing a threat to 2048-bit keys. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- 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 Sep 21 11:55:40 2017 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 21 Sep 2017 18:55:40 +0900 Subject: card_status - change-request to update allways In-Reply-To: References: <87zidmc1wq.fsf@fsij.org> <92939132-CE14-4B41-95F4-12478AD85E74@gmail.com> <87h8vy9c1h.fsf@iwagami.gniibe.org> Message-ID: <87shfgcr4z.fsf@fsij.org> Hello, I think that I understand your case (partially, at least). I don't deny existence of such a use case. And I admit it is a bit difficult to do manual removal of private key file. I think that it is because of the (historical) decision or assumption serial number of card can be stable identifier. I want to fix this, too. Myonium wrote: > Would you prefer modifying stubs only in case the card changed? Given the situation that GnuPG 2.2.x is bug fix only release(s), my idea is avoiding small changes, but to introduce major change, real change for card management, into master branch of GnuPG. > To my understanding stubs are -in case of smart cards- only pointers > indicating where to find the private key ?. Exactly. It seems for me that we can remove this (non-)feature of recording serial number in private key file, completely. Currently, a serial number of the card is used as a kind of permanent identifier of a card. I think that we need to locate such assumptions in the protocol and the implementation of gpg-agent and scdaemon. Then, we can fix them. While T1983 was being fixed, gpg frontend introduced an access to available card keys. This is a step forward to use a serial number of card as runtime/volatile identifier but not as permanent identifier. I don't have whole picture at hand, not yet. If possible, please help us to locate the places in gpg-agent where it uses the recorded serial number, and/or investigate how we can remove that. -- From wk at gnupg.org Thu Sep 21 14:23:35 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 21 Sep 2017 14:23:35 +0200 Subject: card_status - change-request to update allways In-Reply-To: <87shfgcr4z.fsf@fsij.org> (NIIBE Yutaka's message of "Thu, 21 Sep 2017 18:55:40 +0900") References: <87zidmc1wq.fsf@fsij.org> <92939132-CE14-4B41-95F4-12478AD85E74@gmail.com> <87h8vy9c1h.fsf@iwagami.gniibe.org> <87shfgcr4z.fsf@fsij.org> Message-ID: <877ewsgrzs.fsf@wheatstone.g10code.de> On Thu, 21 Sep 2017 11:55, gniibe at fsij.org said: > It seems for me that we can remove this (non-)feature of recording > serial number in private key file, completely. One of the reasons to implemented the extended private key format was to make it easier to add meta data to a private key. For example several S/N could be added to the private key file and it would also be easier to automatically remove them. Having a way to ask the user to insert a certain card using data which is permanently associated with the card (printed serial number) is a very useful feature and cannot, according to my experience, be replaced by just asking for the key id or such. 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 Thu Sep 21 17:32:11 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 21 Sep 2017 11:32:11 -0400 Subject: GnuPG cryptographic defaults on the 2.2 branch [was: Re: [Announce] GnuPG 2.2.1 released] In-Reply-To: <20170921070703.GR5966@gnu.org> References: <87poankkp5.fsf@wheatstone.g10code.de> <20170919153751.GI1026@zeromail.org> <877ewtkhi3.fsf@wheatstone.g10code.de> <87a81p5msi.fsf@fifthhorseman.net> <20170921070703.GR5966@gnu.org> Message-ID: <87a81o3w5g.fsf@fifthhorseman.net> On Thu 2017-09-21 03:07:04 -0400, Ineiev wrote: > On Wed, Sep 20, 2017 at 12:59:09PM -0400, Daniel Kahn Gillmor wrote: >> The goal of cryptographic software is to defend against cryptanalytic >> attack, to make it *more* expensive than, say, physical compromise. > > In many cases I'd prefer a cryptanalitic attack against my key > to a physical attack aganist my person---if I were able to choose. I'd prefer to not be attacked at all -- if i were able to choose. :) Do you think we should avoid the use of cryptography entirely, so that network-based adversaries can monitor us from a distance without getting too close? Your adversary being able to secretly attack your data from a distance without touching you doesn't somehow protect you from being attacked "IRL" in the long run. In many cases, surveillance and privacy violations are the first step toward other negative consequences to the surveilled party, up to and including physical attacks against your person. Keeping your data cryptographically protected, whether at rest or in motion, is a way to defend yourself from physical attack, not to encourage it. Please don't advance this false dichotomy. --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 Thu Sep 21 17:39:21 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 21 Sep 2017 11:39:21 -0400 Subject: GnuPG cryptographic defaults on the 2.2 branch In-Reply-To: <650d6944-b003-9982-950e-34299ed8cfee@digitalbrains.com> References: <87poankkp5.fsf@wheatstone.g10code.de> <20170919153751.GI1026@zeromail.org> <877ewtkhi3.fsf@wheatstone.g10code.de> <87a81p5msi.fsf@fifthhorseman.net> <650d6944-b003-9982-950e-34299ed8cfee@digitalbrains.com> Message-ID: <877ews3vti.fsf@fifthhorseman.net> On Thu 2017-09-21 11:43:10 +0200, Peter Lebbing wrote: > On 20/09/17 18:59, Daniel Kahn Gillmor wrote: >> This statement seems to mix two different types of security requirements >> -- security against malware or system compromise vs. security against >> cryptanalytic attack. > > But if you're really up against people with that much cryptanalysis > power, wouldn't they also be very advanced in different ways of attack? maybe! they might also have different cost analyses when comparing detectable actions in the real world with actions they think they'll be able to keep secret (or at least to deny easily). I'm not saying these other avenues aren't worth defending against. they clearly are. I'm saying that GnuPG isn't in a position to defend against them, but it should take care of those aspects that it is in a position to defend against. > I think the NIST "by 2020" argument is much stronger than a worry about > a super advanced machine that is in the worst scenario still a factor > one billion removed from actually posing a threat to 2048-bit keys. compliance with checkbox-driven quasi-regulatory guidance does sometimes have its moments :) --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From kristian.fiskerstrand at sumptuouscapital.com Thu Sep 21 17:53:36 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Thu, 21 Sep 2017 17:53:36 +0200 Subject: GnuPG cryptographic defaults on the 2.2 branch In-Reply-To: <877ews3vti.fsf@fifthhorseman.net> References: <87poankkp5.fsf@wheatstone.g10code.de> <20170919153751.GI1026@zeromail.org> <877ewtkhi3.fsf@wheatstone.g10code.de> <87a81p5msi.fsf@fifthhorseman.net> <650d6944-b003-9982-950e-34299ed8cfee@digitalbrains.com> <877ews3vti.fsf@fifthhorseman.net> Message-ID: On 09/21/2017 05:39 PM, Daniel Kahn Gillmor wrote: > I'm not saying these other avenues aren't worth defending against. they > clearly are. I'm saying that GnuPG isn't in a position to defend > against them, but it should take care of those aspects that it is in a > position to defend against. Although I tend to agree with the goal, the primary issue is a false sense of security that can actually be a worse situation as data is transmitted that wouldn't otherwise be. Social problems can't be solved solely using technical means, and there is a severe lack of education/knowledge on security aspects such as, inter alia, operational security. Granted that is just as true for 2048 bit keylength, but thinking increasing it to 3072 bit has a noticeable impact on the actual security for the user on its own doesn't compute for me, and in some cases it can reduce the security as it isn't compatible with certain hardware tokens (like youbikey 3 neo). -- ---------------------------- 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 ---------------------------- "If you choose to sail upon the seas of banking, build your bank as you would your boat, with the strength to sail safely through any storm." (Jacob Safra (1891?1963)) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Thu Sep 21 18:18:31 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 21 Sep 2017 12:18:31 -0400 Subject: GnuPG cryptographic defaults on the 2.2 branch In-Reply-To: References: <87poankkp5.fsf@wheatstone.g10code.de> <20170919153751.GI1026@zeromail.org> <877ewtkhi3.fsf@wheatstone.g10code.de> <87a81p5msi.fsf@fifthhorseman.net> <650d6944-b003-9982-950e-34299ed8cfee@digitalbrains.com> <877ews3vti.fsf@fifthhorseman.net> Message-ID: <87poak2ffs.fsf@fifthhorseman.net> On Thu 2017-09-21 17:53:36 +0200, Kristian Fiskerstrand wrote: > Social problems can't be solved solely using technical means, and there > is a severe lack of education/knowledge on security aspects such as, > inter alia, operational security. agreed, sadly. > Granted that is just as true for 2048 bit keylength, but thinking > increasing it to 3072 bit has a noticeable impact on the actual > security for the user on its own doesn't compute for me weak crypto defaults can actually *discourage* operational security, because some people come up with "why bother when the key is able to be cracked anyway". I'm not saying that RSA-2048 should be considered trivially breakable, but an argument about how unsophisticated users experience choices of cryptographic defaults actually cuts both ways. > and in some cases it can reduce the security as it isn't compatible > with certain hardware tokens (like youbikey 3 neo). Users with a yubikey (or other hardware tokens) will make keys that will fit onto their devices. I don't think that the default is an issue for them. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From ilf at zeromail.org Thu Sep 21 18:21:30 2017 From: ilf at zeromail.org (ilf) Date: Thu, 21 Sep 2017 18:21:30 +0200 Subject: GnuPG cryptographic defaults on the 2.2 branch In-Reply-To: References: <87poankkp5.fsf@wheatstone.g10code.de> <20170919153751.GI1026@zeromail.org> <877ewtkhi3.fsf@wheatstone.g10code.de> <87a81p5msi.fsf@fifthhorseman.net> <650d6944-b003-9982-950e-34299ed8cfee@digitalbrains.com> <877ews3vti.fsf@fifthhorseman.net> Message-ID: <20170921162130.GN6807@zeromail.org> Kristian Fiskerstrand: > Although I tend to agree with the goal, the primary issue is a false > sense of security that can actually be a worse situation as data is > transmitted that wouldn't otherwise be. As someone who argues for stronger default keysizes because they might help (however few) people in some cases, I am very much interested in arguments *against* raising the defaults. I would have expected computational overhead or waste of resources to argue against. But I doubt your argument is true. I would assume very, very few people would not enter things into a computer because the key size is 2048, which they would enter with a keysize of 3072 - and even if so, the problem would not be the default keysize we set, but user education here. Noone claims anything is unbreakable, and both 2048 and 3072 are very reasonable for the state being. I am merely asking for more safety margin, which comes at little to no cost. -- 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 ineiev at gnu.org Thu Sep 21 18:40:17 2017 From: ineiev at gnu.org (Ineiev) Date: Thu, 21 Sep 2017 12:40:17 -0400 Subject: GnuPG cryptographic defaults on the 2.2 branch [was: Re: [Announce] GnuPG 2.2.1 released] In-Reply-To: <87a81o3w5g.fsf@fifthhorseman.net> References: <87poankkp5.fsf@wheatstone.g10code.de> <20170919153751.GI1026@zeromail.org> <877ewtkhi3.fsf@wheatstone.g10code.de> <87a81p5msi.fsf@fifthhorseman.net> <20170921070703.GR5966@gnu.org> <87a81o3w5g.fsf@fifthhorseman.net> Message-ID: <20170921164017.GV5966@gnu.org> On Thu, Sep 21, 2017 at 11:32:11AM -0400, Daniel Kahn Gillmor wrote: > I'd prefer to not be attacked at all -- if i were able to choose. :) > > Do you think we should avoid the use of cryptography entirely, so that > network-based adversaries can monitor us from a distance without getting > too close? Your adversary being able to secretly attack your data from > a distance without touching you doesn't somehow protect you from being > attacked "IRL" in the long run. There are adversaries and adversaries. I met people who were happy with adversaries like their government reading all their data, but not with adversaries like their ISP logging the sites they accessed (and vice versa). > In many cases, surveillance and privacy violations are the first step > toward other negative consequences to the surveilled party, up to and > including physical attacks against your person. In that context, it becomes a matter of beliefs. > Keeping your data cryptographically protected, whether at rest or in > motion, is a way to defend yourself from physical attack, not to > encourage it. IMVHO it depends. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Digital signature URL: From rjh at sixdemonbag.org Thu Sep 21 18:56:56 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 21 Sep 2017 12:56:56 -0400 Subject: GnuPG cryptographic defaults on the 2.2 branch In-Reply-To: <20170921162130.GN6807@zeromail.org> References: <87poankkp5.fsf@wheatstone.g10code.de> <20170919153751.GI1026@zeromail.org> <877ewtkhi3.fsf@wheatstone.g10code.de> <87a81p5msi.fsf@fifthhorseman.net> <650d6944-b003-9982-950e-34299ed8cfee@digitalbrains.com> <877ews3vti.fsf@fifthhorseman.net> <20170921162130.GN6807@zeromail.org> Message-ID: <627b3a5d-13ca-2abf-61c3-1bdec710a0dc@sixdemonbag.org> > I am merely asking for more safety > margin, which comes at little to no cost. And the proper response to this is, "absolutely not". *Why* we add more margin is as important as the margin itself. There are some very good justifications to move to RSA-3072: * Compliance with NIST guidance * Raising the minimum estimated work factor to 2**127 * User demand * Etc., etc. But "it costs very little to get more margin", when our margin is already a factor of a *billion* stronger than it needs to be, is just a nonstarter. If a billion isn't enough for you, then what is? From myonium at gmail.com Thu Sep 21 19:18:35 2017 From: myonium at gmail.com (Myonium) Date: Thu, 21 Sep 2017 19:18:35 +0200 Subject: card_status - change-request to update allways In-Reply-To: <877ewsgrzs.fsf@wheatstone.g10code.de> References: <87zidmc1wq.fsf@fsij.org> <92939132-CE14-4B41-95F4-12478AD85E74@gmail.com> <87h8vy9c1h.fsf@iwagami.gniibe.org> <87shfgcr4z.fsf@fsij.org> <877ewsgrzs.fsf@wheatstone.g10code.de> Message-ID: <8A0A4BE0-EAB1-48BF-91D4-EF52DE90AB17@gmail.com> > On Sep 21, 2017, at 14:23, Werner Koch wrote: > > On Thu, 21 Sep 2017 11:55, gniibe at fsij.org said: > >> It seems for me that we can remove this (non-)feature of recording >> serial number in private key file, completely. > > One of the reasons to implemented the extended private key format was to > make it easier to add meta data to a private key. For example several > S/N could be added to the private key file and it would also be easier > to automatically remove them. > > Having a way to ask the user to insert a certain card using data which > is permanently associated with the card (printed serial number) is a > very useful feature and cannot, according to my experience, be replaced > by just asking for the key id or such. I think hinting the user which card to insert to for a card based key operation is a great feature I wouldn't like to miss. There is a good chance that users will have multiple keys on different cards. If none of the attached cards contain a matching key this notice is very welcome. In this respect the key stub as a memory entry where the private key was last seen, seems to be a good thing for me. But it is frustrating if you get ask to insert a different card even so a card inserted contains a matching key. Updating the stubs with ??card-status? would work for me. An automatic check on all connected cards would be cool ? but maybe slow ... > > > Salam-Shalom, > > Werner > > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From angel at pgp.16bits.net Thu Sep 21 20:06:29 2017 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Thu, 21 Sep 2017 20:06:29 +0200 Subject: GnuPG cryptographic defaults on the 2.2 branch In-Reply-To: <87poak2ffs.fsf@fifthhorseman.net> References: <87poankkp5.fsf@wheatstone.g10code.de> <20170919153751.GI1026@zeromail.org> <877ewtkhi3.fsf@wheatstone.g10code.de> <87a81p5msi.fsf@fifthhorseman.net> <650d6944-b003-9982-950e-34299ed8cfee@digitalbrains.com> <877ews3vti.fsf@fifthhorseman.net> <87poak2ffs.fsf@fifthhorseman.net> Message-ID: <1506017189.919.4.camel@16bits.net> On 2017-09-21 at 12:18 -0400, Daniel Kahn Gillmor wrote: > > and in some cases it can reduce the security as it isn't compatible > > with certain hardware tokens (like youbikey 3 neo). > > Users with a yubikey (or other hardware tokens) will make keys that > will fit onto their devices. I don't think that the default is an > issue for them. It would be a problem for them if they created a local key using defaults, and after some time wanted to move it to a hardware token where it doesn't fit. However, what this should do is encourage hardware vendors to support larger keys, not freeze key size in order to support certain tokens! From ilf at zeromail.org Fri Sep 22 10:17:07 2017 From: ilf at zeromail.org (ilf) Date: Fri, 22 Sep 2017 10:17:07 +0200 Subject: GnuPG cryptographic defaults on the 2.2 branch In-Reply-To: <627b3a5d-13ca-2abf-61c3-1bdec710a0dc@sixdemonbag.org> References: <87poankkp5.fsf@wheatstone.g10code.de> <20170919153751.GI1026@zeromail.org> <877ewtkhi3.fsf@wheatstone.g10code.de> <87a81p5msi.fsf@fifthhorseman.net> <650d6944-b003-9982-950e-34299ed8cfee@digitalbrains.com> <877ews3vti.fsf@fifthhorseman.net> <20170921162130.GN6807@zeromail.org> <627b3a5d-13ca-2abf-61c3-1bdec710a0dc@sixdemonbag.org> Message-ID: <20170922081707.GO6807@zeromail.org> Robert J. Hansen: > But "it costs very little to get more margin", when our margin is > already a factor of a *billion* stronger than it needs to be, is just a > nonstarter. If a billion isn't enough for you, then what is? Yes, but this is *now*. But I am arguing for the future in a dozen or more years. We're talking about defaults that will be used until the 2.3 release - that might be years. (2?) Even the last 2.2 before 2.3 will be used by distributions years after. (3?) People generate keys with that 2.2 that will be used for encryption years after they are generated. (5?) And *that* encryption should still be considered strong against attacks at least a decade after the initial encryption, in some cases way more than that. That's a lot of assumptions about the future here, but I do think those values to be reasonable. So we're deciding *now* on what should have enough safety margin for in 20 years. Looking at the last 20, I'd rather be safe than sorry. > There are some very good justifications to move to RSA-3072: Well we agree on that. :) -- 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 ben at adversary.org Fri Sep 22 09:18:00 2017 From: ben at adversary.org (Ben McGinnes) Date: Fri, 22 Sep 2017 17:18:00 +1000 Subject: GnuPG cryptographic defaults on the 2.2 branch [was: Re: [Announce] GnuPG 2.2.1 released] In-Reply-To: <20170921164017.GV5966@gnu.org> References: <87poankkp5.fsf@wheatstone.g10code.de> <20170919153751.GI1026@zeromail.org> <877ewtkhi3.fsf@wheatstone.g10code.de> <87a81p5msi.fsf@fifthhorseman.net> <20170921070703.GR5966@gnu.org> <87a81o3w5g.fsf@fifthhorseman.net> <20170921164017.GV5966@gnu.org> Message-ID: <20170922071800.2ctnuarehbdpmswi@adversary.org> On Thu, Sep 21, 2017 at 04:40:17PM +0000, Ineiev wrote: > On Thu, Sep 21, 2017 at 11:32:11AM -0400, Daniel Kahn Gillmor wrote: >> I'd prefer to not be attacked at all -- if i were able to choose. :) >> >> Do you think we should avoid the use of cryptography entirely, so that >> network-based adversaries can monitor us from a distance without getting >> too close? Your adversary being able to secretly attack your data from >> a distance without touching you doesn't somehow protect you from being >> attacked "IRL" in the long run. > > There are adversaries and adversaries. And then there's my adversary.org. C'mon, I so rarely get to play on that line or similar. > I met people who were happy with adversaries like their government > reading all their data, but not with adversaries like their ISP > logging the sites they accessed (and vice versa). I can understand that and that most are probably more concerned about what might fall in between. Take my situation, I know the biggest technical threat is one of or more of the alphabet agencies. I also know that messages of mine will be in the bank of collected encrypted communications the NSA collects just for practice. I know my name will have popper up in regards to a few things (probably beginning with those PGP signed emails to their own SELinux mailing list back when it launched). OTOH, everything I do that they would or do object to is both entirely public anyway and also an insignificant speck of civil disobedience compared to what they're actually stalking the world after on any given turning of the globe. There's much greater potential threat locally, some with the trappings of an office or position and some without. As long as I don't do something more than a little stupid, then my files and messages are quite save; leaving the principal concerns to gregulatory, physical, medical and other points of corruption ... or as they prefer to put it, governmental oversight. I imagine many people have similar sorts of situations. The potential threat which seems more intellectual and detached, by comparison to some thing or a number of things closer to home and which instil a more visceral reaction. Very few in this worls are in the position where the greatest technical threat also poses the most visceral intended threat. Most of those in that position are actively hunted so viggorously that they either fall, or their health deterorates from the stress. I believe currently there would arguably be only one exception to that: Edward Snowden. Most of the rest of us aren't anywhere near that position, in spite of the interesting intersectional points we may skate through. >> In many cases, surveillance and privacy violations are the first step >> toward other negative consequences to the surveilled party, up to and >> including physical attacks against your person. > > In that context, it becomes a matter of beliefs. That depends on how you measure beliefs I guess. My government already has mandatory data retention in play (all of which I circumvent, there's a reason my MX is in Germany). Now they're already planning on taking that much further with electronic health records containing everything, no matter how sensitive, in a system which they reduced the security of to make it work with mobile phones and have a history of not protectingMedicare records. Necause how could that possibly end badly as long as you have total faith in the Goodness? of those in charge? Oh, right, that's got total disaster written all over it from the outset. Without even taking into accountb departmental reports referring to the patient data of everyone in the country as a commercial asset, as well as referring to patient surveillance (by which they did *not* mean they were content to wait).. >> Keeping your data cryptographically protected, whether at rest or in >> motion, is a way to defend yourself from physical attack, not to >> encourage it. > > IMVHO it depends. Yes, but more often than not there will be greater benefit to leaving things encrypted than in not doing so. I'll grant that it's still a bit subjective, but I suspect we'd find the same inclination reflected across most people lurking around these projects (i.e. beyond just developers). Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: From fabian at henneke.me Fri Sep 22 15:46:43 2017 From: fabian at henneke.me (Fabian Henneke) Date: Fri, 22 Sep 2017 13:46:43 +0000 Subject: Constructed data objects on the OpenPGP card Message-ID: Hi, in the process of developing Chrome/Chromium extensions that support decryption and authentication using OpenPGP cards, I may have found an aspect in which the OpenPGP smart card (the physical device) deviates from the OpenPGP card specification ( https://g10code.com/docs/openpgp-card-2.1.pdf). As it is very well possible that either my interpretation of the spec or my implementation are at fault, I would like to obtain confirmation in this way. The OpenPGP card specification in version 2.1 says in Section 4.3.1, "DOs for GET DATA": "Constructed DOs (C, marked yellow) are returned including their tag and length.". I take this to mean that if for example I were to send a GET DATA request for the Application Related Data (Tag 6E), I would expect to see a single constructed tag 6E in the TLV-encoded response, which then contains as its value a list of the subtags of this constructed tag (e.g. the Application Identifier and PW Status Bytes). I found this interpretation to be consistent with some implementations of the OpenPGP applet (for example on Yubikeys). A log of the communication with the card that a user with an OpenPGP smart card (the physical device, version 2.1) sent me shows that it exhibits a different behavior: All the "subtags" of constructed tag 6E are returned sequentially as a list of tags with no encompassing 6E tag. I would be grateful for any confirmation of the general structure of constructed tags I should expect as responses to GET DATA requests. I have ordered an OpenPGP smart card and will also conduct my own experiments. Fabian -------------- next part -------------- An HTML attachment was scrubbed... URL: From achim at pietig.com Fri Sep 22 17:28:13 2017 From: achim at pietig.com (Achim Pietig) Date: Fri, 22 Sep 2017 17:28:13 +0200 Subject: Constructed data objects on the OpenPGP card In-Reply-To: References: Message-ID: <2b53f177-0f0e-63dc-c059-b0c8bf5a464e@pietig.com> Hi Fabian, a GET DATA command returns only the content of a DO, the given Tag (e. g. 6E) in P1/P2 is never present in the answer of GET DATA. The meaning of the sentence "Constructed DOs (C, marked yellow) are returned including their tag and length" relates only to the Sub-Tags under the main Tag 6E - I see that this may not be clearly enough. I added this to separate the "normal" behaviour of GET DATA from variants that read a tag or data list - in that case only the contents of all sub-tags are returned in a sequence without tag/lenght. Regards Achim Am 22.09.2017 um 15:46 schrieb Fabian Henneke via Gnupg-devel: > Hi, > > in the process of developing Chrome/Chromium extensions that support decryption and authentication using OpenPGP cards, I may have found an aspect in which the OpenPGP smart card (the physical device) > deviates from the OpenPGP card specification (https://g10code.com/docs/openpgp-card-2.1.pdf). As it is very well possible that either my interpretation of the spec or my implementation are at fault, I > would like to obtain confirmation in this way. > > The OpenPGP card specification in version 2.1 says in Section 4.3.1, "DOs for GET DATA": "Constructed DOs (C, marked yellow) are returned including their tag and length.". I take this to mean that if > for example I were to send a GET DATA request for the Application Related Data (Tag 6E), I would expect to see a single constructed tag 6E in the TLV-encoded response, which then contains as its value > a list of the subtags of this constructed tag (e.g. the Application Identifier and PW Status Bytes). I found this interpretation to be consistent with some implementations of the OpenPGP applet (for > example on Yubikeys).? > A log of the communication with the card that a user with an OpenPGP smart card (the physical device, version 2.1) sent me shows that it exhibits a different behavior: All the "subtags" of constructed > tag 6E are returned sequentially as a list of tags with no encompassing 6E tag. > > I would be grateful for any confirmation of the general structure of constructed tags I should expect as responses to GET DATA requests. I have ordered an OpenPGP smart card and will also conduct my > own experiments. > > Fabian > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > From cjwatson at debian.org Sat Sep 23 20:28:30 2017 From: cjwatson at debian.org (Colin Watson) Date: Sat, 23 Sep 2017 19:28:30 +0100 Subject: [GPGME PATCH] core: Restore get_max_fds optimization on Linux In-Reply-To: <87fubixshl.fsf@fifthhorseman.net> References: <20170916031644.gqkho4ow7kbrfdsf@riva.ucam.org> <20170916031719.6hqy5vruhbwrb7h6@riva.ucam.org> <877ewuzodd.fsf@fifthhorseman.net> <87fubixshl.fsf@fifthhorseman.net> Message-ID: <20170923182830.auvuusqcg2fmzdw4@riva.ucam.org> On Tue, Sep 19, 2017 at 05:56:22PM -0400, Daniel Kahn Gillmor wrote: > i guess arm64 is new enough that it doesn't support the 32-bit > SYS_getdents at all? Hmm, I guess so. Thanks for letting me know. > Colin, do you want to propose a change to the patch so that it'll build > on that platform? should we just move it to getdents64 for all > platforms? SYS_getdents64 was added in Linux 2.4, and Python appears to just go ahead and use that. I have a plane trip coming up, so I might experiment with this on the way and see if it's better to use SYS_getdents64 or to take the fork/exec approach after all. -- Colin Watson [cjwatson at debian.org] From gniibe at fsij.org Mon Sep 25 03:07:32 2017 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 25 Sep 2017 10:07:32 +0900 Subject: card_status - change-request to update allways In-Reply-To: <877ewsgrzs.fsf@wheatstone.g10code.de> References: <87zidmc1wq.fsf@fsij.org> <92939132-CE14-4B41-95F4-12478AD85E74@gmail.com> <87h8vy9c1h.fsf@iwagami.gniibe.org> <87shfgcr4z.fsf@fsij.org> <877ewsgrzs.fsf@wheatstone.g10code.de> Message-ID: <87bmlzwppn.fsf@iwagami.gniibe.org> Werner Koch wrote: > Having a way to ask the user to insert a certain card using data which > is permanently associated with the card (printed serial number) is a > very useful feature and cannot, according to my experience, be replaced > by just asking for the key id or such. For some cards, it's true. Card has a unique serial number by manufacturer, which is printed on the card, and a user can recognize the number. A user _can_ use the unique serial number to identify his key. Or... a user could have a practice to strongly assosicate his key to a specific physical media with specific serial number. I don't deny this use case. I know about, the use case of strong association between the serial number and private keys; Some users want to do that. (When he finds his keys on different card, he might want to be notified.) I don't propose killing this. My point is that the use of strong association should not be _required_ (or assumed) for all users always. Speaking about my use case, I identify my tokens by its enclosure, like blue one, red one, one with GPG logo, etc. In this use case, it is more useful for me to be notified "please insert red token" than "please insert token with S/N: xxxx". When I need, I check the serial number by "gpg --card-status". Please note that there are many tokens (Gnuk Token implementations, Nitrokey, Yubikey, etc.), which are basically used without printed serial number on the hardware. -- From wk at gnupg.org Mon Sep 25 10:05:47 2017 From: wk at gnupg.org (Werner Koch) Date: Mon, 25 Sep 2017 10:05:47 +0200 Subject: card_status - change-request to update allways In-Reply-To: <87bmlzwppn.fsf@iwagami.gniibe.org> (NIIBE Yutaka's message of "Mon, 25 Sep 2017 10:07:32 +0900") References: <87zidmc1wq.fsf@fsij.org> <92939132-CE14-4B41-95F4-12478AD85E74@gmail.com> <87h8vy9c1h.fsf@iwagami.gniibe.org> <87shfgcr4z.fsf@fsij.org> <877ewsgrzs.fsf@wheatstone.g10code.de> <87bmlzwppn.fsf@iwagami.gniibe.org> Message-ID: <87r2uv9p9g.fsf@wheatstone.g10code.de> On Mon, 25 Sep 2017 03:07, gniibe at fsij.org said: > Speaking about my use case, I identify my tokens by its enclosure, like > blue one, red one, one with GPG logo, etc. In this use case, it is more That would also benefit my uses cases. I use one Zeitcontrol card which I am used to identify by the serial number (also in authorized_keys) but for the Gnuk a "insert your standard gnuk" would be a better description for me. What about this idea: We move the S/N out of the s-expression used to describe the key into a name tag field in the extended private key format file. gnupg/agent/keyformat.txt has this description of the exdended key format for quite some time: Description: Key to sign all GnuPG released tarballs. The key is actually stored on a smart card. Use-for-ssh: yes OpenSSH-cert: long base64 encoded string wrapped so that this key file can be easily edited with a standard editor. Key: (shadowed-private-key (rsa (n #00AA1AD2A55FD8C8FDE9E1941772D9CC903FA43B268CB1B5A1BAFDC900 2961D8AEA153424DC851EF13B83AC64FBE365C59DC1BD3E83017C90D4365B4 83E02859FC13DB5842A00E969480DB96CE6F7D1C03600392B8E08EF0C01FC7 19F9F9086B25AD39B4F1C2A2DF3E2BE317110CFFF21D4A11455508FE407997 601260816C8422297C0637BB291C3A079B9CB38A92CE9E551F80AA0EBF4F0E 72C3F250461E4D31F23A7087857FC8438324A013634563D34EFDDCBF2EA80D F9662C9CCD4BEF2522D8BDFED24CEF78DC6B309317407EAC576D889F88ADA0 8C4FFB480981FB68C5C6CA27503381D41018E6CDC52AAAE46B166BDC10637A E186A02BA2497FDC5D1221#) (e #00010001#) (shadowed t1-v1 (#D2760001240102000005000011730000# OPENPGP.1) ))) All fields except for Key: are optional. The "Description" field is what it says and should be considered a plain comment on the key. My proposal now would be to write such a stub key with a new field Title: S/N 123456788990000 the first time a stub key is written or when it is updated. The serial number would be the default but the user could at any time change that to whatever is more appropriate to be shown by Pinentry. This would fix the UI for key/card association. What to do for checking whether the right card is inserted is a different question, though. Maybe another field "Serial" which is used for this unless "Title" is also set? 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 lukele at gpgtools.org Tue Sep 26 02:06:15 2017 From: lukele at gpgtools.org (Lukas Pitschl | GPGTools) Date: Tue, 26 Sep 2017 02:06:15 +0200 Subject: Option to pass fingerprint to pinentry instead of keygrip (or both) Message-ID: <0524FD92-CF5A-40EA-8C47-18CDB82C005C@gpgtools.org> Hi all, I noticed that GnuPG 2.2 (probably version > 2.0.X) no longer passes the fingerprint of a key to pinentry, but instead a key grip. I was wondering if it is possible to activate some option that makes sure pinentry receives the fingerprint again or if the key grip is the identifier we have to live with now? Or rather, is it possible to receive both, the fingerprint and the key grip? While the key grip certainly makes sense, it currently breaks all existing keychain entries and lookups. Best, Lukas GPGTools -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: Message signed with OpenPGP using GPGMail URL: From wk at gnupg.org Tue Sep 26 10:19:26 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 26 Sep 2017 10:19:26 +0200 Subject: Option to pass fingerprint to pinentry instead of keygrip (or both) In-Reply-To: <0524FD92-CF5A-40EA-8C47-18CDB82C005C@gpgtools.org> (Lukas Pitschl's message of "Tue, 26 Sep 2017 02:06:15 +0200") References: <0524FD92-CF5A-40EA-8C47-18CDB82C005C@gpgtools.org> Message-ID: <87wp4l6fe9.fsf@wheatstone.g10code.de> On Tue, 26 Sep 2017 02:06, lukele at gpgtools.org said: > I noticed that GnuPG 2.2 (probably version > 2.0.X) no longer passes > the fingerprint of a key to pinentry, but instead a key grip. I was Pinentry never used the fingerprint. What you see is a description formatted in most cases by gpg. This usually included the fingerprint but this is nothing Pinentry will ever be able to evaluate The keygrip is set as additional meta data using the SETKEYINFO command. Some pinentries use this string to lookup a passphrase in a cache. For example from the GNOME keyring manager. That string is based on the keygrip but should be considered an opaque cache id for the passphrase. May it be that you are used to gpg-agent's simple GET_PASSPHRASE command which also takes an opaque cache id? Since 2.1 GET_PASSPHRASE is not anymore used by public key operations because the private key and its passphrase is solely handled by gpg-agent. 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 lukele at gpgtools.org Wed Sep 27 02:00:58 2017 From: lukele at gpgtools.org (Lukas Pitschl | GPGTools) Date: Wed, 27 Sep 2017 02:00:58 +0200 Subject: GnuPG 2.2 - Comments in gpg.conf Message-ID: Hi all, today a case was reported to us, where calling different gpg commands to sign or list keys only printed the following lines and exited after that: hostname:~ username$ gpg --list-secret-keys gpg: '0x7293626A6BF781D1 # astephens' ist keine g?ltige lange Schl?ssel-ID gpg: '0xFBE2D12AFC23DAE1 # cestel' ist keine g?ltige lange Schl?ssel-ID The following 2 lines in gpg.conf where causing this issue: trusted-key 0x7293626A6BF781D1 # astephens trusted-key 0xFBE2D12AFC23DAE1 # cestel Upon further inspection it appears that gpg.conf doesn?t allow comments at the end of options. Since the upgrade to GnuPG 2.2 triggered this problem for our user, I assume they weren?t seeing the same when still using GnuPG 2.0.X I was wondering if this is a bug, or if this is expected behavior in GnuPG 2.2 Best, Lukas GPGTools From wk at gnupg.org Thu Sep 28 14:13:53 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 28 Sep 2017 14:13:53 +0200 Subject: GnuPG 2.2 - Comments in gpg.conf In-Reply-To: (Lukas Pitschl's message of "Wed, 27 Sep 2017 02:00:58 +0200") References: Message-ID: <877ewj2f7i.fsf@wheatstone.g10code.de> On Wed, 27 Sep 2017 02:00, lukele at gpgtools.org said: > The following 2 lines in gpg.conf where causing this issue: > trusted-key 0x7293626A6BF781D1 # astephens > trusted-key 0xFBE2D12AFC23DAE1 # cestel > > Upon further inspection it appears that gpg.conf doesn?t allow comments at the end of options. What do you think of the attached but untested patch? It would help for these configurations. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-gpg-Workaround-for-junk-after-trusted-key.patch Type: text/x-diff Size: 1622 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 ilf at zeromail.org Thu Sep 28 15:10:13 2017 From: ilf at zeromail.org (ilf) Date: Thu, 28 Sep 2017 15:10:13 +0200 Subject: GnuPG 2.2 - Comments in gpg.conf In-Reply-To: <877ewj2f7i.fsf@wheatstone.g10code.de> References: <877ewj2f7i.fsf@wheatstone.g10code.de> Message-ID: <20170928131013.GM1010@zeromail.org> Werner Koch: >> Upon further inspection it appears that gpg.conf doesn?t allow >> comments at the end of options. > What do you think of the attached but untested patch? It would help > for these configurations. We already had this debate last year: https://lists.gnupg.org/pipermail/gnupg-devel/2016-August/031458.html I think comments start with "#" and that does not have to be at the beginning of the line. There are multiple examples of software that agree. I still think it would be right to allow this comment form. But if the solution is to allow this only for specific configuration options, I would also like this for "default-key" in addition to "trusted-key". If you have a handful of more private keys in your keyring, a comment definitely makes sense in addition to the key-id. And as we can see, many people just ad comments to the same line. Thanks, and keep up the good work! -- 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 Thu Sep 28 14:32:26 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 28 Sep 2017 08:32:26 -0400 Subject: [PATCH] default-preference-list: prefer SHA512. In-Reply-To: <87wp50voca.fsf@fifthhorseman.net> References: <87wp50voca.fsf@fifthhorseman.net> Message-ID: <20170928123226.28189-1-dkg@fifthhorseman.net> * g10/keygen.c (keygen_set_std_prefs): when producing default internal personal-digest-preferences, keep the same order. When publishing external preferences, state preference for SHA512 first. -- SHA-512 has a wider security margin than SHA-256. It is also slightly faster on most of the architectures on which GnuPG runs today. New keys should publish defaults that indicate we prefer the stronger, more performant digest. Specifically, this changes --default-preference-list from: SHA256 SHA384 SHA512 SHA224 to: SHA512 SHA384 SHA256 SHA224 This patch deliberately avoids touching --personal-digest-preferences (which itself would affect the default of --digest-algo and --cert-digest-algo), so that public-facing cleartext signatures and identity certifications will continue to be made with SHA256 by default. Signed-off-by: Daniel Kahn Gillmor --- g10/keygen.c | 35 ++++++++++++++++++++++++----------- 1 file changed, 24 insertions(+), 11 deletions(-) diff --git a/g10/keygen.c b/g10/keygen.c index e959ee901..3235fdd5d 100644 --- a/g10/keygen.c +++ b/g10/keygen.c @@ -382,18 +382,31 @@ keygen_set_std_prefs (const char *string,int personal) strcat(dummy_string,"S7 "); strcat(dummy_string,"S2 "); /* 3DES */ - /* The default hash algo order is: + if (personal) { + /* The default internal hash algo order is: SHA-256, SHA-384, SHA-512, SHA-224, SHA-1. - */ - if (!openpgp_md_test_algo (DIGEST_ALGO_SHA256)) - strcat (dummy_string, "H8 "); - - if (!openpgp_md_test_algo (DIGEST_ALGO_SHA384)) - strcat (dummy_string, "H9 "); - - if (!openpgp_md_test_algo (DIGEST_ALGO_SHA512)) - strcat (dummy_string, "H10 "); - + */ + if (!openpgp_md_test_algo (DIGEST_ALGO_SHA256)) + strcat (dummy_string, "H8 "); + + if (!openpgp_md_test_algo (DIGEST_ALGO_SHA384)) + strcat (dummy_string, "H9 "); + + if (!openpgp_md_test_algo (DIGEST_ALGO_SHA512)) + strcat (dummy_string, "H10 "); + } else { + /* The default advertised hash algo order is: + SHA-512, SHA-384, SHA-256, SHA-224, SHA-1. + */ + if (!openpgp_md_test_algo (DIGEST_ALGO_SHA512)) + strcat (dummy_string, "H10 "); + + if (!openpgp_md_test_algo (DIGEST_ALGO_SHA384)) + strcat (dummy_string, "H9 "); + + if (!openpgp_md_test_algo (DIGEST_ALGO_SHA256)) + strcat (dummy_string, "H8 "); + } if (!openpgp_md_test_algo (DIGEST_ALGO_SHA224)) strcat (dummy_string, "H11 "); -- 2.14.1 From dkg at fifthhorseman.net Thu Sep 28 13:06:02 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 28 Sep 2017 07:06:02 -0400 Subject: pinentry's new window titles could be more (less?) informative Message-ID: <87zi9fqe05.fsf@fifthhorseman.net> I've been playing with pinentry's master branch -- i really like the idea of showing some information about the process that's invoking gpg-agent in the title bar, to the extent that pinentry can infer it from the system's introspection mechanisms. however, the information shown usually isn't meaningful to the end user, because it shows some complex gpg command line generated either by gpgme or by the actual user-facing tool's understanding of how to invoke gpg. Here's a recent example of a window title: [13132]@alice (/usr/bin/gpg --charset utf-8 --display-charset utf-8 --use-agent --batch --no-tty --status-fd 2 -a -t --encrypt --sign --trust-model always --encrypt-to 0x0EE5BE979282D80B9F7540F1CCD2E (i recognize that this is truncated, but i haven't done the legwork to figure out where it's being truncated -- maybe xwininfo doesn't believe that a window title could be this long?) At any rate, normal humans don't want to see all that :P What the normal user in the above scenario would probably want to see is something more like: thunderbird on alice (process 2504) or maybe: thunderbird on alice or maybe even just: thunderbird and only show the "on alice" host information if the invoking program is not on the same host as the agent. I grant that just using the title "thunderbird" will confuse people even more about the pinentry window -- it's not actually a thunderbird window! The bug reports will be confused! If we want to make it a little bit clearer, then we could show something like: thunderbird invoking gpg or: gpg from thunderbird As for where we get this information from, i'm imagining that the logic would be: * if the invoking program is not from the GnuPG suite, just show the invoking program (we can deal with those things later, though i don't know how many non-GnuPG tools talk to gpg-agent directly -- i only know of agent-transfer, which i wrote). * otherwise, look at the parent process of the invoking program. * if the parent process is pid 1, show the details of the invoking program. * otherwise, show the details of the parent process. What do folks think? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From rjh at sixdemonbag.org Thu Sep 28 20:03:26 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 28 Sep 2017 14:03:26 -0400 Subject: pinentry's new window titles could be more (less?) informative In-Reply-To: <87zi9fqe05.fsf@fifthhorseman.net> References: <87zi9fqe05.fsf@fifthhorseman.net> Message-ID: > At any rate, normal humans don't want to see all that :P Yep. > or maybe even just: > > thunderbird Normal humans still don't want to see all that. Sorry to be the bearer of bad news. :( Some years ago a friend of mine, Peter Likarish, devised a really neat phishing detector for Firefox. Highly effective, very low false positives: it was good stuff. He turned it into a Firefox plugin that would put a red warning banner at the top of the browser if you were apparently being phished. In human trials (done at the University of Iowa in a formal human-factors lab), precisely 0% of users benefited. They didn't even see the banner. So he made it bigger: no change. When he made it steadily grow to take over half the screen, people clicked the X to dismiss it without even reading it -- clearly they saw the banner, but they didn't read it. When asked in a post-interview what they thought of it, the most common reaction was, "I thought it was a Flash ad! I didn't even bother to read it!" The lesson I take from that is we, as developers, tend to vastly overestimate how much attention we're getting from users. Unless they know a widget is relevant to them, most users ignore it on a level so profound they don't even remember that widget existing. So my question is, yes, I see what the intent is here: to give users some assurance their PIN is being requested by the program they expect. But I'm entirely unconvinced this is a sensible precaution. I'd like to create a simple app called "gpg-helper" which would ask for a pinentry window to pop up. If a significant fraction of our users can see "gpg-helper" in the titlebar and realize "hey, wait, that's not legit", then I think there would be a lot of merit in doing this. Otherwise, we're talking about adding UI clutter to everyone's experience in order to benefit only a few. From peter at digitalbrains.com Thu Sep 28 20:42:41 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 28 Sep 2017 20:42:41 +0200 Subject: pinentry's new window titles could be more (less?) informative In-Reply-To: References: <87zi9fqe05.fsf@fifthhorseman.net> Message-ID: <2ca1fc5f-6efb-9b65-b512-d158970ba6bd@digitalbrains.com> On 28/09/17 20:03, Robert J. Hansen wrote: > He turned it into a Firefox plugin that > would put a red warning banner at the top of the browser if you were > apparently being phished. I remember you telling this before, it's a really neat study that gives good insights. But I'm not convinced it can be transferred to this situation. Yes, people ignore large parts of their browser screen; in fact, I'm willing to bet this goes for a lot of windows, according to my n=1 usability study that is my personal experience. It goes especially for browsers, though, with all the useless cruft on websites. Navigational bars, by the way, can also be ignored until one needs to navigate a site. If I just followed a search engine hit to an interesting article, I don't care about anything around that article no matter how useful it might be in different circumstances. I automatically pay it no mind at all. I don't think this pinentry feature will help identify an unwanted pinentry request when in fact the user is not surprised by being prompted for their key. They'll just think "ah, okay then" and type it in. I know I would seven times out of ten, and then I'm being nice to myself. However, I think it's about when a user /didn't/ expect the pinentry, and is wondering where it came from. People have occasionally come on gnupg-users asking "why does my system keep asking me for my $#&% key?!", and then it, for instance, turned out they had forgotten they allowed their desktop environment's keyring manager to use GnuPG to encrypt their keyring. If the pinentry would have just indicated "gnome-keyring" (I'm not saying gnome-keyring supports this, it's just an example), they wouldn't have been bewildered and worried their system was doing bad stuff. Basically, I don't think it's a security feature to catch malicious activity, like the phishing. It's just informational, which can be quite nice, having some information, knowing what's going on. It's there when you _look_ for it. My 2 cents, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From lukele at gpgtools.org Thu Sep 28 21:04:40 2017 From: lukele at gpgtools.org (Lukas Pitschl | GPGTools) Date: Thu, 28 Sep 2017 21:04:40 +0200 Subject: pinentry's new window titles could be more (less?) informative In-Reply-To: <2ca1fc5f-6efb-9b65-b512-d158970ba6bd@digitalbrains.com> References: <87zi9fqe05.fsf@fifthhorseman.net> <2ca1fc5f-6efb-9b65-b512-d158970ba6bd@digitalbrains.com> Message-ID: <6411EC9F-C6B6-4F52-8ADA-1011A4B821B1@gpgtools.org> I would like to add here, that while I agree with Robert, that most users probably ignore the dialog and simply enter the passphrase, I also believe that what Peter says does make a lot of sense. We would really love to see a more descriptive pinentry and have been planning in the past, to add some context to it, based on the application it is used in. For example, if I?m about to decrypt a message, switch to a different window and a pinentry passphrase request comes up, I would like to see the purpose of it clearly explained. Example: Please enter passphrase to decrypt message ?SUBJECT? from ?FROM" In addition it should be possible to display the icon of the application requiring access to your secret key. I also agree with Peter here that this is much more about providing the necessary context for a passphrase request, rather than being a security feature. Best, Lukas GPGTools > Am 28.09.2017 um 20:42 schrieb Peter Lebbing : > > On 28/09/17 20:03, Robert J. Hansen wrote: >> He turned it into a Firefox plugin that >> would put a red warning banner at the top of the browser if you were >> apparently being phished. > > I remember you telling this before, it's a really neat study that gives > good insights. > > But I'm not convinced it can be transferred to this situation. Yes, > people ignore large parts of their browser screen; in fact, I'm willing > to bet this goes for a lot of windows, according to my n=1 usability > study that is my personal experience. It goes especially for browsers, > though, with all the useless cruft on websites. Navigational bars, by > the way, can also be ignored until one needs to navigate a site. If I > just followed a search engine hit to an interesting article, I don't > care about anything around that article no matter how useful it might be > in different circumstances. I automatically pay it no mind at all. > > I don't think this pinentry feature will help identify an unwanted > pinentry request when in fact the user is not surprised by being > prompted for their key. They'll just think "ah, okay then" and type it > in. I know I would seven times out of ten, and then I'm being nice to > myself. > > However, I think it's about when a user /didn't/ expect the pinentry, > and is wondering where it came from. People have occasionally come on > gnupg-users asking "why does my system keep asking me for my $#&% > key?!", and then it, for instance, turned out they had forgotten they > allowed their desktop environment's keyring manager to use GnuPG to > encrypt their keyring. If the pinentry would have just indicated > "gnome-keyring" (I'm not saying gnome-keyring supports this, it's just > an example), they wouldn't have been bewildered and worried their system > was doing bad stuff. > > Basically, I don't think it's a security feature to catch malicious > activity, like the phishing. It's just informational, which can be quite > nice, having some information, knowing what's going on. It's there when > you _look_ for it. > > My 2 cents, > > Peter. > > -- > I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. > You can send me encrypted mail if you want some privacy. > My key is available at > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: Message signed with OpenPGP using GPGMail URL: From lukele at gpgtools.org Thu Sep 28 21:16:01 2017 From: lukele at gpgtools.org (Lukas Pitschl | GPGTools) Date: Thu, 28 Sep 2017 21:16:01 +0200 Subject: GnuPG 2.2 - Comments in gpg.conf In-Reply-To: <877ewj2f7i.fsf@wheatstone.g10code.de> References: <877ewj2f7i.fsf@wheatstone.g10code.de> Message-ID: <1F83D9E4-FAED-4997-83D0-9F351CE96BAC@gpgtools.org> > Am 28.09.2017 um 14:13 schrieb Werner Koch : > > On Wed, 27 Sep 2017 02:00, lukele at gpgtools.org said: > >> Upon further inspection it appears that gpg.conf doesn?t allow comments at the end of options. > > What do you think of the attached but untested patch? It would help > for these configurations. I?m not sure it makes sense to ignore the strings following # to interpret as comments for some options but not for others. After comparing the behavior of GnuPG 2.0.X vs GnuPG 2.2 I have noticed, that GnuPG 2.0.X did in fact treat the # XX as a comment, but not for all options. Strangely enough for the `trusted-key` option it ignored everything following the # character. For the `charset` option it didn?t. Best, Lukas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rjh at sixdemonbag.org Thu Sep 28 21:49:01 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 28 Sep 2017 15:49:01 -0400 Subject: pinentry's new window titles could be more (less?) informative In-Reply-To: <2ca1fc5f-6efb-9b65-b512-d158970ba6bd@digitalbrains.com> References: <87zi9fqe05.fsf@fifthhorseman.net> <2ca1fc5f-6efb-9b65-b512-d158970ba6bd@digitalbrains.com> Message-ID: > I don't think this pinentry feature will help identify an unwanted > pinentry request when in fact the user is not surprised by being > prompted for their key. They'll just think "ah, okay then" and type it > in. I know I would seven times out of ten, and then I'm being nice to > myself. Right, same here. Complete agreement. > Basically, I don't think it's a security feature to catch malicious > activity, like the phishing. It's just informational, which can be quite > nice, having some information, knowing what's going on. I mostly agree, except that the current titlebar text is so over-detailed that it's not in any way informational. This titlebar text appears to be a straight-up auditing tool giving you excruciatingly detailed information about the invoker. If the titlebar text is intended to be UI polish (which, in its current form, it does not appear to be) then this is a misimplementation we can fix with adjusted text. If the titlebar text is intended to be an audit tool (as it currently appears to be), then this is a misfeature we should remove. So let me stake out the first question: what's it supposed to be, polish or auditing? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 821 bytes Desc: OpenPGP digital signature URL: From gdt at lexort.com Thu Sep 28 20:46:44 2017 From: gdt at lexort.com (Greg Troxel) Date: Thu, 28 Sep 2017 14:46:44 -0400 Subject: installing gnupg 2.2 as "gpg", vs coexistence with gpg 1.4 Message-ID: In pkgsrc (a portable multi-arch multi-os packaging system), we currently have gnupg 2.2.0 (yes, needs update) and 1.4.22. To allow both to be installed at once, long ago when 1.4 was normal and 2.2 was new, we used the"--enable-gpg-is-gpg2" configure flag, or the default without that. This caused users to tend to use gpg 1.4 for OpenPGP, and gpgsm from 2.0 for S/MIME, and the 2.0 agent. Other than perhaps using older code, all was ok. Now, with the incompatible agent changes, gpg 1.4 is unusable (if one considers the agent mandatory). So that leads to dropping --enable-gpg-is-gpg2 to make gnupg 2.2 install as gpg, which leads to either just not having 1.4, or letting it conflict (only one can be installed), or to hacking in a --enable-gpg-is-gpg1 option which doesn't seem to exist. It seems that with 2.2, --enable-gpg-is-gpg1 is no longer default in configure.ac, but README is lagging. So, I wonder what the collective wisdom is, among: 1) Nobody should use 1.4 for anything. Just use 2.2. Don't even have a 1.4 package. 2) There are reasons to use 1.4, but it's odd. Don't bother to accomodate people, and it's ok if the 1.4 and 2.2 packages can't be installed at once. 3) 1.4 is normal enough that packaging systems should allow installing both at the same time, but typing "gpg" should get gpg 2.2.x 4) something else Curentl, I lean to 2 and if it turns out 3 is true maybe move to 3. Thanks, Greg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 162 bytes Desc: not available URL: From rjh at sixdemonbag.org Thu Sep 28 22:50:22 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 28 Sep 2017 16:50:22 -0400 Subject: installing gnupg 2.2 as "gpg", vs coexistence with gpg 1.4 In-Reply-To: References: Message-ID: <91cff6c3-8faa-1285-c42e-409097749c45@sixdemonbag.org> > 1) Nobody should use 1.4 for anything. Just use 2.2. Don't even have a > 1.4 package. (Not speaking for the GnuPG devs) My understanding is that 1.4's continued support will be marginal at best. 1.4 will never receive support for elliptical curve crypto, for instance, and if the WG ever releases a new RFC it's unlikely 1.4 will be modified to conform to it. 1.4 hasn't been EOLed, but it's reached the end of the road: there will be no further new development on it unless someone wants to hire g10 Code to do the work. New development will occur only on the 2.2 branch. Given this, #2 seems to be the most apt way forward. From dkg at fifthhorseman.net Fri Sep 29 06:25:22 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 29 Sep 2017 00:25:22 -0400 Subject: installing gnupg 2.2 as "gpg", vs coexistence with gpg 1.4 In-Reply-To: References: Message-ID: <871smqqggd.fsf@fifthhorseman.net> On Thu 2017-09-28 14:46:44 -0400, Greg Troxel wrote: > 1) Nobody should use 1.4 for anything. Just use 2.2. Don't even have a > 1.4 package. > > 2) There are reasons to use 1.4, but it's odd. Don't bother to > accomodate people, and it's ok if the 1.4 and 2.2 packages can't be > installed at once. > > 3) 1.4 is normal enough that packaging systems should allow installing > both at the same time, but typing "gpg" should get gpg 2.2.x In debian, we're shipping gpg 2.1.x/2.2.x as "/usr/bin/gpg" and the 1.4 branch is explicitly deprecated. for the "odd" reasons that a few people might have to use 1.4, we still support an explicitly deprecated "gnupg1" package, which ships /usr/bin/gpg1 and wasn't particularly hard to build. So i guess you could say that debian is taking your option #3, but i don't think you should interpret it that way -- 1.4 is *not* "normal enough" these days. And while the documentation makes some statements about co-installability, my experience has been that co-installability between the 1.4 and 2.1/2.2 series is illusory at best -- in most circumstances, they end up using different public key rings and different secret keyrings, and end up sharing only the config file, which itself is frustrating because there are options that you might want for one, but not for the other. So I think #1 or #2 is the way to go. You're welcome to point the few holdouts who actually need gpg1 (i.e. folks with legacy PGPv3 keys that need to decrypt old/archived messages, i can't really think of another good reason) that they should take advantage of the deprecated debian gpg1 packages while they last, if it gets you out of having to support two versions concurrently. But in the long term, Debian will evenutally drop gpg1 as well. People should move on. --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 Fri Sep 29 10:26:50 2017 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 Sep 2017 10:26:50 +0200 Subject: GnuPG 2.2 - Comments in gpg.conf In-Reply-To: <20170928131013.GM1010@zeromail.org> (ilf@zeromail.org's message of "Thu, 28 Sep 2017 15:10:13 +0200") References: <877ewj2f7i.fsf@wheatstone.g10code.de> <20170928131013.GM1010@zeromail.org> Message-ID: <87mv5d29md.fsf@wheatstone.g10code.de> On Thu, 28 Sep 2017 15:10, ilf at zeromail.org said: > I think comments start with "#" and that does not have to be at the > beginning of the line. There are multiple examples of software that > agree. I still think it would be right to allow this comment form. The man page clearly states. Lines with a hash ('#') as the first non-white-space character are ignored. This is common for many conf files and makes a lot of sense because it avoids complicated and hard to learn rules on how to quote values. Consider the shell syntax where '#' is used at several places (e.g. $#, ${#foo}, #!) and thus you need to implement a full lexer to detect the '#' token which marks a trailing comment. Even Bash's readline configuration file won't accept those trailing comments. > But if the solution is to allow this only for specific configuration > options, I would also like this for "default-key" in addition to --default-key is different because it accepts a user id (which is allowed to contain a #). --trusted-key accepts a long keyid and nothing else. This is the very reason why I would accept a workaround for this option. Whether this really makes sense is a different question and depends on how many gpgtools users ran into that problem. > keyring, a comment definitely makes sense in addition to the > key-id. And as we can see, many people just ad comments to the same Use one or more comment line above the keyword, 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 Sep 29 10:42:26 2017 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 Sep 2017 10:42:26 +0200 Subject: GnuPG 2.2 - Comments in gpg.conf In-Reply-To: <1F83D9E4-FAED-4997-83D0-9F351CE96BAC@gpgtools.org> (Lukas Pitschl's message of "Thu, 28 Sep 2017 21:16:01 +0200") References: <877ewj2f7i.fsf@wheatstone.g10code.de> <1F83D9E4-FAED-4997-83D0-9F351CE96BAC@gpgtools.org> Message-ID: <878tgx28wd.fsf@wheatstone.g10code.de> On Thu, 28 Sep 2017 21:16, lukele at gpgtools.org said: > After comparing the behavior of GnuPG 2.0.X vs GnuPG 2.2 I have noticed, that > GnuPG 2.0.X did in fact treat the # XX as a comment, but not for all options. Strangely enough for As written in the patch's comment this was not considered a comment but the parser for user ids accepted all kind of junk after a keyid and did not reject that user id. This bug was fixed two years ago. 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 Sep 29 10:53:17 2017 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 Sep 2017 10:53:17 +0200 Subject: installing gnupg 2.2 as "gpg", vs coexistence with gpg 1.4 In-Reply-To: <871smqqggd.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 29 Sep 2017 00:25:22 -0400") References: <871smqqggd.fsf@fifthhorseman.net> Message-ID: <874lrl28ea.fsf@wheatstone.g10code.de> On Fri, 29 Sep 2017 06:25, dkg at fifthhorseman.net said: > holdouts who actually need gpg1 (i.e. folks with legacy PGPv3 keys that > need to decrypt old/archived messages, i can't really think of another A few days ago someone (with a long pgp and gpg history) accidentally sent me an encrypted mail to my old (expired) key from 1995. I had to use gpg1 to decrypt it. Should I ever find a DAT drive for my old backup tapes I might want to decrypt mails from that area. There is also the case for historians who want to dive into the 90ies. > two versions concurrently. But in the long term, Debian will evenutally > drop gpg1 as well. People should move on. Agreed, but I will try to keep on maintaining gpg1 at least for decryption. The next 1.4 release will likely install gpg 1.4 as gpg1, though. Maybe keyserver support will also be removed because that is not needed for decryption. I am not sure what to do with translations, but keeping them is not that expensive. 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 Fri Sep 29 11:00:51 2017 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 Sep 2017 11:00:51 +0200 Subject: pinentry's new window titles could be more (less?) informative In-Reply-To: (Robert J. Hansen's message of "Thu, 28 Sep 2017 14:03:26 -0400") References: <87zi9fqe05.fsf@fifthhorseman.net> Message-ID: <87zi9dzxoc.fsf@wheatstone.g10code.de> On Thu, 28 Sep 2017 20:03, rjh at sixdemonbag.org said: > So my question is, yes, I see what the intent is here: to give users > some assurance their PIN is being requested by the program they expect. Actually the reason I implemented this was to see the ssh invocation. I have a few cron jobs connecting to other boxes running and thus it is interesting to see which kicked the pinentry. 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 Sep 29 11:07:55 2017 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 Sep 2017 11:07:55 +0200 Subject: pinentry's new window titles could be more (less?) informative In-Reply-To: (Robert J. Hansen's message of "Thu, 28 Sep 2017 15:49:01 -0400") References: <87zi9fqe05.fsf@fifthhorseman.net> <2ca1fc5f-6efb-9b65-b512-d158970ba6bd@digitalbrains.com> Message-ID: <87vak1zxck.fsf@wheatstone.g10code.de> On Thu, 28 Sep 2017 21:49, rjh at sixdemonbag.org said: > So let me stake out the first question: what's it supposed to be, polish > or auditing? For ssh I'd like to keep it as is. ssh is for hackers or other folks who understand what is going on. Thus the simple command line is okay. For user uses cases polishing this in ways dkg dscribes is a Good Thing. In addition it should also be possible to set a custom text, like the subject of the mail currently being decrypted or the To: address when sending a mail. Patches welcome. 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 ben at adversary.org Fri Sep 29 19:39:48 2017 From: ben at adversary.org (Ben McGinnes) Date: Sat, 30 Sep 2017 03:39:48 +1000 Subject: pinentry's new window titles could be more (less?) informative In-Reply-To: References: <87zi9fqe05.fsf@fifthhorseman.net> Message-ID: <20170929173948.y3qb4nojh4cwd27x@adversary.org> On Thu, Sep 28, 2017 at 06:03:26PM +0000, Robert J. Hansen wrote: > > In human trials (done at the University of Iowa in a formal > human-factors lab), precisely 0% of users benefited. They didn't > even see the banner. So he made it bigger: no change. When he made > it steadily grow to take over half the screen, people clicked the X > to dismiss it without even reading it -- clearly they saw the > banner, but they didn't read it. When asked in a post-interview > what they thought of it, the most common reaction was, "I thought it > was a Flash ad! I didn't even bother to read it!" This reminds me of something I saw (and retweeted) today: https://twitter.com/Fawke101/status/894610979190951936 It illustrates this point perfectly. It's funny because it's oh-so true. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: From dkg at fifthhorseman.net Sat Sep 30 21:48:05 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 30 Sep 2017 15:48:05 -0400 Subject: installing gnupg 2.2 as "gpg", vs coexistence with gpg 1.4 In-Reply-To: <874lrl28ea.fsf@wheatstone.g10code.de> References: <871smqqggd.fsf@fifthhorseman.net> <874lrl28ea.fsf@wheatstone.g10code.de> Message-ID: <878tgwotmy.fsf@fifthhorseman.net> On Fri 2017-09-29 10:53:17 +0200, Werner Koch wrote: > On Fri, 29 Sep 2017 06:25, dkg at fifthhorseman.net said: > >> holdouts who actually need gpg1 (i.e. folks with legacy PGPv3 keys that >> need to decrypt old/archived messages, i can't really think of another > > A few days ago someone (with a long pgp and gpg history) accidentally > sent me an encrypted mail to my old (expired) key from 1995. I had to > use gpg1 to decrypt it. > > Should I ever find a DAT drive for my old backup tapes I might want to > decrypt mails from that area. There is also the case for historians who > want to dive into the 90ies. for digital historians an legacy nerdery, the source code for gpg 1.4 will continue to be available, whether it's maintained or not. I'm fine with that tradeoff :) > Agreed, but I will try to keep on maintaining gpg1 at least for > decryption. The next 1.4 release will likely install gpg 1.4 as gpg1, > though. Maybe keyserver support will also be removed because that is > not needed for decryption. I am not sure what to do with translations, > but keeping them is not that expensive. I agree that decryption (asymmetric and symmetric) of legacy encrypted messages is the only interesting use case left for gpg1 in the long term. To be clear, means that the following use cases aren't things anyone should be doing with gpg 1.4: * keyserver or LDAP access * signature verification * signing data * certifying keys * Web-of-trust identity validation * asymmetric encryption * symmetric encryption maybe a deprecate 1.4 could start producing warnings when invoked for those operations, if we want to encourage people to move off of it. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: