A backport to 2.0 does not make anymore sense given EOF in 2 months.

No info received, similar to another fixed bug, and for 2.0 which will soon reach EOL.

gniibe: Can you check the status?

2.0 will reach EOL soon and we have received no response. Thus closing. If the problem persists with 2.2 (e.g. from gpg4win 3.0) please re-open this bug.

Won't be fixed for 1.4.

2.0 reached eol in 2 months so need to check it. For 1.4 I assume it has been fixed ;-)

@perske, may I ask you to send a DCO and an possible updated patch against 2.2 to gnupg-devel@ ? I would like to add it to 2.2.2. Sorry for the delays.

There should be a backup file in these cases.

I would suggest to close this as won't fix.

In 2.2 we implemented --import-option show-only which dies the right thing, that is to use the reguarl key-listing code. Backporting this to 1.4 does not make sense - people should move on and use gpg 2.2.

Given that we received no info after nearly two years, shouldn't we simply assume that this bug as been fixed?

This patch was released with 1.4.22

Thanks for testing. Did you try with a powershell?

I can replicate this now. Unfortunately without logging enabled.

GnuPG does not mess with suffixes but Kleopatra has some rules of it own which might be common to KDE. I thus flag your report as a feature request.

gpgme shall provide an interface for commonly required tasks but it shall not expose everything from gpg.

I tried to replicate this but failed. Well, I am on Vista and standard cmd.exe. Can you please try your tests again on a standard cmd.exe shell?

Well we could of course also add code to gpg-agent to verify the card key but the fix I just pushed fixes the problem more easily. If we ever want to implement PASSWD --verify for card keys (which has a couple of side effects) this patch won't be in the way.

Okay, will be fixed in 2.2.2.. I actually found a bug while working on the patch.

@gouttegd provided a patch to implemented that policy. I setup a server server to check this:

gpg -v --fetch-key https://test.gnupg.org/testurl/redirect-to-http.html

Here is a part of the log inline:

I would suggest to close this report even that I have the same problem with the g10 Code cert on Vista - but it used to work when I bought that cert.

It is likely that gpa will be changed to always use the default algorithm. Users who have special requirements will need to use gpg on the command line.

Right, but gpg has a strategy to figure out what it considers the primary (ie. the user id commonly printed). If we would merely convey the primary key flag to gpgme, gpgme or the gpgme calling application still needs to figure out what it considers the primary key - that might be different from what gpg shows.

gnupg 2.1.11 is pretty old and has quite some bugs. Please try at least the Debian version which is 2.1.18 plus a couple of backported fixes. Or yet better, the current stable 2.2.x

Backport to 2.2 done.

DLL hell. There are no command line tools and thus tehre is no need to put them into PATH. Well, except for the shasums - if that is really required, put them into a different directory but that needs to synced with Kleopatras use.

Fixed in master. Backport to 2.2 pending.

Why should that be useful? It will only run us into lot of problems.

This comment in the gpg code is relevant for the bug:

/* Verify the passphrase now so that we get a cache item for the
 * primary key passphrase.  The agent also returns a passphrase
 * nonce, which we can use to set the passphrase for the subkey to
 * that of the primary key.  */

Looking again at this case I assume this problem is seen more often today because 2.1 started to clean keys during import. That enlarges the time span for the race condition. We clearly need to do something about this in gnupg 2.2.

Well, it is already there:

gpg always returns the primary user id first. (see gnupg/g10.keylist.org:reorder_keyblock). gpgme keeps this order and thus the first user +id in the linked list is the primary user id. If the primary user id flag is not set the first is the same what gpg considers the primary user id. I can add this to the documentation.

This is a distribution or desktop environment thing. We maintain only the upstream version.

What is this Chocolatey?

We need a way to delete a secret subkey.

No direct way. You can do this:

Ooops. you meant a subkey - let me check...

Sure: --delete-secret-and-public-key FINGERPRINT

That is intended.

When Enigmail is running several operations at the same time it is possible that this happens. We would need to take a read lock for the entire time it takes to fetch the key or use other complicated methods to avoid a test/insert race. That would be very inconvenient. The proposed solution is to have just one process to update the keyring.

Thanks. I added you to the wiki page.

The private key, which is protected by a passphrase, is handled by gpg-agent. If you really don't want a passphrase (you have it in a script or the command line history anyway) I suggest to remove the passphrase from that key. Other options are

That seems to be a conflict between the two extensions. We need to look deeper into that so learn why it could go wrong and whether there is a way to work around the conflicts.

Up again. Thanks Jens.

On Tue, 10 Oct 2017 09:35, noreply@dev.gnupg.org said:

Our standard test on whether WKD is supported is by looking up the file submission-address in the WKD. If it exists we assume that there is some way to upload the keys.

I see that the completion script already uses --dump-options :-)

See T3441 for one additional screenshot with error codes.

The log file shows that gpgex (or explorer) crashes.

The output from gpgsm -K in the last quote is perfectly okay. -K works by iterating over all public keys and checking for each public key whether the private key part is also available. If the private key is not available gpg-agent returns an error.

Does anyone of you have a gpg-agent.conf and if so, what options are set?

The question is how to detect whether v4 or v6 is supported. Most systems support both versions but that does not mean that they can actually be used (i.e. due to improper setup or no connectivity). Even the "address family" not supported can be due to a missing kernel module and thus be a transient error message.

dirmngr has its own stub resolver to do DNS resolution via TCP so that it can be routed via Tor (to 8.8.8.8 which is a heavy traffic resolver and thus it will be hard to single out requests to other often used addresses.).

The only requirement here is that you use a subdomain of gnupg.org (here wkd, but any will work). This was added for those providers who have outsourced the top level domain but can still add new DNS entries.

Using a different server is actually supported:

So, who is going to work on this?

Indeed the notes for QT 5.9 do not anymore show Vista as supported. Stupid decision if you ask me.

FWIW, I plan to add a few features to gpg-wks-server to make the setup of a new domain and installation of keys easier.

That does not work because a property of WKD is that the key you retrieve has only the requested mail address and no other mail address. Merging them all into one file, which you need to do with your proposal, removes that property.

That is a server error - the redirect is under the server's control and if the server advises to connect via http we should do that. Well, unless our policy is to not allow such a redirect - such a policy makes a lot of sense of course.

• On XP we see an error message from Windows that CancelIoEx is not availabale in XP.
• On Vista we see a different error which comes from Qt and not Windows. See above.

[it seems you are using a Debian version. Thus please report bugs to Debian - they have lots of patches over standard gpg.]

The import-show thing is new. What you see is different from the default action of gpg when it encounters a keyblock. In fact, that old output was never well defined and basically a debugging aid.