On Thu, 24 Oct 2019, Patrick Brunschwig <[email protected]> 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.
oo--JS.
_______________________________________________
Gnupg-users mailing list
[email protected]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
_______________________________________________
Gnupg-users mailing list
[email protected]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
