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

secmem routines are installed into gniibe/secmem branch.
Please note that it's only secmem routines, not malloc_secure.

Something like this was commited.

@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.

Well, the counterpart in gpg-agent is missing.

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?

By the attached test program I can confirm that the issue is solved.

Thanks for your comments, Stephan.

@aheinecke -- @smueller_chronox.de (author of the comment above) is Stephan Müller from atsec. Glad to see he seems ok with the proposal :)

Apologies for not having read all comments in this long thread. I was asked to comment on the patch, so here is my comment:

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.

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.