We are currently investigating another problem with a new feature. Thus things are delayed. Hopefully we get a new release this month (or at least a new gnupg 2.3 version to install on top of gpg4win).

Is it possible to have a gpg4win ETA that fixes this bug? thank you

The option to flag a user ID as the primary user ID is now available in the Certificate Details dialog as button below the user ID table and as context menu entry of the user ID table.

Please reopen my issue. This is a serious issue that we encounter and do not have any explication.

Hi!
No, it's not waiting for the password. This was a 2 times error happening on our server.
We already provided the password but it was hung. We entered different things but it won't make anything.
I can tell you it doesn't wait for anything because we tested the same command on 2 different machines. On one machine it was hung, on another it worked.

gpg was waiting for the passphrase for the signing key to be provided via stdin.

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.

3.1.22 has been released.

Thanks for the analysis!

Hello, i did some debugging with my local sks keyserver version 1.1.6+ on Debian:

Just to clarify: Does this only happen with self-built AppImages? Or does this also happen with AppImages provided by gnupg.com/gnupg.org?

Just to clarify: Does this only happen with self-built AppImages? Or does this also happen with AppImages provided by gnupg.com/gnupg.org? (I haven't found AppImages to download on gnupg.org.)

Hello ...

I may report, that I've tested this behaviour with "kleopatra" with serveral keyservers.

I guess the problem is that the fix for T5741: dirmngr does not ask keyservers for fingerprints wasn't backported to 2.2.

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.

Looks like a duplicate of T5725: Kleopatra: Certificate lookup shows only one result even if there are 100s matches. Solution: Use a key server that returns fingerprints.

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.

So maybe add a hint with the workaround to the error message, maybe even link to some *.reg files that would fix it, with a big fat warning to respect and look out for your E-Mail providers attachement size limits. The 20MB thing from Outlook is nothing more than an educated guess by Microsoft in the first place, some providers have smaller limits and the user has to identifiy the server error code themselves anyways.

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.

Please find the requested log attached.
I don't know, where to look for such a file (candidate).

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.

Thank's Diedrichs for this hint.
Here it works again using Gpg4win V.3.1.15.

I've tried a few things now. Reinstalled Office, reinstalled GPG4win, reset Windows 11 with recovery when still worked. Nothing helped.

I've tried a few things now. Reinstalled Office, reinstalled GPG4win, reset Windows 11 with recovery when still worked. Nothing helped.

oh no

No, unfortunatelly problem is still existing.

Hat sich das Problem gelöst? Bei mir tritt das seit gestern auf auf. Ich kann nichts mehr signieren oder verschlüsseln. andere Plugins habe ich deaktiviert, es beliebt trotzdem.

You need to install the correct Let's Encrypt CA certificates on your legacy Windows box. Check the mailing lists for a discussion on this topic.

GpgOL konfigurieren - Version 2.5.3
Gpg4win 4.0.2
Windows 11
Outlook 365

Welche Gpg4win Version?
Welche Windows und Outlook Version?
Ist das die erste Installation oder ein Update?

Curious as to whether there's been any update on this. GPG4Win is the only approved whole email + attachment encryption solution on this end, and we're having trouble with inline images showing up as attachments only in Outlook 2016 (using GPG4Win 4.0.2). Of course, as you said, at least the attachment isn't being lost; however it does make reading rich emails more difficult.

Please disable all other Add-Ins as well as extra security tools running on that machine to see whether there is some interference with them.

But only with an option - in general showing expired keys is annoying. For revoked keys the situation is different in case of a compromise - but many users revoke old keys anyway and we don't make use of the revocation reason. If we would consider the latter the UI/Support would be more complicated than useful.

Maybe we shouldn't exclude expired or revoked keys from the list so that people can still choose them. Of course, those keys wouldn't be accepted to be used for encryption, but it would help people to find out why the keys are not acceptable.

In T5950#158024, @werner wrote:

Please check the 2020 certificate by using the details dialog. Has it a valid encryption subkey?

Please check the 2020 certificate by using the details dialog. Has it a valid encryption subkey?

We have even released 4.0.2 now.

JW-D with Gpg4win-4 we have support for multiple readers and also a dropdown menu for selecting reader ports. This should resolve this issue.

Please try a decent version of Gpg4win - we have fixed dozens of bugs in the mean time If the problems persists, please re-open this bug.

Conflicts between Add-Ins are often unavoidable. We have a list of known issues at:
https://wiki.gnupg.org/GpgOL/IncompatibleAddons
If you have more information on that ESET thingy please enter it into the above wiki or leave some description here.

In T5950#157442, @ikloecker wrote:

I'm afraid we need a bit more information. Please tell us the exact steps how you can reproduce the problem.

Moreover, please make sure that there is no text in the field above the table (in the second figure) because this text is used to filter the displayed certificates.

I'm afraid we need a bit more information. Please tell us the exact steps how you can reproduce the problem.