Received. Thanks, so this is PGP Inline. Encoding handling in PGP Inline is always "Guessing" as it is no where defined which encoding is used for the message.

I've commited a fix and because this and another issue we might do a release sooner than originally planned.

If you like you can help by confirming that it also works for you by installing 2.3.1-beta11-STABLE-BRANCH-2-3 from https://files.gpg4win.org/Beta/gpgol/ as described under: https://wiki.gnupg.org/TroubleShooting#Manually_update_GpgOL_to_a_beta

interesting. email sent.

Mmh no, I can't reproduce this and my initial hunch was wrong. We do in fact handle encoding in that case.

Patch 0001 applied to master.

Thanks for your report. Applied.

I just tried the newest beta and I can confirm that sending Office attachments does work for me with this version.

Added gpgol and gpg4win project tags as this is important for these projects.

I was unable to figure out what the difference is between the handling of Office files and other files and why it comes to this error.

FreeBSD is fine with no estreams updates to the python bindings or just Jasper's update or just my previous update with the underscores, but not this attenmpt to cover both OS X and Ubuntu.

Right, which is exactly the issue I was trying to solve by adding both versions.

Thanks for the report.

I can reproduce the issue and give it high priority. This is a curious problem of Outlook triggered by the improved send code in Gpg4win 3.1.3.

Here's the debug log file.

Thanks for your answer. So i think we must wait for the Update and downgrade to 3.1.2.

Da wir eine internationale Software sind bevorzugen wir in diesem Tracker Englisch. Ich hoffe das ist ok.

Thanks for the report. I was not aware of this but Indeed the fix should be easy. I think I already know the cause ;-)

Address book integration is in. What is still needed is to respect the overrides in the interactive key selection dialog.

I created gniibe/secmem branch for this.
https://dev.gnupg.org/source/libgpg-error/history/gniibe%252Fsecmem/

well, i tried to push, anyway, but it looks like playfair is rejecting my pushes:

@werner -- yes, i am asking for a change that is specific to the way that gcrypt interacts with the Linux kernel. The minor patch i've proposed only affects a codeblock within #if defined(__linux__), so i don't believe it would have an effect on other Unices. I hope that people working with other kernels will propose any necessary fixes for them.

Thanks for the clarification.

Which is the correct way to handle this. We merely gave the MDC packet a standard packet structure so to help with debugging. Decryption needs to defer the 22 bytes to be able to detect the MDC packet.

Perhaps, the missing length information in compressed data packet is confusing. The length can be determined by the assumption of existence of 22-byte MDC packet.