Thanks, the update button this is now more what I think is expected. Still I am not sure if removing it completely was neccessary, well we have it in the history now. Because I see the need to also update via WKD. Currently we only update from there if a key is expired but we would never see revocations. That is a problem that we will need some solution for at some point. But yeah in that case calling it "RefreshOpenPGPKeysJob" would be a misleading API Name anyhow. So its probably good that you removed it before the upcoming release.

Still, the first thing you should do is to update to a recent version, the version you are on is about 3 years old. See https://gpg4win.org for the most recent version. Then add --verbose and --debug ipc to your command so we can maybe see more what it does.

I thought "Update" would do a key server refresh by fingerprint. Maybe I looked at the wrong job? In testing we noticed this because we suddenly had additional keys after using "update". "Update" in the certificate details should only search by fingerprint. Maybe when we know that the key source is WKD we could also look by mail address?

Most things look good to me, it was automatically enabled when I switched Windows to high contrast mode. The only thing I noticed is that the fields where we explicitly set the background may not look to readable. Especially the Sign&Encrypt buttons because there we don't set the text color.

I am reopening this as the current behavior is strange in my opinion and should be changed before a release.
Currently the refreshopenpgpkeysjob does not refresh the OpenPGP Key by fingerprint but instead imports all keys with a similar e-mail address. This does not work for keys with no email. Also in case of public keyservers it can pull in keys that not belong to the user or are expired and so on.

This was added in b03fab09e188f7bb10237d4f20455e4026737e4e

Oh, there appears to be a reason for that. In line 699 of mainproc.c:

/* Symmetric encryption and asymmetric encryption voids compliance.  */
   && (c->symkeys != !!c->pkenc_list )

Agreed

As part of this the "Change Reset Code" button should be hidden in the general user interface.

No lets close this now.

We have three styles enabled / installed, Windows the Windows 95 style. Windows Vista and fusion. Windows Vista is the default. On Windows 10 these look like the following. On windows 11 they look slightly different again but that is mostly due to window decorations.

Yes, I think that makes sense in the way that we want to provide the best user experience for our own users even if they communicate with communication partners which creates problematic keys.

For this dialog I think we need additional work. I have not yet tested it on Windows 11 but at least on Windows 10 with the default theme it looks much less like a native dialog and more like a "Windows XP" Dialog now. Please do not see this as nitpicking, I know it is hard to have something accessible and both pleasing to the eye but I think that this is something we should try to archive.

This is about showing the corresponding about dialog text for the disable support option.

Sorry, I did not mean to imply that this was a regression, I only noticed this as I was tabbing through the welcome dialog and then wanted to test openpgp certificate creation by keyboard and was also irritated that it did not work as expected on the button.

When the protocol is already choosen then the wizard is still opened and not the dialog. E.g. if the key is created from the welcomewidget's "New Key Pair" button. Or if S/MIME Certificate creation is disabled completely.

In T5824#160925, @ikloecker wrote:

Because it doesn't look good, but it is required for full accessibility, I have considered adding a configuration option to enable/disable extended accessibility.

I tried to reproduce this as we had similar problems in the past, but for me this works with full unicode characters.

The welcomewidget has some problems:

To add an icon:

@ikloecker KWatchGnuPG does not work on Windows. And this also does not work with Kleopatra logging and GPGME logging, Kleopatra logging needs Dbgview on Windows, which can be spammed by other software and GPGME logging requires an enviornment variable. So having this in a logging view would be good for support.

Yes, this sadly happened with 3.1.23 for Gpg4win 4.0.3 this was noticed and fixed with rW3cdf0b10d39c844b6f3557a85dc39dc2b9242b53 as we are planning 3.1.24 anyway this issue pushed the timeline for this a bit earlier so we should have a relase very soon.

As discussed with Markus I'm changing the assignee

3.1.22 has been released.

But this is with the default keyserver keys.ubuntu.com it shows the fingerprint if I do a search --with-colons with 2.3 and the same keyserver (addressed via IP) on the same machine returns results on Windows and says No Fingerprints in the app image. This is what I found so strange here.

Hier scheint es sich um ein individuelles Problem zu handeln. Ich bin irritiert das die Fehlermeldungen von "gpgsm" also unserem S/MIME tool. Tritt der Fehler auch so auf wenn in den Einstellungen von GpgOL der S/MIME Support deaktiviert ist?

I agree, we should look for additional names when verifying checksums.

I can reproduce the problem. Under Windows it works, with my development setup with GnuPG 2.3 it works, but in the appimage I get the error that all keys were skipped.

The problem is that we keep the original, encrypted, signed structure of the mail as a hidden attachment. When we then add the attachments we extracted from the original mail as "real" attachments in the Outlook data structures we basically double in size and hit an error in Outlook. It does not always have to be double, e.g. if the attachment was compressed in the encrypted data it can be much larger then the original mail. So this happens mostly with data that is not easy to compress.

Thanks for the log and the analysis so far. In the log it is visible that the problem is that gpgol cannot create a temporary file to store the mails contents. Due to this it fails later as it has no data to encrypt. The storage as a temporary file was added in 3.1.16 to allow more embedded outlook objects since we now ask Outlook to first serialize the file. I wonder why this only occurs to very few people. Obviously it works for most people, including me.

Yes I agree to go for a.

Thanks for taking this up.

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.