We need more information how to reproduce the bug.

I can reproduce this. Our test indeed feeds a passphrase to the agent.

Addressed in 56aa85f88f6b35fb03a2dc1a95882d49a74290e3.

Addressed in 56aa85f88f6b35fb03a2dc1a95882d49a74290e3.

One thing to look out for is a race condition between the agent deciding to shut
down, and a client trying to connect at that time, and that might lead to
intermittent failures. It may be doable correctly, but it is something to look
out for.

The other point being raised in the bug report about older daemons hanging
around over package upgrades should be discussed in a different bug. Yes,
shutting down the daemon when idle may work around this issue sometimes, but
clearly this is not a robust solution.

Yes, your version of OpenSSH does not seem support elliptic curve cryptography.
I feel that this is the very same issue as T2847, could you please revisit
that bug? I asked what version of ssh you were using over there, and sadly you
did not react.

I guess we need to figure out what kind of algorithms are supported, and skip
the ones that are not.

Merged in 9291ebaa4151a1f6c8c0601095ec45809b963383.

Fixed in 3f4f20ee6eff052c88647b820d9ecfdbd8df0f40.

That is no regression, that never worked well. It only works if one uses a uid
like 'test <test@example.org>'. I'll fix this.

Test added in 5aafa56dffefe3fac55b9d0555c7c86e8a07f072.

To me, your assumptions seem flawed. You somehow assume that you can get a
trustworthy computer A, but cannot get your hands on a trustworthy device to
transport data from A to B?

(Even if your assumptions hold, you can always take A apart and use its data
storage device (which is trustworthy) and use it to carry the public key.)

Thanks for the report. The message you quoted is a very general error message,
and unfortunately does not really help identifying the problem.

Please describe in detail your setup, and how to reproduce this problem.

Fixed in 6f02133bb07726afa6950e5b4685e75621276e60 by backporting a fix from
gpg-error.

If A is to be kept *really* secure, it must not have any network contact

Agreed.

and not
export any files from the point of time where the keys is generated.

I don't follow. You can connect your token to the computer, but for some reason
cannot connect a thumb drive to it? I don't see why exporting data from that
computer is problematic. If you are worried about compromised USB devices, you
should also be worried about the computer being manipulated in the first place,
or the openpgp token. Furthermore, you could use the computers screen to export
any information.

Fixed in 34fa2d79a07a079be472c3ff486debfdac8c6070.

Fixed in 8e3aa3204e74e8d7a7538e0d0f04e555f140131b.

I'm assuming it is. Feel free to reopen this bug if this still causes problems
for you.

I tried to reproduce this problem, and failed. Can you provide more information
about your build environment, and how to reproduce this problem?

I would also be fine just to add -L to any call to /bin/pwd in our tests. Note
that most tests are in tests/openpgp, and that set of tests changed radically
since 2.1.7, and the new version should not be affected (tests/ and tests/pkits
are mostly stubs anyway).

Fixed in 0e242278dfaa64ce31a45b72f5fa0806a3dba898.

We configure the build with -D_DARWIN_C_SOURCE=900000L on our macOs box. Not
sure if this is the proper thing to do, and/or if we should just always set that
when we build on Darwin in configure.

This is a bug tracker, not a support forum. If you need commercial support for
GnuPG, we are happy to provide that.

If you want to use GnuPG in your application, it is *strongly* recommended to
use GPGME. Please see https://wiki.gnupg.org/APIs

FTR: EFL == enlightenment foundation libraries. Calling this
"Enlightenment-based" is like calling the GTK pinentry "Metacity-based".

It does work, but contrary to my expectations it is rather unpolished. I'll
talk to Mike.

Thanks for the report.

This is fixed in commit 6e96cdd41a0e55b672309431062f37c4a4a9f485, but there is
no release with that version. Sorry for the inconvenience.

Indeed, that is a problem. I have created T2879 to track this.

tl;dr: HKPS handler will die when used with non-HKPS hosts in a given pool.

I think dying is reasonable. Maybe it should return a nicer error
than 'general error' and it shouldn't take 10 seconds to figure out
the protocol error.

