Hmmm

You seem to accept it. So Normal Prio and assigned to you :-p

Just as a note: I think the main selling point of GnuPG is that its stable. We care about backwards compatibility and we (are || want to be) rock solid. Even if there is a rare race. With millions of installations, that race will happen regularly. So I really would like us to get all this fixed without losing to much performance by locking to much.

Happens though. With the test invocation above there is only one key in the keyring.

1.9.0-beta68

I have a warning already in my working copy.

Well, it should not happen if you always use the same key.

There is indeed a race condition between the passphrase cache and the pinentry invocation. There is even a comment on this somewhere in the code. The problem is that we would need to lock almost everything to avoid this rare condition.

Which Libgcrypt version?

Forgot to mention. run-threaded is a new test tool in GPGME.

I fixed the gpgrelay link.

"Miranda ICQ [Unix] CHAT" also doesn't work. Maybe it would be a good idea to check all of them via script or something like that...

i don't see any active use of it in all of debian: https://codesearch.debian.net/search?q=gpg-zip

Thank you very much for the quick response and try-out in detail!

Bug or user error?

It is useful if you often log out and in, for example using remote remote ssh session. If you don't like it, you should "gpgconf --kill gpg-agent" in your .bash_logout. ~/.xsession or whatever your system uses. Instead of --kill you can also use --reload so that the passphrase cache is flushed immediately and not only at the end of the TTL.

Thanks. Just pushed the change to master.

Let me also note that gpg-zip was not installed since 2006 due a conflict with gpg1.

gpg-zip is deprecated because we have replaced it by gpgtar. Given that you have a workaround for Debian I tend to close this bug as WONTFIX.

Thanks for reporting your problem. We are highly interested in any crash. But please note that our minimum supported Exchange Version is 2010 because 2007 has reached end of life in april 2017. So I cannot test with that Server.

The corresponding fix can be found here: https://github.com/smuellerDD/jitterentropy-library/commit/9048af7f06fc1488904f54852e0a2f8da45a4745

Please note that this issue in Jitterentropy has been already fixed by upstream: http://www.chronox.de/jent.html

Default settings in Outlook are as following: (i) S/MIME encryption disabled, (ii) S/MIME signature enabled.

I'm lowering the priority as this does not appear to be a general problem. Otherwise more people would have reported it and I can't reproduce it yet.

Strange, even if I take that codepath it just works for me. Just to clarify you are also saying that if you enable "Block Outlook during encryption" it works for you? Which would be doubly strange because in your log I can see that the attachment is detected and due to T4131 we currently still always block Outlook when we detect an attachment.