According to Werner this should work.

In high contrast mode the background should always be white or black.

Well, see my very first comment.

That output was also misleading,. that was from before I added the ignore-crl-extension in there. I was confused because I still got the error:

So dirmngr already has that option.

Well, this bug is fixed by using a decent libgpg-error or configure it correctly.

At the moment we have a green background for the results of a decryption and/or verification, if it was successful.
This does not work with high contrast mode.

and it is also confusing that you can choose the key for signing in Kleopatra, it is displayed with a green check mark but then you run into an error:

yes, fixed

I think this was fixed with the fix for https://dev.gnupg.org/T6534

I have added the confirmation to the following commands:

• Export Certificate(s)
• Publish on Server
• Export Group

Should we have a gpg_error_from_w32() as companion to gpg_error_from_syserror() ?

Here's a patch that should fix this. It's not amazing since we have to copy the map_w32_to_errno from libgpg-error, as it's not public API there.

You should see

org.kde.pim.libkleo: Reloading keycache with remarks enabled

in the debug output shortly after Kleopatra has finished the initial key listing (even if tags (aka remarks) are disabled in the configuration).

The original issue was to unclear to analyse and it was likely meanwhile fixed. For the other issue see the follow up ticket.

@jukivilli I have addressed a number of your comments now. You find my comments inline.

I mean this would also be solved if we did not use qiodevicedataprovider but pass the filenames directly to gpg for single files, too. (can't remember the ticket number) but I don't want to do that right now.

In T6526#177082, @ikloecker wrote:

The original issue was about creating an encrypted archive. This code doesn't use Qt anymore for writing the result file, but delegates this to gpgtar.

That sounds like a solid conclusion. I mean if errno is not set explicitly it is basically undefined which value it is, so maybe some other function set errno to no space left on device in that one case where it "worked".

The original issue was about creating an encrypted archive. This code doesn't use Qt anymore for writing the result file, but delegates this to gpgtar.

I've debugged Eva's problem and I think it's unrelated to the original problem, as it's specific to qt.

Fix was trivial, the classical cancel is not an error problem in the QGpgMEChangeExpiryJob

This has sparked my curiosity.

This happens when cancelling the password entry on normal keys, too. The strange thing is, the changeexpirycommand already checks if "err.isCancelled" and should do nothing in that case.

Tested and there are no available actions. Works.

Ok then we can resolve this. Because I don't want to change the code there too much since it is about a plaintext leak which we cannot reliably reproduce so any change there we cannot really test if it brings up the plaintext leak again. And for users that have problems with the changing of the mail we can point them to the workaround.

Mh, let us concentrate in here on error messages. I was thinking "but what about disable-dirmngr in the settings" then all publish / refresh / receive actions should be disabled or invisible. So that is better something for a different task.

This issue might be a bit to general, some things like avoiding bad error messages are more important then a fully nice solution. A nice solution IMO would make all the "publish on keyserver" actions / checkboxes invisible in that case. If a restart is required when the setting changes that is ok in my book because the way we use "none" is intended that our entry level packages have "none" defined in the global config. Of course if a user then manually enters a value when none is set we would also need to bring up a message box stating that a restart is required for the change to take effect.

I tend to give this high priority since our SecOps state that the creation of non vs-nfd compliant keys is inhibited by our software by default (at least in the UI) I mean no one complained and it is not a regression but this should be fixed soonish. But this does not neccessarily mean before the next release.

Your tools don't use the chain validation model which is required for QES (at least according to German laws). A signature is still valid even if the certificate has been revoked. You need to consider the context and the time the certificate was revoked.