From jca at wxcvbn.org Wed Nov 1 17:13:53 2017 From: jca at wxcvbn.org (Jeremie Courreges-Anglas) Date: Wed, 01 Nov 2017 17:13:53 +0100 Subject: [PATCH] Don't use /dev/srandom on OpenBSD (STABLE-BRANCH-1-4) Message-ID: <87vaiu9dtq.fsf@ritchie.wxcvbn.org> Hi, Please see the patch attached. Christian Weisgerber already patched away that chunk in the gnupg1 OpenBSD port[1] that I maintain. It would be nice to have the change in the next 1.4.x release. The NAME_OF_DEV_*RANDOM abstraction is not really useful after this commit, but I preferred to keep this patch minimal. [1] https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/security/gnupg/patches/patch-configure?rev=1.6&content-type=text/x-cvsweb-markup -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Don-t-use-dev-srandom-on-OpenBSD.patch Type: text/x-patch Size: 1154 bytes Desc: not available URL: -------------- next part -------------- -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE -------------- 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 Thu Nov 2 18:58:17 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 02 Nov 2017 18:58:17 +0100 Subject: GnuPG is looking for a Phrabicator admin Message-ID: <87h8ucv9za.fsf@wheatstone.g10code.de> Hi! It is now been more than 6 months that we replaced our old Roundup based bug tracker by a self-hosted Phrabicator instance (dev.gnupg.org). Unfortunately the admin, who set up and maintained that system, quit his job at g10 Code in September. There is no one left to replace him and I don't have the time to get used to the internals of that large system and take care of it. Thus g10 Code is now looking for a freelancer to take care of the dev.gnupg.org VM. Experience with running Phrabicator would be very helpful. Unless there is an emergency the amount of work required should be less than 20 hours a months. If you are interested in that job please get in contact with me at info at g10code com. Salam-Shalom, Werner ps. Status is tracked at https://dev.gnupg.org/T3468 -- 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 Nov 2 20:20:09 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 02 Nov 2017 20:20:09 +0100 Subject: [PATCH] Don't use /dev/srandom on OpenBSD (STABLE-BRANCH-1-4) In-Reply-To: <87vaiu9dtq.fsf@ritchie.wxcvbn.org> (Jeremie Courreges-Anglas's message of "Wed, 01 Nov 2017 17:13:53 +0100") References: <87vaiu9dtq.fsf@ritchie.wxcvbn.org> Message-ID: <877ev8v66u.fsf@wheatstone.g10code.de> On Wed, 1 Nov 2017 17:13, jca at wxcvbn.org said: > Subject: [PATCH] Don't use /dev/srandom on OpenBSD Thanks. I pushed it and it will thus be part of the next release. 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 matthew.summers at syapse.com Fri Nov 3 18:50:13 2017 From: matthew.summers at syapse.com (Matthew Summers) Date: Fri, 3 Nov 2017 12:50:13 -0500 Subject: Please Consider Increasing SECMEM_BUFFER_SIZE To 1048576 In-Reply-To: <87efpwhnt3.fsf@wheatstone.g10code.de> References: <768f49c6-e0b9-c63a-8104-9d51cf28fd60@suse.com> <87efpwhnt3.fsf@wheatstone.g10code.de> Message-ID: Hello, I just got to testing on 2.2.x and I have had to increase the SECMEM_BUFFER_SIZE to 2097152 to pass my trivial 100 proc concurrency test with 100% reliability. To remind about the test, using a 4096bit RSA key with id test at example.com $ echo "test" | gpg -aer test at example.com -o gpg.txt $ yes gpg.txt | head -100 | xargs -n 1 -P 5 gpg --decrypt -q # 5 $ yes gpg.txt | head -100 | xargs -n 1 -P 10 gpg --decrypt -q # 10 $ yes gpg.txt | head -100 | xargs -n 1 -P 100 gpg --decrypt -q # 100 From wk at gnupg.org Tue Nov 7 11:45:31 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 07 Nov 2017 11:45:31 +0100 Subject: [Announce] GnuPG 2.2.2 released Message-ID: <87375qmkok.fsf@wheatstone.g10code.de> Hello! We are is pleased to announce the availability of a new GnuPG release: version 2.2.2. 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.2 =================================== * gpg: Avoid duplicate key imports by concurrently running gpg processes. [#3446] * gpg: Fix creating on-disk subkey with on-card primary key. [#3280] * gpg: Fix validity retrieval for multiple keyrings. [Debian#878812] * gpg: Fix --dry-run and import option show-only for secret keys. * gpg: Print "sec" or "sbb" for secret keys with import option import-show. [#3431] * gpg: Make import less verbose. [#3397] * gpg: Add alias "Key-Grip" for parameter "Keygrip" and new parameter "Subkey-Grip" to unattended key generation. [#3478] * gpg: Improve "factory-reset" command for OpenPGP cards. [#3286] * gpg: Ease switching Gnuk tokens into ECC mode by using the magic keysize value 25519. * gpgsm: Fix --with-colon listing in crt records for fields > 12. * gpgsm: Do not expect X.509 keyids to be unique. [#1644] * agent: Fix stucked Pinentry when using --max-passphrase-days. [#3190] * agent: New option --s2k-count. [#3276 (workaround)] * dirmngr: Do not follow https-to-http redirects. [#3436] * dirmngr: Reduce default LDAP timeout from 100 to 15 seconds. [#3487] * gpgconf: Ignore non-installed components for commands --apply-profile and --apply-defaults. [#3313] * Add configure option --enable-werror. [#2423] Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.2.2 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.2.tar.bz2 (6394k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.2.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.2_20171107.exe (3807k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.2_20171107.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. A new Gpg4win 3.0 installer featuring this version of GnuPG will be available soon. In the meantime you may install this version on top of an installed Gpg4win 3.0 version. 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.2.tar.bz2 you would use this command: gpg --verify gnupg-2.2.2.tar.bz2.sig gnupg-2.2.2.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.2.tar.bz2, you run the command like this: sha1sum gnupg-2.2.2.tar.bz2 and check that the output matches the next line: efa00fc20295b1cafe467359107ea170258870e2 gnupg-2.2.2.tar.bz2 19224023f5a7750743d042b0bfbd5e44fbc9aeb2 gnupg-w32-2.2.2_20171107.exe 0bb69eb774f8c39b8092b5615a19e656bb681084 gnupg-w32-2.2.2_20171107.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 and Support ========================= 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 to 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. 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. Thanks ====== Maintenance and development of GnuPG is mostly financed by donations. The GnuPG project currently employs one full-time developer and one contractor. Both work exclusivly on GnuPG and closely related software like Libgcrypt, GPGME, and GPA. We are planning to extend our team again. Right now we are looking for an admin for our bug tracker; see We have to thank all the people who helped the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, answering questions on the mailing lists, and with financial support. Happy hacking, Gniibe and Werner p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users'at'gnupg.org mailing list. p.p.s List of Release Signing Keys: To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these 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) The keys are available at 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 Thu Nov 9 22:29:57 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 09 Nov 2017 21:29:57 +0000 Subject: dirmngr logging confusion when trying to connect to a local keyserver (more reverse DNS?) Message-ID: <87fu9n5eei.fsf@fifthhorseman.net> Hi all-- over on reproducible-builds at lists.alioth.debian.org [0], Georg (cc'ed here) described intermittent failures on some platforms for dirmngr talking to a locally-configured keyserver running on 127.0.0.1 port 9999. The most confusing/disturbing part of the logs is here: 2017-10-01 06:16:58 dirmngr[32208.6] DBG: dns: resolve_dns_addr(): Connection closed in DNS 2017-10-01 06:16:58 dirmngr[32208.6] resolve_dns_addr failed while checking '127.0.0.1': Connection closed in DNS 2017-10-01 06:16:58 dirmngr[32208.6] DBG: dns: resolve_dns_name(127.0.0.1): Success 2017-10-01 06:17:00 dirmngr[32208.6] DBG: dns: resolve_dns_addr(): Success 2017-10-01 06:17:00 dirmngr[32208.6] number of system provided CAs: 148 2017-10-01 06:17:00 dirmngr[32208.6] DBG: http.c:connect_server: trying name='127.0.0.1' port=9999 2017-10-01 06:17:00 dirmngr[32208.6] DBG: dns: resolve_dns_name(127.0.0.1): Success 2017-10-01 06:17:00 dirmngr[32208.6] can't connect to '127.0.0.1': no IP address for host 2017-10-01 06:17:00 dirmngr[32208.6] error connecting to 'http://127.0.0.1:9999': Unknown host 2017-10-01 06:17:00 dirmngr[32208.6] marking host '127.0.0.1' as dead 2017-10-01 06:17:00 dirmngr[32208.6] DBG: dns: resolve_dns_name(127.0.0.1): Success 2017-10-01 06:17:01 dirmngr[32208.6] DBG: dns: resolve_dns_addr(): Success 2017-10-01 06:17:01 dirmngr[32208.6] host '127.0.0.1' marked as dead Even if the local keyserver wasn't running at all, these log messages would be (at best) misleading, if not downright confusing. What do these messages mean? "no IP address for host" doesn't make sense when the host is itself an IP address. I'd understand "Connection refused" (or even "Network is unreachable" for hosts that don't have a loopback configured), but that's not what is reported here. Also, why is dirmngr trying to look up names for addresses? i don't know whether "resolve_dns_name" is A/AAAA lookup and "resolve_dns_addr" is PTR lookup or vice versa, but it appears that dirmngr is trying to do both :/ I thought we'd gotten rid of all the PTR lookups in dirmngr except for "gpg-connect-agent --dirmngr 'keyserver --hosttable' /bye" in 2.2.2 it seems to be doing the same thing (learning "localhost" for 127.0.0.1, iiuc). Perhaps that's contributing to the weird failure state? So it looks to me like there might be (at least) two issues with dirmngr: a) it is still trying to do some kind of reverse DNS lookups. this seems like it can only be a source of failure, and is not a security measure. b) dirmngr is logging misleading warnings when the state of the reverse DNS is not what it is expecting. I've been unable to replicate this exact failure state locally with dimrngr 2.2.2 :( --dkg [0] Message-ID: 20171030172139.GG7690 at riseup.net -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From dgouttegattat at incenp.org Fri Nov 10 11:38:32 2017 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Fri, 10 Nov 2017 10:38:32 +0000 Subject: [PATCH] tests: Run the trust-pgp-4 test again. Message-ID: <20171110103832.10347-1-dgouttegattat@incenp.org> * tests/openpgp/Makefile.am (XTESTS): Add trust-pgp-4.scm. (EXTRA_DIST): Remove the test file from EXTRA_DIST. -- Now that issue 2923 is fixed, the trust-pgp-4 test passes as expected and we can enable it again. That should help prevent a future regression on this issue. Signed-off-by: Damien Goutte-Gattat --- tests/openpgp/Makefile.am | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/tests/openpgp/Makefile.am b/tests/openpgp/Makefile.am index f6014c9c5..827d3e32f 100644 --- a/tests/openpgp/Makefile.am +++ b/tests/openpgp/Makefile.am @@ -85,6 +85,7 @@ XTESTS = \ trust-pgp-1.scm \ trust-pgp-2.scm \ trust-pgp-3.scm \ + trust-pgp-4.scm \ gpgtar.scm \ use-exact-key.scm \ default-key.scm \ @@ -102,9 +103,6 @@ XTESTS = \ issue2929.scm \ issue2941.scm -# Temporary removed tests: -# trust-pgp-4.scm - # XXX: Currently, one cannot override automake's 'check' target. As a # workaround, we avoid defining 'TESTS', thus automake will not emit @@ -268,7 +266,7 @@ sample_msgs = samplemsgs/clearsig-1-key-1.asc \ EXTRA_DIST = defs.scm trust-pgp/common.scm $(XTESTS) $(TEST_FILES) \ mkdemodirs signdemokey $(priv_keys) $(sample_keys) \ - $(sample_msgs) ChangeLog-2011 run-tests.scm trust-pgp-4.scm \ + $(sample_msgs) ChangeLog-2011 run-tests.scm \ setup.scm shell.scm all-tests.scm signed-messages.scm CLEANFILES = prepared.stamp x y yy z out err $(data_files) \ -- 2.14.1 From wk at gnupg.org Fri Nov 10 15:48:29 2017 From: wk at gnupg.org (Werner Koch) Date: Fri, 10 Nov 2017 15:48:29 +0100 Subject: [PATCH] 1.4.22 historical gcc compatibility In-Reply-To: <20171019003828.GD823@darioniedermann.it> (Dario Niedermann's message of "Thu, 19 Oct 2017 02:38:28 +0200") References: <20171019003828.GD823@darioniedermann.it> Message-ID: <87mv3udwaq.fsf@wheatstone.g10code.de> On Thu, 19 Oct 2017 02:38, dario at darioniedermann.it said: > The enclosed patch enables gnupg-1.4.22 to compile with gcc-2.95.3. Thanks. Indded we want stick to C90 and don't intermix decls with statements. 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 gniibe at fsij.org Mon Nov 13 10:58:56 2017 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 13 Nov 2017 18:58:56 +0900 Subject: [PATCH] tests: Run the trust-pgp-4 test again. In-Reply-To: <20171110103832.10347-1-dgouttegattat@incenp.org> References: <20171110103832.10347-1-dgouttegattat@incenp.org> Message-ID: <87ineea49r.fsf@fsij.org> Damien Goutte-Gattat wrote: > Now that issue 2923 is fixed, the trust-pgp-4 test passes as > expected and we can enable it again. That should help prevent > a future regression on this issue. Thanks, applied. I think that the feature is not supported well. When DISABLE_REGEX is enabled (Windows), the feature is not available. So, I added another patch to disable this test when DISABLE_REGEX. -- From wk at gnupg.org Mon Nov 13 15:17:49 2017 From: wk at gnupg.org (Werner Koch) Date: Mon, 13 Nov 2017 15:17:49 +0100 Subject: dirmngr logging confusion when trying to connect to a local keyserver (more reverse DNS?) In-Reply-To: <87fu9n5eei.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 09 Nov 2017 21:29:57 +0000") References: <87fu9n5eei.fsf@fifthhorseman.net> Message-ID: <871sl29saa.fsf@wheatstone.g10code.de> On Thu, 9 Nov 2017 22:29, dkg at fifthhorseman.net said: > 2017-10-01 06:17:00 dirmngr[32208.6] DBG: dns: resolve_dns_name(127.0.0.1): Success > 2017-10-01 06:17:00 dirmngr[32208.6] can't connect to '127.0.0.1': no IP address for host Maybe a missing localhost entry in /etc/hosts? I can imagine that our libdns.c does not have a hardwired name for localhost. That would be easy to fix. The problem with libdns.c is that Justus and me tried hard to get our fixes upstream but never got any reply from the original author except for one message that he will look at them. Meanwhile I think it might be better to giveup on trying to get it upstream and keep on fixing problems ourself - which would include better documentaion of the code. > Also, why is dirmngr trying to look up names for addresses? i don't know > whether "resolve_dns_name" is A/AAAA lookup and "resolve_dns_addr" is So that we can return and store the hostname with a key. 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 peter at digitalbrains.com Mon Nov 13 16:33:55 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 13 Nov 2017 16:33:55 +0100 Subject: dirmngr logging confusion when trying to connect to a local keyserver (more reverse DNS?) In-Reply-To: <871sl29saa.fsf@wheatstone.g10code.de> References: <87fu9n5eei.fsf@fifthhorseman.net> <871sl29saa.fsf@wheatstone.g10code.de> Message-ID: <478ffde2-dc09-0ace-b9ef-6b627f049bfe@digitalbrains.com> On 13/11/17 15:17, Werner Koch wrote: > So that we can return and store the hostname with a key. Isn't it better to use the hostname used for the forward lookup rather than the reverse lookup? The forward lookup is what the user or the preferred-keyserver or whatnot requested, the reverse lookup is not. It could even be: mykeyserver.example A 10.11.12.13 13.12.11.10.in-addr.arpa PTR host-42.sharedhosting.example The "mykeyserver.example" is much more informative than the name of the shared machine. Another variation is where the operator for the keyserver does have their own IP, but runs multiple services on that one IP. They could have A records saying "keyserver.mydomain.example" and "mail.mydomain.example", but configure their PTR to say "mail.mydomain.example". That's not a pretty name for a keyserver. Even worse with IPv6, by the way. My provider (XS4ALL) provides native IPv6 to their customers; you get a /48 block. When this was still an experimental feature, you got reverse lookup. But now that it is a normal feature, they no longer do that. They claim that there is discussion in the community whether reverse lookup in IPv6 has advantages that outweigh the costs, and as long as this discussion isn't settled, they aren't going to invest in the infrastructure needed to let every customer configure their NS records for their reverse zone. So I don't have any reverse DNS for my IPv6 address space. (Off-topic: since many mail servers decline mail from hosts without a PTR record for anti-spam reasons, I think you can't reliably run a mail server delivering over IPv6 with such an arrangement.) 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 dkg at fifthhorseman.net Mon Nov 13 15:43:14 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 13 Nov 2017 22:43:14 +0800 Subject: dirmngr logging confusion when trying to connect to a local keyserver (more reverse DNS?) In-Reply-To: <871sl29saa.fsf@wheatstone.g10code.de> References: <87fu9n5eei.fsf@fifthhorseman.net> <871sl29saa.fsf@wheatstone.g10code.de> Message-ID: <87h8tyz1bx.fsf@fifthhorseman.net> On Mon 2017-11-13 15:17:49 +0100, Werner Koch wrote: > On Thu, 9 Nov 2017 22:29, dkg at fifthhorseman.net said: > >> 2017-10-01 06:17:00 dirmngr[32208.6] DBG: dns: resolve_dns_name(127.0.0.1): Success >> 2017-10-01 06:17:00 dirmngr[32208.6] can't connect to '127.0.0.1': no IP address for host > > Maybe a missing localhost entry in /etc/hosts? I can imagine that our > libdns.c does not have a hardwired name for localhost. That would be > easy to fix. where do you imagine such a fix landing? in libdns.c ? > The problem with libdns.c is that Justus and me tried hard to get our > fixes upstream but never got any reply from the original author except > for one message that he will look at them. Meanwhile I think it might > be better to giveup on trying to get it upstream and keep on fixing > problems ourself - which would include better documentaion of the code. ouch, that sounds frustrating. >> Also, why is dirmngr trying to look up names for addresses? i don't know >> whether "resolve_dns_name" is A/AAAA lookup and "resolve_dns_addr" is > > So that we can return and store the hostname with a key. I don't understand this. Why would a hostname be relevant to anyone, given the configuration that the user asked for? Are you talking about a cryptographic key or some other sort of key? --dkg From wk at gnupg.org Tue Nov 14 17:06:35 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 14 Nov 2017 17:06:35 +0100 Subject: dirmngr logging confusion when trying to connect to a local keyserver (more reverse DNS?) In-Reply-To: <87h8tyz1bx.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 13 Nov 2017 22:43:14 +0800") References: <87fu9n5eei.fsf@fifthhorseman.net> <871sl29saa.fsf@wheatstone.g10code.de> <87h8tyz1bx.fsf@fifthhorseman.net> Message-ID: <87lgj87sl0.fsf@wheatstone.g10code.de> On Mon, 13 Nov 2017 15:43, dkg at fifthhorseman.net said: > where do you imagine such a fix landing? in libdns.c ? Yes. Or as a hack in dns-stuff.c. But I believe it belongs into libdns, proper. > I don't understand this. Why would a hostname be relevant to anyone, > given the configuration that the user asked for? Are you talking about Let's look at code used add a new host if (is_pool) { /* For a pool immediately convert the address to a string. */ tmperr = resolve_dns_addr (ai->addr, ai->addrlen, (DNS_NUMERICHOST | DNS_WITHBRACKET), &tmphost); } else if (!is_ip_address (name)) { /* This is a hostname. Use the name as given without going * through resolve_dns_addr. */ tmphost = xtrystrdup (name); } else { /* Do a PTR lookup on AI. If a name was not found the function * returns the numeric address (with brackets). */ tmperr = resolve_dns_addr (ai->addr, ai->addrlen, DNS_WITHBRACKET, &tmphost); } If that is a host from a pool the name indeed makes no sense and thus we shore the IP address. If the user has configured a host by name, we use that verbatim. If the host has been specified by IP address we map it back to a name. My original code was refactor in November 2015 and I would need to dig deeper into the history to see why this was done. So this is a guess: The idea was probably to avoid duplicate entries in the hosttable. Given that keyservers are more commonly configured by name it is plausible to map an IP to a name. That IP address might be from a preferred keyserver entry. Anyway, this third case (keyserver given by IP address) is not very common and this popped up only due to a missing entry for localhost in /etc/hosts. Thus having a fallback for 127/8 (and all the v6 local addresses) in the case of a missing /etc/hosts would solve the problem. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dgouttegattat at incenp.org Wed Nov 15 19:01:53 2017 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Wed, 15 Nov 2017 18:01:53 +0000 Subject: [PINENTRY PATCH] fltk: Fix compilation and distcheck errors. In-Reply-To: <20171029111939.21497-1-dgouttegattat@incenp.org> References: <20171029111939.21497-1-dgouttegattat@incenp.org> Message-ID: Hi GnuPG folks, On 10/29/2017 11:19 AM, Damien Goutte-Gattat wrote: > * fltk/Makefile.am (AM_CXXFLAGS): Add -std=c++11 flag. > (pinentry_fltk_SOURCES): Add header files. > (EXTRA_DIST): Add icon files. > * .gitignore: Ignore autoconf-generated files in fltk/. Nobody explicitly objected to this patch and since I have commit access to the pinentry repository, I plan to push this tomorrow in the evening. Please speak if you have any concern about it. In particular, is everyone fine with requiring C++11? Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed Nov 15 20:39:38 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 15 Nov 2017 20:39:38 +0100 Subject: [PINENTRY PATCH] fltk: Fix compilation and distcheck errors. In-Reply-To: (Damien Goutte-Gattat's message of "Wed, 15 Nov 2017 18:01:53 +0000") References: <20171029111939.21497-1-dgouttegattat@incenp.org> Message-ID: <8760ab49hh.fsf@wheatstone.g10code.de> On Wed, 15 Nov 2017 19:01, dgouttegattat at incenp.org said: > Please speak if you have any concern about it. In particular, is > everyone fine with requiring C++11? FLTK is optional thus the C++11 requirement is fine with me. 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 Nov 15 20:52:08 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 15 Nov 2017 20:52:08 +0100 Subject: [PATCH] default-preference-list: prefer SHA512. In-Reply-To: <20170928123226.28189-1-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 28 Sep 2017 08:32:26 -0400") References: <87wp50voca.fsf@fifthhorseman.net> <20170928123226.28189-1-dkg@fifthhorseman.net> Message-ID: <874lpv2uc7.fsf@wheatstone.g10code.de> On Thu, 28 Sep 2017 14:32, dkg at fifthhorseman.net said: > Specifically, this changes --default-preference-list from: > > SHA256 SHA384 SHA512 SHA224 > > to: > > SHA512 SHA384 SHA256 SHA224 Given that these are only preferences I don't see a reason to object against swapping SHA256 with SHA512. In general I would like to get rid of SHA224 and SHA384 because I can't see any advantage in using them or _announcing_ that they are supported: Both are truncated version of the other algos using a different IV. They are similar like AES192 which is also rarely used. Note that gpg will in any case _support_ all 4 algos. However, dropping them 2.2 would not be good. Thus my suggestion for 2.2 would be: SHA512 SHA256 SHA384 SHA224 and for 2.3: SHA512 SHA256 Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Thu Nov 16 09:17:35 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 16 Nov 2017 09:17:35 +0100 Subject: [PATCH] python: Default whence argument for Data() to SEEK_SET. In-Reply-To: <1507567430.31190.7.camel@cryptobitch.de> (Tobias Mueller's message of "Mon, 09 Oct 2017 18:43:50 +0200") References: <1503416905.23294.52.camel@cryptobitch.de> <1507567430.31190.7.camel@cryptobitch.de> Message-ID: <87shde1vts.fsf@wheatstone.g10code.de> On Mon, 9 Oct 2017 18:43, muelli at cryptobitch.de said: > I also wonder whether this patch has been reviewed and whether it is > acceptable. I guess that is okay. Can you please post a DCO (see gpgme/doc/HACKING). 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 rainer.perske at uni-muenster.de Thu Nov 16 13:36:14 2017 From: rainer.perske at uni-muenster.de (Rainer Perske) Date: Thu, 16 Nov 2017 13:36:14 +0100 (CET) Subject: Proposal with patch: Make socket directory host dependent In-Reply-To: Message-ID: Hello Usually you absolutely do not want to place any private data (keyrings, sockets) on a network drive. But there are exceptions when it comes to clustering for fail safety and the complete system (including network components) is under your full control. I have this situation: The user home directory of my webmailer is located on a network file system so it can be accessed from all nodes in the cluster. common/homedir.c places the socket for the agent communication into the same directory. But multiple nodes cannot share the same socket file; this causes curious problems. So the socket files must be node-specific, either by placing them into a non-shared directory or by using node-specific files, so that each node can run its own gpg-agent for a user. For this reason, I have patched common/homedir.c to use a nodename-specific subdirectory of the user directory for the sockets, see below. I am using this patch since long time in our production environment. I'd like to propose to incorporate this patch into GnuPG. It will change the default location of the socket files into a subdirectory of the previous location but I cannot see any way how it could hurt, except that you may need to restart running agents when installing this patch. Signed-off-by: Rainer Perske diff -ur gnupg-2.2.2/common/homedir.c gnupg-2.2.2rp/common/homedir.c --- gnupg-2.2.2/common/homedir.c 2000-01-01 00:00:00.000000000 +0000 +++ gnupg-2.2.2rp/common/homedir.c 2000-01-01 00:00:00.000000000 +0000 @@ -57,7 +57,9 @@ #include /* for stat() */ #endif - +#ifndef HAVE_W32_SYSTEM +#include +#endif #include "util.h" #include "sysutils.h" @@ -547,6 +549,9 @@ char prefix[13 + 1 + 20 + 6 + 1]; const char *s; char *name = NULL; +#ifndef HAVE_W32_SYSTEM + struct utsname utsbuf; +#endif *r_info = 0; @@ -694,6 +699,21 @@ name = xstrdup (prefix); leave: +#ifndef HAVE_W32_SYSTEM + /* try hostname specific subdirectory of gnupg_homedir */ + if (!name && !uname (&utsbuf) && utsbuf.nodename && !strchr (utsbuf.nodename, '/')) + { + name = xmalloc (strlen (gnupg_homedir ()) + 7 + strlen(utsbuf.nodename) +1); + strcpy (name, gnupg_homedir ()); + strcat (name, "/S.dir."); + strcat (name, utsbuf.nodename); + if (-1 == gnupg_mkdir (name, "-rwx") && errno != EEXIST) + { + xfree (name); + name = NULL; + } + } +#endif /* If nothing works fall back to the homedir. */ if (!name) { Thank you very much for thinking about it. Best regards -- Rainer Perske System operations dept. and director of the certification authority (WWUCA) Center for Information Processing (university computer center) Westf?lische Wilhelms-Universit?t Zentrum f?r Informationsverarbeitung Rainer Perske R?ntgenstra?e 7-13 48149 M?nster Germany phone: +49 251 83-31582 fax: +49 251 83-31555 e-mail: rainer.perske at uni-muenster.de WWW: https://www.uni-muenster.de/ZIV/Mitarbeiter/RainerPerske.shtml office: room 006, R?ntgenstra?e 11 site map: http://wwwuv2.uni-muenster.de/uniplan/?action=spot&gebnr=7474 Certification Authority of the University of M?nster (WWUCA): phone: +49 251 83-31590 fax: +49 251 83-31555 e-mail: ca at uni-muenster.de WWW: https://www.uni-muenster.de/WWUCA/ Center for Information Processing: phone: +49 251 83-31600 (Mon-Fri 7:30-17:30) fax: +49 251 83-31555 e-mail: ziv at uni-muenster.de WWW: https://www.uni-muenster.de/ZIV/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6807 bytes Desc: S/MIME cryptographic signature URL: From wk at gnupg.org Thu Nov 16 15:09:23 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 16 Nov 2017 15:09:23 +0100 Subject: Proposal with patch: Make socket directory host dependent In-Reply-To: (Rainer Perske's message of "Thu, 16 Nov 2017 13:36:14 +0100 (CET)") References: Message-ID: <87d14ixqlo.fsf@wheatstone.g10code.de> On Thu, 16 Nov 2017 13:36, rainer.perske at uni-muenster.de said: > So the socket files must be node-specific, either by placing them into > a non-shared directory or by using node-specific files, so that each > node can run its own gpg-agent for a user. Actually the default in 2.1 is to use a non-shared socket directry. From the README ** Socket directory GnuPG uses Unix domain sockets to connect its components (on Windows an emulation of these sockets is used). Depending on the type of the file system, it is sometimes not possible to use the GnuPG home directory (i.e. ~/.gnupg) as the location for the sockets. To solve this problem GnuPG prefers the use of a per-user directory below the the /run (or /var/run) hierarchy for the the sockets. It is thus suggested to create per-user directories on system or session startup. For example the following snippet can be used in /etc/rc.local to create these directories: [ ! -d /run/user ] && mkdir /run/user awk -F: = 1000 && $3 < 65000 {print $3}' \ | ( while read uid rest; do if [ ! -d "/run/user/$uid" ]; then mkdir /run/user/$uid chown $uid /run/user/$uid chmod 700 /run/user/$uid fi done ) Depending on the system it is /var/run. You can use gpgconf --list-dirs socketdir to check whether GnuPG is actually using it. To check for problems you may explicitly create the directory (which gpg does on the fly) using gpgconf --verbose --create-socketdir this uses the same code as gpg and --verbose (or --dry-run) prints warnings if the permissions are not as expected. 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 rainer.perske at uni-muenster.de Thu Nov 16 17:31:01 2017 From: rainer.perske at uni-muenster.de (Rainer Perske) Date: Thu, 16 Nov 2017 17:31:01 +0100 (CET) Subject: Proposal with patch: Make socket directory host dependent In-Reply-To: <87d14ixqlo.fsf@wheatstone.g10code.de> Message-ID: Hello > Actually the default in 2.1 is to use a non-shared socket directry. Thank you very much! Unfortunately I cannot use /run/user/(userid) because it is maintained by systemd and in my webmailer situation it can be deleted even if the agent is still running. (systemd does not know anything about the sessions of a webmailer.) But your objection brings me a much better and more simple idea: Line 544 of common/homedir.c contains: static const char * const bases[] = { "/run", "/var/run", NULL}; Could you please prepend a configurable directory to this list? I propose this most simple change: static const char * const bases[] = { GNUPG_LOCALSTATEDIR"/run", "/run", "/var/run", NULL}; Then I can simply use your mechanism. Best regards -- Rainer Perske Abteilung Systembetrieb und Leiter der Zertifizierungsstelle (WWUCA) Zentrum f?r Informationsverarbeitung (Universit?tsrechenzentrum) Westf?lische Wilhelms-Universit?t Zentrum f?r Informationsverarbeitung Rainer Perske R?ntgenstra?e 7-13 48149 M?nster Tel.: +49 251 83-31582 Fax.: +49 251 83-31555 E-Mail: rainer.perske at uni-muenster.de WWW: https://www.uni-muenster.de/ZIV/Mitarbeiter/RainerPerske.shtml B?ro: Raum 006, R?ntgenstra?e 11 Lageplan: http://wwwuv2.uni-muenster.de/uniplan/?action=spot&gebnr=7474 Zertifizierungsstelle der Universit?t M?nster (WWUCA): Tel.: +49 251 83-31590 Fax.: +49 251 83-31555 E-Mail: ca at uni-muenster.de WWW: https://www.uni-muenster.de/WWUCA/ Zentrum f?r Informationsverarbeitung (ZIV): Tel.: +49 251 83-31600 (Mo-Fr 7:30-17:30 Uhr) Fax.: +49 251 83-31555 E-Mail: ziv at uni-muenster.de WWW: https://www.uni-muenster.de/ZIV/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6807 bytes Desc: S/MIME cryptographic signature URL: From dkg at fifthhorseman.net Fri Nov 17 03:26:19 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 17 Nov 2017 10:26:19 +0800 Subject: [PATCH] doc: clarify that --encrypt refers to public key encryption Message-ID: <20171117022619.32121-1-dkg@fifthhorseman.net> * doc/gpg.texi: update --encrypt stanza -- A simple read of gpg(1) is ambiguous about whether --encrypt could be for either symmetric or pubkey encryption. Closer inference suggests that --encrypt is about pubkey encryption only. Make that clearer on a first read. Signed-off-by: Daniel Kahn Gillmor --- doc/gpg.texi | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/doc/gpg.texi b/doc/gpg.texi index bd45b0422..858105d27 100644 --- a/doc/gpg.texi +++ b/doc/gpg.texi @@ -196,11 +196,12 @@ Make a detached signature. @item --encrypt @itemx -e @opindex encrypt -Encrypt data. This command may be combined with @option{--sign} (to -sign and encrypt a message), @option{--symmetric} (to encrypt a -message that can decrypted using a secret key or a passphrase), or - at option{--sign} and @option{--symmetric} together (for a signed -message that can be decrypted using a secret key or a passphrase). +Encrypt data to a public key. This command may be combined with + at option{--sign} (to sign and encrypt a message), @option{--symmetric} +(to encrypt a message that can decrypted using a secret key or a +passphrase), or @option{--sign} and @option{--symmetric} together (for +a signed message that can be decrypted using a secret key or a +passphrase). @item --symmetric @itemx -c -- 2.15.0 From wk at gnupg.org Fri Nov 17 08:43:41 2017 From: wk at gnupg.org (Werner Koch) Date: Fri, 17 Nov 2017 08:43:41 +0100 Subject: [PATCH] doc: clarify that --encrypt refers to public key encryption In-Reply-To: <20171117022619.32121-1-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 17 Nov 2017 10:26:19 +0800") References: <20171117022619.32121-1-dkg@fifthhorseman.net> Message-ID: <87mv3lwdsi.fsf@wheatstone.g10code.de> On Fri, 17 Nov 2017 03:26, dkg at fifthhorseman.net said: > * doc/gpg.texi: update --encrypt stanza I don't think that ChangeLog entries are required for doc entries. The subject should be enough. > +Encrypt data to a public key. This command may be combined with Maybe Encrypt data to one or more public keys and a reference to -r might also be justified. 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 Nov 17 08:55:07 2017 From: wk at gnupg.org (Werner Koch) Date: Fri, 17 Nov 2017 08:55:07 +0100 Subject: Proposal with patch: Make socket directory host dependent In-Reply-To: (Rainer Perske's message of "Thu, 16 Nov 2017 17:31:01 +0100 (CET)") References: Message-ID: <87ine9wd9g.fsf@wheatstone.g10code.de> On Thu, 16 Nov 2017 17:31, rainer.perske at uni-muenster.de said: > Could you please prepend a configurable directory to this list? > I propose this most simple change: > > static const char * const bases[] = { > GNUPG_LOCALSTATEDIR"/run", > "/run", "/var/run", NULL}; Thus for building without any options this would be "/usr/local/var/run", "/run", "/var/run" and for a distro build (--prefix=/) this would be "/var/run", "/run", "/var/run" so that we need to detect this case to get the order right again. I assume you are not using a a distro supplied gnupg; in this case a dedicated configure option for the first socketdir to try would be easier because it does not break existing usages. A runtime option can't be used here, except if we would take the list of socketdirs to try from a global config files (e.g. /etc/gnupg/socketdirs.list). 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 rainer.perske at uni-muenster.de Fri Nov 17 20:03:12 2017 From: rainer.perske at uni-muenster.de (Rainer Perske) Date: Fri, 17 Nov 2017 20:03:12 +0100 (CET) Subject: Proposal with patch: Make socket directory host dependent In-Reply-To: <87ine9wd9g.fsf@wheatstone.g10code.de> Message-ID: Hello, [common/homedir.c] > > static const char * const bases[] = { > > GNUPG_LOCALSTATEDIR"/run", > > "/run", "/var/run", NULL}; > [...] and for a distro build (--prefix=/) this would be > "/var/run", > "/run", > "/var/run" > so that we need to detect this case to get the order right again. ok, I had not seen this common edge case. What about this? (line 544) static const char * const bases[] = {"/run/gnupg", "/var/run/gnupg", "/run", "/var/run", NULL}; btw we must not forget to enlarge char prefix[] accordingly: (line 547) char prefix[6 + 13 + 1 + 20 + 6 + 1]; > I assume you are not using a a distro supplied gnupg; in this case a > dedicated configure option for the first socketdir to try would be > easier because it does not break existing usages. Absolutely correct. However, inventing a new configure option would make my change request much larger and I always try to make such changes or change requests as small as possible hoping to avoid breaking something by accident. > A runtime option > can't be used here, except if we would take the list of socketdirs to > try from a global config files (e.g. /etc/gnupg/socketdirs.list). I agree completely, but that would be even more work that IMHO is probably not justified. Have a fine weekend! -- Rainer Perske Abteilung Systembetrieb und Leiter der Zertifizierungsstelle (WWUCA) Zentrum f?r Informationsverarbeitung (Universit?tsrechenzentrum) Westf?lische Wilhelms-Universit?t Zentrum f?r Informationsverarbeitung Rainer Perske R?ntgenstra?e 7-13 48149 M?nster Tel.: +49 251 83-31582 Fax.: +49 251 83-31555 E-Mail: rainer.perske at uni-muenster.de WWW: https://www.uni-muenster.de/ZIV/Mitarbeiter/RainerPerske.shtml B?ro: Raum 006, R?ntgenstra?e 11 Lageplan: http://wwwuv2.uni-muenster.de/uniplan/?action=spot&gebnr=7474 Zertifizierungsstelle der Universit?t M?nster (WWUCA): Tel.: +49 251 83-31590 Fax.: +49 251 83-31555 E-Mail: ca at uni-muenster.de WWW: https://www.uni-muenster.de/WWUCA/ Zentrum f?r Informationsverarbeitung (ZIV): Tel.: +49 251 83-31600 (Mo-Fr 7:30-17:30 Uhr) Fax.: +49 251 83-31555 E-Mail: ziv at uni-muenster.de WWW: https://www.uni-muenster.de/ZIV/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6807 bytes Desc: S/MIME cryptographic signature URL: From dkg at fifthhorseman.net Sat Nov 18 00:28:01 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 18 Nov 2017 07:28:01 +0800 Subject: Proposal with patch: Make socket directory host dependent In-Reply-To: References: Message-ID: <87375cv62m.fsf@fifthhorseman.net> On Thu 2017-11-16 17:31:01 +0100, Rainer Perske wrote: > Unfortunately I cannot use /run/user/(userid) because it is maintained > by systemd and in my webmailer situation it can be deleted even if the > agent is still running. (systemd does not know anything about the > sessions of a webmailer.) I'm not convinced this response makes much sense. Why *wouldn't* the system's service manager (systemd, in your case) be unaware of webmailer sessions? What is your webmail configuration doing that it is switching to a new user session, but deliberately avoiding registering that user session with the local system service manager? Fixing this problem at the GnuPG layer seems like an odd approach. --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 Sat Nov 18 01:11:49 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 18 Nov 2017 08:11:49 +0800 Subject: [PATCH] default-preference-list: prefer SHA512. In-Reply-To: <874lpv2uc7.fsf@wheatstone.g10code.de> References: <87wp50voca.fsf@fifthhorseman.net> <20170928123226.28189-1-dkg@fifthhorseman.net> <874lpv2uc7.fsf@wheatstone.g10code.de> Message-ID: <87wp2otph6.fsf@fifthhorseman.net> On Wed 2017-11-15 20:52:08 +0100, Werner Koch wrote: > On Thu, 28 Sep 2017 14:32, dkg at fifthhorseman.net said: > >> Specifically, this changes --default-preference-list from: >> >> SHA256 SHA384 SHA512 SHA224 >> >> to: >> >> SHA512 SHA384 SHA256 SHA224 > > Given that these are only preferences I don't see a reason to object > against swapping SHA256 with SHA512. great! should i merge the patch then on master and STABLE-BRANCH-2-2, or will you do it? > In general I would like to get rid of SHA224 and SHA384 because I can't > see any advantage in using them or _announcing_ that they are supported: > Both are truncated version of the other algos using a different IV. > They are similar like AES192 which is also rarely used. Note that gpg > will in any case _support_ all 4 algos. > > However, dropping them 2.2 would not be good. Thus my suggestion for > 2.2 would be: > > SHA512 SHA256 SHA384 SHA224 > > and for 2.3: > > SHA512 SHA256 If you'd like to have a separate discussion about dropping SHA224 and SHA384 for 2.3, i have no objections -- i've never seen those used in the wild, so discouraging their use further doesn't seem like a problem to me. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From rainer.perske at uni-muenster.de Sun Nov 19 14:59:27 2017 From: rainer.perske at uni-muenster.de (Rainer Perske) Date: Sun, 19 Nov 2017 14:59:27 +0100 (CET) Subject: Proposal with patch: Make socket directory host dependent In-Reply-To: <87375cv62m.fsf@fifthhorseman.net> Message-ID: Hello, > > Unfortunately I cannot use /run/user/(userid) because it is > > maintained by systemd and in my webmailer situation it can be > > deleted even if the agent is still running. (systemd does not know > > anything about the sessions of a webmailer.) > I'm not convinced this response makes much sense. Why *wouldn't* the > system's service manager (systemd, in your case) be unaware of > webmailer sessions? > What is your webmail configuration doing that it is switching to a > new user session, but deliberately avoiding registering that user > session with the local system service manager? Because systemd manages processes on a *single* host. I have servers clustered and distributed over two locations for fail safety and load distribution and a webmailer session is valid on all cluster hosts. systemd (more exactly: "systemd-logind") cannot be used to manage cluster-wide sessions. So I have to fight with the fact that my webmailer is running in a cluster, but GnuPG and its agent are not because they use localhost-only sockets for interprocess communication and never were designed to be used in a cluster environment. I want to use GnuPG because it is the best software for this purpose so my webmailer gives GnuPG an environment it is happy with. Some more background information: I do not need GnuPG sessions at all. If I could call gpgsm in a way that no gpg-agent or dirmngr process and no socket file would survive this call, this would be slower but I could live with it. But GnuPG is now built in a way that always socket files are created and that always gpg-agent and dirmngr are started the first time they are needed. (You definitely have very good reasons to do so, avoiding long startup times is one of them.) So I have to live with these files and processes, for nearly 100,000 possible users. Because the processes are running on single hosts, the socket files must be placed on host-local file systems. Otherwise processes on other hosts see the socket files but do not see the agents. Fall-back location of the socket file is the user's home directory. In my situation, this is a cluster-wide file system. And so I got into trouble. This is the main cause for my patch and proposal. To solve the problems, I must make sure that GnuPG places the socket files on host-only file systems. My patch and proposal have this single aim: Place the socket on a host-only file system but do not allow cluster-unaware managers like "systemd-logind" to bother with them. So I cannot use /run/user/ or /var/run/user/ that are managed by systemd-logind. A general solution would be to make these directories configurable. I do not dare to ask you to develop such a general solution. A simple solution would be to prepend GnuPG-specific host-local directories not managed by systemd-logind to the list of directories. Hence my proposal. According to the Linux File System Standard, /var/run/gnupg/ (or /run/gnupg/ on those systems using /run/ ) seems to be the best place in my eyes. So my proposal (prepend /run/gnupg and /var/run/gnupg to /run and /var/run ) would solve my problem. (My webmailer can make sure that /run/gnupg/user/ exists and has the correct owner, group, and permissions before calling gpgsm. And my cluster-aware session management can clean these directories.) (I know that my solution can cause multiple agents running for the same user on different hosts concurrently. But as far as I can see you are using proper file locking so this does not cause any problem. At least in the last 3 years my patch (see first mail of this thread) has not caused any problem.) Best regards -- Rainer Perske Abteilung Systembetrieb und Leiter der Zertifizierungsstelle (WWUCA) Zentrum f?r Informationsverarbeitung (Universit?tsrechenzentrum) Westf?lische Wilhelms-Universit?t Zentrum f?r Informationsverarbeitung Rainer Perske R?ntgenstra?e 7-13 48149 M?nster Tel.: +49 251 83-31582 Fax.: +49 251 83-31555 E-Mail: rainer.perske at uni-muenster.de WWW: https://www.uni-muenster.de/ZIV/Mitarbeiter/RainerPerske.shtml B?ro: Raum 006, R?ntgenstra?e 11 Lageplan: http://wwwuv2.uni-muenster.de/uniplan/?action=spot&gebnr=7474 Zertifizierungsstelle der Universit?t M?nster (WWUCA): Tel.: +49 251 83-31590 Fax.: +49 251 83-31555 E-Mail: ca at uni-muenster.de WWW: https://www.uni-muenster.de/WWUCA/ Zentrum f?r Informationsverarbeitung (ZIV): Tel.: +49 251 83-31600 (Mo-Fr 7:30-17:30 Uhr) Fax.: +49 251 83-31555 E-Mail: ziv at uni-muenster.de WWW: https://www.uni-muenster.de/ZIV/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6807 bytes Desc: S/MIME cryptographic signature URL: From wk at gnupg.org Sun Nov 19 15:50:03 2017 From: wk at gnupg.org (Werner Koch) Date: Sun, 19 Nov 2017 15:50:03 +0100 Subject: [PATCH] default-preference-list: prefer SHA512. In-Reply-To: <87wp2otph6.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Sat, 18 Nov 2017 08:11:49 +0800") References: <87wp50voca.fsf@fifthhorseman.net> <20170928123226.28189-1-dkg@fifthhorseman.net> <874lpv2uc7.fsf@wheatstone.g10code.de> <87wp2otph6.fsf@fifthhorseman.net> Message-ID: <87po8euxus.fsf@wheatstone.g10code.de> On Sat, 18 Nov 2017 01:11, dkg at fifthhorseman.net said: > great! should i merge the patch then on master and STABLE-BRANCH-2-2, > or will you do it? Please push to 2.2 > If you'd like to have a separate discussion about dropping SHA224 and > SHA384 for 2.3, i have no objections -- i've never seen those used in I would say just go ahead and remove these preferences from master. 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 mcgrof at kernel.org Tue Nov 21 02:27:14 2017 From: mcgrof at kernel.org (Luis R. Rodriguez) Date: Tue, 21 Nov 2017 02:27:14 +0100 Subject: RFC: retry keyservers witout SRV Message-ID: <20171121012714.GC729@wotan.suse.de> I have a R6300v2 which after a firmware upgrade it seems it now replies to SRV queries for _pgpkey-https and others as a "format error". I've captured tcpdumps for it and are on file. I figured something like the below would work as it retries without the SRV if it first failed with it, but no go so far. This is a slightly odd issue for an AP/router to have though, specially since it seems to have been a firmware regression if this is the mechanism we've had in place for a long time. Otherwise I guess this is a regression due to an even older bug where it was reported _hkp_tcp SRV record doesn't work. If this was a firmware regression, it begs the question what might have motivated Netgear to reply in such a way, and one then wonders what other APs out there followed similar logic. Sadly to the user, this just seems like gpgp does't work, given something so simple as a search for a key fails, even if "DNS" seems to be working. In my case no matter what I used as my keyserver, nothing worked, and it seems its because we default to SRV _pgpkey* stuff first always now and never retry without SRV. [0] https://dev.gnupg.org/T3517 [1] https://dev.gnupg.org/T2451 diff --git a/dirmngr/ks-engine-hkp.c b/dirmngr/ks-engine-hkp.c index 4a0b08f4f..1ba307828 100644 --- a/dirmngr/ks-engine-hkp.c +++ b/dirmngr/ks-engine-hkp.c @@ -1459,8 +1459,17 @@ ks_hkp_search (ctrl_t ctrl, parsed_uri_t uri, const char *pattern, err = make_host_part (ctrl, uri->scheme, uri->host, uri->port, reselect, uri->explicit_port, &hostport, &httpflags, &httphost); - if (err) - goto leave; + /* + * Some buggy Routers (R6300v2) treat _pgpkey-https.tcp SRV queries + * as invalid queries, as a query format error. One has no other + * option but to retry without SRV. + */ + if (err) { + if (reselect) + goto leave; + reselect = 1; + goto again; + } searchkey = http_escape_string (pattern, EXTRA_ESCAPE_CHARS); if (!searchkey) @@ -1603,7 +1612,12 @@ ks_hkp_get (ctrl_t ctrl, parsed_uri_t uri, const char *keyspec, estream_t *r_fp) reselect, uri->explicit_port, &hostport, &httpflags, &httphost); if (err) - goto leave; + { + if (reselect); + goto leave; + reselect = 1; + goto again; + } xfree (request); request = strconcat (hostport, From wk at gnupg.org Tue Nov 21 08:51:58 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 21 Nov 2017 08:51:58 +0100 Subject: [Announce] GnuPG 2.2.3 released Message-ID: <87bmjwkr1d.fsf@wheatstone.g10code.de> Hello! We are is pleased to announce the availability of a new GnuPG release: version 2.2.3. 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.3 =================================== * gpgsm: Fix initial keybox creation on Windows. [#3507] * dirmngr: Fix crash in case of a CRL loading error. [#3510] * Fix the name of the Windows registry key. [Git#4f5afaf1fd] * gpgtar: Fix wrong behaviour of --set-filename. [#3500] * gpg: Silence AKL retrieval messages. [#3504] * agent: Use clock or clock_gettime for calibration. [#3056] * agent: Improve robustness of the shutdown pending state. [Git#7ffedfab89] Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.2.3 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.3.tar.bz2 (6393k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.3.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.3_20171120.exe (3806k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.3_20171120.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. A new Gpg4win 3.0 installer featuring this version of GnuPG will be available soon. 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.3.tar.bz2 you would use this command: gpg --verify gnupg-2.2.3.tar.bz2.sig gnupg-2.2.3.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.3.tar.bz2, you run the command like this: sha1sum gnupg-2.2.3.tar.bz2 and check that the output matches the next line: 68ed37d363166b5bd79971537484148eb8f2958c gnupg-2.2.3.tar.bz2 9914e93d5ac50b4e542b4320e1e130dc1552e24b gnupg-w32-2.2.3_20171120.exe 74d3d9565b4baa5627932b20af557645d7915e77 gnupg-w32-2.2.3_20171120.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 and Support ========================= 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 to 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. 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. Thanks ====== Maintenance and development of GnuPG is mostly financed by donations. The GnuPG project currently employs one full-time developer and one contractor. Both work exclusivly on GnuPG and closely related software like Libgcrypt, GPGME, and GPA. We are planning to extend our team again. Right now we are looking for an admin for our bug tracker; see We have to thank all the people who helped the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, answering questions on the mailing lists, and with financial support. Happy hacking, Your GnuPG hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users'at'gnupg.org mailing list. p.p.s List of Release Signing Keys: To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: rsa2048 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048 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 2014-10-29 [expires: 2020-10-30] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa3072 2017-03-17 [expires: 2027-03-15] Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) The keys are available at 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 alon.barlev at gmail.com Tue Nov 21 07:54:36 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 21 Nov 2017 08:54:36 +0200 Subject: Release gpgme-1.10.0? Message-ID: Hi, Any chance for gpgme-1.10.0 release? This release contains important build fixes. Thanks! Alon From kristian.fiskerstrand at sumptuouscapital.com Tue Nov 21 14:48:30 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 21 Nov 2017 14:48:30 +0100 Subject: RFC: retry keyservers witout SRV In-Reply-To: <20171121012714.GC729@wotan.suse.de> References: <20171121012714.GC729@wotan.suse.de> Message-ID: <498b1760-13d4-f9cd-0868-4b34bcd40b6e@sumptuouscapital.com> On 11/21/2017 02:27 AM, Luis R. Rodriguez wrote: > I have a R6300v2 which after a firmware upgrade it seems it now replies to SRV > queries for _pgpkey-https and others as a "format error". I've captured tcpdumps > for it and are on file. My $0.02 would be that a format error for SRV request is that should be fixed in the DNS resolver (or use another resolver) and not introduce complexity to work around, in particular as long as it isn't a widespread issue. Are you aware of any bug reports for this with netgear? -- ---------------------------- 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 ---------------------------- "My father used to say: ?Don?t raise your voice, improve your argument.?" (Desmond Tutu) -------------- 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 Tue Nov 21 17:15:02 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 21 Nov 2017 11:15:02 -0500 Subject: [PATCH] doc: clarify that --encrypt refers to public key encryption In-Reply-To: <87mv3lwdsi.fsf@wheatstone.g10code.de> References: <20171117022619.32121-1-dkg@fifthhorseman.net> <87mv3lwdsi.fsf@wheatstone.g10code.de> Message-ID: <87vai3obg9.fsf@fifthhorseman.net> On Fri 2017-11-17 08:43:41 +0100, Werner Koch wrote: > On Fri, 17 Nov 2017 03:26, dkg at fifthhorseman.net said: >> * doc/gpg.texi: update --encrypt stanza > > I don't think that ChangeLog entries are required for doc entries. The > subject should be enough. > >> +Encrypt data to a public key. This command may be combined with > > Maybe > > Encrypt data to one or more public keys > > and a reference to -r might also be justified. OK, pushed a modified/clarified form to master. Should this also be backported to the stable branches? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From matthew.summers at syapse.com Tue Nov 21 19:12:56 2017 From: matthew.summers at syapse.com (Matthew Summers) Date: Tue, 21 Nov 2017 12:12:56 -0600 Subject: [RFC PATCH] enable configurable SECMEM_BUFFER_SIZE [WAS Re: Please Consider Increasing SECMEM_BUFFER_SIZE To 1048576] In-Reply-To: References: Message-ID: Hello! What can I do to get this into good enough shape to be included in a release? I can sign the contrib agreement. I can submit this under my @gentoo.org dev ID if that is better, generally versus the corporate id. This is a severe issue for us that seems pretty easy to remedy with a patch like this. Thanks, Matt From wlt-ml at o-sinc.com Tue Nov 21 21:08:19 2017 From: wlt-ml at o-sinc.com (William L. Thomson Jr.) Date: Tue, 21 Nov 2017 15:08:19 -0500 Subject: Release gpgme-1.10.0? In-Reply-To: References: Message-ID: On Tue, 21 Nov 2017 08:54:36 +0200 Alon Bar-Lev wrote: > Hi, > Any chance for gpgme-1.10.0 release? > This release contains important build fixes. Jumping on the release bandwagon. What about a pinentry release? https://dev.gnupg.org/T3279 #releaseme2 :) -- William L. Thomson Jr. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From dgouttegattat at incenp.org Wed Nov 22 00:25:00 2017 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Tue, 21 Nov 2017 23:25:00 +0000 Subject: Release gpgme-1.10.0? In-Reply-To: References: Message-ID: <3432994d-7b98-1b13-a034-0b1f979b9f25@incenp.org> On 11/21/2017 08:08 PM, William L. Thomson Jr. wrote: > Jumping on the release bandwagon. What about a pinentry release? If we are about to make a new pinentry release, it would be nice to have a decision about the recently proposed pinentry-tqt (a pinentry for the KDE3-based Trinity Desktop Environment). If the decision is positive, it could then be shipped with the upcoming release. As announced previously [1], I have the code properly integrated in pinentry's build system in the "pinentry-tqt" branch of my own repository at git://git.incenp.org/pinentry.git. I can merge it at anytime, but even with commit access I do not feel it is up to me to accept a new pinentry, and therefore I do not want to merge it without explicit approval from other pinentry developers. Damien [1] https://lists.gnupg.org/pipermail/gnupg-devel/2017-October/033200.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed Nov 22 09:47:10 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 22 Nov 2017 09:47:10 +0100 Subject: [RFC PATCH] enable configurable SECMEM_BUFFER_SIZE In-Reply-To: (Matthew Summers's message of "Tue, 21 Nov 2017 12:12:56 -0600") References: Message-ID: <87shd6hf8x.fsf@wheatstone.g10code.de> Hi! On Tue, 21 Nov 2017 19:12, matthew.summers at syapse.com said: > id. This is a severe issue for us that seems pretty easy to remedy > with a patch like this. Can you please explain the problem you try to solve. Most crypto operations which temporary require allocation of extra chunks of data (big integer computation) the secure memory area is enlarged on the fly. The gpg-agent stores secret keys in a cache which is allocated in standard memory. This can be done because the keys are stored encrypted in this cache (using a per process ephemeral key). Any problems creating or using more keys is either due to a memory leak in gpg-agent or because you have a lot of active connections to the gpg-agent using private keys. For that latter case there are two solutions: 1. Enlarging the secure memory area. This has the problem that you will never known how much is sufficient. 2. Enlarge the secure memory area on the fly as we do it with some of the Libgcrypt internal mallocs (actually all xmalloc style allocations). That would require an update to Libgcrypt and a runtime option to gpg-agent to enable this. 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 Nov 22 09:52:05 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 22 Nov 2017 09:52:05 +0100 Subject: [PATCH] doc: clarify that --encrypt refers to public key encryption In-Reply-To: <87vai3obg9.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 21 Nov 2017 11:15:02 -0500") References: <20171117022619.32121-1-dkg@fifthhorseman.net> <87mv3lwdsi.fsf@wheatstone.g10code.de> <87vai3obg9.fsf@fifthhorseman.net> Message-ID: <87o9nuhf0q.fsf@wheatstone.g10code.de> On Tue, 21 Nov 2017 17:15, dkg at fifthhorseman.net said: > OK, pushed a modified/clarified form to master. Should this also be > backported to the stable branches? Yes. On Monday's telco we agreed on that clear bug fixes (and I would also say doc fixes) should be done to the 2.2 branch and then merged by the hacker on duty into master within the next few days. All changes for which it is not clear whether they need to go into 2.2 are to be done in master and will be cherry-picked into 2.2 on a case to case base. 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 Nov 22 10:04:07 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 22 Nov 2017 10:04:07 +0100 Subject: Release gpgme-1.10.0? In-Reply-To: (Alon Bar-Lev's message of "Tue, 21 Nov 2017 08:54:36 +0200") References: Message-ID: <87fu96hego.fsf@wheatstone.g10code.de> On Tue, 21 Nov 2017 07:54, alon.barlev at gmail.com said: > Any chance for gpgme-1.10.0 release? Right, it is long overdue. There are some open bugs and a proposal for a compatible Python change for which I have seen no other opinions [1]. 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 Nov 22 10:00:46 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 22 Nov 2017 10:00:46 +0100 Subject: Release gpgme-1.10.0? In-Reply-To: <3432994d-7b98-1b13-a034-0b1f979b9f25@incenp.org> (Damien Goutte-Gattat's message of "Tue, 21 Nov 2017 23:25:00 +0000") References: <3432994d-7b98-1b13-a034-0b1f979b9f25@incenp.org> Message-ID: <87k1yihem9.fsf@wheatstone.g10code.de> On Wed, 22 Nov 2017 00:25, dgouttegattat at incenp.org said: > If we are about to make a new pinentry release, it would be nice to > have a decision about the recently proposed pinentry-tqt (a pinentry I am fine with this as long as it is not enabled by default. > it is up to me to accept a new pinentry, and therefore I do not want > to merge it without explicit approval from other pinentry developers. Yesterday I did some work on Pinentry to see how much effort it will be to build a FLTK Pinentry for Windows. I reached a point where I can cross-build it using static FLTK libs; it does not yet work on my (aehmm) Vista box - needs some debugging. Building the FLTK libs is pretty slow and FLTK needs to be stripped down to what we actually need. Thus I doubt that we will see an FLTK Pinentry in the plain Windows installer in the next weeks. I am all in favor of doing a pinentry release very soon. GPGME will be the next candidate. I am still looking for a Python hacker to take responsibility for the GPGME's Python bindings (including working on a Windows port of them). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dgouttegattat at incenp.org Wed Nov 22 11:07:57 2017 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Wed, 22 Nov 2017 10:07:57 +0000 Subject: Release gpgme-1.10.0? In-Reply-To: <87k1yihem9.fsf@wheatstone.g10code.de> References: <3432994d-7b98-1b13-a034-0b1f979b9f25@incenp.org> <87k1yihem9.fsf@wheatstone.g10code.de> Message-ID: <529820b4-f741-23e0-9375-24d2ddcd0112@incenp.org> On 11/22/2017 09:00 AM, Werner Koch wrote: >> If we are about to make a new pinentry release, it would be nice to >> have a decision about the recently proposed pinentry-tqt (a pinentry > > I am fine with this as long as it is not enabled by default. The TQt pinentry is enabled only when explicitly requested (--enable-pinentry-tqt), and when enabled it is selected as the default pinentry only if that's the only pinentry available (that is, all other pinentries are disabled). OK then, I will push it to master at some point today. Thanks, Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed Nov 22 11:32:48 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 22 Nov 2017 11:32:48 +0100 Subject: Release gpgme-1.10.0? In-Reply-To: <529820b4-f741-23e0-9375-24d2ddcd0112@incenp.org> (Damien Goutte-Gattat's message of "Wed, 22 Nov 2017 10:07:57 +0000") References: <3432994d-7b98-1b13-a034-0b1f979b9f25@incenp.org> <87k1yihem9.fsf@wheatstone.g10code.de> <529820b4-f741-23e0-9375-24d2ddcd0112@incenp.org> Message-ID: <87r2sqfvsf.fsf@wheatstone.g10code.de> On Wed, 22 Nov 2017 11:07, dgouttegattat at incenp.org said: > OK then, I will push it to master at some point today. Thanks. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From matthew.summers at syapse.com Wed Nov 22 16:23:48 2017 From: matthew.summers at syapse.com (Matthew Summers) Date: Wed, 22 Nov 2017 09:23:48 -0600 Subject: [RFC PATCH] enable configurable SECMEM_BUFFER_SIZE In-Reply-To: <87shd6hf8x.fsf@wheatstone.g10code.de> References: <87shd6hf8x.fsf@wheatstone.g10code.de> Message-ID: On Wed, Nov 22, 2017 at 2:47 AM, Werner Koch wrote: > Hi! > > On Tue, 21 Nov 2017 19:12, matthew.summers at syapse.com said: > >> id. This is a severe issue for us that seems pretty easy to remedy >> with a patch like this. > > Can you please explain the problem you try to solve. > > Any problems creating or using more keys is either due to a memory leak > in gpg-agent or because you have a lot of active connections to the > gpg-agent using private keys. We have a lot of active connections to the gpg-agent using a single private key. I outlined our use case in more detail here [1]. > For that latter case there are two solutions: > > 1. Enlarging the secure memory area. This has the problem that you > will never known how much is sufficient. We are enlarging the secmem_buffer using the patch attached previously. We are determining the size using a simple empirical test we constructed based on our known use case and concurrency requirements. This is a fairly standard tuning process we have to go through now so we are able to continue using GnuPG (we love it). This test is outlined here [2]. This is the reason why we would love to see the secmem_buffer size configurable, per the patch. It is perhaps notable that we needed to go from ~1mb to 2mb when moving from 2.1.23 to 2.2.0. Thanks for taking the time to reply and investigate this issue. I know how busy it is maintaining OSS, and want you all to know how much we all appreciate your efforts all these years. Many many thanks. Cheers! Matt Summers aka quantumsummers at gentoo dot oh arrrrr geeeee [1] https://lists.gnupg.org/pipermail/gnupg-devel/2017-June/032913.html [2] https://lists.gnutls.org/pipermail/gnupg-devel/2017-November/033227.html From wlt-ml at o-sinc.com Wed Nov 22 16:27:20 2017 From: wlt-ml at o-sinc.com (William L. Thomson Jr.) Date: Wed, 22 Nov 2017 10:27:20 -0500 Subject: Release gpgme-1.10.0? In-Reply-To: <87k1yihem9.fsf@wheatstone.g10code.de> References: <3432994d-7b98-1b13-a034-0b1f979b9f25@incenp.org> <87k1yihem9.fsf@wheatstone.g10code.de> Message-ID: Sorry to hijack Alon's gpgme thread! On Wed, 22 Nov 2017 10:00:46 +0100 Werner Koch wrote: > On Wed, 22 Nov 2017 00:25, dgouttegattat at incenp.org said: > > > If we are about to make a new pinentry release, it would be nice to > > have a decision about the recently proposed pinentry-tqt (a > > pinentry > > I am fine with this as long as it is not enabled by default. > > > it is up to me to accept a new pinentry, and therefore I do not want > > to merge it without explicit approval from other pinentry > > developers. > > Yesterday I did some work on Pinentry to see how much effort it will > be to build a FLTK Pinentry for Windows. The EFL one likely can run on Windows as well. I have no information to help there, other than I know EFL has support for Windows. If anyone does test that welcome to make any changes or let me know and I will. https://phab.enlightenment.org/w/windows/ -- William L. Thomson Jr. From Amul.Shah at fisglobal.com Wed Nov 22 14:40:15 2017 From: Amul.Shah at fisglobal.com (Shah, Amul) Date: Wed, 22 Nov 2017 13:40:15 +0000 Subject: [RFC PATCH] enable configurable SECMEM_BUFFER_SIZE In-Reply-To: <87shd6hf8x.fsf@wheatstone.g10code.de> References: <87shd6hf8x.fsf@wheatstone.g10code.de> Message-ID: [amul] Hi, please excuse any Outlook reformatting. From: Gnupg-devel [mailto:gnupg-devel-bounces at gnupg.org] On Behalf Of Werner Koch Sent: Wednesday, November 22, 2017 9:47 AM >On Tue, 21 Nov 2017 19:12, matthew.summers at syapse.com said: > >> id. This is a severe issue for us that seems pretty easy to remedy >> with a patch like this. > >Can you please explain the problem you try to solve. [amul] Similar to Matt, we're trying to use GnuPG to decrypt secret keys. If I understood Matt's problem, they use 4k keys which exhaust the mlock()ed space very fast. With fis-gtm, we spawn so many processes that exhaust mlock()ed space frequently enough for this to be a problem for us. >Most crypto operations which temporary require allocation of extra chunks of >data (big integer computation) the secure memory area is enlarged on the fly. > >The gpg-agent stores secret keys in a cache which is allocated in standard >memory. This can be done because the keys are stored encrypted in this cache >(using a per process ephemeral key). [amul] "secure" memory allocations only use the first mlock()ed memory area. Is this what you mean by "standard memory"? [amul] When you say that the agent can cache a secret key, does that mean subsequent requests for the same key will be serviced from cache? >Any problems creating or using more keys is either due to a memory leak in >gpg-agent or because you have a lot of active connections to the gpg-agent >using private keys. [amul] In our case, we have many active connections to the gpg-agent (via libgpgme and gpg) as processes decrypt the secret key that encrypts the fis-gtm database. >For that latter case there are two solutions: > > 1. Enlarging the secure memory area. This has the problem that you > will never known how much is sufficient. > > 2. Enlarge the secure memory area on the fly as we do it with some of > the Libgcrypt internal mallocs (actually all xmalloc style > allocations). That would require an update to Libgcrypt and a > runtime option to gpg-agent to enable this. [amul] I agree with your assessment of option #1. I think, however, that there is a third option. In its current form, the gpg-agent accepts every request and spawns a thread to handle it. There is no limit on the rate at which it accepts connections. Other than crudely limiting the thread count, I don't know of a good way to slew the agent. Do you have any suggestions? Additionally, I have not seen any timeouts in gpg/libassuan when communicating with the gpg-agent. [amul] If I were to prepare a patch for option #2, assuming it passes a review and conforms to the coding standards, would it be acceptable? [amul] Best Regards, Amul The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From mcgrof at kernel.org Wed Nov 22 19:04:13 2017 From: mcgrof at kernel.org (Luis R. Rodriguez) Date: Wed, 22 Nov 2017 19:04:13 +0100 Subject: RFC: retry keyservers witout SRV In-Reply-To: <498b1760-13d4-f9cd-0868-4b34bcd40b6e@sumptuouscapital.com> References: <20171121012714.GC729@wotan.suse.de> <498b1760-13d4-f9cd-0868-4b34bcd40b6e@sumptuouscapital.com> Message-ID: <20171122180413.GD729@wotan.suse.de> On Tue, Nov 21, 2017 at 02:48:30PM +0100, Kristian Fiskerstrand wrote: > On 11/21/2017 02:27 AM, Luis R. Rodriguez wrote: > > I have a R6300v2 which after a firmware upgrade it seems it now replies to SRV > > queries for _pgpkey-https and others as a "format error". I've captured tcpdumps > > for it and are on file. > > My $0.02 would be that a format error for SRV request is that should be > fixed in the DNS resolver (or use another resolver) and not introduce > complexity to work around, I'd agree if this was not widespread. > in particular as long as it isn't a widespread issue. I've taken a random silly twitter poll [0] and so far its two failures, two successes for a 50% failure rate, feel free to poll up if you've succumbed to twitter. And that doesn't count my own issue, putting this failure rate up might higher. I'm certain these metrics must be off otherwise folks on this list would have digged into the issue and found it earlier as well. Unless of course folks have been lazy :) Since it so far seems it may be an issue affecting much more folks than expected, I think its fair to consider for us to try to both: 1) get to the bottom of what is causing this issue on routers and; 2) consider a work around for DNS servers when they don't work with SRV HKP As for 1) I'm currently suspect of a dnsmasq bug, however since the software was proprietary I can't do any more work on it. > Are you aware of any bug reports for this with netgear? Netgear only offers complimentary support 90 days after purchase, you can also pay for extra support contracts, one is at at $149.00, no thanks! After that they let you just use community forums. I'll note that even if this issue was fixed this router interface currently does not even let you pick an option to use alternative DNS servers, nor for a way to confirm this. Because of this I suspect more similarly affected routers may suffer similar fate or making it hard to work around for an entire network. I've reflashed my first R6300v2 with OpenWRT but that worked miserbly -- but I did confirm that it *does not* have the SRV HKP issue. I then then tried to move on to the R6300v2 DD-WRT firmware, this worked *much better* (has the stupid proprietary driver which enables 5 GHz and 802.11ac, and has a functional web interface), but more importantly I was also able to confirm it does not have the same DNS SRV HKP issue and *does* lets users select specific DNS servers as verified through tcpdump on the router itself (using defaults, ie my ISP, and also using shiny new 9.9.9.9, or 8.8.8.8). We can't expect users to *know* how to do all the above, and if its widespread, I think we do need to address an alternative route than using HKP SRV first. The documentation is not very clear also as to why its imperative we don't do a retry *without* HKP SRV, why should we shy away from that? The best justification I could find for DNS HKP SRV was Kristian Fiskerstrand's paper on using SRV on sks-keyservers.net. It goes into much of the algorithmic aspects about weights, but doesn't seem to have anything which to me reads "though shall not skip SRV HKP". Why should we avoid simply DNS lookups if all SRV HKP attempts fail? Currently we fail with a brutal and non-obvious non-functional GPG for basic operations. I'll keep on digging to root cause 1) by looking to see if there may be an old dnsmasq bug, or "feature" / flag, but at this point I could not let such issue stall my work, since I reflashed I now cannot reproduce the original issue but it would seem there a souls out there that also suffer from it. [0] https://twitter.com/mcgrof/status/932849226895126529 [1] https://sks-keyservers.net/files/sks-keyservers-SRV.pdf Luis From wk at gnupg.org Wed Nov 22 20:46:10 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 22 Nov 2017 20:46:10 +0100 Subject: [RFC PATCH] enable configurable SECMEM_BUFFER_SIZE In-Reply-To: (Matthew Summers's message of "Wed, 22 Nov 2017 09:23:48 -0600") References: <87shd6hf8x.fsf@wheatstone.g10code.de> Message-ID: <87k1yi6qrh.fsf@wheatstone.g10code.de> On Wed, 22 Nov 2017 16:23, matthew.summers at syapse.com said: > We have a lot of active connections to the gpg-agent using a single > private key. I outlined our use case in more detail here [1]. Frankly I followed the discussion in June only briefly. Thanks for pointing me again to this. > We are enlarging the secmem_buffer using the patch attached > previously. We are determining the size using a simple empirical test I would accept this as a quick workaround but we need a better solution. > configurable, per the patch. It is perhaps notable that we needed to > go from ~1mb to 2mb when moving from 2.1.23 to 2.2.0. I just checked the commits between tehse release and I can't see anything which shoudl affect the allocation pattern. This only shows how fragile the fixed memory approach is. On Wed, 22 Nov 2017 14:40, Amul.Shah at fisglobal.com said: > very fast. With fis-gtm, we spawn so many processes that exhaust > mlock()ed space frequently enough for this to be a problem for us. Okay, that is the same pattern. > [amul] "secure" memory allocations only use the first mlock()ed memory area. Is > this what you mean by "standard memory"? I call this all secure memory. The first chunk is mlock()ed but if we need to allocate more chunks to satisfy memory requests from Libgcrypt which do not expect to fail [1], we can't use mlock anymore. There are two other properties of secmem: - A free() wipes out the formerly allocated memory - Some crypto code in Libgcrypt enables slower but less side-channel leaking algorithms if the material is stored in secmem. If possible gpg-agent also does an extra wipememory before a free to protect against not weel behaving external memory allocaters used with Libgcrypt. As dkg already mentioned, the protection against swapping out sensitive data can nowdays better achieved by using encrypted swap. Along with no way to protect against suspend/resume, I view the mlock more of a historical feature. > [amul] When you say that the agent can cache a secret key, does that mean > subsequent requests for the same key will be serviced from cache? Right. However, each running session needs a copy of the key because we don't have reference counting. This is the problem of too many concurrent session (more exact: decrypt or sign commands). > [amul] In our case, we have many active connections to the gpg-agent (via > libgpgme and gpg) as processes decrypt the secret key that encrypts the Well, adding a limit to GPGME so that it will block in case of too many concurrent gpg operations should be easy to implement. But that does not solve the problem of having several gpgme using processes running concurrently. So let's forget this. > [amul] I agree with your assessment of option #1. I think, however, that there > is a third option. In its current form, the gpg-agent accepts every request and > spawns a thread to handle it. There is no limit on the rate at which it accepts > connections. Other than crudely limiting the thread count, I don't know of a > good way to slew the agent. Do you have any suggestions? Additionally, I have > not seen any timeouts in gpg/libassuan when communicating with the gpg-agent. Limiting the number of concurrent connections to gpg-agent is a useful feature but it requires more thought and is unlikley to make it into 2.2 anytime soon. I opened a ticket at https://dev.gnupg.org/T3529 . > [amul] If I were to prepare a patch for option #2, assuming it passes a review and > conforms to the coding standards, would it be acceptable? We should try this. Let me implement something for testing. https://dev.gnupg.org/T3530 Shalom-Salam, Werner [1] Error checking all gcry_mpi_foo function would make the code unreadable and requires complex and hard to test error cleanup. -- 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 Amul.Shah at fisglobal.com Thu Nov 23 10:43:31 2017 From: Amul.Shah at fisglobal.com (Shah, Amul) Date: Thu, 23 Nov 2017 09:43:31 +0000 Subject: [RFC PATCH] enable configurable SECMEM_BUFFER_SIZE In-Reply-To: <87k1yi6qrh.fsf@wheatstone.g10code.de> References: <87shd6hf8x.fsf@wheatstone.g10code.de> <87k1yi6qrh.fsf@wheatstone.g10code.de> Message-ID: -----Original Message----- From: Werner Koch [mailto:wk at gnupg.org] Sent: Wednesday, November 22, 2017 8:46 PM >On Wed, 22 Nov 2017 16:23, matthew.summers at syapse.com said: > >> We have a lot of active connections to the gpg-agent using a single >> private key. I outlined our use case in more detail here [1]. > >Frankly I followed the discussion in June only briefly. Thanks for pointing >me again to this. > >> We are enlarging the secmem_buffer using the patch attached >> previously. We are determining the size using a simple empirical test > >I would accept this as a quick workaround but we need a better solution. > >> configurable, per the patch. It is perhaps notable that we needed to >> go from ~1mb to 2mb when moving from 2.1.23 to 2.2.0. > >I just checked the commits between tehse release and I can't see anything >which shoudl affect the allocation pattern. This only shows how fragile the >fixed memory approach is. >On Wed, 22 Nov 2017 14:40, Amul.Shah at fisglobal.com said: >As dkg already mentioned, the protection against swapping out sensitive data >can nowdays better achieved by using encrypted swap. Along with no way to >protect against suspend/resume, I view the mlock more of a historical feature. [amul:2] I see two issues with how libgcrypt treats xmalloc style allocations and secure malloc style allocations. [amul:2] Secure malloc style allocations are currently limited to the mainpool, but xmalloc allocations can use the overflow pool(s). This means that every xmalloc allocation consumes the limited main pool. Once the mainpool is exhausted, xmalloc allocations continue, but secure mallocs stop. [amul:2] An ugly solution would move lines 610-615 below line 666. This would have the negative effect of allocating two memory pool sized chunks which could cause problems on memory strapped systems. 576 _gcry_secmem_malloc_internal (size_t size, int xhint) ... 610 mb = mb_get_new (pool, (memblock_t *) pool->mem, size); 611 if (mb) 612 { 613 stats_update (pool, mb->size, 0); 614 return &mb->aligned.c; 615 } 616 617 /* If we are called from xmalloc style function resort to the 618 * overflow pools to return memory. We don't do this in FIPS mode, 619 * though. */ 620 if (xhint && !fips_mode ()) ... 666 } 667 668 return NULL; 669 } [amul:2] Currently, when the secure malloc fails, libgcrypt reports an ENOMEM. That is not accurate as ENOMEM would imply that the process cannot allocate more memory. The problem is that there is no secure memory available to service the request. libgcrypt should report a different error. [amul:2] If we implement option 2 below, these points are moot. >> [amul] I agree with your assessment of option #1. I think, however, >> that there is a third option. In its current form, the gpg-agent >> accepts every request and spawns a thread to handle it. There is no >> limit on the rate at which it accepts connections. Other than crudely >> limiting the thread count, I don't know of a good way to slew the >> agent. Do you have any suggestions? Additionally, I have not seen any >> timeouts in gpg/libassuan when communicating with the gpg-agent. > >Limiting the number of concurrent connections to gpg-agent is a useful feature >but it requires more thought and is unlikley to make it into 2.2 anytime soon. >I opened a ticket at https://dev.gnupg.org/T3529 . [amul:2] Thank you for creating the bug. Given the trouble that a buggy agent can cause, I concur! >> [amul] If I were to prepare a patch for option #2, assuming it passes >> a review and conforms to the coding standards, would it be acceptable? > >We should try this. Let me implement something for testing. >https://dev.gnupg.org/T3530 [amul:2] I updated the bug with the test script that I used to expose the problem. [amul:2] While I have you reading my mail, let me thank you and the others involved in producing this useful suite of tools. I appreciate your time and effort. The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From wk at gnupg.org Fri Nov 24 10:59:57 2017 From: wk at gnupg.org (Werner Koch) Date: Fri, 24 Nov 2017 10:59:57 +0100 Subject: [RFC PATCH] enable configurable SECMEM_BUFFER_SIZE In-Reply-To: (Amul Shah's message of "Thu, 23 Nov 2017 09:43:31 +0000") References: <87shd6hf8x.fsf@wheatstone.g10code.de> <87k1yi6qrh.fsf@wheatstone.g10code.de> Message-ID: <87zi7c574y.fsf@wheatstone.g10code.de> On Thu, 23 Nov 2017 10:43, Amul.Shah at fisglobal.com said: > but xmalloc allocations can use the overflow pool(s). This means that every > xmalloc allocation consumes the limited main pool. Once the mainpool is > exhausted, xmalloc allocations continue, but secure mallocs stop. To clarify: that is xmalloc_secure. I meanwhile implemented a Libgcrypt feature to allow expanding the secmem pool. It is also possible to advice Libcgrypt on the size of the newly allocated pools. The latter can be important because all calls to free need to check whether that free is affects the secmem pool - this is done by comparing the tagnges of all secmem pools - many pools obviously take a little bit longer. gpg-agent has a new option --auto-expand-secmem to enable this features. This is currently in the 2.2 branch but will soon be merged into master. > [amul:2] Currently, when the secure malloc fails, libgcrypt reports an > ENOMEM. That is not accurate as ENOMEM would imply that the process > cannot allocate more memory. The problem is that there is no secure > memory available to service the request. libgcrypt should report a > different error. ENOMEM does not mean it is not possible to allocate more memory. It should always been viewed as a temporary error code. Right a different error code would be useful but has the disadvantgae that all ENOMEM handling code needs to be adjusted. With the auto-expand-secmem feature any ENOMEM will anyway be a "real" ENOMEM. > [amul:2] I updated the bug with the test script that I used to expose the problem. Thanks. All as been pushed and a Libgcrypt 1.8.2 release can be done soonish. GnuPG 2.2.4 needs to wait a few weeks. 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 Nov 24 11:12:15 2017 From: wk at gnupg.org (Werner Koch) Date: Fri, 24 Nov 2017 11:12:15 +0100 Subject: RFC: retry keyservers witout SRV In-Reply-To: <20171122180413.GD729@wotan.suse.de> (Luis R. Rodriguez's message of "Wed, 22 Nov 2017 19:04:13 +0100") References: <20171121012714.GC729@wotan.suse.de> <498b1760-13d4-f9cd-0868-4b34bcd40b6e@sumptuouscapital.com> <20171122180413.GD729@wotan.suse.de> Message-ID: <87vai056kg.fsf@wheatstone.g10code.de> On Wed, 22 Nov 2017 19:04, mcgrof at kernel.org said: > "though shall not skip SRV HKP". Why should we avoid simply DNS lookups > if all SRV HKP attempts fail? Currently we fail with a brutal and non-obvious > non-functional GPG for basic operations. Because that is not the Right Thing to do. However, I can imagine an option --debug-no-srv-lookups. You could use this as a workaround and we may use it to debug problems with SRV records. The "debug" prefix would also clearly mark this as a non-standard option. > I'll keep on digging to root cause 1) by looking to see if there may be an > old dnsmasq bug, or "feature" / flag, but at this point I could not let > such issue stall my work, since I reflashed I now cannot reproduce the original > issue but it would seem there a souls out there that also suffer from it. Well, then updating the hardware would be better for everyone - most people would do that against ROCA 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 Fri Nov 24 12:01:05 2017 From: wk at gnupg.org (Werner Koch) Date: Fri, 24 Nov 2017 12:01:05 +0100 Subject: Release gpgme-1.10.0? In-Reply-To: (William L. Thomson, Jr.'s message of "Wed, 22 Nov 2017 10:27:20 -0500") References: <3432994d-7b98-1b13-a034-0b1f979b9f25@incenp.org> <87k1yihem9.fsf@wheatstone.g10code.de> Message-ID: <87d14854b2.fsf@wheatstone.g10code.de> On Wed, 22 Nov 2017 16:27, wlt-ml at o-sinc.com said: > The EFL one likely can run on Windows as well. I have no information to Sure, as do the GTK and Qt Pinentries. However with the plain GnuPG installer for Windows I do not want to include large sets of libraries just for one simple GUI program. The policy here is to build everything From scratch and distribute all source code. Building the GTK or EFL libraries will also take much longer than the whole rest of the installer. This is why I was looking into FLTK - it can be linked statically with pinentry and there should be a way to strip the required code down. We could also improve the simple Windows Pinentry we currently include in the installer. But doing GUI work on Windows without any framework is like working on plain X with maybe the Athena widget set. Has anyone experience with the IUP toolkit (iup.sourceforge.net)? It somehow looks like a GTK+ clone but using native widgets. 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 Amul.Shah at fisglobal.com Fri Nov 24 11:30:48 2017 From: Amul.Shah at fisglobal.com (Shah, Amul) Date: Fri, 24 Nov 2017 10:30:48 +0000 Subject: [RFC PATCH] enable configurable SECMEM_BUFFER_SIZE In-Reply-To: <87zi7c574y.fsf@wheatstone.g10code.de> References: <87shd6hf8x.fsf@wheatstone.g10code.de> <87k1yi6qrh.fsf@wheatstone.g10code.de> <87zi7c574y.fsf@wheatstone.g10code.de> Message-ID: From: Werner Koch [mailto:wk at gnupg.org] Sent: Friday, November 24, 2017 11:00 AM > >On Thu, 23 Nov 2017 10:43, Amul.Shah at fisglobal.com said: > >> but xmalloc allocations can use the overflow pool(s). This means that >> every xmalloc allocation consumes the limited main pool. Once the >> mainpool is exhausted, xmalloc allocations continue, but secure mallocs stop. > >To clarify: that is xmalloc_secure. I meanwhile implemented a Libgcrypt >feature to allow expanding the secmem pool. It is also possible to advice >Libcgrypt on the size of the newly allocated pools. The latter can be >important because all calls to free need to check whether that free is affects >the secmem pool - this is done by comparing the tagnges of all secmem pools - >many pools obviously take a little bit longer. > >gpg-agent has a new option --auto-expand-secmem to enable this features. >This is currently in the 2.2 branch but will soon be merged into master. [amul:3] Awesome! And thanks for the explanation. >ENOMEM does not mean it is not possible to allocate more memory. It should >always been viewed as a temporary error code. Right a different error code >would be useful but has the disadvantgae that all ENOMEM handling code needs >to be adjusted. With the auto-expand-secmem feature any ENOMEM will anyway be >a "real" ENOMEM. [amul:3] I never considered ENOMEM as a transient error. Something new to think about. >> [amul:2] I updated the bug with the test script that I used to expose the problem. > >Thanks. All as been pushed and a Libgcrypt 1.8.2 release can be done soonish. >GnuPG 2.2.4 needs to wait a few weeks. [amul:3] DKG, What does one need to do to back-port these changes to stable? File a bug, attach patches that apply cleanly to the target sources and request the maintainer to add them? The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From wk at gnupg.org Mon Nov 27 20:30:09 2017 From: wk at gnupg.org (Werner Koch) Date: Mon, 27 Nov 2017 20:30:09 +0100 Subject: Bug#882736: [pkg-gnupg-maint] Bug#882736: gpg-agent: does not always use same socketdir In-Reply-To: <1511803448.31788.38.camel@43-1.org> (Ansgar Burchardt's message of "Mon, 27 Nov 2017 18:24:08 +0100") References: <151169403120.11461.13977899989139122744.reportbug@deep-thought.43-1.org> <87efojahol.fsf@fifthhorseman.net> <151169403120.11461.13977899989139122744.reportbug@deep-thought.43-1.org> <1511803448.31788.38.camel@43-1.org> Message-ID: <87o9nnr03i.fsf@wheatstone.g10code.de> On Mon, 27 Nov 2017 18:24, ansgar at debian.org said: >> this is a deliberate choice by upstream. > > Yes, I saw it in the source :-/ There is a clear reason for this. In the past we had lot of troubles with too freely configurable socket names and file systems which don't support local sockets. Recall that GnuPG 2.x goes back to 2003 and it has always used the local socket and fully relied on it for gpgsm - a maybe nice application but nevertheless a tool which has been in wide use since about 2005 by a few large sites. So with 2.2 removed the trouble by using a fixed socket dir utilizing the /var/run hierarchy which is on all known Unices a local file system supporting sockets. The only overhead a _Unix_ sysadm has to do is putting this into rc.local: [ ! -d /run/user ] && mkdir /run/user awk -F: = 1000 && $3 < 65000 {print $3}' \ | ( while read uid rest; do if [ ! -d "/run/user/$uid" ]; then mkdir /run/user/$uid chown $uid /run/user/$uid chmod 700 /run/user/$uid fi done ) Unfortunately Debian GNU/Linux is no longer a standard Unix system and thus long standing things don't work anymore. nohup. On such semi-Unix systems you need to work around their shortcomings; in your case cron. Adding yet another thing and in particular XDG, which more targets the desktop than the server, would make things more complicate. However, there is another proposal on the gnupg-devel list to try another socketdir first. The suggestion is to try the socket names in this order: 1. /var/run/gnupg/user/UID/S.gpg-agent 2. /var/run/user/UID/gnupg/S.gpg-agent 3. HOME/.gnupg/S.gpg-agent The first one would be new. It has the advantage that systemd does not know about it and thus can't remove it (and should not because it belongs to gnupg). The disadvantage is that systemd does not remove this directory and gpg-agent can't use the directory removal as trigger to terminate itself. However, it is at the discretion of the sysadm to create such directories in the first place. The other option would be a global config file to list additional socket directories to try. That would a require a bit more code but that shall not be the problem. > Yes, but that depends on the internal gpg logic to decide where to put > sockets (which is unstable). If one could tell gpg which directory to That is not unstable due to gpg but because something removes or creates directories which are supposed to exist right after system startup or at least before calling gpg the first time. > It also requires to call gpgconf to configure the supervisor (and the > location might change at any time in the future so gpgconf needs to be The directories are fixed and won't change: Iff /var/run/user/UID exists it is used, if not ~/.gnupg is used (with all its problems). 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 Tue Nov 28 01:50:57 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 27 Nov 2017 19:50:57 -0500 Subject: Release gpgme-1.10.0? In-Reply-To: <87fu96hego.fsf@wheatstone.g10code.de> References: <87fu96hego.fsf@wheatstone.g10code.de> Message-ID: <87vahv8bv2.fsf@fifthhorseman.net> On Wed 2017-11-22 10:04:07 +0100, Werner Koch wrote: > On Tue, 21 Nov 2017 07:54, alon.barlev at gmail.com said: > >> Any chance for gpgme-1.10.0 release? > > Right, it is long overdue. > > There are some open bugs and a proposal for a compatible Python change > for which I have seen no other opinions [1]. The copy of this message that i received was missing the reference for [1]. Can you dig it up again? thanks, --dkg, who would be happy to see a new gpgme release -------------- 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 Nov 28 02:02:33 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 27 Nov 2017 20:02:33 -0500 Subject: [RFC PATCH] enable configurable SECMEM_BUFFER_SIZE In-Reply-To: References: <87shd6hf8x.fsf@wheatstone.g10code.de> <87k1yi6qrh.fsf@wheatstone.g10code.de> <87zi7c574y.fsf@wheatstone.g10code.de> Message-ID: <87shcz8bbq.fsf@fifthhorseman.net> Hi Amul -- thanks for your persistence on this, i'm glad to see new ideas and approaches are being tried out. You're not the only person who has run into concurrency problems with gpg-agent. On Fri 2017-11-24 10:30:48 +0000, Shah, Amul wrote: > From: Werner Koch [mailto:wk at gnupg.org] Sent: Friday, November 24, 2017 11:00 AM >> Thanks. All as been pushed and a Libgcrypt 1.8.2 release can be done >> soonish. GnuPG 2.2.4 needs to wait a few weeks. > > [amul:3] DKG, What does one need to do to back-port these changes to stable? > File a bug, attach patches that apply cleanly to the target sources and request > the maintainer to add them? Are you asking about debian stable, or the GnuPG stable branch? Since you're asking me specifically, i assume you're asking about debian stable (aka "stretch"). please ignore the rest of this if that isn't what you meant ;) At first glance, it looks like it would require patches to libgcrypt itself, in addition to patches to GnuPG. That would be something to coordinate for a point release perhaps, but it could be complicated; there are several other bugfix improvements that it would also be good to include into debian stable. To make this stand out clearly, you probably want to start by opening a bug report (in the debian BTS) against the gcrypt package, tagged appropriately for the affected versions, explaining the problem, pointing to the upstream reports and commits, and also mark it so that it "affects" the gnupg2 source package. make sense? --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 Nov 28 07:52:53 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 28 Nov 2017 07:52:53 +0100 Subject: Release gpgme-1.10.0? In-Reply-To: <87vahv8bv2.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 27 Nov 2017 19:50:57 -0500") References: <87fu96hego.fsf@wheatstone.g10code.de> <87vahv8bv2.fsf@fifthhorseman.net> Message-ID: <874lperj22.fsf@wheatstone.g10code.de> On Tue, 28 Nov 2017 01:50, dkg at fifthhorseman.net said: > The copy of this message that i received was missing the reference for > [1]. Can you dig it up again? 22-Aug. Tobias Mueller [PATCH] python: Default whence argument for Data() to SEEK_SET. 1503416905.23294.52.camel at cryptobitch.de Sorry, for not having a link. Which reminds me that our mailman has a crippled List-Archive header. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Tue Nov 28 07:59:32 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 28 Nov 2017 07:59:32 +0100 Subject: [RFC PATCH] enable configurable SECMEM_BUFFER_SIZE In-Reply-To: <87shcz8bbq.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 27 Nov 2017 20:02:33 -0500") References: <87shd6hf8x.fsf@wheatstone.g10code.de> <87k1yi6qrh.fsf@wheatstone.g10code.de> <87zi7c574y.fsf@wheatstone.g10code.de> <87shcz8bbq.fsf@fifthhorseman.net> Message-ID: <87zi76q46j.fsf@wheatstone.g10code.de> On Tue, 28 Nov 2017 02:02, dkg at fifthhorseman.net said: > At first glance, it looks like it would require patches to libgcrypt > itself, in addition to patches to GnuPG. FWIW, changes in the repo since 1.8.1 are: 59df8d6 * sexp: Avoid a fatal error in case of ENOMEM in called functions. f4582f8 * api: Add auto expand secmem feature 334e1a1 * tests: Add HAVE_MMAP check for MinGW. da127f7 * Fix secmem test for machine with larger page. The first one actually fixes a side-effect of the "out of secure memory" state. I can do a Libcgrypt 1.8.2 at any time. Just let me know. Backporting the required change for GnuPG to any 2.1 version will be trivial. 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 Amul.Shah at fisglobal.com Tue Nov 28 12:14:21 2017 From: Amul.Shah at fisglobal.com (Shah, Amul) Date: Tue, 28 Nov 2017 11:14:21 +0000 Subject: [RFC PATCH] enable configurable SECMEM_BUFFER_SIZE In-Reply-To: <87shcz8bbq.fsf@fifthhorseman.net> References: <87shd6hf8x.fsf@wheatstone.g10code.de> <87k1yi6qrh.fsf@wheatstone.g10code.de> <87zi7c574y.fsf@wheatstone.g10code.de> <87shcz8bbq.fsf@fifthhorseman.net> Message-ID: >thanks for your persistence on this, i'm glad to see new ideas and approaches >are being tried out. You're not the only person who has run into concurrency >problems with gpg-agent. [amul:4] Thanks for the kind words. >On Fri 2017-11-24 10:30:48 +0000, Shah, Amul wrote: >> [amul:3] DKG, What does one need to do to back-port these changes to stable? >> File a bug, attach patches that apply cleanly to the target sources >> and request the maintainer to add them? > >Are you asking about debian stable, or the GnuPG stable branch? Since you're >asking me specifically, i assume you're asking about debian stable (aka >"stretch"). please ignore the rest of this if that isn't what you meant ;) [amul:4] Ack! I did mean Debian stable. >At first glance, it looks like it would require patches to libgcrypt itself, >in addition to patches to GnuPG. > >That would be something to coordinate for a point release perhaps, but it >could be complicated; there are several other bugfix improvements that it >would also be good to include into debian stable. [amul:4] If I understood Werner's last mail, Debian stable should update to libgcrypt 1.8.1 and then back port his changes to GnuPG 2.1. >To make this stand out clearly, you probably want to start by opening a bug >report (in the debian BTS) against the gcrypt package, tagged appropriately >for the affected versions, explaining the problem, pointing to the upstream >reports and commits, and also mark it so that it "affects" the gnupg2 source >package. [amul:4] I created #882985 for this issue. I ran reportbug from my Debian "unstable" server, and since this is my first time through the utility, I'm sure that I made more than one mistake. [amul:4] I'm not sure if I set the "affects" gnupg2 correctly. Amul The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From mcgrof at kernel.org Tue Nov 28 22:41:21 2017 From: mcgrof at kernel.org (Luis R. Rodriguez) Date: Tue, 28 Nov 2017 22:41:21 +0100 Subject: RFC: retry keyservers witout SRV In-Reply-To: <87vai056kg.fsf@wheatstone.g10code.de> References: <20171121012714.GC729@wotan.suse.de> <498b1760-13d4-f9cd-0868-4b34bcd40b6e@sumptuouscapital.com> <20171122180413.GD729@wotan.suse.de> <87vai056kg.fsf@wheatstone.g10code.de> Message-ID: <20171128214121.GQ729@wotan.suse.de> On Fri, Nov 24, 2017 at 11:12:15AM +0100, Werner Koch wrote: > On Wed, 22 Nov 2017 19:04, mcgrof at kernel.org said: > > > "though shall not skip SRV HKP". Why should we avoid simply DNS lookups > > if all SRV HKP attempts fail? Currently we fail with a brutal and non-obvious > > non-functional GPG for basic operations. > > Because that is not the Right Thing to do. Thanks, what sort of documentation exists where this is stated other than in actual code? *Why?* > However, I can imagine an > option --debug-no-srv-lookups. You could use this as a workaround and > we may use it to debug problems with SRV records. The "debug" prefix > would also clearly mark this as a non-standard option. Given the above this makes perfect sense. > > I'll keep on digging to root cause 1) by looking to see if there may be an > > old dnsmasq bug, or "feature" / flag, but at this point I could not let > > such issue stall my work, since I reflashed I now cannot reproduce the original > > issue but it would seem there a souls out there that also suffer from it. > > Well, then updating the hardware would be better for everyone - most > people would do that against ROCA anyway. Sure, but given my little survey it would seem many more devices are affected, so it does not seem to just be a one-off router, essentially completely disabling PGP without any warning what so ever to the user about the reason for the issue. Luis From wk at gnupg.org Wed Nov 29 09:53:10 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 29 Nov 2017 09:53:10 +0100 Subject: RFC: retry keyservers witout SRV In-Reply-To: <20171128214121.GQ729@wotan.suse.de> (Luis R. Rodriguez's message of "Tue, 28 Nov 2017 22:41:21 +0100") References: <20171121012714.GC729@wotan.suse.de> <498b1760-13d4-f9cd-0868-4b34bcd40b6e@sumptuouscapital.com> <20171122180413.GD729@wotan.suse.de> <87vai056kg.fsf@wheatstone.g10code.de> <20171128214121.GQ729@wotan.suse.de> Message-ID: <877eu9o495.fsf@wheatstone.g10code.de> On Tue, 28 Nov 2017 22:41, mcgrof at kernel.org said: > Thanks, what sort of documentation exists where this is stated other than > in actual code? There is no real documentation for keyservers. Howerver SRV records are in use for ages and that makes them a part of the specification. >> we may use it to debug problems with SRV records. The "debug" prefix >> would also clearly mark this as a non-standard option. > > Given the above this makes perfect sense. I will consider that. > Sure, but given my little survey it would seem many more devices are affected, > so it does not seem to just be a one-off router, essentially completely disabling > PGP without any warning what so ever to the user about the reason for Given your description won't also not be able to use any XMPP service. In XMPP the use of SRV records is specified in the RFCs and many sites won't work without them. In case XMPP works for you - how does your gateway behave in this case? 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 mcgrof at kernel.org Wed Nov 29 20:20:01 2017 From: mcgrof at kernel.org (Luis R. Rodriguez) Date: Wed, 29 Nov 2017 20:20:01 +0100 Subject: RFC: retry keyservers witout SRV In-Reply-To: <877eu9o495.fsf@wheatstone.g10code.de> References: <20171121012714.GC729@wotan.suse.de> <498b1760-13d4-f9cd-0868-4b34bcd40b6e@sumptuouscapital.com> <20171122180413.GD729@wotan.suse.de> <87vai056kg.fsf@wheatstone.g10code.de> <20171128214121.GQ729@wotan.suse.de> <877eu9o495.fsf@wheatstone.g10code.de> Message-ID: <20171129192001.GU729@wotan.suse.de> On Wed, Nov 29, 2017 at 09:53:10AM +0100, Werner Koch wrote: > On Tue, 28 Nov 2017 22:41, mcgrof at kernel.org said: > > Thanks, what sort of documentation exists where this is stated other than > > in actual code? > > There is no real documentation for keyservers. Howerver SRV records are > in use for ages and that makes them a part of the specification. Not having any formal docs for keyservers seems pretty unfortunate to say the least, but its understandable given how it came about with Marc Horowitz's first web based OpenPGP HTTP Keyserver. In particular having to fulfill a DNS query for keyservers using DNS HKP SRV seems like a pretty unique requirement I certainly was not expecting, has it been a requirement since day 1 for keyservers? Since there is no formal documentation about keyservers I can say I at least tried to look for some and I did find at least one paper by Kristian Fiskerstrand on benefits of using SRV on sks-keyservers.net [0]. This paper seems to indicate to me it was *not* used since day 1 for all keyservers. In fact it says GnuPG has had support for it since GnuPG v1.4.10 and v2.0.13, and it makes it clear that PGP *did not* have support for it at the time the paper was published on May 28, 2012. The paper goes on about benefits and the algorithm used but its in no way clear at all why using DNS HKP SRV is a hard requirement today. So what is the hard technical requirement for it? If GnuPG started using DNS HKP SRV since GnuPG v1.4.10 and v2.0.13 why is it *now* a hard requirement? Even if there is no real documentation I think it might be fair to ask this, and perhaps for us to add such documentation now to GnuPG (yes, I can volunteer). > >> we may use it to debug problems with SRV records. The "debug" prefix > >> would also clearly mark this as a non-standard option. > > > > Given the above this makes perfect sense. > > I will consider that. > > > Sure, but given my little survey it would seem many more devices are affected, > > so it does not seem to just be a one-off router, essentially completely disabling > > PGP without any warning what so ever to the user about the reason for > > Given your description won't also not be able to use any XMPP service. > In XMPP the use of SRV records is specified in the RFCs and many sites > won't work without them. In case XMPP works for you - how does your > gateway behave in this case? I've long gone replaced the firmware on the router now so this is no longer an issue for me. But I don't recall issues with XMMP. In fact the original issues were so odd that I *had* to look underneath the hood. If *no* keyserver records are found *at all* and the operation requested does need one, should the error at least be clear about the issue being an SRV record request? As noted, it does *not* seem to be off-one issue, I suspect others may run into this again, and unless they really try to look underneath the hood, PGP would essentially appear to just not work and it would be very unclear why. Specially given SRV records *are* required for DNS lookup for an undocumented service, expecting it to be obvious why PGP may not work for users seems counter intuitive. [0] https://sks-keyservers.net/files/sks-keyservers-SRV.pdf Luis From alon.barlev at gmail.com Wed Nov 29 20:40:20 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Wed, 29 Nov 2017 21:40:20 +0200 Subject: [PATCH GPGME] tests: gpgsm: fix gpg-agent detection Message-ID: <20171129194020.2255-1-alon.barlev@gmail.com> * tests/gpgsm/Makefile.am: set the GPG_AGENT var. Signed-off-by: Alon Bar-Lev --- tests/gpgsm/Makefile.am | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/gpgsm/Makefile.am b/tests/gpgsm/Makefile.am index 3774c5ff..4ab22833 100644 --- a/tests/gpgsm/Makefile.am +++ b/tests/gpgsm/Makefile.am @@ -20,6 +20,7 @@ ## Process this file with automake to produce Makefile.in GPGSM = gpgsm +GPG_AGENT = gpg-agent TESTS_ENVIRONMENT = GNUPGHOME=$(abs_builddir) LC_ALL=C GPG_AGENT_INFO= \ top_srcdir=$(top_srcdir) -- 2.13.6 From wk at gnupg.org Thu Nov 30 09:53:04 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 30 Nov 2017 09:53:04 +0100 Subject: [PATCH GPGME] tests: gpgsm: fix gpg-agent detection In-Reply-To: <20171129194020.2255-1-alon.barlev@gmail.com> (Alon Bar-Lev's message of "Wed, 29 Nov 2017 21:40:20 +0200") References: <20171129194020.2255-1-alon.barlev@gmail.com> Message-ID: <87y3mojggf.fsf@wheatstone.g10code.de> On Wed, 29 Nov 2017 20:40, alon.barlev at gmail.com said: > * tests/gpgsm/Makefile.am: set the GPG_AGENT var. Thanks. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From astieger at suse.com Thu Nov 30 13:26:17 2017 From: astieger at suse.com (Andreas Stieger) Date: Thu, 30 Nov 2017 13:26:17 +0100 Subject: error return code when no agent available Message-ID: Hello, In GnuPG 2.2.x we see the following when compared to 2.0.x: * no gpg-agent binary available * no gnupg home directory created and no keyrings * gpg --import a random public key * The public key import succeeds in both cases, but 2.2.x returns with an exit code of 2. CLI is: /usr/bin/gpg2 --import --homedir /var/tmp/RAMDOM --no-default-keyring --quiet \ --no-tty --no-greeting --no-permission-warning --status-fd 1 /var/tmp/KEY The return code of 2 seems to depends specifically on the availability of an agent binary. This is a minimal installer system where no agent is available or required due to the lack of private key operations. Previously this was not an issue. Do you know what and why this changed? If this is intentional, is there a work-around in terms of settings or the CLI? Our bug: https://bugzilla.opensuse.org/show_bug.cgi?id=1067992 Thanks, Andreas -- Andreas Stieger Project Manager Security SUSE Linux GmbH, GF: Felix Imend?rffer, Jane Smithard, Graham Norton, HRB 21284 (AG N?rnberg) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Nov 30 15:57:42 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 30 Nov 2017 15:57:42 +0100 Subject: error return code when no agent available In-Reply-To: (Andreas Stieger's message of "Thu, 30 Nov 2017 13:26:17 +0100") References: Message-ID: <87indrak61.fsf@wheatstone.g10code.de> On Thu, 30 Nov 2017 13:26, astieger at suse.com said: > The return code of 2 seems to depends specifically on the availability > of an agent binary. This is a minimal installer system where no agent is The agent is required because gpg needs to check whether it has a matching secret key for the imported public key. > Previously this was not an issue. Do you know what and why this changed? > If this is intentional, is there a work-around in terms of settings or > the CLI? The gpg-agent is a part of GnuPG and has been since 2003. With 2.0 you could get away without it because gpg did not yet utilize the agent for private key store (in contrast to gpgsm). The return codes from gpg have no specific meaning. For scripting you need to look at the status lines. GPGME entirely ignores the return codes. 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 astieger at suse.com Thu Nov 30 16:14:02 2017 From: astieger at suse.com (Andreas Stieger) Date: Thu, 30 Nov 2017 16:14:02 +0100 Subject: error return code when no agent available In-Reply-To: <87indrak61.fsf@wheatstone.g10code.de> References: <87indrak61.fsf@wheatstone.g10code.de> Message-ID: <52138f0f-3194-dd89-682b-386518d22e58@suse.com> On 11/30/2017 03:57 PM, Werner Koch wrote: > On Thu, 30 Nov 2017 13:26, astieger at suse.com said: > >> The return code of 2 seems to depends specifically on the availability >> of an agent binary. This is a minimal installer system where no agent is > The agent is required because gpg needs to check whether it has a > matching secret key for the imported public key. Ah okay that's a reason. > >> Previously this was not an issue. Do you know what and why this changed? >> If this is intentional, is there a work-around in terms of settings or >> the CLI? > The gpg-agent is a part of GnuPG and has been since 2003. With 2.0 you > could get away without it because gpg did not yet utilize the agent for > private key store (in contrast to gpgsm). Under the assumption that the operation executed is public key only and does not involve private keys, --no-autostart may fix this specific case. > The return codes from gpg have no specific meaning. For scripting you > need to look at the status lines. GPGME entirely ignores the return > codes. Thanks! Andreas -- Andreas Stieger Project Manager Security SUSE Linux GmbH, GF: Felix Imend?rffer, Jane Smithard, Graham Norton, HRB 21284 (AG N?rnberg) From dkg at fifthhorseman.net Thu Nov 30 16:17:36 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 30 Nov 2017 10:17:36 -0500 Subject: error return code when no agent available In-Reply-To: <87indrak61.fsf@wheatstone.g10code.de> References: <87indrak61.fsf@wheatstone.g10code.de> Message-ID: <877eu74wz3.fsf@fifthhorseman.net> On Thu 2017-11-30 15:57:42 +0100, Werner Koch wrote: > The return codes from gpg have no specific meaning. For scripting you > need to look at the status lines. GPGME entirely ignores the return > codes. Perhaps we could invest the return codes with some specific meaning? There are many scenarios in UNIX where return codes are expected to be 0 when an standard operation succeeds. It's unusual to not folow that convention. --dkg From dkg at fifthhorseman.net Thu Nov 30 16:25:39 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 30 Nov 2017 10:25:39 -0500 Subject: [PATCH] doc: clarify that --encrypt refers to public key encryption In-Reply-To: <87o9nuhf0q.fsf@wheatstone.g10code.de> References: <20171117022619.32121-1-dkg@fifthhorseman.net> <87mv3lwdsi.fsf@wheatstone.g10code.de> <87vai3obg9.fsf@fifthhorseman.net> <87o9nuhf0q.fsf@wheatstone.g10code.de> Message-ID: <874lpb4wlo.fsf@fifthhorseman.net> On Wed 2017-11-22 09:52:05 +0100, Werner Koch wrote: > On Tue, 21 Nov 2017 17:15, dkg at fifthhorseman.net said: > >> OK, pushed a modified/clarified form to master. Should this also be >> backported to the stable branches? > > Yes. pushed to 2.2, thanks for the followup. > On Monday's telco we agreed on that clear bug fixes (and I would also > say doc fixes) should be done to the 2.2 branch and then merged by the > hacker on duty into master within the next few days. > > All changes for which it is not clear whether they need to go into 2.2 > are to be done in master and will be cherry-picked into 2.2 on a case to > case base. This sounds like sensible policy. Thanks for spelling it out here. is there an explicit role or rotation for "hacker on duty" that i should know about? Pointers to existing documentation are welcome. 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 wk at gnupg.org Thu Nov 30 19:24:11 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 30 Nov 2017 19:24:11 +0100 Subject: error return code when no agent available In-Reply-To: <877eu74wz3.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 30 Nov 2017 10:17:36 -0500") References: <87indrak61.fsf@wheatstone.g10code.de> <877eu74wz3.fsf@fifthhorseman.net> Message-ID: <878tenaalw.fsf@wheatstone.g10code.de> On Thu, 30 Nov 2017 16:17, dkg at fifthhorseman.net said: > There are many scenarios in UNIX where return codes are expected to be 0 If there is no error the return code will be zero. However as soon as there is any error the return code will be 2. Some of these errors can be ignored but that depends on the the user. No Agent is an error. 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 Nov 30 19:25:40 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 30 Nov 2017 19:25:40 +0100 Subject: [PATCH] doc: clarify that --encrypt refers to public key encryption In-Reply-To: <874lpb4wlo.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 30 Nov 2017 10:25:39 -0500") References: <20171117022619.32121-1-dkg@fifthhorseman.net> <87mv3lwdsi.fsf@wheatstone.g10code.de> <87vai3obg9.fsf@fifthhorseman.net> <87o9nuhf0q.fsf@wheatstone.g10code.de> <874lpb4wlo.fsf@fifthhorseman.net> Message-ID: <874lpbaaje.fsf@wheatstone.g10code.de> On Thu, 30 Nov 2017 16:25, dkg at fifthhorseman.net said: > is there an explicit role or rotation for "hacker on duty" that i should > know about? Pointers to existing documentation are welcome. No. If there is a question we quickly coordinate on Jabber. In general I will do the merging. 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: