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

I also have these seldom freezings. Any log / tracker I could activate that would help you?

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:

Removed the global trust model flag.

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/

To avoid a traumatic change to Gpg4win I do not want to change the default trust-model globally. Changing it on demand will provide the freedom to "port" each application using GnuPG to the new trust-model independently.

Changes are included to master branch of gnupg.

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.