I guess we can close this one.

works

I do not really understand why this is necessary. The problem is that /nonfatal conflicts with our msi creation as there is no such equivalent in the wix toolset language.

This overlaps with T5959: Kleopatra: Show key source in details widget if it is not unkown.

Another idea (based on above ideas): We add an optional column named "Valid For" and only list the usages that are currently possible. If the encryption subkey is expired, then the key will probably only be valid for signing and certifying. This should be easier to understand than my fancy color coding idea while still giving the user a hint what a certain certificate can be used for. I'd still abbreviate the usage to a single letter in English. Translators could still use more letters if a single letter would be ambiguous.

If you enter a wrong password in a window, the error message will only be given after you have answered all requests for the transport passwords.

A failed import is now reported immediately when the file was processed.

Thanks !

I think showing "partially certified" makes sense.

A real fix will be in the next gpgrt release

No. We now ignore expired key with --mirror, --create, and --install-key.

And what do we return if no keyserver is configured?

I would ideally like a result message like "Could not connect to keyserver ks.example.org" if the server is not reachable and
"the key has not changed on keyserver ks.example.org" or "the key could not be found on keyserver ks.example.org" if one of those is true.
At least the last two not if the key was found via wkd, obviously, in that case a similar message for wkd.

By the way, I don't know exactly what Werner means with

Works on the command line but needs more testing.

because at least on Linux gpg cannot import UTF-16LE-encoded armored certificates:

$ gpg --show-keys <test1-pub.utf16.asc 
gpg: [don't know]: partial length invalid for packet type 63
gpg: read_block: read error: Invalid packet
gpg: import from '[stdin]' failed: Invalid keyring

Kleopatra is now able to import certificates from UTF-16 (or UTF-32 or UTF-8-with-BOM) encoded text files.

Not so fun fact: If you enter tcp://1.2.3.4:10001 (literally) as value for gpg-agent's log file, then on save gpgconf calls
gpg-connect-agent --homedir /home/ingo/dev/g10/.gnupghomes/utf16 --no-autostart RELOADAGENT
which hangs (probably trying to connect to the not existing IP address or to the blocked port). This also makes Kleopatra hang.

Windows accepts forward slashes in all API calls. Users are sometimes confused by this but this is a documented feature for ages in the API.

@werner Full disclosure, it is possible to package gpg/gpgme within binary wheel for Python to support multiple platforms now. But, if there are no plans for that then I can use this for a namespace package instead.

But what about real Windows filenames?

I'm happy to hand over the PyPI package. Werner, what should I do with it?

The log file is intended to be an URL. Thus forward slash is fine.

The same problem will very likely occur with any file dialog opened by Kleopatra because file dialogs are always modal. It may not be nice that people can maneuver themselves in such a situation, but how likely is it that a normal user (and not just a good test engineer who is looking for such problems) will run into this problem.

Support for multiple smart cards has been vastly improved in the last few years. I will tentatively close this as resolved because it's very likely that the problems have been resolved.

Looks like Kleopatra is writing the filename with the system's preferred directory separator. If GnuPG on Windows works if filenames are written with Unix directory separators, e.g. c:/foo/bla or //server/foo/bla, to the config files, then we can certainly change this in Kleopatra.

Wild guess: Since creating a local certification seems to work, but creating an exportable certification fails, maybe the problem occurs when trying to promote an existing local certification to an exportable certification.

This has been fixed some time ago when the UI for generating OpenPGP keys was rewritten.

In T2671#158357, @werner wrote:

It seems that editing a pre-created revocation certificate on Windows with Notepad doesn't let Kleopatra detect this correctly as OpenPGP file and thus refuses to import. Works on the command line but needs more testing.

I don't see why this would be a Kleopatra issue. How is Kleopatra supposed to know that "mytestfile.txt (002)" isn't the original filename, but just the result of another program that's too stupid to properly resolve filename conflicts?

Another idea would be a gpgconf daemon that answers all queries from its in-memory cache. Obviously, this wouldn't help with the very first start unless the daemon is started automatically on login which should probably be default behavior at least on Windows anyway. OTOH, gpgme does already cache the config so this would only have an effect when starting Kleopatra.