Sep 29 2021
Looks like this should be handled in the Enigmail tracker, if being handled at all.
Hi @Lambd0x, with Thunderbird having migrated to a different main OpenPGP implementation and Enigmail not supporting old thunderbirds version anymore (in two days https://www.enigmail.net/index.php/en/home/news/71-2021-08-31-end-of-support-for-thunderbird) and new GnuPG versions over the last three years. Do you still have problems?
In my understanding, it should be possible to wait for the gpg command pipe from a different process and then terminate the connection on a timeout, kllling the process eventually. So the Enigmail side could implement something. These days I'm not sure what Enigmail uses for OpenPGP support. Thunderbird has moved on to a different implementation and Enigmail stops supporting Thunderbird 68 in two days https://www.enigmail.net/index.php/en/home/news/71-2021-08-31-end-of-support-for-thunderbird
Enigmail's support for Thunderbird 68 ends in two days:
Aug 13 2021
May 29 2019
Jan 25 2019
I know, I helped implementing that. Patrick changed it.
Enigmail used to use gpg-wks-client. @kai implemented it back then and we had a milestone meeting to show that it works with posteo.
Oct 18 2018
Oct 17 2018
Apr 19 2018
I have a patch for this, but its not so good and we did not see a chance to get it upstream. For even medium sized mail accounts it already took to long as Enigmail (or better the Thunderbird Addon API) is prohibitively slow.
Let's use the new issue as the problem is described completely there and it makes it more clear.
This was done.
No problem :).
Currently I cannot access this newer pinentry release.
My .bashrc is almost default, hence it doesn't have the line you requested.
Apr 18 2018
I already created a new issue for this in the new version of gpg4win (v3.1.0) with GpgOL v2.1.0. This is the issue: T3917.
Apr 17 2018
Do you have a chance to try with a more recent pinentry; ie. 1.10 ? This may give better diagnostics.
Another thing I would suggest is to debug the invocation of pinentry: Put
Apr 11 2018
You are right in that enigmail uses no-auto-check-trustdb
As far as I understand your comment there is already a timeout of 15s per connection. But as you wrote, it doesn't fit all cases. In my case, gpg.exe just stayed open indefinitely.
Mar 1 2018
Jan 7 2018
My OS has everything compiled from sources obtained from devs as they release them. Funtoo Linux is a derivative of Gentoo Linux.
Hence, the default behavior of the software is not altered except when removed some of its features, but I've installed gnupg without alteration.
Jan 6 2018
This looks more like an Enigmail bug. In particular the manual start of gpg-agent as described in the workaround is useless because gpg-agent is always started as needed. I don't know your OS and thus I do not know whether gpg-agent is used in --supervised mode, as in Debian, or in the default way. What does
Dec 7 2017
I tried to reproduce this with current GpgOL and it just worked. Even if I connected Enigmail to Exchange (Outlook.com).
Dec 3 2017
Nov 28 2017
Nov 13 2017
Thank you very much. Both the signed only and the encrypted mail are fully valid for me (checked on the IMAP server and with kmail) and don't contain any references to gpgolXXX.dat. This means they were correctly converted to valid PGP/MIME Mails.
This means that the MAPI to MIME conversion did not happen.
Oct 16 2017
You could try to use NO-MIME (or PGP/INLINE) instead of the OpenPGP/MIME standard. You can change the way of packaging your encrypted content in the GpgOL Addin Options.
Sep 26 2017
Sep 4 2017
Sep 1 2017
Ok, I implemented this for Inline messages. The resulting armored literal data packet is encrypted as PGP/MIME message. I'm not sure this is what we want.
Implemented --unwrap stuff, too.