Thanks for reporting. Fixed in master for 2.1.19.

And a second message

(sorry, I accidentally removed the attached while while editing the mime type)

Can we test whether /run is mounted on a tmpfs ?
should we assume that /run is always on a tmpfs but /var/run is a classical Unix
w/o a tmpfs? Or is it better to have a configure option.

I can imagine to agree to auto-create the directory on a tmpfs.

Yes, notmuch decided that they needed to workaround the situation anyway,
because they're in an environment that doesn't create the standard per-user
rundir. That doesn't seem like a great argument that gpg should also fail in
environments where the standard per-user rundir is available. I can demonstrate
a number of environments where gpg or its daemons will fail, but i don't think
any of them justify forcing gpg or its daemons to *also* fail when those
environments aren't present.

In answer to your nitpick, here is evidence that gpg's daemons cannot create
their sockets when the GNUPGHOME is too long:

1 dkg@alice:~$ mkdir -m 0700
/home/dkg/tmp/very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-long
0 dkg@alice:~$
GNUPGHOME=/home/dkg/tmp/very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-long
gpgconf --launch dirmngr
gpgconf: error running '/usr/bin/gpg-connect-agent': exit status 1
gpgconf: error running '/usr/bin/gpg-connect-agent --dirmngr NOP': General error
1 dkg@alice:~$

FYI: It is fixed in 2.1.
Backporting the change to 2.0 will be a bit large, and I hesitate to do that.

Notmuch deemed --create-socketdir to be insufficient for their test suite:

https://notmuchmail.org/pipermail/notmuch/2017/024148.html

Now they create GNUPGHOMEs in /tmp. That is exactly what our test suite does.

(We also use --create-socketdir, but we don't rely on it, and indeed, on my
system it fails b/c the per-user directory is not created. Likewise on the
OpenBSD build server, and the macOS one.)

Nitpick: You wrote:

when GNUPGHOME points to a directory whose path is larger than
sockaddr_un.sun_path, daemons like gpg-agent and dirmngr cannot create their
sockets.

I don't think this is correct. I have not seen any evidence that creating the
socket is problematic.

Yes, .cpu generic+simd+crypto that what I thought after first patch from the beginning
but didn't test it first, blame me for it. Now it compiles as expected, please include
it into next release.

D410: 957_03-fix-clang-arm64.patch

How about this patch?

No, it still fails, here is fresh log:
http://pkg.krion.cc/data/110arm64-default/2017-02-26_16h58m38s/logs/errors/libgcrypt-
1.7.6.log

Does the attached patch fix the problem?

D411: 956_02-fix-clang-arm64.patch

Ok, thanks!

ntbtls support is now available in master and we will release a TLS enabled
2.1.19 installer for Windows.

Right now it is somewhat limited and does not work with some sites, notably
those which allow only ECC ciphersuites. An example for such a site is
posteo.de. Note that posteo.net sends a a bogus certifcate with rediretion to
posteo.de.

Most other sites work.

You need to wait for 1.8 - in a few weeks.
I looked at the required changes but decided not to backport that for 1.7.6.

Should be fixed with commit 6d50eeb for 2.1.19.

My idea on how to do a general fix turned out to be too complicated and thus I
fixed just the Polish translation

Are you using tor? if so, is your tor daemon up and running, and actively
connecting to the outside world?

Okay... using a later distribution with a newer wget fixed this:
https://travis-ci.org/azul/gpg-build/builds/203543109

closing. Sorry for the noise.

The same build works locally for me with wget 1.17.1.
travis has 1.13.4

$ wget --version

GNU Wget 1.13.4 built on linux-gnu.

+digest +https +ipv6 +iri +large-file +nls +ntlm +opie +ssl/openssl

Wgetrc:

    /etc/wgetrc (system)

Locale: /usr/share/locale

Compile: gcc -DHAVE_CONFIG_H -DSYSTEM_WGETRC="/etc/wgetrc"

    -DLOCALEDIR="/usr/share/locale" -I. -I../../src -I../lib 

    -I../../lib -D_FORTIFY_SOURCE=2 -Iyes/include -g -O2 

    -fstack-protector --param=ssp-buffer-size=4 -Wformat 

    -Wformat-security -Werror=format-security -DNO_SSLv2 

    -D_FILE_OFFSET_BITS=64 -g -Wall

Link: gcc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat

    -Wformat-security -Werror=format-security -DNO_SSLv2 

    -D_FILE_OFFSET_BITS=64 -g -Wall -Wl,-Bsymbolic-functions 

    -Wl,-z,relro -Lyes/lib -lssl -lcrypto -lz -ldl -lz -lidn -lrt 

    ftp-opie.o openssl.o http-ntlm.o ../lib/libgnu.a

Copyright (C) 2009 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later

http://www.gnu.org/licenses/gpl.html.

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

