[jerf]

It sounds like these errors predate X.Org qua X.Org. A lot of people have had some responsibility for this code at some point without noticing this.

Bear in mind X11 is pretty old, and these are some of the oldest libraries in the whole X constellation. That isn't an "excuse", but it's a reason.

[anonymouz]

And when the stuff was originally written, this was probably not considered to be a "security boundary" in the sense that the client will have higher privileges than the server. As the email notes, this happens rather rarely.

[lawnchair_larry]

Actually it was more common back then. Remember, "client" and "server" are backwards in the context of X. A "thin client" actually runs an X Server, and you remotely launch an xterm on the central server as an "x client", exported to your display.

However, as the email states, this only gets you the same access your user already had on the remote system, unless it's a setuid program. The canonical example and only one I can think of off the top of my head is xscreensaver or xlock. There are now GUI versions of su/sudo that would also be targets, but I don't think variants of these were used back when this topology was common.

[mprovost]

This is a good read about how jwz coded xscreensaver to be secure and the pitfalls of using GUI toolkits:

http://www.jwz.org/xscreensaver/toolkits.html

[mikeash]

I'd wager that many of these errors predate many of the commenters on this site. X is pretty old.

[MostAwesomeDude]

I was an X.org hacker a few years ago. X predates me.

X is (very) roughly the size of GCC. It's massive and it's nearly entirely C, with a few modern Python scripts to generate some of the more onerous tables. There are many old libraries, and they are horrifying. Eldritch, cyclopean, etc.

[rjsw]

A lot of the libraries listed are relatively new though.

[jevinskie]

An macros to rival, but not beat (they can't be!!!) Perl's!