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.

is there any update ? I having the same Issue here on Windows 11 Pro, Outlook Version 2203 (Microsoft 365) 64bit

Any idea? Any update?

Have you selected an Output file in a location where you can write files with your permissions?

I had already tried both, to deselct all other add-ins and to select all possible add-ins.
No change of the behaviour.

Could you please create a log file using the debug settings with Outlook Object Model debugging enabled?

We should give this higher priority as users need to change their e-mail through kleopatra. A customer also wishes this.

Updated the copy on our mirror as welll as the gpg4win and swdb packages files.

The fix is from 2018 but was not picked up widely; see
https://github.com/madler/zlib/commit/5c44459c3b28a9bd3283aaceab7c615f8020c531

(Werner just told me that I was mistaken and he needs to take a look. There was a mixup because of the 2018 CVE number.)

Sorry, that was a misunderstanding. My fault.

I don't like it either but the browser vendors don't like SRV records.

Not in the way it is used by gpg. See T5880

I still think that redirecting to another catch-all domain is contrary to the original goal and weakens the security model. We need to see what we can do about this.

Thank you, works now on Windows with openpgpkey.sanka-gmbh.de

Independently of that, it seems that gpg4win doesn't work with at least one widely deployed webserver in its default configuration, specifically Caddy, so this fix is well appreciated.

I still think that redirecting to another catch-all domain is contrary to the original goal and weakens the security model. We need to see what we can do about this.

Not in the way it is used by gpg. See T5880

Oof. That hinges on the certificate, guess we'll need to renew the bunch of them. I reconfigured, might take a while for all pages but ciphers should now be:

The ECDHE_ECDSA suites are not yet implemented in ntbtls and thus we can't agree on a common cipher suite. Will be solved in the next Windows version.

In the above test, I was using
Windows: 2.3.4
Debian: 2.2.12

I captured some logs server-side, and I do see this error:

Are you using 2.3.4 also on Windows?

I have the same error when using wkd.keys.openpgp.org with a CNAME DNS entry. The error occurs with Windows 10, 11 and Server 2019 (only the most recent versions tested). With Debian it works fine.

SWDB updated - thus the latest zlib will be part of the next Windows build.

Not relevant for Windows, but for the AppImage: Qt's X11 xcb platform plugin depends on libfontconfig and therefore indirectly depends on libexpat. So, at least on Linux X11, pinentry-qt and Kleopatra both load libexpat.

All 4 CVEs are findings related to standard conforming compiler optimizations which OTOH break long standing assumptions on C coding. “Let us show that our compiler produces the fastes code ever and ignore any assumptions coders had made over the last 50 year”.

Right, we are not affected by these CVE because we use only the very basic core in gpg and no higher level functions. At least for GnuPG there will be no update.

One solution is to remove GPA and pinenty-gtk completely, as the used GTK+ version 2 is end-of-life. @aheinecke already asked on https://lists.wald.intevation.org/pipermail/gpg4win-users-en/2022-March/001740.html for reasons to keep GPA. (For which we should make a new issue).

because libexpat does contain vulnerabilties

@mieth sorry for the delay. meanwhile I adjusted the ciphersuite of the WKD gateway to include an AES-CBC suite. would be interested if it works now on the setup you tested before.

Please describe your problem in more detail. Also: Which version of GpgOl and Outlook are you using, SMTP/IMAP or Exchange?

Works for me in the current Kleopatra.

@ikloecker thanks for the hint (At first it looked like a different defect.)

This has already been fixed: T5711: Kleopatra: Keyserver config does not fallback to default.

In T5848#155277, @bernhard wrote:

@hakan-int :

As soon as I change the value and check the "dirmngr"file, it is overwriten with the "keyserver hkps://" value again.

(I hope only if you completely delete it, as it should keep any other value and write it to file.)

As soon as I change the value and check the "dirmngr"file, it is overwriten with the "keyserver hkps://" value again.

@bernhard when I close Kleopatra and stop the its task by the task manager, then the value remains. But as long as I do not change the default value to an other value in "Settings" -> "Configure Kleopatra". As soon as I change the value and check the "dirmngr"file, it is overwriten with the "keyserver hkps://" value again. I think, this is not the expected default value, is it?