As mentioned in T6134. The overlayer encoding is still broken and only as a workaround uses verschlusseln instead of verschlüsseln in german. Should be fixed once and for all.

Right, I think I never fixed this but someone changed the ü to u in translation to workaround it. That was what https://dev.gnupg.org/T4637 is about. I think I'll reopen this one.

@werner @ikloecker I tend to agree with the original reporter that this is an issue. Not a Bug, but an issue that causes problems for our Users. At least we should have some way in Kleopatra to disable "Advanced Features". Then users could be pointed to some screenshots how to disable AEAD.

This works now with the fix in pinentry that uses the same code to bring the smartcard insertion dialog to the front as we use in the password entry dialog.
Before I was able to reproduce the issue, now it works as expected:

I am adding the gpgcom tag as this causes support problems because we do not really know if it is an invalid object with the correct passphrase or if just the passphrase is incorrect.

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.