Originally written by Hrvoje Niksic <hniksic@xemacs.org>.

Please send bug reports and questions to <bug-wget@gnu.org>.

Thanks, i've pushed this back to python-gnupg folks, and they've accepted it:

https://bitbucket.org/vinay.sajip/python-gnupg/commits/d0375e034da3efa6fbda713cb4bde0fbb6d3b158

so i think we can consider this issue resolved, at least from 2.1.14 and onward,
where import-show was introduced.

That is definitely a bug.

I guess that is because the prompt has not been translated but the answer string
is translated.

msgid "NnCcEeOoQq"
msgstr "IiKkEeDdWw"

Thus using 'i' should give you the prompt for name.

A fix for this would be to use a different answer string for --gen-key - the one
we use if from --full-gen-key (i.e. with "(C)omment". This would the also work
for other incomplete translations, which will have the same problem.

dkg thank you. One of the user reporting the issue has confirmed that fixes it:
https://github.com/Homebrew/homebrew-versions/pull/1527#issuecomment-280667350

gpg --version

gpg (GnuPG) 2.0.30 (Gpg4win 2.3.3)
libgcrypt 1.6.6
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: C:/Users/<username>/AppData/Roaming/gnupg
Supported algorithms:
Pubkey: RSA, RSA, RSA, ELG, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,

CAMELLIA128, CAMELLIA192, CAMELLIA256

Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

Yes...seems old! But this is what latest gpg4win packages. :(
It is also the latest stable gpg release...so normal, I guess.

I've installed gpg on various recent Windows 10 builds (~10 machines/builds)
and noticed the behavior on all of them. For example builds 14939, 14986, and some
others.

Thanks for these fixes! I'm not sure i understand why ptr lookups are needed
for keyserver --hosttable. Can we drop those too?

This sounds like issues we were seeing in debian, which i believe have been
fixed in git already.

we're shipping the following two patches in debian against 2.1.18:

https://sources.debian.net/src/gnupg2/2.1.18-6/debian/patches/0028-scd-Backport-two-fixes-from-master.patch/
https://sources.debian.net/src/gnupg2/2.1.18-6/debian/patches/0029-scd-Fix-use-case-of-PC-SC.patch/

We have Homebrew users reporting this problem to us.

https://github.com/Homebrew/homebrew-versions/commit/bece3fdbb732bcf646589c051f2f882e2bbf0875#commitcomment-20846337
https://github.com/Homebrew/homebrew-versions/commit/bece3fdbb732bcf646589c051f2f882e2bbf0875#commitcomment-20910048

"I had to revert to 2.1.17, gnupg was unable to access my yubikey with 2.1.18.
The error was "gpg: selecting openpgp failed: Operation not supported by
device". Not sure if I'm the only one with the problem, if not I'd recommend
reverting the version."

I have fixed some things. In general PTR lookups are onow only used when you
run the 'keyserver --hosttable' command.

I note that even if i drop the "--trust-model tofu+pgp" and subsequently invoke
just "gpg --tofu-default-policy ask --fingerprint" i get the same crash.

however, if i just execute that in a fresh homedir without ever having set
"--trust-model tofu+pgp" i don't get a crash. so there is some sort of state
being set up that is then tickling the assertion later.

Yet another Yubikey think, I'll better a a keyword for this.

Never use system() anywhere!

You need to call cmd with the script. However, there are some security issues
with than too and thus I consider it better use a dedicated executabe for this.

If you can tell us what the script shall do, we may distribute a simple
executable for that purpose.

For a key listing I would suggest this

  gpg --dry-run --import-options import-show --import  FILE

This uses the regular key listing code.

Please tell us which version of GnUPG ayou are using and on what OS.

jenkins is redirected from kerckhoffs to soro using pound features. Please
check out /etc/pound/pound.cfg on kerckhoffs. The jenkins server on soro is
running on a non-standard port - may be this is the reason for the wrong redirect.

I can't easily test this because I am living in the same network.

Regarding HSTS (HTTP Strict Transport Security): The Jenkins server needs to
generate that header

Tested this again with 2.1.18 and it works now as expected. Export secret key
just exports a key if it has no passphrase. So I think this issue can be marked
as resolved.

Done with commit b456e5be

gpg: Make --export-ssh-key work for the primary key.

* g10/export.c (export_ssh_key): Also check the primary key.
--

If no suitable subkey was found for export, we now check whether the
primary key is suitable for export and export this one.  Without this
change it was only possible to export the primary key by using the '!'
suffix in the key specification.

Also added a sample key for testing this.

I don't know about HSTS, but I'd love to see a forced redirect.

It seems Jenkins sometimes generates a redirect that strips the httpS off, e.g.
go to https://jenkins.gnupg.org/manage, click on [Manage Plugins] (the link
itself looks fine), but one is for some reason redirected to
http://jenkins.gnupg.org/pluginManager/.