X server does not have an option to specify which address to listen on for TCP connections

[ornx]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, May 11, 2020 8:18 AM, Attila Kinali <attila at kinali.ch> wrote:

> On Mon, 11 May 2020 01:41:11 +0000
> ornx ornx at protonmail.com wrote:
>
> > why?
>
> Probably because it has never come up? X was intended to be used
> on desktops, which, usually, had only a single network interface.
> In case restrictions were needed, xauth/xhost provided the means
> to limit access. These days TCP is even disabled on most distros
> by default, for security reasons.
>
> Attila Kinali

>X was intended to be used on desktops
is this really true? my understanding is that X has always had a networked client/server model

my use case is that i need X to use TCP so that i can intercept its traffic with wireshark for debugging purposes, but i only need this server accessible on the loopback interface and specifically do not want it listening on any other interfaces for basic security reasons of not giving programs any network resources that they do not strictly need. using xauth/xhost seems insufficient for this purpose, because i already know that i do not want any external traffic to be able to access the server, why do i need to decide this at the application level instead of specifying it at the network level? what if there is a bug in the X authentication mechanism?
the workaround for this is also rather inconvenient and requires specialized knowledge, to prevent external network traffic from reaching X now involves writing firewall rules instead of merely setting a flag limiting the interfaces that X is listening on. it is also at odds with normal networking application behavior, i have actually never encountered a program before that listened on a port but did not allow to specify the listening interface

is the reason why this behavior has not been implemented in Xorg simply because nobody has thought to add it, or is there a specific reason that it was left out? if someone provided a patch implementing this behavior, would it have a chance of being merged?