While I can't reproduce it myself (because I probably don't have the right mails in my exchange) looking at your log I think that I see the problem there might be an issue with the error handling in openProperty. So for old mails the openProperty probably fails because we have exchange online for that and the property is not yet available in Outlook and then the error is not correctly handled and it crashes.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Nov 19 2018
This should be fixed in commit fd34415bdd57332424bd5a98d279e2331678a2fb
3.1.5 was released on 13.11.2018
Was released with 3.1.5
Was released with 3.1.5
3.1.5 is released with this change.
This should work with Gpg4win-3.1.5
Nov 18 2018
hm, adding: --with-tar=tar to my invocation of ./configure appears to leave gpg-zip with:
My problem isn´t linked to forwarding encrypted e-mails and / or attachments. It occurs by ordinary PGP mails WITH attachments which are not ASCII format. Encrypted e-mails without attachmoments or in ASCII format will be delivered.
Nov 17 2018
oh! i suppose i underestimated the severity of it. apologies!
Form my understanding this needs to be fixed urgently.
Nov 16 2018
So for me, sending encrypted attachments by selecting them from disk works fine for attachments. up to ~200k (I haven't tried larger ones).
Pretty obvious. Thanks.
Nov 15 2018
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.
Nov 14 2018
"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.