I confirm this bug!

@werner Given you filed it as low priority and documentation - could you give feedback on whether that is expected behaviour or not?

Perhaps it happens because I'm asking for "Lesebestätigungen" along all mails? But still the icons for signing should not be gone!

Thanks a lot.
By this report, I was able to fix more memory leaks.

sorry, i haven't had time to test gpgme with those changes myself. i hope someone can do so.

The background of my earlier comment was that I didn't tested GPGME in this regard.

if gpgme doesn't rely on the return value, but instead on parsing the --status-fd for errors, then there will still be an ERROR printed:

Okay. So for GPGME should we add --no-keyring if --override-session-key is also enabled? I think this would be better than relying on the fact that gpgme ignores the returned error code.

I've uploaded a Gpg4win installer with this fix (3.1.4-beta3) to https://files.gpg4win.org/Beta/current/

yes, it looks like using --no-keyring does change the return code from 2 to 0 for me.

@dkg does --no-keyring solves the problem for you?

We assume that this has meanwhile been fixed.

Asked in https://github.com/google/oss-fuzz/pull/1806

I made a mistake and put the DLL in the wrong folder. After placing it into the correct one, everything is working fine and stable.

Actually it fails only when you set TERM to the empty string. Unsetting TERM still works:

Another address does not help as long as we are forced to use a Google account. That is not subject to discussion. sorry.

ok @werner
Should I change it to another mail address (@gniibe if you are interested) or should I just use mine ?

You may indeed post to gnupg-devel if that helps to raise the attention of the Travis folks. If they need support we would be glad to help.

This has always been the case and the worst thing which can happen is that (64 bit keyid clash) you might not be abale to import the "real" key. Keyserver's never promised to deliver the correct (in whatever sense) key, but are merely an anonymous and distributed stoarage systenms. This is why gpg does not trust a key by default but requires you to validate the key by other means (WoT, second channel, Web Key Directory).

I confirmed: Now, all use cases of iobuf_get check against negative value or are using iobuf_get_eof.
So, closing.

@catenacyber thanks fo this bug report.

..anybody?

Yes we had a bug in 3.1.2 that when you had a contact group as recipients gpgol would silently ignore them and don't encrypt to them.

Here's an example of a bad key: http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0x4359ED62E084DAB9
which mimics the good key for R-CRAN: http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0x51716619E084DAB9

First let me say; Thank you very much for your help ! :-)

I think this might be a ticket in itself. If I send a PGP signed email to someone who then responds to me, there should ideally not be issues with it - although I think it would be important to separate which parts are signed and which are not.

header of mail forwarded. looks like it says utf-8. either way, it does work with the right key.

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.

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 ;-)

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.

Here is my understanding.

I'm looking at my personal Inbox on both computers.
I received the encrypted mails, before I connected computer B with my Account
And yes, I'm using an exchange connection.

Thanks for the details. I tried to reproduce it but again for me it works. Still I give this high priority as this can be a blocker in deploying GpgOL and we should fix it for the next release.

I have additionally the problem, that signed and encrypted S/MIMI messages are handled by GPGOL even if S/MIME support is disabled.

Gpg4win-3.1.3 was released.

Gpg4win-3.1.3 was released. This issue can be closed. Hurray!

Gpg4win-3.1.3 was released.

Gpg4win-3.1.3 was released.

Gpg4win-3.1.3 was released.

Closing.

Gpg4win-3.1.3 was released.

Gpg4win-3.1.3 was released

By grabbing I guess you mean that the cursor / keyboard input is automatically focused on the input field? I also noticed that this sometimes does not work well.

I can see MDC packet of 22-byte (which starts by 0xd3 0x14, and then 20-byte SHA-1 hash), when SEIP data packet is decrypted.
I don't see your situation.
How about with no compression (-z 0)? I mean, compression is not applied to MDC packet.