I improved our test suite so that it detects this problem.

This is indeed a bug in libgcrypt. Thanks for the report.

Partially addressed in d568a1561642ed9b7b7b6282b86c56786d10a956.

Already fixed in 4db9a425644dccaf81b51ebc97b32a9cc21941a4. Duplicate of T2848.

Thanks!

Addressed in 9fb5e9c14557f7567cbc7c50b9881b7d7bfa2f12.

Is that sufficient?

Also:

$ ssh -V
OpenSSH_7.2p2, LibreSSL 2.4.1

Let's use T2425 for the tar failure, and T2847 for the ssh failure. The
log you posted here shows exactly the same problem as in T2847.

Do you also see tar failing?

You can use

make -Ctests/openpgp check XTESTS="gpgtar.scm gpgtar.scm gpgtar.scm gpgtar.scm
gpgtar.scm"

to run the same test over and over again. That is how I measured how often we
see the failure. We updated our box since, and I haven't tried it again yet.

Thanks for the report.

I changed the title to reflect what I learned from the log.

Our test runs fine, here a recent the log:

http://jenkins.gnupg.org/job/gnupg/501/XTARGET=native,label=macos/consoleFull

I don't know how to compare the OS versions, but this is what I see:

$ uname -a
Darwin ... 16.0.0 Darwin Kernel Version 16.0.0: Mon Aug 29 17:56:20 PDT 2016;
root:xnu-3789.1.32~3/RELEASE_X86_64 x86_64
$ shasum /usr/bin/ssh-add
bdb1005292b0891edba78b3f1f00fe036c4e60f9 /usr/bin/ssh-add

Could you please arrange the tests to be called using 'make check verbose=2',
and post
the generated ssh.scm.log file? For reference, here is our log:

http://jenkins.gnupg.org/job/gnupg/XTARGET=native,label=macos/ws/obj/tests/openpgp/ssh-import.scm.log/*view*/

(Note that I just renamed the test to 'ssh-import.scm'.)

Fixed in 4db9a425644dccaf81b51ebc97b32a9cc21941a4.
Test for --export-ssh-key added in 47b8b9e2ce5af7fba117ae0b00e10bec414dcfb0.

Fixed in 40e5ff0a0084c0d9521b401db4f38885bfdae233.

Fixed in 5840353d8bbcd9e75374f3bdb2547ffa7bbea897.

Neal, that is exactly what happens, thanks for writing it out.

Werner, yes, it also affects gpg1:

% faketime "2016-07-01" g10/gpg --edit foo
gpg (GnuPG) 1.4.22-beta2; Copyright (C) 2015 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

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: key 0707DEE4 was created 29 seconds in the future (time warp or clock problem)

pub 2048R/0707DEE4 created: 2016-06-30 expires: never usage: SCEA

trust: unknown       validity: unknown

[ unknown] (1). foo bar <foo@example.org>
% faketime "2016-07-02" g10/gpg --edit foo
gpg (GnuPG) 1.4.22-beta2; Copyright (C) 2015 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

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!

pub 2048R/0707DEE4 created: 2016-06-30 expires: 2016-09-28 usage: C

trust: unknown       validity: unknown

[ unknown] (1). foo bar <foo@example.org>

I just tried:

$ g10/gpg --encrypt -r samuel </dev/urandom >/dev/null

As expected, the gpg process eats a lot of cpu time, and I can spawn two of them
just fine. This works with both my build as well as gpg from Debian testing.

I once thought about making yatm emit org mode. Wdyt?

Fixed in ab89164be02012f1bf159c971853b8610e966301.

I also don't quite understand why we restrict this to user ids resembling mail
addresses, so I'll keep issue this open for discussion.

I'm closing this bug due to inactivity. Feel free to reopen it with more
information.

Fixed in 60ad1a7f37ffc10e601e69a3e2d2bb14af510257.

Try running "gpgconf --create-socketdir" after step 3.

If gpg does not create this directory when it is trying to start an agent, but
gpg-agent does, then I guess that is a bug. But to be honest, this is easily
one of my least favorite features of GnuPG, and I have no opinion whatsoever
regarding its design.

