On Sun, Jan 12 2020, Matthieu Herrb <[email protected]> wrote: > On Sun, Jan 12, 2020 at 02:59:46PM +0100, Benjamin Baier wrote: >> >> Here is my status on this. >> >> Claws-mail 3.17.4p2 has the backout diff so all the testing below was done >> with >> claws-mail 3.17.4p1. >> >> Following the advise from Thomas Dickey i compiled libXmu with >> CONFIGURE_ARGS+= --disable-tcp-transport >> which sets #undef TCPCONN >> which is only used once in libXmu/src/CvtStdSel.c where now the offending >> code >> is disabled. So this option only affects Copy&Paste actions. > > Yes that prevents xterm from doing DNS resolution if asked for the IP > address of the selection owner. >> >> Everything fixed, everything still works with this setting. >> >> Copy from | Paste into | Result >> ----------------------------------------------- >> local xterm | claws-mail | OK >> local xterm | ssh -XY ... xterm | OK >> ssh -XY ... xterm | claws-mail | OK >> ssh -XY ... xterm | local xterm | OK >> >> So I will be running with the --disable-tcp-transport flag and see if I get >> other misbehaviour, but i suspect not. > > Apparently claws-mail, patched to accept image pastes does the > IP_ADDRESS query for nothing (and ignores the result). > >> >> Only one other consumer in base, which is xenocara/app/xlockmore. >> The only thing I'm worried about is the 200+ ports that have an libXmu >> dependency declared. > > No: it's not the consumers of XmuConvertStandardSelection() that > matter, The question is how other apps requsting the IP address of the > selection owner, and how they behave if this feature is removed from > Xmu it one way or the other. > > I guess, given that there there have been no other reports since the > introdution of the xterm(1) pledges that there are no or very few > applications that cares, but at least Gtk has implemented support for > this.
claws-mail requested all TARGETS advertized by the peer, and then looped over them. From a quick look there is no code specific to IP_ADDRESS in gtk+2. > The patch below tries to get an IP adress at startup (before any > pledge()) and caches it. That's a big price to pay for all applications using Xmu even though IP_ADDRESS may never be requested at runtime. If the hostname isn't in /etc/hosts DNS requests leak info (the hostname) and may slow down startup. I think that's wrong. > It's also possible to not add the constructor > and always return 127.0.0.1 when queried. If IP_ADDRESS is really needed by a client we'd better not lie. > And below the patch it the small test program I wrote to test how > various applications react to the different selection target > requests. > > Thoughts, oks ? I'm not ok with that approach, I think IP_ADDRESS should just go. Upstream doesn't seem to care much about it: https://bugs.freedesktop.org/show_bug.cgi?id=7611 Index: src/CvtStdSel.c =================================================================== RCS file: /d/cvs/xenocara/lib/libXmu/src/CvtStdSel.c,v retrieving revision 1.5 diff -u -p -p -u -r1.5 CvtStdSel.c --- src/CvtStdSel.c 28 Sep 2013 17:31:53 -0000 1.5 +++ src/CvtStdSel.c 11 Jan 2020 19:58:07 -0000 @@ -219,7 +219,7 @@ XmuConvertStandardSelection(Widget w, Ti *format = 8; return True; } -#if defined(TCPCONN) +#if defined(TCPCONN) //&& !defined(__OpenBSD__) if (*target == XA_IP_ADDRESS(d)) { char hostname[1024]; #ifdef XTHREADS_NEEDS_BYNAMEPARAMS @@ -307,7 +307,7 @@ XmuConvertStandardSelection(Widget w, Ti return True; } if (*target == XA_TARGETS(d)) { -#if defined(unix) +#if defined(unix) && !defined(__OpenBSD__) # define NUM_TARGETS 8 #else # define NUM_TARGETS 7 @@ -316,7 +316,9 @@ XmuConvertStandardSelection(Widget w, Ti int i = 0; std_targets[i++] = XA_TIMESTAMP(d); std_targets[i++] = XA_HOSTNAME(d); +#if !defined(__OpenBSD__) std_targets[i++] = XA_IP_ADDRESS(d); +#endif std_targets[i++] = XA_USER(d); std_targets[i++] = XA_CLASS(d); std_targets[i++] = XA_NAME(d); -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
