This happens on at least PPC Mac OS X 10.4.11, Tiger. Compiler is by default Apple's
version of GCC 4.2. The error is reported as this:

libtool: compile: /opt/local/bin/gcc-apple-4.2 -DHAVE_CONFIG_H -I. -I..
-I.. -I/opt/local/include -I/opt/local/include -pipe -Os -arch ppc -Wall
-Wcast-align -Wshadow -Wstrict-prototypes -Wpointer-arith -MT
libassuan_la-assuan-socket.lo -MD -MP -MF .deps/libassuan_la-assuan-
socket.Tpo -c assuan-socket.c -fno-common -DPIC -o .libs/libassuan_la-
assuan-socket.o
assuan-socket.c: In function 'socks5_connect':
assuan-socket.c:732: error: 'INADDR_LOOPBACK' undeclared (first use in
this function)
assuan-socket.c:732: error: (Each undeclared identifier is reported only
once
assuan-socket.c:732: error: for each function it appears in.)
make[3]: * [libassuan_la-assuan-socket.lo] Error 1
make[3]: Leaving directory
`/opt/local/var/macports/build/_opt_local_var_macports_sources_lil.fr.rsync.macports.or
g_release_tarballs_ports_devel_libassuan/libassuan/work/libassuan-2.4.3/src'
make[2]: * [all] Error 2
make[2]: Leaving directory
`/opt/local/var/macports/build/_opt_local_var_macports_sources_lil.fr.rsync.macports.or
g_release_tarballs_ports_devel_libassuan/libassuan/work/libassuan-2.4.3/src'
make[1]: * [all-recursive] Error 1
make[1]: Leaving directory
`/opt/local/var/macports/build/_opt_local_var_macports_sources_lil.fr.rsync.macports.or
g_release_tarballs_ports_devel_libassuan/libassuan/work/libassuan-2.4.3'
make: * [all] Error 2
make: Leaving directory
`/opt/local/var/macports/build/_opt_local_var_macports_sources_lil.fr.rsync.macports.or
g_release_tarballs_ports_devel_libassuan/libassuan/work/libassuan-2.4.3'
Command failed: cd
"/opt/local/var/macports/build/_opt_local_var_macports_sources_lil.fr.rsync.macports.or
g_release_tarballs_ports_devel_libassuan/libassuan/work/libassuan-2.4.3"
&& /usr/bin/make -w all

Cause is that the declaration of 'INADDR_LOOPBACK' is hidden behind some guards. The
two external links document the situation, they also offer patches, either the attached
one or this addition for src/assuan-socket.c:

//fix missing define in MacOSX 10.4 Tiger
#ifndef INADDR_LOOPBACK

#define INADDR_LOOPBACK (u_int32_t)0x7f000001

#endif

In ten days I'll be at home again with my Apple PowerBook G4 and might have time to
check the situation in Mac OS X 10.5, Leopard.

D380: 963_src_assuan-socket_INADDR_LOOPBACK.patch

Justus, thanks for this work, it's great!. If we can solve the problem by doing
more clever socket(7) manipulation, that would be a big win.

How do you propose dealing with the getsockname() variations? or should we just
forbid the use of getsockname() entirely in the gnupg codebase?

See T2910.

I addressed this for GPGME in 60273e8b2c11d42215a5707bc55e3e0d8f350e07 but
apparently forgot to mention that here.

I'll keep the bug open until I fixed this in all packages.

I added the following snippet to our pound configuration in the ListenHTTP
section for IPv4:

1. Justus: Redirect all jenkins request to https. Service HeadRequire "Host:.*jenkins.gnupg.org" Redirect 301 "https://jenkins.gnupg.org" End

I hope I didn't break anything. Jenkins is much nicer to use now :)

Wichtiger Hinweis:
Diese E-Mail enthält vertrauliche oder rechtlich geschützte Informationen.
Wenn Sie nicht der beabsichtigte Empfänger sind, informieren Sie bitte sofort den Absender und löschen Sie diese E-Mail. Das unbefugte Kopieren dieser E-Mail oder die unbefugte Weitergabe der enthaltenen Informationen ist nicht gestattet.

Thanks for your report. Indeed it should work as you described and we have code
in the installer to print a non admin warning. If this is not shown then it is a
bug.

On a related note: I have on my TODO list to enable "Single User" installation
in case a user tries to install Gpg4win without admin rights, because with the
modern gnupg versions we don't need admin rights anymore. Would this also have
solved your problem but or do you specifically want to have Gpg4win installed
systemwide?

Yes, it's the same issue.

dkg, I understand that GnuPG does not work with such a homedir, however, it is
not the act of creating the socket that is problematic. In fact, both
bind(2)ing and connect(2)ing is ok if one uses relative paths, as demonstrated
by the test program I have attached here.

Here is the program binding and connecting to a socket with an absolute path
length of ~10 * sizeof sockaddr_un.sun_path:

System: OpenBSD:6.0:GENERIC.MP#1992
sizeof addr.sun_path: 104
Running test with strlen (cwd): 22, name: '/tmp/test-unix-sockets/socket'

getsockname returned '/tmp/test-unix-sockets/socket', addrlen: 106

Running test with strlen (cwd): 22, name: 'socket'

getsockname returned 'socket', addrlen: 106

Running test with strlen (cwd): 126, name: 'socket'

getsockname returned 'socket', addrlen: 106

Running test with strlen (cwd): 1062, name: 'socket'

  getsockname returned 'socket', addrlen: 106

This works on all Unices that I have access to. I've asked on gnupg-devel@ for
people to run it elsewhere.

I understand that '--create-socketdir' solves problems besides this one. But I
disagree with the statement that our handling of socket paths is unproblematic
because --create-socketdir solves this problem.

Isn't this the same as T2975 ?

The --hostable option is a debugging aid and only used manually.

The nsswitch items "mymachine", "resolve", and "myhostname" are not known to
libdns but should have been skipped. "files" is the first entry and should have
delivered the result.

Fixed in cd32ebd152a522e362469ab969d91f8d49f28a60.

Seems that libdns does not pick it up /etc/hosts

Fix pushed. Thanks.

Simply not implemented. Will be in 2.1.19

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