Still failing.

In T3438#104050, @werner wrote:

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.

https://netzguerilla.net/.well-known/openpgpkey/submission-address

does not return anything.

gpg-agent.conf actual content:

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?

It works correctly when installed and executed.
After a period of inactivity and with Thunderbird still open, it stops working.
With Gpg4Win 2.3.4 it works correctly.

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.

I agree with @kristianf that dirmngr should be more clever about this sort of failure. The error message could be clearer at least, but the right response is really to skip all IPv4 addresses if the machine has no IPv4 stack, and to skip all IPv6 addresses if the machine has no IPv6 stack.

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

okay, I see. Than I havn't found the documentation for this feature. This is enough for defining a different sever.

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:

This doesn't seem just to affect E-Mails but also File-Encryption.

I'm trying to find all relevant information first, then we can discuss who should work on this.

The workaround I've found is to put:

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.

From reading T3425, I would say that QT isn't supported anyome on both, XP and Vista. XP has the additional issue, that CancelIoEx is missing (which seems to be called from QT since Q5Core.dll uses CancelIOE).

I recieved the Log File of a user which may helps analyzing this problem further

I know, that I can't handle all WKD request under one domain for multiple once. But i could make sure, that autoconfig.<domain> would result under another IP adresse so I can handle all of the WKD request at another server. Add a own VirtualHost entry etc.

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.

I don't know yet what exactly is going wrong, but it seems that it is consistently not working with standard configuration on Vista and XP.

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

Something related seems to still be happening in 2.2.1. make test passes, but here on macOS 10.12.6., my ~/Library/Logs/DiagnosticReports is full of crash reports for scdaemon. As far as I can tell from the timestamps, it looks like scdaemon is *still* getting called by the gpg test suite, even though I built gpg with the flag --disable-scdaemon.

Because of policy requirements I have.

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.

Is this not a regression, rather than a new feature request? Earlier versions of GnuPG report sec rather than pub for such keys. The file itself is a private key - that it contains a public part is surely secondary in this context.

I see. NSIS is not (or not fully) UTF-8 aware.

I didn't open a bug for this, but what happended was that, after i changed the portuguese translations files from ISO-8859-1 to utf-8, the accents broke:

The Vista problem seems to be unrelated to the missing CancelIoEx in XP. The error message is that it "... could not find or load the Qt platform plugin "Windows" in "".

Can you please explain in the commit message why this was needed? A commit message stating only what has been done is not useful. There is also the option to reference a bug in the commit message, for example:

I agree that it is better to keep it in two directories.
(The potential advantages outweight the drawbacks.)

I'm not sure this is what you are looking for, but in Kleopatra latest version (3.0.0-gpg4win-3.0.0), it is possible to use ascii armor by default in all encryptions:
Make sure you check the following options in settings:
Settings > Configure Kleopatra > Crypto operations > Create signed or encrypted files as text files

I see.

So how would one distinguish between private and public key using any kind of automatic processing?

With the GPG4Win 3.0 Release, the software is differently distributed to the System. In the 2.x releases it was one folder (usually C:\Programms\gpg4win), now it is distributed to two different folder (C:\Programms\gpg4win and C:\Programms\gnupg). So the complete GnuPG files have been rearranged to their complete own folder.

Sorry, I don't understand this. Can you please elaborate?

No. GPGME can't check return codes because it uses a double fork approach.

My suggestion would be to create a wiki-page (http://wiki.gnupg.org/SampleKeys) or to store it in the git repository (gnupg/tests/samplekeys). That way they would be in a public place and reachable (and linkable) for everyone.

--clearsign is for text only and canonizes the the signed text to make it robust against different line-endings and white space changes. Thus this is no bug. To get a bit identical copy you may not use --clearsign or --text-mode but use standard signing,

What you see is the public key which is always part of the private key.

For context, here's what the wisdom of the crowd is rigging together around GPG to get this single-sign-on feature:

GnuPG is definitely not affected. I do my release test on Vista Ultimate Pro (or whatever it was called)

Someone described this issue with Windows Vista as well.

oh ... I see thanks. I am thinking now about an analogy between the place where I live in real life and the unix home directory, (also called a login directory). Very interesting indeed ...

Did just that in master and 2.2.

For workaround (master branch with rG0a7661129499), moving the private key file to *.key.bak can do that.