Should gpg try to connect to TCP/993?

Jay Sulzberger jays at
Fri Oct 25 18:23:29 CEST 2019

On Thu, 24 Oct 2019, Patrick Brunschwig <patrick at> wrote:

> Bjarni Runar Einarsson wrote on 23.10.2019 21:35:
> [...]
>>>> Each active TCP/IP connection has an open file descriptor. So, if
>>>> Enigmail's gpg launcher hasn't taken care to close unneeded file
>>>> descriptors after fork() and before exec()
>> [...]
>>> Should the `Enigmail's gpg launcher` take care of that? Maybe
>>> is a bug or something?
>> IMO, yes, if this is what is going on it is almost certainly a
>> bug. Whatever code is calling exec() should be closing file
>> descriptors first. Not doing so can lead to all sorts of wasted
>> resources and even deadlocks if processes depend on file
>> descriptors getting properly closed in a timely fashion.
> Your guess is perfectly right, that's exactly what happens. Enigmail
> uses a standard library provided by Mozilla for add-ons to execute
> processes. Earlier versions of the library did close all file
> descriptors correctly. But the library is written in JavaScript, and
> closing all file descriptors could sometimes lead to Thunderbird/Firefox
> crashes. Therefore that part has been disabled.
> It's therefore not surprising to see such open connections from gpg
> processes, but I don't consider this bad.
> -Patrick

Is the following correct:

   When I use gpg to just encrypt or decrypt a file already on my
   computer/OS's file system, then gpg does not open any formal
   channels of communication going outside my computer/OS.


> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at

More information about the Gnupg-users mailing list