I think it's worth noting that this is not restricted to encrypted e-mails but signed-only e-mails also.

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.

This problem does not seem to exist in GnuPG 2.3.6.

My intention to refer rG7b1db7192 was to specify the HEAD of STABLE-BRANCH-2-2, meaning "the head of STABLE-BRANCH-2-2 today". The commit itself has no meaning.

I fixed the title, because it is not a Windows only issue.

The mentioned "g10: Fix garbled status messages in NOTATION_DATA" has nothing to do with the problem. So it can'r be the actual cause. Anway, I hope to get a 2.2.36 out this week.

I can replicate the error by 2.2.35, but I cannot replicate it with rG7b1db7192.
I tested:

• GNU/Linux
  • i686
  • x86_64
• Windows
  • i686

The likely cause is that the secret key is not protected. Problem seems to be in gpg-agent.

Looking again at your report, I don't think it is an IPC problem (bad magic cooky was my assumption). I can replicate this with the current 2.2 but not with 2.3. Both un Unix.

In T6031#159248, @werner wrote:

{please add comments instead of adding the description - a changed description makes it hard to understand follow up comments. I will change the title, though for clarity.]

Please don't play ping pong now,

Please report such bugs to RedHat - they use a modified Libgcrypt and thus it's there bug.

The length limit of the signature sub packets are not reasy to pre-compute. Better to have a fatal error than a corrupt message. I am not sure whether we want to change this to a regualar error message - at that point we anyway need to stop.

I will try, but it will likely be a while. In any case I believe you will need a Red Hat-family distro to trigger the bug; it happens when gpg trys to encrypt with a key that uses a public key algorithm libgcrypt does not support.

Please provide a test case.

Reopening as gpg’s handling of the situation is very much suboptimal.

Applied to 1.10 branch.

didn't seem to work with 1.9.x

Closing as I believe this is a downstream bug.

Thanks! Interestingly didn't seem to work with 1.9.x but it does with 1.10x. Maybe I made some error when testing.

Here is a test signature with long notation data. During verification gpg faults when emitting the NOTATION_DATA lines.

Thank you. Applied.

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.

Fixed. Thanks for the report.

Yeah, seems to be related to daylight saving. Running

TZ='America/Adak' GPGME_DEBUG=3 TESTS="initial.test t-various" make -e check-TESTS

results in

FAIL!  : TestVarious::testSignKeyWithExpiration() Compared values are not the same
   Actual   (expirationDate)   : 2106/02/04
   Expected (QDate(2106, 2, 5)): 2106/02/05
   Loc: [/home/ingo/dev/g10/src/gpgme/lang/qt/tests/t-various.cpp(342)]

because the code adds 30555 days to the current time (2022-06-10-00:xx:xx+UTC-9) which gives us 2106-02-04-23:xx:xx+UTC-10.

I couldn't reproduce the one-off problem of the original report, but running the test with time zone UTC-11

TZ='Pacific/Pago_Pago' GPGME_DEBUG=3 TESTS="initial.test t-various" make -e check-TESTS

resulted in

FAIL!  : TestVarious::testSignKeyWithExpiration() Compared values are not the same
   Actual   (expirationDate)   : 2022/06/09
   Expected (QDate(2106, 2, 6)): 2106/02/06
   Loc: [/home/ingo/dev/g10/src/gpgme/lang/qt/tests/t-various.cpp(342)]

because adding 30557d (number of days in UTC-11 until 2106-02-06) to the current time resulted in a u32-overflow. I'll change the maximal expiration date to 2106-02-05 to avoid the overflow.

Because it's the library which refuses null passphrase as input, only possible options are either:

Backported to GnuPG 2.2.

Added --enable-maintainer-mode to ./configure

Applied the changes.

Can you do a search on the command line:

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?

I take this ticket. The way to go is removing all such cases.

Reference to a CVE for old MinGW-W64: https://nvd.nist.gov/vuln/detail/CVE-2018-1000101
https://sourceforge.net/p/mingw-w64/bugs/709/

At least old Windows versions did not add a nul in the truncation case. Thus I used to make that sure. I don't think we need it anymore.

Also applied to 1.10.

Applied and pushed.

AFAIK the above case has a lot of wiggle room to fit one PID and the surrounded string into 400 bytes and even if it would need to truncate, it would write terminating character, at least on Linux:

Pushed the solution which doesn't require new flag for libassuan.

^-- I withdraw the solution (with error value) above.

For me it is faster: