There is no Enigmail for TB anymore.

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:
https://www.enigmail.net/index.php/en/home/news/71-2021-08-31-end-of-support-for-thunderbird

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.

Dear aheinecke,

Hi Adam,

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.

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.

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

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.

man dirmngr

Hi Andre

Hi, Werner.
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.

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

I tried to reproduce this with current GpgOL and it just worked. Even if I connected Enigmail to Exchange (Outlook.com).

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.

Dear Andre

This means that the MAPI to MIME conversion did not happen.

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.

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.

I now got something that works on MIME mail rENIG1cde116d7a3dadcd8ddd45ee1259cc62a4de9cd3. This patch leaves the original mail & decrypted version in the folder on the IMAP server.

I just tried it w/ the current master and it works. First, it displays the upload dialog and progress bar. After a second or two a message pops up that the upload was successful and I'll get a confirmation request my mail later. Clicking Ok on the message hides both dialogs.

I'll look into it

Right. Now I see the wks page in advanced setup. In basic setup there is only a minimal wks info page. WKS confirmation email is send in both cases. Good.

It's only displayed in the advanced mode. Also, what do you mean w/ no response?

Sorry... I tested the current nightly build from today. There is no WKS upload dialog in Enigmail's setup wizard (default setup). And my manually upload test (via context menu from Engimails key management) gets no response...
@kai Can you please check the current state in upstream. Thanks.

it is: 073bc2b01d1f60c85ba4206f3ff37bc618b4a4a9

@kai Can you say when your patch will be upstream? We wait for a public nightly build of enigmail with all your wkd/wks changes.

IMO this would be the first step to have the options we need for EasyGPG.

Kai, as you can see from

Ok. Lets put this problem back until we have a possibility to encrypt through filters so that can maybe enable this just for some kind of reenecrypt workflow.

So, I had a look at the code in decrypt-data.c and proc_packets. I understand that getting gpg output the resulting in human readable way isn't possible w/o changing a lot of code.

OK, thanks. I just tied it on the console and adding --unwrap causes gpg to output the PGP packet that was encrypted. I guess this is intended but from my perspective this isn't a small change. Before a user could read his permanently decrypted mail w/o any tools, now he needs gpg the parse and display the literal data packet.

Indeed it's unwrap and not nowrap. Sorry.

Revisited patch

You sure about that? The --nowrap doesn't seem to exist. The manpage doesn't mention it and running gpg2 with it outputs gpg: invalid option "--nowrap".

This is usually helpful: https://pypi.python.org/pypi/six

Patch submitted

Patch was accepted into Enigmail: 5e39a44f17f9ef45fd04d3069ba5d6f3092e28d6

Patch improved & submitted

Patch submitted

Hello. Please note that this is a bug tracker and not a support forum. Nevertheless, let's investigate.

Patch was accepted.