Hi,
I have tested a GnuPG Token with Gpg4win-3.1.12 and generating a key with Kleopatra did not work
With 2.2.23-beta4 that contains: 0a9665187a7cbf68933b7162fb5f974177684a50 I have repeated the test on Linux and first the key-attr change that Kleopatra sends fails:

See also: T3506

I have removed that feature intentionally. There were some issues where encryption errors were not properly reported to Kleopatra and handled by Kleopatra. This could result in catastrophic data loss. I have fixed ~3 issues regarding to that and then decided that in our architecture we cannot absolutely guarantee that this never can happen and cannot happen in the future. We have resolved all the issues, but they could occur again.

So if gnupg version >= 2.2.22 Kleopatra needs to convert the passed filenames to UTF-8 and pass them with the --utf8-strings option to gpgtar. This needs to be changed in Kleo. -> Assigned to me.

Further analysis shows that this only happens when async crypt is enabled.

This has been shipped with Gpg4win-3.1.12

Thanks for providing your workaround.

To be honest I have not tried that but it should work because then it has another 50 tries to find a name like "attachment_51.txt" because we stay in the loop.

I think this is good now.

I'm not sure what to do with the issue. For further analysis we would need to figure out what third party software breaks the MIME structure of the mail. That is more something for a support contract and not for the general issue tracker. This issue is very specific to your setup and so I'm not surprised that Microsoft says it can't help.

Thanks. rMdb82e99 resolved this.

We have released 3.1.12 which updated all the GUI libraries Kleopatra uses and I got some feedback in related issues like T4689 that this might have helped.

3.1.12 was released with this.

I just ran the test suite ~10 Times with -j48 on a 12 core machine and cannot reproduce this at all with GnuPG-2.2.21 and gpgme-1.14.0 so I tend to put this on resolved, otherwise this is a candidate for an issue that will be indefinetly in the tracker which we cannot reproduce or analyze further.

The t-json failure is: T4820

Thanks, I've applied this with an explicit include to <cstdlib> it was not required on Linux and Windows but I think it's better not to rely on internal libc++ include chains.

@bzbue1 Thanks for the info.

Yes. We want to move away from the edit interface as much as possible. It's very fragile and broke a lot in the past when --edit-key emitted different status lines and the state machine did not work anymore.

That patch fixes the build problem I got into today when trying to build 2.3 for windows. So ? from me and please commit the patch as it is already required when assuan and gpgrt config no longer emit ws2_32 in their pgk-config --libs line.

I just saw that there is related discussion and a patch for this in T4994 so I will close again here.

to give you any help I would need to know the exact error. I can only tell you that this is not a problem related to Gpg4win something else must be messy on your system. The Uninstaller of Gpg4win cleans up all registry keys that do not contain user config and all files should be removed unless some other process on the system interferes.

This change broke for me the compilation of GPGME which I fixed with: 52f930c1ed7eee6336a41598c90ef3605b7ed02b I found that fix there OK because GPGME explicitly uses ws2_32.

Phabricator allows it again to upload patches. It's D507

In Kleopatra/src/dialogs/subkeyswidget.cpp there is already a context menu for subkeys.

Still an issue, just noticed that with the 3.1.12 release announcement, it really looks ugly.