libksba fixed in 561d03a008150c201ece22b29c97b24a1f6bf590.

libassuan fixed in b26b73d04bff10852382113ae361ea5726661510.

libgpg-error fixed in 5e51b642f747547c737a7abbc37e65b0f630d188.

Note that simply reverting 02eb9fc9d5863abcfed6af704e618f8cac7cc2e8 will make
our sanitizer build miscompile, likely because -fsanitize=x breaks some test.
This would be easy to fix with my approach, but Werner does not like it.

Reverted 4b57359ef3ce0b87e15889e12ef0fcd23f62dcb4.

Fixed in 4b57359ef3ce0b87e15889e12ef0fcd23f62dcb4.

Fixed in 591b6a9d879cbcabb089d89a26d3c3e0306054e1.

Simple Y2038 problem. Fixed in de3838372ae3cdecbd83eea2c53c8e2656d93052.

It fails exactly the same way on 64 bit Windows too. Our 32 bit build machine,
an OpenBSD box, is fine. I'll have a look.

Werner does not think that this is a problem and does not want me to spend time
on this.

getsockname is only used to recover the paths of sockets bound by a supervisor
like systemd. So unless systemd starts doing the same trick that I propose,
there is no problem.

Fixed in 0c4d0620d327e8a2069532a5519afefe867a47d6.

So I went over the code that does --locate-key. There, the available methods
are ordered, and if 'local' is not given, it is explicitly done first, unless
'nodefault' is given. This is one of the parts of GnuPG that I'm really afraid
to change ;)

Hum, there is something strange going on here:

% gpg --auto-key-locate wkd --locate-key root@leckerlecker
... no update...
% gpg --auto-key-locate wkd,local --locate-key root@leckerlecker
... no update...
% gpg --auto-key-locate clear,wkd,local --locate-key root@leckerlecker
... update!...

Glad to hear that. Niibe will have a closer look at the issue tomorrow.

Fixed in 4735ab96aa5577d40ba7b3f72d863057198cc6a7.

I read the code and documentation for key-edit's revuid, and --quick-revoke-uid,
and the code makes no effort to ensure that one valid UID remains.

I read rfc4880 trying to find the basis for "some non-revoked User ID must
remain", but the only justification I could find is in section 11.1.,
Transferable Public Keys, that states that at least one UID must be included if
one wants to transfer keys.

So, do we actually want to enforce that or fix the documentation?

A possible workaround for you is to disable the use of scdaemon in the tests.
Currently, it is not needed anyway. I'll attach a patch to do that.

D412: 966_issue2980-workaround.patch

This is interesting indeed. Might be related to a recent change to support
multiple smart cards.

From what I've seen there is no variation in getsockname, it just returns
whatever path is passed to bind. I don't understand the need for getsockname
tbh, because we are the ones that bind the socket in the first place.

(The only variation seems to be that the function is broken on Hurd...).

Fixed in 62d21a4ab4029b32ea129f1cf3a0e1f22e2fb7b0.

Can you please give us ssh -V, and describe the sandbox environment? Does it
affect which ssh version is used?

(I'm mildly annoyed that I have to ask again. You are not forthcoming with
information about your environment. macOS is somewhat alien for us, and if you
want help with tracking down the issue, you need to give us more information.
Note that we really do make an effort, and we have a macOS build slave that does
not see these issues:

https://jenkins.gnupg.org/job/gnupg/XTARGET=native,label=macos/

(though we get our build dependencies from pkgsrc, and you get it from your
packages I guess, so there are bound to be differences).)

From your latest log I see that the version of ssh used supports ed25519, so
this must be version newer than 6.5.

I just committed a patch that dumps the ssh version and the path to the binary
when executing the test:

https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=74cb3b230c1f99afc5fd09bccc24186a63b154b0

This is not about socket directories, and SSH_AUTH_SOCK is set properly (as
demonstrated by the fact that dsa and rsa works).

Oh cool, so that patch was effective :)

2.1.18 did not have this problem, and the tests completed successfully within
the sandboxed Homebrew build environment.

Your T2947 says otherwise. So does T2847. Can you please clarify that?

This is the interesting part of the log:

Importing ssh keys...

> dsa Executing: '/usr/bin/ssh-add' '-'

Identity added: (stdin) ((stdin))
Executing: '/usr/bin/ssh-add' '-l' '-E' 'md5'
rsa Executing: '/usr/bin/ssh-add' '-'
Identity added: (stdin) ((stdin))
Executing: '/usr/bin/ssh-add' '-l' '-E' 'md5'
ecdsa Executing: '/usr/bin/ssh-add' '-'
Identity added: (stdin) ((stdin))
Executing: '/usr/bin/ssh-add' '-l' '-E' 'md5'
error fetching identities for protocol 1: agent refused operation
error fetching identities for protocol 2: agent refused operation

So, what happens for 'dsa', 'rsa', 'ecdsa' is that first the key is added, then
with ssh-add -l we check that it is in fact added. This works for dsa and rsa,
but fails for ecdsa.

Can you please give us ssh -V, and describe the sandbox environment? Does it
affect which ssh version is used?

As of e064c75b08a523f738108428fe0c417a46e66238 newlines are always escaped.

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 :)

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.

Fixed in cd32ebd152a522e362469ab969d91f8d49f28a60.

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.

As of d379a0174cca595204b32da9a66c513a1304e6d0 auto-key-retrieve is configurable.

As of ebeccd73eb85f9027f0985d77dfe901266c6ddef the trust model is configurable
via gpgconf.

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/.

however i still think the actual key fingerprint used should be shown here.

There are two problems with this proposal:

1/ Usability. Showing a keyid or fingerprint is less user-friendly than to show
the identifier that the user actually used in the configuration file to refer to
her key. I'd guess that most users use a UID here.

2/ Consistency. The code around the message in question also deals with error
handling in case looking up the key fails. In this case, we cannot show
anything besides what the user used in her configuration.

shouldn't we avoid short keyids everywhere?

We should avoid short keyids everywhere we use keyids, but this is not the case
here.

This is because you use a short key id in your gpg.conf. gpg is merely echoing
back whatever you specify there:

% touch tmp ; gpg2 --detach-sign tmp
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: using "baz" as default secret key for signing
% grep default-key gpg.conf
default-key baz

Delegating to our resident C++ expert.

So I believe that if we have a test that demonstrates this problem, then it is
safe to set the status to resolved.

Fixed in 6823ed46584e753de3aba48a00ab738ab009a860.