Certificate generation should now be possible with 400 % magnification. I haven't checked the different actions under "Next Steps".

I have merged a contribution by Felix Tiede which adds support for publishing a key via WKS. It depends on KF5IdentityManagement, KF5MailTransport, and KF5MailTransportAkonadi. Those dependencies are optional. If they are not provided, WKS publishing is not available.

Thanks for taking this up.

We meanwhile released two versions to our clients and are looking on how we can make it available to the community.

We have a workaround by using a recent version of gpgtar directly. Thus lowering priority.

https://invent.kde.org/frameworks/kconfigwidgets/-/merge_requests/140

On second thought: Let me open the MR.

@aheinecke I suggest to open an MR for this at https://invent.kde.org/frameworks/kconfigwidgets and see how the discussion goes. Either the change is accepted or other proposals are made to fix the crash in Kleopatra.

No. And this is out of scope for Kleopatra. You can use existing file sync tools to sync the files in ~/.gnupg. Which files to sync depends on what you want to sync. For details, I suggest to ask on the gnupg-users mailing list.

Hmm, according to lxr.kde.org this is the only usage of a static thread_local KSharedConfigPtr variable in all of (indexed) KDE. OTOH, there's also exactly one usage of a static KSharedConfigPtr variable in all of KDE (in plasma/plasma-nm/libs/editor/configuration.cpp).

Ingo: I have now assigned this to you. If you can explain why my fix is required in a way that upstream would accept the change we should try to get this into KConfigWidgets proper. But I do not think that I can convincingly explain why it is required or what happens here.

After some debugging and reading the code I did not find any way that the KSharedConfigPtr could be accessed when it was NULL. It is never saved in a member variable. The only place it was saved was in the static thread_local variable of defaultConfig in kcolorschemehelpers_p.h. Since this was irritating because I understood QExplicitlySharedDataPointer to already handle thread_local ness

So after updating to latest kf5 this still happens. The windows event log tells me that the crash occurs from libkf5configwidgets.dll
Does not seem to happen on Linux, i have run it with valgrind to and only found other crashes on linux shutdown when closing the window.

Sorry, yes I meant the Certificate Dump not the Details.

I would love to defer those encoding problems to gpgme. The output of gpgme should always be UTF-8 encoded, so that higher API doesn't need to bother about encoding. Obviously, this would mean that we shouldn't bypass gpgme by running gpg commands with QProcess.

When we want to add more smartcards we should open new issues. This one is resolved.

I am closing this as the group support for gpgol is now in T5967