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.

Is currently not enabled, sorry. Use git:// ot the mirror here at dev.gnupg.org. Note that we sign all our commits using a token and as such it is a stronger security prove than a just an arbitrary TLS connection.

Sorry, we have nothing do to with this pypi thing even if that file claims " The GnuPG hackers".

The debug/workaround option works: When the option is checked, opening the msg file will not change its date.

With VS-Desktop-3.1.90.246-Beta I can not import the secret part of the edward.tester@demo.gnupg.com.p12 Testkey (ECC brainpool).
I do not see any error message.

works: installed VS-Desktop-3.1.90.246-Beta with

Questions:

• What does "not certified" mean? Not certified by the user exporting the certificates (use case: I'm the "CA" for the exported group.)? Or not fully valid (i.e. not certified by a trusted certificate) (use case: I want to give some certificates to my co-workers and certification is centralized)?
• What about expired, revoked, or otherwise invalid certificates?

I have created T6766: Kleopatra: On export, inform user about uncertified user IDs for points 3 and 4 of T6469#174361.

Yes, it consists of libkleo DocAction actions which are invisible unless they find the document which they would open. I expect that I can somehow find the menu element and then hide it. But a patch against KXMLGui to hide empty submenus automatically might be a better use of our time. So I put this in the backlog and if someone wants to pick it up in some downtime feel free to fix this :)

The submenu is empty because the referenced actions don't exist outside of VSD builds, right?

it was decided to write the encrypted archive with ending .part and only rename it at the end. In this way the users can't think they have a valid encrypted archive

Thanks, what should I look out for? I don't think I can provide the .p12 directly because it is from a production provider that I do not have full access. I can provide the log and x509 public certificate again using the firefox generated one.

Needed changes in Kleopatra are tracked in T6761.

I am pretty sure that we have done everything in gnupg. Now if we only had a workboard for kleopatra.

Yes, apparently I confused uint8_t and unsigned char here because the former appears in Simon's comments. We also kept to the use of unsigned char* in our implementations (that is even part of the GNU coding guidelines if I remember correctly).

Funny error description from macOS. Looks that there is no device - your PC/SC test programs confirms this. Thus I don't think this is a bug in scdaemon.