Hi,

with the latest changes, x2goclient will also run on Mac OS X 10.4. However, it will not be officially supported.

While x2go is generally "use at own risk", this one is "use at own risk and don't expect it to work properly."

Mac OS 10.4 is really old and unsupported even by Apple Inc. - not even with security updates.

The X11 server version bundled with 10.4 is also old and known to cause color problems. The X11 server is not meant to be updated by users in an easy and convenient way, or at all. X11 server releases for 10.5 can't be installed on 10.4.

Generally, starting an X11 application on 10.5 and higher will automatically launch the X11 server, if installed. This is due to structural changes in X11 integration implemented by Apple. On user login, an environmental variable called "$DISPLAY" is set and points to a UNIX socket monitored by the system daemon launchd. Whenever something tries to connect to this socket, the X11 binary is started.

This is not true for 10.4. On those systems, $DISPLAY is not automatically set and thus not available from the initial environment.

Starting X11 manually will spawn an xterm instance with this env. var. set. From this terminal application, other X11 applications could be launched just fine. However, non-child-processes still won't be able to communicate with the X11 server.

Also, there is no easy way to know if an X11 server is already running, and if it is, on which socket it's listening. My first idea was to implement some kind of autodetection/probing for X11 sockets and connect to them in order to determine whether they work or not. This said, at the same time valid security concerns were raised. Connecting to unknown sockets is potentially dangerous, and as the place those sockets are placed in is world-writable, anyone could put a prepared socket in there. For obvious reasons, I dismissed this idea.

Instead, I am now probing for a free display number and launching a separate X11 server instance whenever it is needed. Existing instances/sockets won't be re-used. This works fine, but obviously means that for every session a separate X11 server is launched and the user has to clean up those instances by hand (luckily each instance is shown as a normal application, so terminating those processes is not a problem at all.)

This seemed like the safest, fastest and easiest way to go.

Another way would be searching the currently running processes for X11 and examining the open files to find the socket, but this is way more complicated and not really worth the effort.

Aside from that, the X11 server is listening for TCP connections by default and there is no way/option to turn this behavior off, unlike in 10.5 and higher. While the X protocol does have some security model based on the authcookies, I'm really not too happy with exposing my X11 server to the whole network. At the very least, evil users could crash the server. Evil geniuses may even obtain root access in some way or another, especially with such an old and unmaintained version.

I've only been rudimentary testing remote sessions, but as far as I see, opening a new session, resuming and terminating works, at least with xterm as the remote application. I can't really test this more thoroughly, as my test system seems somewhat borked in X11 mode and is pressing "escape" after every key press. This is also happening in local xterm sessions for me, but I haven't found any information to this kind of misbehavior. Not being able to test this stuff is just another good reason to not support it officially.

This said, I guess I will publish new versions for 10.4 from time to time, for those users who are bound to it and brave enough to use it. But again, if it opens up anything visible, this is far more than you should even expect.

Best regards,

Mihai