Talked with Jochen and tested this. Jochen's test forwarded the mail so he ran into T2854

I can't reproduce this issue. I've imported the attached mail with KMail and synced the folder to outlook.
GpgOL did decrypt the mail. It did not set the category correctly (These were two other bugs which I've fixed now) and displayed the wrong status information but decryption happened.

IMO this would be the first step to have the options we need for EasyGPG.

Kai, as you can see from

Ok. Lets put this problem back until we have a possibility to encrypt through filters so that can maybe enable this just for some kind of reenecrypt workflow.

Indeed it's unwrap and not nowrap. Sorry.

Thanks for your report. Indeed this accidentally was broken in the last release. Fixed now. As a workaround copy libintl-9.dll to libintl-8.dll and rename it back in the portable directory afterwards.

IMO for now we should not add DANE as this has been published for a while and we don't see widespread adoption. To avoid additional delays I would keep it disabled by default for now. But you know the pros / cons there better then me.

The problems I recall were about linking the C library gpgme against MSVC compiled other binaries.

I have not tested this. But I think it does not what we want.
Use case: I have thousands of mails encrypted to my old ELG 1024 key.

Or you publish some gnupg-2.1.23-beta3 or so. Would also be ok imo.

I'd say a patched installer with a different date. This is how I would have handled this in the Gpg4win 2.x times.

I can't reproduce this I even tried to completly remove TCP/IP from the DCOM Protocols. No problems.

Sorry. Git log had some ...skipping which i overlooked instead of 3419a339d9c4e800bf30e9021e05982d8c1021c1 the actual one is 9b43220b8ad1a5c1cd51de3bbfff7ccbcc3fa877

It's either rev: 5b9025cfa1f9b1c67ddf2f6bf87d863e780cf157 which does not compile by itself or 3419a339d9c4e800bf30e9021e05982d8c1021c1

Uhm. I can't reproduce this with a dirmngr built on my development system.

I tried to reproduce this through various scripts in variations of

Fixed with https://commits.kde.org/kleopatra/3e08e4d25d34140a1d03e02c7bd9d066120d0baa

Ah no. GpgME is not at fault. Kleopatra just eats the status and only shows system error. Have to fix this in kleopatra.

To make it easier to reproduce

Works in my tests. Thanks.

Something still fishy.

87703dbb86ac8fd8abd23170f8038ea6e3dbde28 was the offender. It called _gpgme_split_fields on a non fatal decrypt error which resulted in a mangled error passed to verify.

Ah! I can now also reproduce it on Linux, I had two gpgme's installed and the wrong one was picked up. Bisect here I come :-)

From this I take it that the checksum error comes from gcrypt but is wrongly propagated as Pinentry error.

With the vsnfdhome attached to this report:

Maybe related: T3187

I'm in a checksum error scenario again.

Sorry to have overlooked your report initially.
We fixed some bugs related to this. Can you please try with the latest Beta from https://files.gpg4win.org/Beta/current/

Outlook 2003 is no longer maintained.

I think its done and released with beta-270

There is highlighting now but we don't have the fancy new keyresolver.

• How to prepare the next general assembly
• Involvement of Members (Verein ML) and Transparency

Indeed _chdir("/"); might still be problematic. Because as werner says it would create problems e.g. if you sign a file on a network drive or removable device because the agents homedir would then be the root of the device.

The diff was commited. A general review of the ldap fetching on Windows is still pending but I think this can be resolved for now and we revisit this topic when we see new problems.

Commited with https://commits.kde.org/kleopatra/bfb379a204dc36e86689685b2c56727c87128cdb

No. But as of 3.0 GpgOL for Outlook 2003 and 2007 is no longer maintained and the support for this will be removed in some future version. This bug only affects new installations of GpgOL on the unmaintained (by Microsoft) Outlook 2003 and Outlook 2007 Versions. So -> Wontfix.