X.Org Server 1.19.5 Released To Fix Another Handful Of Security Vulnerabilities

[jpg44]

I'd hate to break it to people here but Wayland has potential security problems that eclipse X due to the reliance on direct rendering in applications, and the lack of indirect (network transparent) stream based protocol like X has with with core protocol and GLX. Direct rendering maps video RAM and video hardware interfaces into the applications. This is basically asking for trouble should there be a security problem in the video hardware.

So your giving a much larger body of more questionable application code direct contact with video hardware, whereas the X server traditionally only touched video hardware. With X being a userspace process, it would have been possible to constrain X with a security profile using something like apparmor, with fine grained security controls that give it access just to the hardware resources it needs.

All large C programs have security problems. The problem is C, not X, and speed-fanatics who think that everything needs to be written in dangerous C code for that little bit extra speed. Wayland also is written in C, do not assume it does not have the same problems. Wayland and X.org were written by the same people.

Also, Wayland does reinvent the wheel. There is no point in it. Performance profiling has shown virtually no speed improvement of Wayland over X. Everything Wayland was sold on can be done with double buffering and verticial synchronization extensions to X and by the already underway work to port X.org to an OpenGL/DRI/EGL backend itself. This would fix visual artifacts.

As for legacy features in X, the sensible thing for that would be to have a runtime flag to disable those features and break out legacy support code into runtime loaded libraries for this purpose. Thus if you dont use an app that needs the legacy feature, you dont have to load the code that it uses. These legacy features are not great in number, usually some 2D graphics primatives and some older font APIs.

Its important to note that the problem with the older graphics primatives was they were not powerful enough, most apps now need a rich set of 3D graphics operation. The traditional X protocol provides far, far too few primatives, OpenGL apps need a much richer set of primatives. Wayland apps do use a vast number of OpenGL primatives, which have to make it to the video adapter, it doesnt provide the option of isolating apps from the video hardware however, due to the lack of an indirect protocol.

The rest of the X.org code base can be fuzz tested and scanned with security tools to spot possible problems.

So, one by one, all of the arguments for Wayland can be debunked.

[aufkrawall]

Spread the word that Xorg doesn't have to run as root, many people don't know that because their login manager doesn't tell them and limits them to running it as root (except GDM).

[uid313]

X.Org is like swizz cheese. Full of holes.

[jpg44]

Because there is only so much you can do by bolting more modern stuff on an obsolete core.
Xorg has large amounts of ridiculously obsolete and more or less unmaintained crap inside that is mandated by the (also obsolete) X11 protocol, and it can't just drop it.

For example, In Xorg all applications can snoop all you see on screen and all you write on your keyboard, by design (as back then in the stone age of computing security was not an issue).

Wayland is basically the modern parts of Xorg being split off and run on their own, it reuses most of the driver infrastructure and other reusable parts where possible.

This is not hard coded the core design of the protocol to lock out security features. It is completely feasible to design an extension to implement security policy profiles to address this. What could have fixed this would be a security extension to control which applications if any should be privileged to access which windows. Normal applications can then be constrained to their own window and its children. Some of this was addressed by Xsecurity extension.

[bridgman]

X.Org is like swizz cheese. Full of holes.

There should be a snappy retort possible here since most Swiss cheese does not actually have holes... maybe someone else can come up with it.

[JPerez]

Blaming a programming language for bad design (outdated in this case) or using poor programming techniques means that he can't understand that language, even in Python and Rust bad programming happens.

Instead of blaming on the language why not to improve the design? maybe opening parts to be implemented in other languages (shared libraries exists for that reason)... oh right, people gave up on x11, but still works better than whatever is available that they are stuck with it for some more time.

Also, Wayland is a modern design, and weston is made in C.

[Marc Driftmeyer]

I'm more interested wrt OS X WindowServer [as an alum] and Quartz/Quartz Extreme where Wayland/Weston fit in relation.

[caligula]

Blaming a programming language for bad design (outdated in this case) or using poor programming techniques means that he can't understand that language, even in Python and Rust bad programming happens.

Instead of blaming on the language why not to improve the design?

You're basically arguing that the features that were designed to improve reliability won't help, yet there's tons of data that shows otherwise. You could also argue that driving etiquette won't work or that gun control laws don't help. Yet they do. Language features can't fix everything. If you have a problem with alcohol or design shitty programs, there's little a compiler can do. But it sure can fix problems in the scope of programming language related issues.

Consider concurrency and parallelism. Would you really claim that some ridiculous scripting language that's limited to a single thread and GIL would beat Rust when comes to reliable, high performance programming. How about educating yourself a bit about programming languages? Heck, I don't even know where to start.

Some modern day toy languages don't even check for typos in variable references. Basically none of the scripting languages that don't transform the script text to some byte code before execution. Imagine running a 100 000 line bash script. Suddenly it crashes due to a typo. This amateurish error can never ever happen with C. Imagine, such a crappy piece of 1970s technology (= C), yet it beats Bash hands down. Now use your imagination and try to see what kind of leap Rust could be when C is the starting point. That's right, the computer scientists DID invent something new after 1970. Might sound unbelievable, but it's true. Computer science didn't just suddenly stop in 1970.

[leipero]

X works fine for me, I don't know much about programming languages, but I do have trust to this guy that he knows what he's talking about.

https://www.youtube.com/watch?v=ci1PJexnfNE

[jhenke]

Certainly C is not a good language any more by today's standards. It's main benefit is that it is simple. It is easy to be mapped to machine instructions and thus you do not need a lot to run a C application (in fact you only need an initialized stack pointer for a free standing C application to run). So it has it's benefits when you cannot depend on a sophisticated environment to exist for you code (e.g. early kernel runtime, embedded).
So we clearly need to get rid of C code in application code that does not need one of C's advantages.

But C++ on the other hand is still very well suited for modern application development, if you use a modern version (C++ 11 or newer). Many of C's common source of problems do not apply to C++ if you stick to well accepted coding practices (e.g. do not manually manage memory, use smart pointers, RAII). In fact even pre-C++11 already offered langauge features to address many of C's sort comings (e.g. destructors to guarantee release of acquired resources).

We do not need hip new languages to address these problems. People just need to understand what they are doing and use their tools correctly. Of course I know that won't change anything, because there will always be people writing bad code and use any language in a way that causes bugs, for one of many reasons (time pressure, lack of knowledge, plain mistake, etc...)
But Rust or any other new language is not the solution, but understanding what you are doing and using the right tool are.