I've tried

What did you try?

• unfortunately the gpg-binary doesn't try that on its own

What is it that which of the gpg binaries does not try?

That doesn't work then of course, unless the configuration is copied over to the
new GNUPGHOME.

Another option would be to create directories or links to directories
/run/user/0 or /var/run/user/0. If those exist, gnupg will create the sockets
there.

Set the environment variable GNUPGHOME to the desired location.

Now that gnupg v2 is using gpg-agent for all of the hard work,

It isn't. The agent merely decrypts the session key. gpg then decrypts the
actual data with the symmetric cipher.

and gpg-agent either gets locked

It isn't.

or isn't parallelized,

It is.

this does not work any more.

Can you please be more specific?

You need to find a writable place for GnuPG 2.1 to bind its sockets to. If you
do, you can also use the smart card daemon. Using a smart card to store could
increase the security of your setup considerably. Also, I consider this an
integration issue, so talking to your distribution makes more sense imho.

Otoh, if GnuPG 1.4 fits your needs, you could continue to use that. It will be
maintained forever for compatibility with older PGP versions.

Fixed in 165f0ecebc8a68bff30d5255962a3b44d8113940. Will be deployed to the
webserver soonish.

I figured out that the custom_id property also works without an toc.

If you want to use the pinentry mechanism you need the agent in GnuPG 2.1.
There is no way around that. You need to find a writable place for GnuPG to
bind its sockets to.

Note that this is not an "issue", it is an improvement. GnuPG has been split up
into several components, a process called compartmentalization. The agent is no
longer optional.

The bug tracker has a spam problem, so new users need to be approved. I did that.

Note that the gpg-agent *does* relay comments if the private key has one. If
the key resides on a smart card, the cards serial number is used. It uses
'(none)' to indicate that no comment has been set.

I agree that '(none)' while technically correct is not very helpful, I'll have a
look if I can come up with a more helpful fallback comment.

How do you supply the passphrase? Modern GnuPG uses the gpg-agent to ask for
passphrases.

Also note that 'S.gpg-agent' is not a file, but a socket. Nothing is written
there, it is merely used for interprocess communication. Are you sure that
there is no writable location that can be used to create the sockets?

Please tell us more about your setup. What operating system are you using, how
is GnuPG used in the LUKS setup?

This is due to the fact that the Wiki software turns all upper-case words into
links, and there is some way to prevent that using ~ (or something like that).

In any case, there is no site HTTPS, so even if the link were correct, it
wouldn't lead to an article.

Also, it's a Wiki, if you want to fix it, please go ahead. You can log into the
Wiki using the same credentials you use with this bug tracker.

This is fixed in 3703a4723899d7563937b4b99f5bbe4dd8d3dfed. We will release a
minor update really soon now.

John is using 2.1.14, but this bug was fixed in 2.1.15.

Fixed in 1e6073ff.

So you installed GnuPG from source. If you didn't specify a --prefix during the
configure phase, it will be installed to /usr/local. Check that /usr/local/bin
is in PATH. Check what 'type -a gpg' says.

I'm sorry, but this is not a GnuPG problem, and helping you with installing
software on Linux is out of scope for us.

We now have a macOS box, and are building our software on it using Jenkins.

On that box, I also see the gpgtar test failing in about 14% of all runs. There
is something to be learned here.

To investigate, we need more information. What OS are you using, how did you
install 2.0.14, how did you install 2.0.30, and what exactly do you mean by
"reflecting the older version"?

Fixed in 683620c4.

Please clarify the plan a bit. Shall we use the algorithm currently used by
--recipient, the one used by --locate-key, or implement a new one?

I'm going to close this due to inactivity. Feel free to reopen this with more
information.

I have created two sample commits, pushed to

https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=shortlog;h=refs/heads/justus/issue2700

The second one does indeed change translated strings. If I don't update
translated strings, then the messages will still refer to the old version of the
options, which will still work but won't show up in '--help'. Is there a
problem with updating the strings when I also update the .po files?

I'm going to close this due to inactivity. Feel free to reopen it with more
information.

Fixed in 8d370180.