..... And now after looking into this a bit deeper after attempting to build gpg-agent for windows, it appears that this is a bit deeper than the logic above (which is actually sound, when I read it for the second time)

In this case the data is taken from a byte buffer, (unsigned char *). I can't see why iobuf_readbyte should be invoked here.

@gniibe there seems to be one remaining issue.
Even with iobuf_get_noeof, we have to cast to an unsigned integer before shifting 24 places to avoid undefined behavior :

diff --git a/common/iobuf.c b/common/iobuf.c
index 5eeba8fe6..1b9722d0a 100644
--- a/common/iobuf.c
+++ b/common/iobuf.c
@@ -878,7 +878,7 @@ block_filter (void *opaque, int control, iobuf_t chain, byte * buffer,
                    }
                  else if (c == 255)
                    {
-                     a->size = iobuf_get_noeof (chain) << 24;
+                     a->size = (size_t)iobuf_get_noeof (chain) << 24;
                      a->size |= iobuf_get_noeof (chain) << 16;
                      a->size |= iobuf_get_noeof (chain) << 8;
                      if ((c = iobuf_get (chain)) == -1)
``

Regression introduced with 1.12.0.

This is a new bug, I believe, but perhaps it only appears with "broken"
S/MIME-messages of this type, So I'll first post it here:

@werner Be my guest.

fine with me

I'll leave the fallback to "just try to decrypt" in though because it is better then doing nothing like we did before.

Thanks, from that log I can understand the problem:

please add a unit to the test suite to make sure something like this doesn't happen in the future!

Why not using PowerShell? Because --with-colons does not output the required hash? But that can't be the reason because Python has the very same problem. Using Python for scripts is anyway a bit of overkill.

Ok, with the beta gpgol the mail is successfully decrypted. This is the debug.log:

Precondition: A list of pubkeys, as keyring or as keyring file with list of fingerprints.
Goal: a static file structure that can be uploaded on my webserver.
Platform: Windows, a better solution does require less additional dependencies apart from Gpg4win.

You are running in a codepath that means "Outlook told us this was S/MIME, but we have not seen the proper message headers and neither does the data look like it is S/MIME."
Sadly your log does not help much in that case because it marked the mail as bad and aborts.
I've changed that "marking a mail as bad" so that future logs will be more helpful and that it will still try to treat this case as "encrypted" maybe that will already work, although I doubt it. The log will at least be a bit more helpful.

... that would be useful in many ways. I'd say we should support anyone who wants to use pythong-gnupg on windows.

@werner it is like @aheinecke writes:

As I see it Bernhard is just asking for the flat strucuture so basically some export script that creates the needed files on windows.

If they really want to do that for Windows, they can use some database approach like Protonmail does it. This does not require any file structure.

Sorry, we won't implement a server for WIndows. No sane provider uses Windows for a large mail setup.

additional info: I have their certificate(s) and sending encrypted mails to them is successful.

I forgot the debug log:

Gets reported multiple times and should be fixed for the next Gpg4win release as it is a bad first impression. (Although it can convert users to Kleopatra ;-) )

not yet, I try to get to it this week.

i'd be happy to help you set up your own x86 32-bit guest VM for testing
if you like, even if you're running on x86_64 hardware. they're cheap
and easy to run, and have a delightfully small memory footprint :P just
let me know!

I'll look into it.

BTW I am aware that Git repository does not contain many files which are prebuilt in tarballs. I am okay with that, I know the difference. I am just reporting that pinentry's configure script is missing an option, which is clearly needed and which is present in other components.

I wasn't using tarballs. I have fetched code from Git (git clone git://git.gnupg.org/pinentry).

Well, that is a detailed bug report. Thanks.

I'm closing this issues as "Invalid" because it is not an issue of Gpg4win. You can still comment and discuss here.

Ok. If you can confirm that then it means that my analysis is right. Still unexpected to get an error there. I have to do some more tests with Exchange Online but that would be another issue. If this issue is fixed by turning of debugging then it will also be fixed by my patches.

You are right that Outlook behaves normally if debugging is deactivated.
I had major problems with 3.1.4 and never used it until 3.1.5 came
along, so I guess it might be an existing problem.

While I can't reproduce it myself (because I probably don't have the right mails in my exchange) looking at your log I think that I see the problem there might be an issue with the error handling in openProperty. So for old mails the openProperty probably fails because we have exchange online for that and the property is not yet available in Outlook and then the error is not correctly handled and it crashes.