Should gpg try to connect to TCP/993?

[Bjarni Runar Einarsson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello!

Mikhail Morfikov <mmorfikov at gmail.com> wrote:
> Let's assume you are right, and it's because of the way the
> linux works.
> 
> When I clear the conntrack table, the following messages appear
[...]
> So it's an ACK packet (possibly one per already opened
> connection, since src ports differ), and not SYN. So it's not a
> new connection for sure.
[...]
> But in the case of gpg,
> there's no entry that would match anything that was printed
> above. So will this match to your idea?

I think yes, it does. The assumption here is that gpg inherits
the file descriptor after the connection is opened - so the SYN
is already sent and recorded as having come from Thunderbird.

The other assumption is that the firewalling systems are confused
about which process owns the packets, because after the
fork()/exec() there are actually two possibilities. Without
keeping expensive historic state about which process *created*
the connection, it's impossible for the kernel to know which is
the owner and some connections will get misreported.

All pretty plausible, no?

> > 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.

> > Since gpg doesn't actually know anything about these connections,
> > it likely won't close them, they'll stay open (potentially even
> > after Thunderbird has closed them, although that doesn't match
> > all the symptoms you've described).
> So what doesn't match the symptoms I've described? Maybe I have
> to pay attention to certain things, and than it will match.

Since (I think) Enigmail's gpg processes are usually short-lived,
you're unlikely to see this happen, and if it does it's likely to
be harmless. If the gpg processes were long-lived, it could over
time lead to resource exhaustion (running out of file descriptors
or RAM).

The symptoms that didn't match this, was that Thunderbird was
unable to download mail. If this was *only* happening with
connections that Thunderbird thought it had closed, then your
firewall rules wouldn't have impacted TB's operations.

Again, I'll stress that this is all educated guesswork. But the
symptoms match. I've created bugs like this myself in the past.
Of course, maybe GnuPG does like to connect to port 993. I
haven't ruled that out, but if that were the case, you'd probably
have seen SYN packets in your logs. :-D

 - Bjarni

- -- 
PageKite.net lets your personal computer be part of the web

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEETBSz4pzXkOHlSFMhjgA3FgDPlJEFAl2wq2QACgkQjgA3FgDP
lJE3KAgAtVKIkBlAXRXhtvsuWvPUFoygc/LF7ice2PWKbBada8yIiY3U0F8YtbSJ
bmtm+bqPhPijBuAH8O0RdGkFQsvyUFSYzvXKE92Tb6jZF5NEdOktVkIRbwurNOAS
0MreNosHaV9wPx5mm1DtY5UkDF9ccZzdQXdXRGvoMz5uKBdRgxtHaaBWS1+0pwey
VsAqmjeSB8UOdJDpnqIXRxxyoZ7Ti/Aru4KweKoYVnIac39fFg2GRY3mRD0D0pIL
nI+Znnm0nAi64wLQ6/hVEJ2175TN6g/XgRtCCPyjytmrFrIMnOwB6t+ZmSWADUH9
QzQpKFwoW1mC/+/7aDT0unQlUtDGDg==
=j1yU
-----END PGP SIGNATURE-----