-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello!
Mikhail Morfikov <mmorfi...@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-----
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users