Using setup directions from
https://sks-keyservers.net/overview-of-pools.php I assumed that
configuring my GnuPG client to use ipv4.pool.sks-keyservers.net
would provide an appropriate response. It took me quite some time to
determine that HKPS is totally incompatible with the ipv4 (or other)
server pools.

This is further confused by the fact that an older version of the
GnuPG skeleton files which includes a clause with examples that mix
HKPS and hkp servers (skel may not necessarily be updated in a
user's directory):

Sorry about that. I think the current skeleton file is clearer on
this.

As a result, I kept encountering the errors reported in
T1792

I don't see a connection to this bug.

Here's a simple demonstration of the failure case

$ gpg2 --keyserver hkps://ipv4.pool.sks-keyservers.net --search-keys
2071B08A33BD3F06
gpg: error searching keyserver: General error
gpg: keyserver search failed: General error

Contrast with:

$ gpg2 --keyserver hkps://hkps.pool.sks-keyservers.net --search-keys
2071B08A33BD3F06
gpg: data source: https://mud.stack.nl:443
(1) NIIBE Yutaka (GnuPG Release Key) <gniibe@fsij.org>

 	  2048 bit RSA key 2071B08A33BD3F06, created: 2014-10-29, expires: 2020-10-30

PERSISTENT FAILURE CASE:
Now, once the failure condition is encountered, further queries FAIL:

$ pkill dirmngr

A nicer way to kill the dirmngr is:

  gpg-connect-agent --dirmngr 'killdirmngr' /bye

$ gpg2 --keyserver hkp://pool.sks-keyservers.net --search-keys 2071B08A33BD3F06
gpg: error searching keyserver: No route to host
gpg: keyserver search failed: No route to host

This is strange, and looks like it should work. Works over here. Maybe it is
bad luck and you got a bad host from the roundrobin.

$ gpg2 --keyserver hkps://hkps.sks-keyservers.net --search-keys 2071B08A33BD3F06
gpg: no keyserver known (use option --keyserver)
gpg: keyserver search failed: No keyserver available

WHAT?! I just specified --keyserver!!!??

Relax. You forgot the '.pool' in the url.

Let's see if this can be rectified with clearing the keyserver:

$ gpg-connect-agent --dirmngr keyserver
> keyserver --clear
OK

$ gpg2 --keyserver hkps://hkps.sks-keyservers.net --search-keys 2071B08A33BD3F06
gpg: no keyserver known (use option --keyserver)
gpg: keyserver search failed: No keyserver available

Likewise.

1. Try this with other VALID --keyserver combinations. Bang head against wall. The ONLY command that seems to fix this persistent failure case: $ gpg2 --search-keys 2071B08A33BD3F06 Suddenly, I can use --keyserver again, after this.

I'm pretty sure you just messed up the urls.

This is a misunderstanding. 'delkey' only operates on public keys. I have
updated the documentation to make that clear.

Fixed in a76fe9e86d7802e67373218bd1759168585e92ab.

Unfortunately, it is currently not possible to delete secret subkeys while
keeping the secret identity key. You can use gpg --delete-secret-keys to delete
the whole secret key though.

Fixed in 3c7d6a1769ed6cc90d86247a814a0dce341512a3.

I went over the other programs, and did not see any glaring problems. I have
decided to ignore the socket configuration for now. I'm quite happy with the
changes, but feel free to reopen this bug.

Fixed in ca02a8b78fca8815388a859962584d75169ae3ee.

I'm going to write some documentation about the programmatic use of GnuPG.

Fixed for gpg as of 6b16b02109f4bb5b934e456667ff4c0ba7bc85fd.

A bug tracker is not a support forum. Nevertheless, you need to look into your
configuration file and see what line 143 says. Also, a configuration file that
long looks suspicious, maybe it just got corrupted somehow.

--quick-keygen fixed in dd3dde07a9a46130ac01d849f8edf0566e44f11f.

The default expiration interval has been discussed on the mailing list. There
was a rough consensus on two years, which has been challenged by Neal who thinks
it is too short given the current state of the tools, but the ensuing discussion
did not revolve around the time span, so I'm keeping my two years for now. In
any case, it is easy to adjust.

I decided to not change the --full-key-gen, because a) the user asked for it, b)
changing that requires breaking up a large chunk of translated text, and I do
not want to do that right now (a release is imminent).