Wonder how these play out against the https://github.com/X11Libre/xserver base, would be interesting to hear from that end as to how these things are handled. My understanding is that they address any sec issues that arise on x.org but it would be fascinating if the issues are already mitigated since XLibre updated their xserver port with 1000s of issues that were never addressed on the x.org side of things.
On their github you can see all three changes identical to x.org's happened on October 28th (same day as the advisory). So, they were not already fixed, but the fixes were applied immediately.
The problem with XLibre is political, not technical. When they came out they made a big deal of being the anti-woke free-speech no-vaccine-mandate alternative to woke cancel-culture Xorg, which instantly ruined their reputation before it even began.
Your comment is missing how the project initially presented itself and the main dev being an anti-vaxxer certainly puts those words into a bad context.
In essence, that's not a lot different different from the section I linked to in the current version. But I appreciate that the dev could have curbed his emotions while writing the README.md, if for no other reason, then to cater to public appearance.
As for the lead dev's stance on mandatory vaccination, that should not play a role in assessing the need for and the technical merits of the project. Attempting to cancel a project based on such personal views of its maintainers is exactly my issue here.
I can't possibly be the victim of anything as long as you stick to the party line. After all, isn't doing its bidding new morality, and isn't its opposition nothing but evil ghouls? </sarcasm>
If I really hated people, perhaps I would suggest to troubled ones that hating their own body to the point of mutilating it is the solution to their problems
That's the fork where the primary cause was to be "anti-woke", right? Honestly it seemed like it was just because that one guy was a little unbalanced, and he happened to be channeling that energy into an X server fork.
which mattered because everyone pulls from master, because xorg stopped doing proper releases. it's certainly something to bear in mind if you intend to run xlibre though.
I don't think "everyone" pulls from master - "everyone" run the distributions, and they always pin to the specific git commits. Only people who run xorg master are the ones who want bleeding edge, and those would be using it no matter release or not.
And it's not like metux will suddenly become more careful just because he does not have to worry about other anymore. If anything, I expect there to be much faster changes and much more breaking things... Here is a great quote [0]
> @metux that you've had to fix this bug twice (!1844 (merged), !1845 (merged)) shows a lack of attention and care. This was a known regression, with clear reproduction steps, and at first glance, it does not look like you tested your PR at all.
> And that goes in general; I really haven't seen the level of care and attention I would expect to see in these patches; several of them had obvious buffer overflow issues that would have easily been caught if tested.
I'm not even trying to say they shouldn't have kicked him out, just that it had nothing to do with wokeness, and more to do with philosophy of how the project should be run.
An X server code base is such a niche topic, do you honestly think Xorg or any other project is capable of being a "woke" X server? It sounds more like this one guy has some issues and is trying to blame something he is already bitter about.
Good that people are finding and fixing these, but basically allowing any untrusted client to talk to your X server is asking for trouble just by design. (Bonus points if you have any Tcl/Tk apps running, where you can simply transmit commands for the program to run via the X server.)
There are plenty of setups where the X server runs at higher privileges/on a different host than the (partially trusted) application that might exploit the X server. This is a classic elevation of privileges vulnerability in those setups.
X11's practical absence of any security mechanisms for user sessions means you should probably not run any kind of low-trust UI program anyway, as there is no prevention of keystroke injection or screen recording, but that's a design flaw that will never be solved. That doesn't mean that EoP style attacks like these should be ignored or underestimated, though.
Why do people keep persisting this myth? X11 has authentication. You can either rely on filesystem permissions, or a shared secret. The same way thousands of other network servers work.
Any program you run on a computer (especially a Linux computer, which lacks modern OS security measures and has constant privesc kernel holes) exposes you to security flaws. There has yet to be any computer system designed that a hacker can't break out of. If you intentionally download and execute a program, you are rolling the dice, regardless of what the software is.
What's insane about all these discussions is that NOBODY IS HACKING X SERVERS. There's a thousand other kinds of software on Linux that there is real malware for. But nobody is trying to hijack your X11 session. This imagined threat is a red herring designed to bolster the argument for Wayland's horrible designs.
> What's insane about all these discussions is that NOBODY IS HACKING X SERVERS
I knew someone who worked for a small loan type company. Passwords were stored in plain text, but even worse, the login form didn't actually check the password at all, it created valid sessions as long as you provided a valid user name.
When he informed his boss that was very bad, his boss simply said that nobody has abused it, and nobody would, don't waste time changing it.
The point, of course, is why would you wait until people are getting hacked to address a known vulnerability?
Sure, there are others, and they should be closed too, and they are when they are found. It makes no sense whatsoever to leave one open just because.
I think the point being made isn't that X.org shouldn't fix their vulnerabilities. It's that there's always a huge amount of discussion about vulnerabilities and security models when one is found in the display server or the window manager when actual exploitation doesn't seem to be particularly high.
Many distros, if not most distros, disable port 6000+ listening for X.org by default. So, immediately, it's not a remote exploit. OK, so it's scope is already limited to local escalation attacks. Looking at the CVE, the only reason it's high is because (a) X.org is everywhere, (b) you don't need to interact with [another] user to exploit it, and (c) it's not particularly complex to exploit.
That is bad, but it's also behind most of the other security, rather than bypassing essentially all of it like Heartbleed or Shellshock.
So, either I have to have X forwarding turned back on, or have people with SSH access to a server that is also running X. Both of those seem like uncommon situations. You probably shouldn't be running X or permitting X to be started unless you need X forwarding, and X forwarding is a pretty odd requirement given modern application design being so web-browser-focused.
So it might be CVE High 7+ if you're on a system where it's possible to exploit it. But it feels like you shouldn't often be on a system configured in a way where it could be exploited in spite of the prevalence of X.
Essentially: This isn't a rehash of the libXfont problem.
This is because Wayland wants to differentiate itself from X on security. Wayland has to show it's more secure than X - as part of that, Wayland has to show that X is insecure.
No, wayland already differentiates itsself from X11 because X is a tool for graphical network terminals and Wayland is a tool for single machine rendering.
X11 is a mountain of tech debt that almost nobody wants to maintain.
Wayland is what you get when you decide to start a space program because, let's be honest, the electrical gremlins in your 1983 Mercedes 560SL are beyond properly fixing, and the kids still need to get to school
But there is no vulnerability at all. For a normally configured X server with TCP listening, the server should be configured to use MIT magic cookies for authentication. This randomly-generated string is needed to authenticate and establish a connection to the X server. You can use the xauth command to manually configure it as needed.
It's the equivalent of HTTP Digest authentication, and nobody's demanding that we rewrite HTTP because Digest authentication. It's in plaintext, so you shouldn't use it; but if a hacker doesn't know the secret, they can't get in.
> But there is no vulnerability at all. For a normally configured X server with TCP listening, the server should be configured to use MIT magic cookies for authentication.
This feels like you're not understanding why something is called a vulnerability, how they're defined, or why they get rated the way they do. "It's not vulnerable in a best practice configuration," is not the same thing as, "there is no vulnerability." That is incorrect and misleading, and I think you're conflating risk and severity.
The definition used for a vulnerability is [0]: "A weakness in the computational logic (e.g., code) found in software and hardware components that, when exploited, results in a negative impact to confidentiality, integrity, or availability." (emphasis mine)
The CVSS score is not a measure of risk. It is a measure based on the qualities of the defect that was identified and how widespread the software is. A higher CVSS score is associated with higher risk, but your risk is going to vary based on your configuration.
All they did was go to the calculator[1], plug in the answers that best fit the definitions provided for what those areas and responses mean (e.g., CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:H for CVE-2025-62229), and they get that 7.3 score [2].
Digest as I understand it is a weak authentication protocol, it doesn't mean it is implemented with known vulnerabilities.
I distinguish vulnerability from weak. The weakness is not necessarily intended, but the question is, does it do what it is supposed to do. Or is there a known bug: non intended possible exploit, that would make it a vulnerability.
If it isn't known then it doesn't exist. But we can assume all software do have bugs.
Digest is part of the http protocol, if the protocol is found to have vulnerability I can imagine it would be dropped and be rewritten. The digest part, not the entire http protocol.
A hacker may not have the password, but manages to brute forces it. Is that a digest vulnerability or does it fall onto the application to integrate some preventing brute force authentication measures?
My take is digest doesn't pretend to prevent brute force attacks.
Some may not agree with that logic, but since about everything is made of a combination of vectors, and that each typically has some weakness, all you get is a balance between usability, cost, and security.
We can make the case for your typical cryptographic signature, or encryption algorithm. ECDSA standing as well respected, solid cipher. Is it vulnerable? It is vulnerable to the potential power of machines we may build in times to come. Quantum or leaps ahead. Will it be vulnerable then? Yes but it isn't a vulnerability. We would then call ECDSA obsolete.
Digest is obsolete yes.
The interesting part about cryptographic methods is that we may know of some being obsolete ahead of time. So long as we can determine they can be brute forced. For now it isn't obsolete despite the existence of quantum resistant alternatives. Hacker news uses ECDSA for the exchange of keys between server and client, then encrypts all connections using another algorithm safe against quantum computers. Thanks. But beyond that, probably not.
Is X obsolete? Vulnerable? Seems like X developers themselves admit it is a vulnerability. They didn't know of the possible exploit. As to the severity? It's often subjective from my experience.
I don't dispute your anecdote but I think the point was: x11 has been around for decades, and these things just don't happen. And the reason is that there are much simpler and more effective ways to pwn a box than trying to screenshot an x session or trying to hook for key presses. So the vulnerability surface just isn't large enough.
That's not how this works. If you cannot prove conclusively that something is not the case ever, then you must accept that somewhere in the infinity of possibility it is.
I have seen this happen as well. A memory corruption vulnerability in popular software allows unpriv shellcode to reach out and drop a rootkit which loads a rat as a kernel module. Attacker has control. Several big problems.
cobaltstrike beacons blocked. Instead pierce nat with STUN to attacker proxy. Use socket activated VNC/RDP/X.
Why not just steal the sessions and local data? Remote services log access (ip, time, location), easily correlate and forensics would lead back. Local data encrypted at rest, hands on keyboard needed any way since recon incomplete. Are they planning to scan memory for ssh key unlocks or intercept ssh -sk key? This is big, noisy and take developer time. If you log in to a email this leave forensics and is a CFAA violation while risking FAANG security. Attacker needs to shoulder surf.
Most hack is install crypto mining or steal a password. Maybe it is ransom. How do you get 2fa code if you want access to sensitive information? How do you steal hardware keys? You can back door browser, MitB but it gets updated away and you lose access. back door anything and lose access or discovered.
This is not a advanced attacks but it is targeted attacks. People are saying x server never get hacked, but computers get hacked. with X11 the chain is Exploit -> Game over. with wayland you need to go farther.
It sounds like you're out of your depth in this conversation, Lieutenant. I have ambivalent feelings about X11, but they aren't relevant to the topic at hand.
0xbadcafebee said, "Why do people keep persisting this myth? X11 has authentication. ... What's insane about all these discussions is that NOBODY IS HACKING X SERVERS. There's a thousand other kinds of software on Linux that there is real malware for. But nobody is trying to hijack your X11 session. This imagined threat is a red herring ..." and then nurettin followed up by saying, "x11 has been around for decades, and these things just don't happen. And the reason is that there are much simpler and more effective ways to pwn a box than trying to screenshot an x session or trying to hook for key presses."
But in fact I have seen people gaining elevated privileges by "hijacking" X servers when the authentication was configured to be lax, and I've sometimes configured my own authentication to be lax (because configuring it properly was a hassle), so I know it's not an "imagined threat" from "NOBODY" or a "myth" or things that "just don't happen" because "nobody is trying" them.
But it's not a "bug" either. It's a design tradeoff. X just wasn't designed to provide a security boundary between applications, to encrypt its network traffic, or by default to use any authentication at all other than host-based authentication. Even MIT-MAGIC-COOKIE-1 auth was an add-on, and it is sent in the clear, permitting replay attacks. These are defensible tradeoffs, and ssh -X and the current xauth defaults improve the situation significantly, but Wayland's design provides a lot more isolation between applications by default, which is probably a more defensible tradeoff.
> is why would you wait until people are getting hacked to address a known vulnerability?
Do you have some other way of _reliably_ identifying vulnerabilities?
> It makes no sense whatsoever to leave one open just because.
It makes sense to have security options. If I want to leave it fully unlocked, that's my business, and I possibly have good environmental reasons to do this.
What you should really care about are security _defaults_. And in X11's case I'm not aware of any distribution that ships the server with TCP connections to the sever enabled. You have to go well out of your way to even begin using this functionality.
> Do you have some other way of _reliably_ identifying vulnerabilities?
This is irrelevant given that we are talking about known vulnerabilities.
No, you can't reliably find all the vulnerabilities by auditing the code.
Yes, if you audit the code and believe you have found a vulnerability, you fairly reliably are correct in your belief. And should probably take action even if you aren't.
It does make sense if the vuln doesn’t fit in your threat model.
There are always an uncountable number of vulnerabilities and you can never fix all that are found.
No idea of course if the threat model that said boss had in mind made sense. But I always recommend to come up with a reasonable threat model first and then think you can harden against it.
I think the issue isn't that you downloaded random hostile software, but that other software you do use has some sort of vulnerability (recent Unity vulnerability, browser sandbox escape, etc) and an issue like this would allow for privilege escalation.
Wayland doesn't need X11's vulnerability as its only argument, Wayland is a much simpler design that is easier to iterate on because it doesn't assume the client and server are on different machines. The fact that it moves privileged APIs like screen capture behind portals is a bonus.
So simple and easy to iterate on that Wayland compositors are still not as full-featured as X11 desktop environments after more then a decade, and can't be due to protocols no one is able to agree to implement.
X11 has options for tear free video playback; it's not in the base protocol, and not all drivers offer it, etc, but it's acheivable. Fundamentally, you need to send the next frame to the server and ask it to switch frames during vblank (+/- notification), on today's systems, this is more of a coordination problem than a technical one; there's plenty of video ram to go around to double/tripple buffer.
HDR would fit in the X11 model of many bit depths, however the specifics don't really; afaik, X11 has a maximum bitdepth of 32 for pixel values, which means either limiting to 2-bits of alpha channel or using palettes (I think I saw that indexed colors can be defined with 16-bits per channel). An extension might be possible (with everything that brings), but I think the ship has sailed.
I agree that Wayland's security model prevents some undesirable interactions that X11 allows, but it also prevents or makes difficult some desirable interactions, so it's a mixed bag.
> I agree that Wayland's security model prevents some undesirable interactions that X11 allows, but it also prevents or makes difficult some desirable interactions, so it's a mixed bag.
That is so true, I wanted to have a typing sound from my pc everytime I typed on wayland and I looked at LITERALLY every single solution and none of them worked... simply because of the security model of wayland (so things like Mechvibes and alternatives don't work generally speaking)
On one hand, its a good thing to prevent things like password injection etc. but on the other, really?
I got frustrated and I created a lot of github issues on every such project if they said that they are working on wayland and I didn't care if it meant running it as sudo, I just asked them kindly if there was a way or not/ what's the issue here
There are still times where I get a lot of notifications simply because someone commented on those issues
So naturally a lot of people are/were frustrated about it. Not sure if its a good thing or not, but I 100% agree about this comment of yours
Another big issue imo to me feels like ssh, X servers ssh forwarding/vnc just works, Yet I haven't really found ways to do things like VNC on wayland on a server or something as easy (or even possible?) on wayland as compared to x servers, Please let me know if there are apps which do this though, I know about weston but I haven't found ways to work with it/make it work (maybe my skill issue)
Are there any solutions to these things though? Fundamentally that mechvibes things requires an app to view the key from every other application and make a sound, Nothing stops it from being a key-logger as well if it had that capability and Wayland was created with a better security model but as you say and I experienced, that security model comes up with its own compromises and I am not sure if that's a good thing or bad thing....
> Another big issue imo to me feels like ssh, X servers ssh forwarding/vnc just works, Yet I haven't really found ways to do things like VNC on wayland on a server or something as easy (or even possible?) on wayland as compared to x servers
Waypipe[0] for native Wayland applications, and if you need to forward X11 apps there's xwayland-satellite[1].
You can hook xwayland-satellite with Waypipe and forward X11 apps through Waypipe. This way you get even better performance than with traditional X11 forwarding methods.
The other day I was playing Steam/Proton games through the network this way.
Of course, X11 forwarding also works fine on Wayland with ssh -X, but as I said, consider Waypipe + xwayland-satellite.
> Another big issue imo to me feels like ssh, X servers ssh forwarding/vnc just works, Yet I haven't really found ways to do things like VNC on wayland on a server or something as easy (or even possible?) on wayland as compared to x servers,
waypipe just works too. That replaces any reason to do SSH forwarding.
Also some desktop like Gnome (maybe KDE has similar feature?) offer remote desktop. In Gnome's case it is using RDP protocol instead of VNC.
With the caveat that I haven't used Wayland ... [1]
Waypipe is supposed to help replace things like remote X. I'd be surprised if there's no vnc server that offers a wayland desktop... that would be a big missed opportunity.
For your noisemaker, I think you might have a better time integrating at another level. Either intercept the inputs before the display server gets them, or integrate into the display server itself. X was more flexible, but as long as it's just typing -> noise, you don't need it to have the same architecture as it did in X.
[1] Wayland has no compelling features for me, and X remains viable for me as well. At some point, hardware support might be compelling, or IMHO, something will come to replace Wayland and X that is compelling.
> Another big issue imo to me feels like ssh, X servers ssh forwarding/vnc just works, Yet I haven't really found ways to do things like VNC on wayland on a server or something as easy (or even possible?) on wayland as compared to x servers,
Yes, this should be workable, assuming your compositor is compatible (a meaningful caveat, but not insurmountable):
* To forward one application like `ssh -X`, you want waypipe
* For VNC, it really depends on your compositor, but wayvnc works for many of them. (And GNOME does their own thing and I think KDE has their own official option)
I remember watching tear free HD video in 2011 on a netbook I dug out of the e-waste dumpster in the UC Berkeley CS building basement. Chrome/Openbox/X11. That laptop was literally trash.
>> Using a compositor fixes screen tearing, no need to use Wayland for that.
Right, and that abandons the whole X drawing API in favor of passing around client drawn bitmaps. That was one of the big points of Wayland too - X has a whole bunch of stuff that no modern apps use anyway so lets throw it out and build up a better version of the capabilities we need.
If we abandon the X drawing API and half an OS included (memory management) and use KMS, all that's left is the features that are security holes.
Wayland is the way to go. The same applies to Flatpak, Pipewire, systemD, etc. I'd say that this is obvious, and doesn't even need to be argued, to 99%+ of those who actually use the Linux desktop. The only opposition to this is a small group of decelerationists with a major, irrational aversion to change.
Having only two major options, X and Wayland, doesn't mean either one is correct. It is generally true that X needs to be replaced, but Wayland is not necessarily the replacement we need. It would be good to have more competition.
On a separate note, I think it's probably true that Wayland has significant drawbacks that preclude it from being an obvious replacement.
Everybody is pushing it and trying to convince the people who have problems with it that it's completely fine and their problems aren't important (like blind people being completely unable to use the computer).
At some point the pipewire of display will come along and we'll all forget wayland was ever a proposed solution.
Pulseaudio is both a protocol and also an implementation of that protocol. Pipewire also implements the pulseaudio protocol, hence its compatibility with all existing software.
Wayland is a protocol only. Every compositor - and there are many - implements it "from scratch". The "pipewire of display" would simply be yet another Wayland compositor. No one is going to solve the problems of Wayland in one fell swoop by releasing another Wayland compositor. What is actually happening is that problems are being gradually solved by the introduction of protocol extensions, which usually get adopted by other compositors after achieving success in one.
Everything you listed is bloated, slow, incompatible, unfinished or unstable. My system worked fine 20 years ago on far less capable hardware. Now even with high end workstations systems lag, crash or have strange behavior
We are running systemd with all bells and whistles on Raspberry Pi based 1 GB RAM systems. systemd-networkd, iwd, timers etc. The base usage barely touches 350 MiBs. Our actual application is containerized with systemd thanks to broad set of options increasing system security quite a bit. It works great.
You know what's bloated? Replacing all those functions with custom bash scripts or worse system services.
> We are running systemd with all bells and whistles on Raspberry Pi based 1 GB RAM systems. systemd-networkd, iwd, timers etc. The base usage barely touches 350 MiBs.
Er. I have Linux boxes that have 128MB of total RAM doing useful work in my house (not using systemd). This is not the win you think it is.
>systemd-networkd, iwd, timers etc. The base usage barely touches 350 MiBs.
That’s absurdly high for a headless system that’s doing nothing. There are countless millions of embedded devices doing useful work today with 1/10 the RAM. They run modern Linux just fine without the ridiculous bloatware.
My thoughts on systemd are complicated but I wasn't around at the time of systemd
Personally it is my opinion that Linux really split in two due to systemd partially because of the idea of the sheer size of systemd code
I am not saying that we always need such simplicity, but that I am merely giving an opinion that there are people who actually want to understand what they are running as their root and this sense of "control" really is so hard to get from things like system-d
System-d is also thus a little "bloated" compared to other inits which really show in systems like containers etc. where most developers if possible try to have alpine containers (I have seen this especially so much in golang/rust communities partially because golang is mostly static available and rust can be done the same too or compiled with musl pretty easily)
As such, personally, I can understand both systemd and other init systems, I feel like there are some guides which prefer using hummingbird etc. (https://github.com/comfies/tldrlfs) and I feel like for actually understanding "linux" from linux from scratch, other inits can be good.
Another minor nitpick I have of systemd is that its glibc based, Glibc has some of the weirdest complexities I have ever seen and a lot of package management in my opinion has been built around it and personally it feels like the decisions were made in a different era where different types of resources were constrained and updates weren't as widespread but now it has been a mess which is why we need so many linux distros in the first place with their opinions and package management
I genuinely prefer musl for this, So I prefer things like alpine/void in the process as well yet to me, freedom matters a lot. There should be a freedom of choice in such matters and systemd severely restricts it for many.
I feel like systemd is way too ambitious and which is why it requires glibc to be more feature complete in the first place, not sure if its a good or bad thing but I am merely stating what I feel like.
As I said, I have nothing against systemd myself but I am just giving the nuance I felt like, as I was trying to build my own linux distro trying to make it hyper compact and I came into this rabbit-hole, My philosophy almost was out of curiosity regarding what are the smallest systems which are still functionable (Hint: its tiny core linux which is an absolute pleasure although it isn't "secure" partially because they run everything as root If I remember correctly but )
>We are running systemd with all bells and whistles on Raspberry Pi based 1 GB RAM systems. systemd-networkd, iwd, timers etc. The base usage barely touches 350 MiBs
Okay but what are your thoughts on alpine, Alpine's motto or the first thing you see in bold letters on their website (https://alpinelinux.org/) is
Small. Simple. Secure.
Alpine Linux is a security-oriented, lightweight Linux distribution based on musl libc and busybox.
Combined with either gcompat to run glibc or personally I genuinely prefer golang/rust applications (mostly golang) like running gitea on alpine etc. and I found it to be an absolute pleasure server side to work with mostly, except sometimes software download especially python when I was running alpine on android using userLand was a somewhat-issue but maybe I had skill issue or something but I genuinely learnt a lot trying to install python on it.
Bun/Deno just works out of the box, in fact deno is even available in the apk format of alpine out of the box
I truly love alpine/appreciate its message. I feel like systems should be small partially because that means that such software could run even on much older systems just out of the box
Alpine features raspberry pi images and there is dietpi which has some decent low iso file sizes, Check them out as well if possible
Personally I love alpine but I also love the idea of using debian or some immutable distro which uses systemd and then running alpine in container, it seems to be the best of both worlds really.
When distributions started to use systemd, it was extremely buggy.
The first 24h of me using it, I found 3 different bugs in journald where it was losing data.
I'm currently using systemd, but it was far from being ready when all the fanboys with very basic use cases were insulting anyone who complained about it.
WTF? You can't address people like this on HN, and comments like this are completely unacceptable. You might not owe containers better, but you owe the community better if you want to participate here. Please take a moment to read the guidelines and make an effort to observe them if you want to keep participating here.
Wayland won't run fast on my n270 CPU based netbook. Pipewire it's good but sndio it's much faster. And SystemD it's a joke compared to the simple setup at /etc/rc.conf under OpenBSD and rcctl.
People keep talking about X11 security in the context of servers and networking, but I'm more concerned about exposing more attack surface to local malware (i.e. keylogging other processes, capturing program state).
Of course X has authentication, but once you're in, you're in. There are no elevated windows, screen recording permissions, or any sort of keylogger prevention. That was normal a few decades ago, but the world has moved on since.
There's no real reason it can't do any of that, it just doesn't and there are no real plans to add these features.
I'm not convinced by the "if you run a program you should assume you've already been hit by a CIA 0day". Obviously nobody is dialing into your X11 server from the internet, but this is a relatively easy nobody:nobody -> root/wm-session/whatever elevation of privilege.
If malware is in your X server, doesn't that mean it's running under your user account? And if that's the case, then couldn't it just steal your data right off the filesystem without needing to get it from X?
The valuable data on your machine might not be something permanently stored in the filesystem, but ephemerally recorded in a process. Say, a memorized password.
I assume you're talking about Yama, but that's not universally enabled by default. And even if it is, malware could do something like wait for you to open Firefox, then immediately kill it and launch its own version with its own code already baked in.
It's enabled in all mainstream distros that I know of. I work on debuggers and this is the single most common issue that people report with attach.
And yes, if the malware is running under the same account that you use to login, it can do a lot, X or no X. That's where various forms of sandboxing come in. And the problem with X is that it is basically impossible to properly sandbox an X app.
> Why do people keep persisting this myth? X11 has authentication. You can either rely on filesystem permissions, or a shared secret. The same way thousands of other network servers work.
Any program you incidentally run within a typical graphical user session will have access to the X socket and a cookie, they will be able to connect. And after they connect... They basically just can do anything they want with zero real restrictions, including most likely some fairly trivial paths to root escalation. Even if they're running inside of a sandbox or container, with only an X11 socket poking through.
This problem was realized a very long time ago with the security extension but most of it never really caught on.
> Any program you run on a computer (especially a Linux computer, which lacks modern OS security measures and has constant privesc kernel holes) exposes you to security flaws. There has yet to be any computer system designed that a hacker can't break out of. If you intentionally download and execute a program, you are rolling the dice, regardless of what the software is.
If you believe this is true, then what exactly is the point of any security measure? Why bother using isolation and sandboxing, or passwords? Why does Windows bother patching flaws if they know there are certainly more of them and they will never fix them?
Do you by chance also smoke because you're going to die anyways?
> What's insane about all these discussions is that NOBODY IS HACKING X SERVERS. There's a thousand other kinds of software on Linux that there is real malware for. But nobody is trying to hijack your X11 session. This imagined threat is a red herring designed to bolster the argument for Wayland's horrible designs.
Lol. That's primarily because the Linux desktop is utterly irrelevant, not because nobody would care to do it. Is it really surprising that attacks against desktop computers would focus almost entirely on the OS that has 90+% of the market share? We don't get free software OS desktop malware for the same reason we don't get free software OS software ports.
Watching and waiting with security was a totally acceptable position in the 90s, but we get the general gist these days. We need security-by-design.
On the server side of Linux where Linux is relevant, the situation is much more impressive; auditing using eBPF, sandboxing with gVisor, microVMs with Firecracker and cloud-hypervisor, isolation using namespaces and seccomp-bpf and more.
On the desktop side, people are still arguing over whether or not it's a problem that any X client can by default silently keylog the entire system trivially. Okay, but a lot of us actually see that as a problem, and we're not interested much in "hearing you out". Most of us recognize that the Wayland protocol has warts (and too many damn protocols), but X11 has many more warts. I didn't care what was the successor to X11 specifically, I just cared that we eventually made some progress. Most people have nothing to offer here and just suggest we should've stuck with X11. Okay dude, but nobody wants to. The X.org devs would like to move on. The desktop environments really would like to move on. There was basically one serious guy that actually wanted to work on improving X11 and he turned out to be kind of crazy and couldn't stop breaking shit anyways.
Yeah, with Qubes that's exactly what they do. I forget what the software is called, but they use an X11 proxy that tries to enforce policy.
That said though, that does require you to proactively run every X application with this sandboxing. For Qubes which forces everything into VMs this is doable, but for most other systems there isn't an obvious way to handle this sort of thing.
My only major complaint about Wayland that can't just be fixed relatively easily is Mutter refusing to support SSD. (Well, the actual technical problem could be fixed relatively easily, but the social one not so much.)
Because there is no isolation whatsoever. A terminal running as root can just be typed into. Some apps can be coerced into code execution when messaging them over X11. You might have to get a little creative, but there's a lot of room for creativity.
Needless to say, though, if the user doesn't have anything open with root privileges or cached sudo, then you probably won't be escalating to root with only X11. You'd have to wait for something to crop up. I'd reckon though if you are resident for long enough during a desktop session you'll find an opportunity. (And on most desktop systems that still, of course, leaves the usual points of interest outside X11. But if you wanted a way to escape, say, Flatpak containment, this is definitely a good start.)
X11 had the distinction between trusted and untrusted X11 clients basically forever. But nobody bothered to even spend the minimal amount of work to make this usable in practice^1.
This had two reasons: 1.) It is irrelevant when you run the programs as the same user so nobody bothered (and no: Wayland does not help: https://github.com/Aishou/wayland-keylogger) 2.) It is more fun to simply pretend it is unfixable broken and write something new (something any good engineering manager should have stopped immediately).
¹. I used to use this and also fixed some bugs in some programs. The main problem when I last checked a decade ag was that some important extensions such as composite would need to be exposed to untrusted clients.
That Wayland keylogger is not the same thing. X11 has several mechanisms (XTest, XRecord, XI raw inputs) to receive a global raw key input stream, accessible to anyone who connects to the X server, without even making a visible window surface. It even bypasses grabs, meaning that your lock screen password entry can be snooped on.
The Wayland keylogger acts like an application; all Wayland compositors will only send key events to the focused surface, so the user has to focus an active surface in order to get key events. Even in the scenario where you've LD_PRELOAD-hooked all applications, you still will never get the lock screen password, as the compositor never sends it out across the wire.
LD_PRELOAD is problematic from a security perspective, but it's not Wayland-specific: the same issue is true for CLI applications and X11 applications, and any attacker with the ability to write files could also just replace your binaries with malicious ones (stuff them somewhere into ~/.hidden, and then add a $PATH entry to the start).
I think you did not understand my point. X11 has several such mechanisms, yes, but it also has the concept of untrusted clients that disallow the use of these mechanisms and could be used to provide safety similar to Wayland. The point is that this mechanism of untrusted X clients was neglected and I gave an explanation way.
Yes and your response in the whole thread reading top to bottom was the first one that really taught an old dog a new trick. I've been using gnu on x11 since 1991, been annoyed by fellow student's audio streams on my work station back then, and I've never heard about trusted vs untrusted x11 apps.
I wonder how this debate was mainstream? did some gamers try to squeeze 3 extra percent by taking the protocol out of local stacks? there must have been better ways to do that, without throwing out all X11 benefits?
to this day I'm annoyed I can't have a decent window manager integration on gWSL because the compositor doesn't implement the full window manager protocol.
See the ssh manpage for an explanation of untrusted/trusted clients.
This debate was mainstream. Basically, some people presumable paid to work on Linux graphics decided to implement something new instead of doing their job, and gave talks about why X is fundamentally broken. I believe the driving force might have been the hope to support Linux on mobile or embedded devices, and X seems just unnecessary (although I think network transparency would be super useful on mobile devices). Some gamers certainly believed nonsense such as "all X programs are forced to use ancient drawing primitives and so programs will be much faster with Wayland". Wayland developers certainly did not do anything to stop such misconceptions. Later there was disappointment because obviously it was not faster (the drawing model for modern clients is essentially the same), but other myth such as the "fundamental security issue" prevailed.
It's like if Wayland is not just a graphical system, but a full business plan.
Control upstream, then companies wanting solutions will go to you first. Because why go to someone else in the FOSS market, when there is no certainty the code or standard (extension, protocol, etc) will get accepted, forcing you to maintain a fork? With IBM-RH and Ubuntu doings eg., it's hard to say FOSS is immune to vendor lock-in.
> It's like if Wayland is not just a graphical system, but a full business plan. Control upstream, then companies wanting solutions will go to you first.
Wayland is open source with a fixed core protocol that's extremely stable, which anyone can build on. New protocols are constantly proposed. The core is minimal and defines how applications interact with the compositor to render and produce the final output. Control by a single entity is virtually impossible. Wayland ensures everyone has a voice because it's an open protocol which means discussion and development are done in the public.
in _reality_ it gives stack owners full proprietary control.
specifically the wslg stack does not enable Linux gui apps to smoothly integrate with the Windows window manager, because some bits are missing in the Windows Wayland stack, clipboard, window decorations, thumbnails, maximize into a part of the monitor? nope. and no patches taken. supposed you figure where to offer them and how.
It's unfair to claim Wayland is inherently different from X11 in this regard. Both are just specifications, and there are also proprietary implementations of the X11 protocol, primarily for Windows and enterprise settings.
> Some gamers certainly believed nonsense such as "all X programs are forced to use ancient drawing primitives and so programs will be much faster with Wayland".
This is incorrect. Kristian Høgsberg has explicitly stated that a primary motivation for Wayland is the reduced need for a central X server, as many programs already bypass it.
A Wayland compositor is even more centralized as it combines compositor, Window manager, and server while in X these could be separate components. I also do not know any program that bypasses the X server. Are you talking about programs that you can start from the text console and which then do graphics directly? Those are very rare.
There are reasons for those architecture differences.
Wayland is an evolution of the previous design. X11's architecture had clients sending drawing commands to the X server, a method that became limited and required extensions over time. Wayland's approach is: applications perform their own rendering into their own separate buffers, then tell the compositor when they are ready. The compositor takes those buffers to produce the final image.
Because those buffers are separate, enhanced security is a direct side effect. Wayland is the result of decades of experience and represents the current way of doing things.
I'm aware that extensions exist now, like present, which make it possible to send buffers, similar to how Wayland operates, so you don't have to do things the primitive way.
However, to claim to speak the X protocol, you still need to support the older functionality, that's what I mean by a tremendous amount of functionality to support. The moment you get rid of that old functionality, you've essentially created a new protocol, which is what Wayland is.
How is that point nonsense? I don't want to see X go, but I don't think it's reasonable to prevent progress.
If you know these extension exist (for a long time), why spread the misinformation about "drawing commands" in the first place? A client does not need to support old functionality. A server does for backwards compatibility and this is a good thing! In fact, breaking decades of compatibility is the worst blunder of Wayland. The idea that this is a "tremendous amount of functionality" or a huge burden to maintain is also misleading, first because some drawing commands from the 80s are not a lot of functionality to support from a modern point of view, and also because all this is still being maintained anyway, just much worse because the resources redirected to Wayland. And even if one had deprecated some stuff eventually, this would not have broken compatibility and many other features at the same time as Wayland did.
It's not misinformation, that's how X still works. Clients do all kinds of things. New programs aren't like 80s ones but your X server still must support every operation clients expect.
Wayland doesn't break anything, it's a completely new protocol. Claiming Wayland breaks your use case is like saying systemd broke old init scripts. It did because it's a different system.
Wayland isn't trying to be Xorg 2. It's a protocol. At its core it's only a compositor protocol. Everything built on top is up to the implementation developers.
The logical problem with your argument is that as long as we want to support old clients, we now must support the X server in parallel to Wayland. So there is nothing gained. And the moment we can stop supporting them, we could do this also in X. And yes, Wayland being new and incomplete both creates a huge amount of problem which nobody needs.
So far Wayland gave me only headaches and I do not see what it offers that X does not already provide. And the fact that Wayland make their case by lying, etc. the drawing commands BS, network transparency does not work (I feature we do use every day), etc. and the fact that important use cases such as accessibility are now treated as an afterthought that there are diverging implementations with inconsistent support for important functionality, ... all this does not build confidence that the developers even remotely know what they are doing outside of their narrow view on the Graphics pipeline itself.
And this after decades of effort. Maybe it is too late now to save X, but Wayland was a terrible idea, not the idea of developing Wayland itself as an experiment with open result, but to declare X dead and Wayland its successor long before it was ready and before it was clear that it is actually a better replacement (so far, it isn't).
Those are not lies. I don't think you know what you are talking about. If you knew, you would know that waypipe + xwayland-satellite works even for forwarding X11 clients over waypipe. I use it myself every day, but it's pointless to discuss it with someone who isn't interested in listening, only in spreading the same lies as everyone else.
> Everything built on top is up to the implementation developers.
and that's exactly creating the problem: Window management for example is left as an excercise to the reader. thus (my point above) the WSLg interop for graphcial applications _sucks_ compared to where X Servers already were. and if MS doesn't implement what's needed, it won't come. no way to fix it in the Linux or on the Windows side. the MS Wayland thingie in between tightly controls what is possible.
As far as I can tell, enabling the trusted/untrusted security feature breaks a lot of basic features, including clipboards, XRandR, GPU acceleration, XKB keyboard layouts, and whatnot. It's theoretically available but practically useless.
Xnamespaces looks to be more promising, but as far as I can tell that's still a WIP with little documentation, and from the documentation I can find it looks like it still breaks things like clipboard functionality.
Permission system? X11 with a permission system is the next logical step for Unix graphics. There is absolutely no need to break 40 years of graphic software, or throw away 40 years of accumulated features.
Yes, but even a permission system can only give a program access to the clipboard or not. You can't deny a program access to the clipboard and complain that the clipboard doesn't work.
Solaris had Trusted Extensions for X11 which shipped with Trusted Solaris 8.
In 2000.
Solaris 10 had it built into the base OS and integrated into both the CDE and GNOME desktops they shipped. With OpenSolaris it was released as open source under the non-GNU CDDL license.
That looks like the display manager (i.e. login screen) running on vt4, which is probably not where you are logged in. Does it switch to another user when you log in?
Note you have multiple virtual consoles which can have independent X servers.
No, that's actually my real and only Xorg, it's the child process of /usr/libexec/gdm-x-session and that process is owned by my real user id, and the Xorg process provides /tmp/.X11-unix/X1 that e.g. strace -e connect xlsclients shows is the socket it uses. Notice also that it uses a significant amount of memory and has consumed a meaningful amount of CPU time, much more than a dm would do.
Good point about display manager though, I suppose it's not using Xorg then as I do know there is a login screen waiting at vt1 but that's the only Xorg process. Maybe the gdm3 incorporates a Wayland implementation in Debian 13.
I think I ran into some display managers that do not start a new X session for every user. However I was trying out some rather non standard configurations at the time, some of which required root access for driver specific features.
And going to rabbit hole there are even proof of concept security implementation named Xnamespace for Xorg fork (needs polishing and much more patches but looks doable. see wip documentation: https://raw.githubusercontent.com/X11Libre/xserver/d2b60a3d6... )
The way X11 developers ended up fixing this is by creating Wayland. This way privileged operations (like keylogging, screen capture, etc) require the cooperation and authentication through the display server.
That sort of solution is cancer if you want to do anything the display server authors didn't think of. I've got a script that I invoke with a global hotkey that determines the window title of the currently focused window and fuzzy matches it against pipewire audio stream names so I can mute the focused window with a single keypress. If I want that to work in Wayland I'm pretty much up shit creek because somebody with their head in the clouds thinks that my needs are super dangerous or something.
Wayland devs for the longest time thought implementing what was needed for accessibility (mainly, global keyboard hooks for Orca to work) was a security problem. Nevermind the fact that nobody hacks X servers, or your wayland compositor, because if I wanted to hook your keyboard with a keylogger, I'd hook it through evdev. And then you wouldn't even know let alone be able to do much about it if I did it properly.
Wayland doesn't say "this is impossible", it says "this is out of scope of the core display protocol, implement this somewhere else".
Which, well, we do. Practically all the X usecases are covered on Wayland systems now. Screen sharing, screen clipping, global hotkeys, file pickers, getting the window title like you said... I can do all of that on KDE, right now, under Wayland.
If you change to another DE that has less capabilities than KDE, of course you can't do it. Emacs and LibreOffice Writer will have vastly different capabilities and people can choose what they want based on the capabilities they desire.
And that is exactly the problem. Now things like accessibility (or, really, any feature that the maintainers of the core protocol didn't think were "necessary" because they like minimalism) have to be implemented by each and every compositor. If the compositor doesn't implement it, your screwed unless either you convince them to add it or you add it yourself. Talk about causing huge amounts of fragmentation for absolutely no reason.
The proper thing Wayland should've done is waited until Wayland had reached feature parity with X, then released it to the world and started acting like it's the future.
Wayland was specifically built to support things that aren't desktops, so feature parity with X was never a design goal of Wayland. The idea was that Wayland would be a super-flexible "you give me a window and events, I give you rendered bitmaps" kind of protocol, and then desktop functionality would be layered on top for people who wanted a desktop. Not everything needs to be a desktop (e.g. car infotainment displays, KDE Plasma widgets, etc), and some protocols would be super limited if they had to fit in a desktop mold (e.g. VR displays[0] with apps in non-planar windows).
The main mistake FD.o made is that they didn't get consensus on a "Desktop Profile" extension, so all the DEs wound up implementing their own thing. This is still fixable, just very annoying until we have agreement on this shit. I think that's what you meant by "feature parity with X".
[0] Currently, every desktop VR setup has to have two layers of compositors. VR applications have to communicate with a special VR compositor that then draws normal desktop windows with the contents of what should be hitting each eye of the VR display, all so it can pretend to be two normal displays.
I could say the exact same thing about X, A lot of the problems people had with X historically was that developments goal was to "create mechanisms not policy" and people just wanted a desktop environment that worked.
An antidote on non desktop use of X: the other day I wanted to show a program on my phone, there are many good ways to do this, but I picked none of them. Instead I had just installed a terminal on the phone and noticed they had an X11 package, So A few minutes later I was the proud owner of an X server on a phone. And you know what... It was pretty great. My gaming system load and temps dashboard were displaying just fine.
Despite using X for many, many years, I had never just sat down and played with a bare X server, I had only dealt with it through the lens of a locked down, encumbered desktop system. It was like having a network attached monitor. From whatever system I was using as a desktop system I could just go "display this on that monitor", in this case a phone. Based on that experience I put a raspberry pi on my TV running a bare unprotected X server because having a network attached monitor rocks.
Yeah, pretty much. I would be less disagreeable about Wayland if they had solved this problem early (and yes, they should've thought about this early during Wayland because the most prominent target is desktop environments). But they didn't, and I don't even know if they'll come up with some unified solution that all DEs/WMs can agree on or whether they'll just keep allowing DEs/WMs to do their own thing. Either way, fragmentation is never a good idea on what, I think, many would consider critical functionality. At least, I consider the requirements to implement accessibility to be rather critical, which is the primary reason I still use Xorg.
If I have a kiosk terminal, why would I want the overhead of, say, screensharing? Also, isn't this the point of libraries, so that you only have to implement stuff once, and you can reuse it in different projects? Like you can build on top of wlroots just fine.
> The proper thing Wayland should've done is waited until Wayland had reached feature parity with X
How on Earth would you expect a fundamental protocol to be developed behind closed doors?! Wtf even.
> If I have a kiosk terminal, why would I want the overhead of, say, screensharing? Also, isn't this the point of libraries, so that you only have to implement stuff once, and you can reuse it in different projects? Like you can build on top of wlroots just fine.
Yeah but again this fragments the ecosystem massively. If people really wanted flexibility they could've just made it a configure option or something equivalent?
> How on Earth would you expect a fundamental protocol to be developed behind closed doors?! Wtf even.
Your making a pretty big assumption here, aren't you? I never said it had to be developed behind closed doors. It's the "lets just obsolete X11 even though Wayland can't even replicate a quarter of it's functionality right now now now because of security security security" that irritates me. If they had worked on Wayland and obsoleted it once they had reached feature parity, that would be releasing it to the world. Then they would've had far less friction and the transition would've been a lot smoother. Would it have delayed Wayland by maybe a decade? Sure, but I see little issue with that. IMO that probably would've made Wayland even better.
Who is the supposed agent mastermind singlehandedly developing Wayland and deprecating X11? You do realize there are multiple people working (having worked) on both in their free time and each have agency and their own incentives. Separate people have had enough of maintaining X, while another group of people enjoyed working on Wayland. Some indeed moved from one to another but there were no coordinated attempt at hijacking the Linux graphic stack or whatever..
3. Shortly after all distros finished switching to X.org, declaring it obsolete and announcing wayland
4. stopping any major development on X.org immediately even though it's was the one and only option at the time
5. and channeling all development resources (not only on the display server, but also downstream users like toolkits, DEs etc.) to rewrite their code for a protocol that wasn't even gonna be usable until a 10+ years later
6. Depraving Linux desktop users from 10-15 years of improvements and making Linux graphis stack stuck in 2000s
wasn't hijacking the Linux graphic stack?
I mean had Steve Balmer
wanted to sabotage Linux in desktop he couldn't do better
That's the issue. Because wayland punts on so much functionality that used to be available with standard interfaces in X11, it fragments the ecosystem to such a degree that all these useful little utilities just don't really have a means to grow.
> Practically all the X usecases are covered on Wayland systems now. ... global hotkeys ...
Are you sure? I looked at that earlier this year for a personal tool I wanted to create and found no way to do it on Wayland (On X, I did it just fine).
I had a long back and forth about this very thing with both Claude and ChatGPT, and neither conversation was fruitful: every option had some dependency (like switching to KDE, or similar).
I know some blind people who tolerate it but yeah, I find it completely unusable at the moment. I haven't tried Gnome recently but last time I tried it I had apps like Bitwarden malfunctioning in some very, very weird ways that just... Never happened on Xorg. If I remember right, it was things like forms not being read properly or something, can't remember off the top of my head now. But it certainly didn't leave me with a good impression; it made me think this Wayland thing was just half-baked. Also, Orca modifiers were passed-through directly to the compositor and Orca wasn't allowed to intercept them either, which made just using my computer feel awkward since I'd always need to remember to turn off caps lock every time I wanted to do something even remotely complicated. I've heard that Gnome has solved this but as I said above, I think this may be a Gnome (and at most KDE) thing, and not something that everybody has decided to just do.
For some weird reason I can't access it, it just redirects me to this image about hacker news. Did he just configure his webserver to just universally display that image? Even if I manually enter the address into my address bar it does that so I assume that that's what he did...
Good. Disallowing software to position its own windows has been a major usability improvement over the X11 days of software making stupid positioning decisions and having to patch it out everywhere...
Yeah, assuming all users and all software should work the same idea is a great way to get people moving to a new platform.
Maybe, just maybe, some people know what they want, and if they want applications that can put themselves in specific corners, why shouldn't the desktop let the applications do that, if the user is OK with it?
Fixing X11's security would of broken window positioning as well. Since that is a security issue.
The deal here is that the only way to fix X11's security issues is by breaking all those types of workflows and forcing application rewrites to implement them in authenticated ways.
So if you are going have to go and break all that stuff, why not fix a crapload of other problems while you are at it?
Calling Wayland "X13" may have avoided a lot of misunderstandings, but it probably would of caused others.
Maybe it's both? There are applications with good reason that need to chose their location themselves, and users who want that type of behavior, so it's definitively not just a security issue.
> X11's practical absence of any security mechanisms for user sessions means you should probably not run any kind of low-trust UI program
This has nothing to do with X11 or even UI at all. You should not run any low-trust program whatsoever (outside of a container). Any program that runs as your user can change your ~/.bashrc or any other file on your homedir.
Of course this is a feature that you want, for example when you edit these files with a text editor.
Some oldschool legends are still fixing bugs in xorg.
Alan Coopersmith in particular. He even fixed a bug I reported. :)
(I forgot in which app it was but the bug report should be somewhere still; it is not old, perhaps 2 years ago or 3 years ago. The xorg app in question behaved oddly when doing "--version". I only noticed
this because I wrote a ruby script that displays which version of programs are
installed, and that one kept on making problems, whereas the others worked
fine. After I reported it, Alan fixed this very quickly. I think it was some
missing flag in the C program or something like that; right now I can not
remember the name of the program ... my brain tries to say xrandr but I think
it was not xrandr but a less frequently used program somewhere in the FTP
listing ...)
Keith Packard, another legend, was proposing X11 improvements in 2018. [0] He doesn't seem to be paid to work in X11 or Wayland, thus being free to float ideas he likes.
It did, but it could receive messages thanks to MIT Magic Cookies, which you could send because of Tk’s excellent integration with X. I can’t remember now if it was the browser you could also effectively spy on via similar means. Long time ago. I have largely forgotten how my tool worked now but the code I wrote (modified wish shell) might still be out there.
Coverity is pretty good about finding these kinds of bugs. Is there a reason why a project as significant as Xorg isn't taking advantage of their gratis access for that tool?
I think the short story is that the people who develop Wayland are the people who used to develop Xorg.
And they’d rather spend their energy on giving you a compelling reason to switch, rather than using it to add to the reasons for staying on a project they now consider obsolete.
You may disagree with their assessment, but you can’t blame them for how they decide to prioritize.
Graphics is the reason Linux got over 1% desktop market share. When you have a problematic piece of hardware, sure, it sucks. But most setups will run Steam games near native quality out of the box. I'd blame the hardware not Linux.
Xorg is indeed a lot of painful complexity. This being said, the software is not Linux specific, and for modern Linux distributions, it is more and more a legacy technology.
Our chief pain is graphics... graphics and audio... audio and graphics... our two pains are audio and graphics... and wifi hardware support... Our three pains are audio, graphics, and wifi hardware support, and an almost fanatical devotion to the command line.... Our four... no... Amongst our pains... are such elements as graphics, audio.... I'll come in again.
_Roughtly_ speaking, X11 is only there for old games and the steam client. It is even worse with the steam client since the main executable in still 32bits.
You could say the same about thousands of open source projects on which trillion dollar companies depend on. Maybe these kind souls deserve more respect, buddy.
> Probably not seeing how the code for at least the 3rd was written in 1994, some 30 years before Fil-C existed.
How is this possibly the most charitable reading of parents comment, and honestly, do you think that's what they meant? You can't read that in some other way, where maybe parent wasn't actually asking about time traveling but something else?
Yes it was bit uncharitable, but I couldn't resist based on the way he phrased it. It was just a joke.
"Preventing" the vulnerability would indeed require going back to 1994. Since it is a vulnerability that has existed in every display server released since then.
I meant it in the sense of continuing to run old C code like X.org in a safer way without unnecessary rewrites to memory safe languages. These vulnerabilities, like this one that's been in the wild as you say for 30 years uncaught, will continue to be found. Something like Fil-C is really useful in that context.
I also said "would it have" -- I don't really care about timeline. Obviously Fil-C is a recent development, that doesn't make the question I asked any less interesting.
Wonder how these play out against the https://github.com/X11Libre/xserver base, would be interesting to hear from that end as to how these things are handled. My understanding is that they address any sec issues that arise on x.org but it would be fascinating if the issues are already mitigated since XLibre updated their xserver port with 1000s of issues that were never addressed on the x.org side of things.
On their github you can see all three changes identical to x.org's happened on October 28th (same day as the advisory). So, they were not already fixed, but the fixes were applied immediately.
XLibre looks nice with lots of work happening in only 5mo.
The problem with XLibre is political, not technical. When they came out they made a big deal of being the anti-woke free-speech no-vaccine-mandate alternative to woke cancel-culture Xorg, which instantly ruined their reputation before it even began.
Such an unforced error given how irrelevant any of this is to their project.
I think you're confusing how XLibre was presented by others[1], with how the project presents itself[2].
Disclaimer: I find their screenshot unfortunate (it promotes ideologies that are arguably harmful to healthy bodies and souls).
[1] https://www.theregister.com/2025/06/10/xlibre_new_xorg_fork/ [2] https://github.com/X11Libre/xserver?tab=readme-ov-file#youre...
Your comment is missing how the project initially presented itself and the main dev being an anti-vaxxer certainly puts those words into a bad context.
[1] https://github.com/X11Libre/xserver/blob/fea8b78358a169238a2...
In essence, that's not a lot different different from the section I linked to in the current version. But I appreciate that the dev could have curbed his emotions while writing the README.md, if for no other reason, then to cater to public appearance.
As for the lead dev's stance on mandatory vaccination, that should not play a role in assessing the need for and the technical merits of the project. Attempting to cancel a project based on such personal views of its maintainers is exactly my issue here.
Yet another transphobic throwaway? Color me surprised!
Your labels notwithstanding, I will continue to sympathize with people suffering from gender dysphoria and oppose mutilation.
No need to lie about it. Although my suggestion would be to try minding your own business :)
You're making me into a boogeyman so that _you_ can hate _me_ and do as you please.
Oh, you are the victim now? Idk who you are, other than someone who hates trans people. I am indifferent to you.
I can't possibly be the victim of anything as long as you stick to the party line. After all, isn't doing its bidding new morality, and isn't its opposition nothing but evil ghouls? </sarcasm>
If I really hated people, perhaps I would suggest to troubled ones that hating their own body to the point of mutilating it is the solution to their problems
the OC was a throwaway, so I felt I might as well make one to respond. Now I'm just using it to reply to replies.
That project is a pipe dream. They don't have what it takes to continue X11 alive once X.Org pulls the plug.
I bet you are the life of the party. Seriously though, what makes you write that so matter of factly?
That's the fork where the primary cause was to be "anti-woke", right? Honestly it seemed like it was just because that one guy was a little unbalanced, and he happened to be channeling that energy into an X server fork.
no the primary cause was that the main xorg project wasn't accepting the devs patches any more.
... because this dev's patches broke master, multiple times.
I feel this is an important detail to keep in mind while choosing a fork.
which mattered because everyone pulls from master, because xorg stopped doing proper releases. it's certainly something to bear in mind if you intend to run xlibre though.
I don't think "everyone" pulls from master - "everyone" run the distributions, and they always pin to the specific git commits. Only people who run xorg master are the ones who want bleeding edge, and those would be using it no matter release or not.
And it's not like metux will suddenly become more careful just because he does not have to worry about other anymore. If anything, I expect there to be much faster changes and much more breaking things... Here is a great quote [0]
> @metux that you've had to fix this bug twice (!1844 (merged), !1845 (merged)) shows a lack of attention and care. This was a known regression, with clear reproduction steps, and at first glance, it does not look like you tested your PR at all.
> And that goes in general; I really haven't seen the level of care and attention I would expect to see in these patches; several of them had obvious buffer overflow issues that would have easily been caught if tested.
[0] https://gitlab.freedesktop.org/xorg/xserver/-/issues/1797#no...
I'm not even trying to say they shouldn't have kicked him out, just that it had nothing to do with wokeness, and more to do with philosophy of how the project should be run.
And he blamed wokeness.
sure, he's a bit of a kook, but wokeness itself is really incidental to the whole thing.
On the github, he points to this document:
https://github.com/X11Libre/xserver/blob/master/HISTORY.md
Doesn't mention "woke" but the style is reminiscent to me from grandiosity/paranoia issues
From the README: ``It's explicitly free of any "DEI" or similar discriminatory policies.'' and ``Together we'll make X great again!''
These are both phrases used by people who are anti-woke (I guess asleep would be the proper term).
[flagged]
[flagged]
An X server code base is such a niche topic, do you honestly think Xorg or any other project is capable of being a "woke" X server? It sounds more like this one guy has some issues and is trying to blame something he is already bitter about.
[flagged]
[flagged]
[flagged]
Good that people are finding and fixing these, but basically allowing any untrusted client to talk to your X server is asking for trouble just by design. (Bonus points if you have any Tcl/Tk apps running, where you can simply transmit commands for the program to run via the X server.)
There are plenty of setups where the X server runs at higher privileges/on a different host than the (partially trusted) application that might exploit the X server. This is a classic elevation of privileges vulnerability in those setups.
X11's practical absence of any security mechanisms for user sessions means you should probably not run any kind of low-trust UI program anyway, as there is no prevention of keystroke injection or screen recording, but that's a design flaw that will never be solved. That doesn't mean that EoP style attacks like these should be ignored or underestimated, though.
Why do people keep persisting this myth? X11 has authentication. You can either rely on filesystem permissions, or a shared secret. The same way thousands of other network servers work.
Any program you run on a computer (especially a Linux computer, which lacks modern OS security measures and has constant privesc kernel holes) exposes you to security flaws. There has yet to be any computer system designed that a hacker can't break out of. If you intentionally download and execute a program, you are rolling the dice, regardless of what the software is.
What's insane about all these discussions is that NOBODY IS HACKING X SERVERS. There's a thousand other kinds of software on Linux that there is real malware for. But nobody is trying to hijack your X11 session. This imagined threat is a red herring designed to bolster the argument for Wayland's horrible designs.
> What's insane about all these discussions is that NOBODY IS HACKING X SERVERS
I knew someone who worked for a small loan type company. Passwords were stored in plain text, but even worse, the login form didn't actually check the password at all, it created valid sessions as long as you provided a valid user name.
When he informed his boss that was very bad, his boss simply said that nobody has abused it, and nobody would, don't waste time changing it.
The point, of course, is why would you wait until people are getting hacked to address a known vulnerability?
Sure, there are others, and they should be closed too, and they are when they are found. It makes no sense whatsoever to leave one open just because.
I think the point being made isn't that X.org shouldn't fix their vulnerabilities. It's that there's always a huge amount of discussion about vulnerabilities and security models when one is found in the display server or the window manager when actual exploitation doesn't seem to be particularly high.
Many distros, if not most distros, disable port 6000+ listening for X.org by default. So, immediately, it's not a remote exploit. OK, so it's scope is already limited to local escalation attacks. Looking at the CVE, the only reason it's high is because (a) X.org is everywhere, (b) you don't need to interact with [another] user to exploit it, and (c) it's not particularly complex to exploit.
That is bad, but it's also behind most of the other security, rather than bypassing essentially all of it like Heartbleed or Shellshock.
So, either I have to have X forwarding turned back on, or have people with SSH access to a server that is also running X. Both of those seem like uncommon situations. You probably shouldn't be running X or permitting X to be started unless you need X forwarding, and X forwarding is a pretty odd requirement given modern application design being so web-browser-focused.
So it might be CVE High 7+ if you're on a system where it's possible to exploit it. But it feels like you shouldn't often be on a system configured in a way where it could be exploited in spite of the prevalence of X.
Essentially: This isn't a rehash of the libXfont problem.
This is because Wayland wants to differentiate itself from X on security. Wayland has to show it's more secure than X - as part of that, Wayland has to show that X is insecure.
No, wayland already differentiates itsself from X11 because X is a tool for graphical network terminals and Wayland is a tool for single machine rendering.
X11 is a mountain of tech debt that almost nobody wants to maintain.
Wayland is what you get when you decide to start a space program because, let's be honest, the electrical gremlins in your 1983 Mercedes 560SL are beyond properly fixing, and the kids still need to get to school
X is equivalent to calling your spouse on the telephone when they are sitting next to you on the couch.
How do shared memory and unix sockets fit into this analogy?
whomst among us
But there is no vulnerability at all. For a normally configured X server with TCP listening, the server should be configured to use MIT magic cookies for authentication. This randomly-generated string is needed to authenticate and establish a connection to the X server. You can use the xauth command to manually configure it as needed.
It's the equivalent of HTTP Digest authentication, and nobody's demanding that we rewrite HTTP because Digest authentication. It's in plaintext, so you shouldn't use it; but if a hacker doesn't know the secret, they can't get in.
> But there is no vulnerability at all. For a normally configured X server with TCP listening, the server should be configured to use MIT magic cookies for authentication.
This feels like you're not understanding why something is called a vulnerability, how they're defined, or why they get rated the way they do. "It's not vulnerable in a best practice configuration," is not the same thing as, "there is no vulnerability." That is incorrect and misleading, and I think you're conflating risk and severity.
The definition used for a vulnerability is [0]: "A weakness in the computational logic (e.g., code) found in software and hardware components that, when exploited, results in a negative impact to confidentiality, integrity, or availability." (emphasis mine)
The CVSS score is not a measure of risk. It is a measure based on the qualities of the defect that was identified and how widespread the software is. A higher CVSS score is associated with higher risk, but your risk is going to vary based on your configuration.
All they did was go to the calculator[1], plug in the answers that best fit the definitions provided for what those areas and responses mean (e.g., CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:H for CVE-2025-62229), and they get that 7.3 score [2].
[0]: https://nvd.nist.gov/vuln
[1]: https://www.first.org/cvss/calculator/3-1
[2]: https://www.first.org/cvss/calculator/3-1#CVSS:3.1/AV:L/AC:L...
Digest as I understand it is a weak authentication protocol, it doesn't mean it is implemented with known vulnerabilities.
I distinguish vulnerability from weak. The weakness is not necessarily intended, but the question is, does it do what it is supposed to do. Or is there a known bug: non intended possible exploit, that would make it a vulnerability.
If it isn't known then it doesn't exist. But we can assume all software do have bugs.
Digest is part of the http protocol, if the protocol is found to have vulnerability I can imagine it would be dropped and be rewritten. The digest part, not the entire http protocol.
A hacker may not have the password, but manages to brute forces it. Is that a digest vulnerability or does it fall onto the application to integrate some preventing brute force authentication measures?
My take is digest doesn't pretend to prevent brute force attacks.
Some may not agree with that logic, but since about everything is made of a combination of vectors, and that each typically has some weakness, all you get is a balance between usability, cost, and security.
We can make the case for your typical cryptographic signature, or encryption algorithm. ECDSA standing as well respected, solid cipher. Is it vulnerable? It is vulnerable to the potential power of machines we may build in times to come. Quantum or leaps ahead. Will it be vulnerable then? Yes but it isn't a vulnerability. We would then call ECDSA obsolete.
Digest is obsolete yes.
The interesting part about cryptographic methods is that we may know of some being obsolete ahead of time. So long as we can determine they can be brute forced. For now it isn't obsolete despite the existence of quantum resistant alternatives. Hacker news uses ECDSA for the exchange of keys between server and client, then encrypts all connections using another algorithm safe against quantum computers. Thanks. But beyond that, probably not.
Is X obsolete? Vulnerable? Seems like X developers themselves admit it is a vulnerability. They didn't know of the possible exploit. As to the severity? It's often subjective from my experience.
Happy to be wrong, and we don't have to agree.
I don't dispute your anecdote but I think the point was: x11 has been around for decades, and these things just don't happen. And the reason is that there are much simpler and more effective ways to pwn a box than trying to screenshot an x session or trying to hook for key presses. So the vulnerability surface just isn't large enough.
That's not how this works. If you cannot prove conclusively that something is not the case ever, then you must accept that somewhere in the infinity of possibility it is.
I have definitely seen "these things" happen.
What did you see specifically? And on what OS?
Hi -- throwaway
I have seen this happen as well. A memory corruption vulnerability in popular software allows unpriv shellcode to reach out and drop a rootkit which loads a rat as a kernel module. Attacker has control. Several big problems.
cobaltstrike beacons blocked. Instead pierce nat with STUN to attacker proxy. Use socket activated VNC/RDP/X.
Why not just steal the sessions and local data? Remote services log access (ip, time, location), easily correlate and forensics would lead back. Local data encrypted at rest, hands on keyboard needed any way since recon incomplete. Are they planning to scan memory for ssh key unlocks or intercept ssh -sk key? This is big, noisy and take developer time. If you log in to a email this leave forensics and is a CFAA violation while risking FAANG security. Attacker needs to shoulder surf.
Most hack is install crypto mining or steal a password. Maybe it is ransom. How do you get 2fa code if you want access to sensitive information? How do you steal hardware keys? You can back door browser, MitB but it gets updated away and you lose access. back door anything and lose access or discovered.
This is not a advanced attacks but it is targeted attacks. People are saying x server never get hacked, but computers get hacked. with X11 the chain is Exploit -> Game over. with wayland you need to go farther.
All of NIXen.
~/.profile
~/.env
~/.xprofile
Exploiting TMPDIR, /tmp race conditions, ~/.mailcap and mutt (I used that to get access to 'premium' binaries under restricted accounts).
If you have Emacs you can do tons of stuff from a single account.
And so on.
Not sure what mutt has to do with X. Maybe you replied to the wrong thread.
~/.xprofile
I agree in a little way to what you say, but if you can write .xprofile you can with no work escalate from the x socket.
Can't give details.
Source?
No, I've seen them. Myself. I didn't get this from a source.
So you didn't report the bugs?
No bugs were involved, just X11 functioning as designed.
So you just don't like X11. Ok. But what was your point then other than share your personal feelings?
It sounds like you're out of your depth in this conversation, Lieutenant. I have ambivalent feelings about X11, but they aren't relevant to the topic at hand.
0xbadcafebee said, "Why do people keep persisting this myth? X11 has authentication. ... What's insane about all these discussions is that NOBODY IS HACKING X SERVERS. There's a thousand other kinds of software on Linux that there is real malware for. But nobody is trying to hijack your X11 session. This imagined threat is a red herring ..." and then nurettin followed up by saying, "x11 has been around for decades, and these things just don't happen. And the reason is that there are much simpler and more effective ways to pwn a box than trying to screenshot an x session or trying to hook for key presses."
But in fact I have seen people gaining elevated privileges by "hijacking" X servers when the authentication was configured to be lax, and I've sometimes configured my own authentication to be lax (because configuring it properly was a hassle), so I know it's not an "imagined threat" from "NOBODY" or a "myth" or things that "just don't happen" because "nobody is trying" them.
But it's not a "bug" either. It's a design tradeoff. X just wasn't designed to provide a security boundary between applications, to encrypt its network traffic, or by default to use any authentication at all other than host-based authentication. Even MIT-MAGIC-COOKIE-1 auth was an add-on, and it is sent in the clear, permitting replay attacks. These are defensible tradeoffs, and ssh -X and the current xauth defaults improve the situation significantly, but Wayland's design provides a lot more isolation between applications by default, which is probably a more defensible tradeoff.
> is why would you wait until people are getting hacked to address a known vulnerability?
Do you have some other way of _reliably_ identifying vulnerabilities?
> It makes no sense whatsoever to leave one open just because.
It makes sense to have security options. If I want to leave it fully unlocked, that's my business, and I possibly have good environmental reasons to do this.
What you should really care about are security _defaults_. And in X11's case I'm not aware of any distribution that ships the server with TCP connections to the sever enabled. You have to go well out of your way to even begin using this functionality.
> Do you have some other way of _reliably_ identifying vulnerabilities?
This is irrelevant given that we are talking about known vulnerabilities.
No, you can't reliably find all the vulnerabilities by auditing the code.
Yes, if you audit the code and believe you have found a vulnerability, you fairly reliably are correct in your belief. And should probably take action even if you aren't.
> we are talking about known vulnerabilities.
In a context which does not involve them. I simply ignored the subtle goalpost shift and addressed the core issue of the article.
> And should probably take action even if you aren't.
Where they action could include "disabling as a default option." Yes?
It does make sense if the vuln doesn’t fit in your threat model. There are always an uncountable number of vulnerabilities and you can never fix all that are found.
No idea of course if the threat model that said boss had in mind made sense. But I always recommend to come up with a reasonable threat model first and then think you can harden against it.
I think the issue isn't that you downloaded random hostile software, but that other software you do use has some sort of vulnerability (recent Unity vulnerability, browser sandbox escape, etc) and an issue like this would allow for privilege escalation.
Wayland doesn't need X11's vulnerability as its only argument, Wayland is a much simpler design that is easier to iterate on because it doesn't assume the client and server are on different machines. The fact that it moves privileged APIs like screen capture behind portals is a bonus.
So simple and easy to iterate on that Wayland compositors are still not as full-featured as X11 desktop environments after more then a decade, and can't be due to protocols no one is able to agree to implement.
>> Wayland compositors are still not as full-featured as X11 desktop environments
It depends what features you care about. X11 doesn't have tear-free video playback, HDR, or as good a security model as Wayland.
X11 has options for tear free video playback; it's not in the base protocol, and not all drivers offer it, etc, but it's acheivable. Fundamentally, you need to send the next frame to the server and ask it to switch frames during vblank (+/- notification), on today's systems, this is more of a coordination problem than a technical one; there's plenty of video ram to go around to double/tripple buffer.
HDR would fit in the X11 model of many bit depths, however the specifics don't really; afaik, X11 has a maximum bitdepth of 32 for pixel values, which means either limiting to 2-bits of alpha channel or using palettes (I think I saw that indexed colors can be defined with 16-bits per channel). An extension might be possible (with everything that brings), but I think the ship has sailed.
I agree that Wayland's security model prevents some undesirable interactions that X11 allows, but it also prevents or makes difficult some desirable interactions, so it's a mixed bag.
> I agree that Wayland's security model prevents some undesirable interactions that X11 allows, but it also prevents or makes difficult some desirable interactions, so it's a mixed bag.
That is so true, I wanted to have a typing sound from my pc everytime I typed on wayland and I looked at LITERALLY every single solution and none of them worked... simply because of the security model of wayland (so things like Mechvibes and alternatives don't work generally speaking)
On one hand, its a good thing to prevent things like password injection etc. but on the other, really?
I got frustrated and I created a lot of github issues on every such project if they said that they are working on wayland and I didn't care if it meant running it as sudo, I just asked them kindly if there was a way or not/ what's the issue here
There are still times where I get a lot of notifications simply because someone commented on those issues
So naturally a lot of people are/were frustrated about it. Not sure if its a good thing or not, but I 100% agree about this comment of yours
Another big issue imo to me feels like ssh, X servers ssh forwarding/vnc just works, Yet I haven't really found ways to do things like VNC on wayland on a server or something as easy (or even possible?) on wayland as compared to x servers, Please let me know if there are apps which do this though, I know about weston but I haven't found ways to work with it/make it work (maybe my skill issue)
Are there any solutions to these things though? Fundamentally that mechvibes things requires an app to view the key from every other application and make a sound, Nothing stops it from being a key-logger as well if it had that capability and Wayland was created with a better security model but as you say and I experienced, that security model comes up with its own compromises and I am not sure if that's a good thing or bad thing....
> Another big issue imo to me feels like ssh, X servers ssh forwarding/vnc just works, Yet I haven't really found ways to do things like VNC on wayland on a server or something as easy (or even possible?) on wayland as compared to x servers
Waypipe[0] for native Wayland applications, and if you need to forward X11 apps there's xwayland-satellite[1].
You can hook xwayland-satellite with Waypipe and forward X11 apps through Waypipe. This way you get even better performance than with traditional X11 forwarding methods.
The other day I was playing Steam/Proton games through the network this way.
Of course, X11 forwarding also works fine on Wayland with ssh -X, but as I said, consider Waypipe + xwayland-satellite.
[0] - https://gitlab.freedesktop.org/mstoeckl/waypipe/
[1] - https://github.com/Supreeeme/xwayland-satellite
> Another big issue imo to me feels like ssh, X servers ssh forwarding/vnc just works, Yet I haven't really found ways to do things like VNC on wayland on a server or something as easy (or even possible?) on wayland as compared to x servers,
waypipe just works too. That replaces any reason to do SSH forwarding.
Also some desktop like Gnome (maybe KDE has similar feature?) offer remote desktop. In Gnome's case it is using RDP protocol instead of VNC.
With the caveat that I haven't used Wayland ... [1]
Waypipe is supposed to help replace things like remote X. I'd be surprised if there's no vnc server that offers a wayland desktop... that would be a big missed opportunity.
For your noisemaker, I think you might have a better time integrating at another level. Either intercept the inputs before the display server gets them, or integrate into the display server itself. X was more flexible, but as long as it's just typing -> noise, you don't need it to have the same architecture as it did in X.
[1] Wayland has no compelling features for me, and X remains viable for me as well. At some point, hardware support might be compelling, or IMHO, something will come to replace Wayland and X that is compelling.
> Another big issue imo to me feels like ssh, X servers ssh forwarding/vnc just works, Yet I haven't really found ways to do things like VNC on wayland on a server or something as easy (or even possible?) on wayland as compared to x servers,
Yes, this should be workable, assuming your compositor is compatible (a meaningful caveat, but not insurmountable):
* To forward one application like `ssh -X`, you want waypipe
* For VNC, it really depends on your compositor, but wayvnc works for many of them. (And GNOME does their own thing and I think KDE has their own official option)
I remember watching tear free HD video in 2011 on a netbook I dug out of the e-waste dumpster in the UC Berkeley CS building basement. Chrome/Openbox/X11. That laptop was literally trash.
Using a compositor fixes screen tearing, no need to use Wayland for that.
>> Using a compositor fixes screen tearing, no need to use Wayland for that.
Right, and that abandons the whole X drawing API in favor of passing around client drawn bitmaps. That was one of the big points of Wayland too - X has a whole bunch of stuff that no modern apps use anyway so lets throw it out and build up a better version of the capabilities we need.
If we abandon the X drawing API and half an OS included (memory management) and use KMS, all that's left is the features that are security holes.
Even a compositor is unnecessary to fix screen tearing these days: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...
Aren't you just doubling down on Wayland being simple? X11 is the kitchen sink here.
What missing features? Xforward?
Wayland is the way to go. The same applies to Flatpak, Pipewire, systemD, etc. I'd say that this is obvious, and doesn't even need to be argued, to 99%+ of those who actually use the Linux desktop. The only opposition to this is a small group of decelerationists with a major, irrational aversion to change.
Having only two major options, X and Wayland, doesn't mean either one is correct. It is generally true that X needs to be replaced, but Wayland is not necessarily the replacement we need. It would be good to have more competition.
On a separate note, I think it's probably true that Wayland has significant drawbacks that preclude it from being an obvious replacement.
I see wayland as the pulseaudio of display.
Everybody is pushing it and trying to convince the people who have problems with it that it's completely fine and their problems aren't important (like blind people being completely unable to use the computer).
At some point the pipewire of display will come along and we'll all forget wayland was ever a proposed solution.
That's not really how any of this works.
Pulseaudio is both a protocol and also an implementation of that protocol. Pipewire also implements the pulseaudio protocol, hence its compatibility with all existing software.
Wayland is a protocol only. Every compositor - and there are many - implements it "from scratch". The "pipewire of display" would simply be yet another Wayland compositor. No one is going to solve the problems of Wayland in one fell swoop by releasing another Wayland compositor. What is actually happening is that problems are being gradually solved by the introduction of protocol extensions, which usually get adopted by other compositors after achieving success in one.
Man I hope you're right
Everything you listed is bloated, slow, incompatible, unfinished or unstable. My system worked fine 20 years ago on far less capable hardware. Now even with high end workstations systems lag, crash or have strange behavior
[flagged]
We are running systemd with all bells and whistles on Raspberry Pi based 1 GB RAM systems. systemd-networkd, iwd, timers etc. The base usage barely touches 350 MiBs. Our actual application is containerized with systemd thanks to broad set of options increasing system security quite a bit. It works great.
You know what's bloated? Replacing all those functions with custom bash scripts or worse system services.
> We are running systemd with all bells and whistles on Raspberry Pi based 1 GB RAM systems. systemd-networkd, iwd, timers etc. The base usage barely touches 350 MiBs.
Er. I have Linux boxes that have 128MB of total RAM doing useful work in my house (not using systemd). This is not the win you think it is.
>systemd-networkd, iwd, timers etc. The base usage barely touches 350 MiBs.
That’s absurdly high for a headless system that’s doing nothing. There are countless millions of embedded devices doing useful work today with 1/10 the RAM. They run modern Linux just fine without the ridiculous bloatware.
Who said that systemd doesn't run on it?
Also, what's bloated about systemd? It's a C binary, while I suppose you are into a ridiculous line-by-line textual interpreter?
My thoughts on systemd are complicated but I wasn't around at the time of systemd Personally it is my opinion that Linux really split in two due to systemd partially because of the idea of the sheer size of systemd code
There are things like https://github.com/Sweets/hummingbird which, I, not even a C person can understand and appreciate its simplicity.
I am not saying that we always need such simplicity, but that I am merely giving an opinion that there are people who actually want to understand what they are running as their root and this sense of "control" really is so hard to get from things like system-d
System-d is also thus a little "bloated" compared to other inits which really show in systems like containers etc. where most developers if possible try to have alpine containers (I have seen this especially so much in golang/rust communities partially because golang is mostly static available and rust can be done the same too or compiled with musl pretty easily)
As such, personally, I can understand both systemd and other init systems, I feel like there are some guides which prefer using hummingbird etc. (https://github.com/comfies/tldrlfs) and I feel like for actually understanding "linux" from linux from scratch, other inits can be good.
Another minor nitpick I have of systemd is that its glibc based, Glibc has some of the weirdest complexities I have ever seen and a lot of package management in my opinion has been built around it and personally it feels like the decisions were made in a different era where different types of resources were constrained and updates weren't as widespread but now it has been a mess which is why we need so many linux distros in the first place with their opinions and package management
I genuinely prefer musl for this, So I prefer things like alpine/void in the process as well yet to me, freedom matters a lot. There should be a freedom of choice in such matters and systemd severely restricts it for many.
I feel like systemd is way too ambitious and which is why it requires glibc to be more feature complete in the first place, not sure if its a good or bad thing but I am merely stating what I feel like.
As I said, I have nothing against systemd myself but I am just giving the nuance I felt like, as I was trying to build my own linux distro trying to make it hyper compact and I came into this rabbit-hole, My philosophy almost was out of curiosity regarding what are the smallest systems which are still functionable (Hint: its tiny core linux which is an absolute pleasure although it isn't "secure" partially because they run everything as root If I remember correctly but )
>We are running systemd with all bells and whistles on Raspberry Pi based 1 GB RAM systems. systemd-networkd, iwd, timers etc. The base usage barely touches 350 MiBs
Okay but what are your thoughts on alpine, Alpine's motto or the first thing you see in bold letters on their website (https://alpinelinux.org/) is
Small. Simple. Secure.
Alpine Linux is a security-oriented, lightweight Linux distribution based on musl libc and busybox.
Combined with either gcompat to run glibc or personally I genuinely prefer golang/rust applications (mostly golang) like running gitea on alpine etc. and I found it to be an absolute pleasure server side to work with mostly, except sometimes software download especially python when I was running alpine on android using userLand was a somewhat-issue but maybe I had skill issue or something but I genuinely learnt a lot trying to install python on it.
Bun/Deno just works out of the box, in fact deno is even available in the apk format of alpine out of the box
I truly love alpine/appreciate its message. I feel like systems should be small partially because that means that such software could run even on much older systems just out of the box
Alpine features raspberry pi images and there is dietpi which has some decent low iso file sizes, Check them out as well if possible
Personally I love alpine but I also love the idea of using debian or some immutable distro which uses systemd and then running alpine in container, it seems to be the best of both worlds really.
You might be interested in Devuan (Debian but with OpenRC init), or for immutable, Guix System (Shepherd init).
When distributions started to use systemd, it was extremely buggy.
The first 24h of me using it, I found 3 different bugs in journald where it was losing data.
I'm currently using systemd, but it was far from being ready when all the fanboys with very basic use cases were insulting anyone who complained about it.
350MB? I run a CWM under 350MB under OpenBSD plus Dillo and a few of terminal tools under i686.
[flagged]
WTF? You can't address people like this on HN, and comments like this are completely unacceptable. You might not owe containers better, but you owe the community better if you want to participate here. Please take a moment to read the guidelines and make an effort to observe them if you want to keep participating here.
https://news.ycombinator.com/newsguidelines.html
Wayland won't run fast on my n270 CPU based netbook. Pipewire it's good but sndio it's much faster. And SystemD it's a joke compared to the simple setup at /etc/rc.conf under OpenBSD and rcctl.
People keep talking about X11 security in the context of servers and networking, but I'm more concerned about exposing more attack surface to local malware (i.e. keylogging other processes, capturing program state).
Of course X has authentication, but once you're in, you're in. There are no elevated windows, screen recording permissions, or any sort of keylogger prevention. That was normal a few decades ago, but the world has moved on since.
There's no real reason it can't do any of that, it just doesn't and there are no real plans to add these features.
I'm not convinced by the "if you run a program you should assume you've already been hit by a CIA 0day". Obviously nobody is dialing into your X11 server from the internet, but this is a relatively easy nobody:nobody -> root/wm-session/whatever elevation of privilege.
If malware is in your X server, doesn't that mean it's running under your user account? And if that's the case, then couldn't it just steal your data right off the filesystem without needing to get it from X?
The valuable data on your machine might not be something permanently stored in the filesystem, but ephemerally recorded in a process. Say, a memorized password.
Couldn't the malware still get it without having to deal with X? E.g., by attaching to your process as a debugger?
Try doing that on a regular Linux install, you might be surprised.
I assume you're talking about Yama, but that's not universally enabled by default. And even if it is, malware could do something like wait for you to open Firefox, then immediately kill it and launch its own version with its own code already baked in.
It's enabled in all mainstream distros that I know of. I work on debuggers and this is the single most common issue that people report with attach.
And yes, if the malware is running under the same account that you use to login, it can do a lot, X or no X. That's where various forms of sandboxing come in. And the problem with X is that it is basically impossible to properly sandbox an X app.
It could be a remote X client on another machine.
> Why do people keep persisting this myth? X11 has authentication. You can either rely on filesystem permissions, or a shared secret. The same way thousands of other network servers work.
Any program you incidentally run within a typical graphical user session will have access to the X socket and a cookie, they will be able to connect. And after they connect... They basically just can do anything they want with zero real restrictions, including most likely some fairly trivial paths to root escalation. Even if they're running inside of a sandbox or container, with only an X11 socket poking through.
This problem was realized a very long time ago with the security extension but most of it never really caught on.
> Any program you run on a computer (especially a Linux computer, which lacks modern OS security measures and has constant privesc kernel holes) exposes you to security flaws. There has yet to be any computer system designed that a hacker can't break out of. If you intentionally download and execute a program, you are rolling the dice, regardless of what the software is.
If you believe this is true, then what exactly is the point of any security measure? Why bother using isolation and sandboxing, or passwords? Why does Windows bother patching flaws if they know there are certainly more of them and they will never fix them?
Do you by chance also smoke because you're going to die anyways?
> What's insane about all these discussions is that NOBODY IS HACKING X SERVERS. There's a thousand other kinds of software on Linux that there is real malware for. But nobody is trying to hijack your X11 session. This imagined threat is a red herring designed to bolster the argument for Wayland's horrible designs.
Lol. That's primarily because the Linux desktop is utterly irrelevant, not because nobody would care to do it. Is it really surprising that attacks against desktop computers would focus almost entirely on the OS that has 90+% of the market share? We don't get free software OS desktop malware for the same reason we don't get free software OS software ports.
Watching and waiting with security was a totally acceptable position in the 90s, but we get the general gist these days. We need security-by-design.
On the server side of Linux where Linux is relevant, the situation is much more impressive; auditing using eBPF, sandboxing with gVisor, microVMs with Firecracker and cloud-hypervisor, isolation using namespaces and seccomp-bpf and more.
On the desktop side, people are still arguing over whether or not it's a problem that any X client can by default silently keylog the entire system trivially. Okay, but a lot of us actually see that as a problem, and we're not interested much in "hearing you out". Most of us recognize that the Wayland protocol has warts (and too many damn protocols), but X11 has many more warts. I didn't care what was the successor to X11 specifically, I just cared that we eventually made some progress. Most people have nothing to offer here and just suggest we should've stuck with X11. Okay dude, but nobody wants to. The X.org devs would like to move on. The desktop environments really would like to move on. There was basically one serious guy that actually wanted to work on improving X11 and he turned out to be kind of crazy and couldn't stop breaking shit anyways.
You could use a proxy server (regardless of the protocol), which might improve security (and other things) better than other methods do, I think.
There are problems with both X11 and Wayland, although I dislike some of the features of Wayland.
Yeah, with Qubes that's exactly what they do. I forget what the software is called, but they use an X11 proxy that tries to enforce policy.
That said though, that does require you to proactively run every X application with this sandboxing. For Qubes which forces everything into VMs this is doable, but for most other systems there isn't an obvious way to handle this sort of thing.
My only major complaint about Wayland that can't just be fixed relatively easily is Mutter refusing to support SSD. (Well, the actual technical problem could be fixed relatively easily, but the social one not so much.)
Firejail uses nested X11 servers like xeohyr or xrdp to restrict application access to the primary X11.
Hmm, I thought it was Xephyr but I was wrong. It looks like Qubes actually does something even more involved:
https://doc.qubes-os.org/en/latest/developer/system/gui.html
This makes sense though, given the way clipboard works in Qubes. I think I must've entirely mistaken how Qubes works for an entirely different scheme.
> including most likely some fairly trivial paths to root escalation
Why would this be likely?
Because there is no isolation whatsoever. A terminal running as root can just be typed into. Some apps can be coerced into code execution when messaging them over X11. You might have to get a little creative, but there's a lot of room for creativity.
Needless to say, though, if the user doesn't have anything open with root privileges or cached sudo, then you probably won't be escalating to root with only X11. You'd have to wait for something to crop up. I'd reckon though if you are resident for long enough during a desktop session you'll find an opportunity. (And on most desktop systems that still, of course, leaves the usual points of interest outside X11. But if you wanted a way to escape, say, Flatpak containment, this is definitely a good start.)
X11 had the distinction between trusted and untrusted X11 clients basically forever. But nobody bothered to even spend the minimal amount of work to make this usable in practice^1. This had two reasons: 1.) It is irrelevant when you run the programs as the same user so nobody bothered (and no: Wayland does not help: https://github.com/Aishou/wayland-keylogger) 2.) It is more fun to simply pretend it is unfixable broken and write something new (something any good engineering manager should have stopped immediately).
¹. I used to use this and also fixed some bugs in some programs. The main problem when I last checked a decade ag was that some important extensions such as composite would need to be exposed to untrusted clients.
That Wayland keylogger is not the same thing. X11 has several mechanisms (XTest, XRecord, XI raw inputs) to receive a global raw key input stream, accessible to anyone who connects to the X server, without even making a visible window surface. It even bypasses grabs, meaning that your lock screen password entry can be snooped on.
The Wayland keylogger acts like an application; all Wayland compositors will only send key events to the focused surface, so the user has to focus an active surface in order to get key events. Even in the scenario where you've LD_PRELOAD-hooked all applications, you still will never get the lock screen password, as the compositor never sends it out across the wire.
LD_PRELOAD is problematic from a security perspective, but it's not Wayland-specific: the same issue is true for CLI applications and X11 applications, and any attacker with the ability to write files could also just replace your binaries with malicious ones (stuff them somewhere into ~/.hidden, and then add a $PATH entry to the start).
I think you did not understand my point. X11 has several such mechanisms, yes, but it also has the concept of untrusted clients that disallow the use of these mechanisms and could be used to provide safety similar to Wayland. The point is that this mechanism of untrusted X clients was neglected and I gave an explanation way.
Yes and your response in the whole thread reading top to bottom was the first one that really taught an old dog a new trick. I've been using gnu on x11 since 1991, been annoyed by fellow student's audio streams on my work station back then, and I've never heard about trusted vs untrusted x11 apps.
I wonder how this debate was mainstream? did some gamers try to squeeze 3 extra percent by taking the protocol out of local stacks? there must have been better ways to do that, without throwing out all X11 benefits?
to this day I'm annoyed I can't have a decent window manager integration on gWSL because the compositor doesn't implement the full window manager protocol.
See the ssh manpage for an explanation of untrusted/trusted clients. This debate was mainstream. Basically, some people presumable paid to work on Linux graphics decided to implement something new instead of doing their job, and gave talks about why X is fundamentally broken. I believe the driving force might have been the hope to support Linux on mobile or embedded devices, and X seems just unnecessary (although I think network transparency would be super useful on mobile devices). Some gamers certainly believed nonsense such as "all X programs are forced to use ancient drawing primitives and so programs will be much faster with Wayland". Wayland developers certainly did not do anything to stop such misconceptions. Later there was disappointment because obviously it was not faster (the drawing model for modern clients is essentially the same), but other myth such as the "fundamental security issue" prevailed.
It's like if Wayland is not just a graphical system, but a full business plan.
Control upstream, then companies wanting solutions will go to you first. Because why go to someone else in the FOSS market, when there is no certainty the code or standard (extension, protocol, etc) will get accepted, forcing you to maintain a fork? With IBM-RH and Ubuntu doings eg., it's hard to say FOSS is immune to vendor lock-in.
> It's like if Wayland is not just a graphical system, but a full business plan. Control upstream, then companies wanting solutions will go to you first.
Wayland is open source with a fixed core protocol that's extremely stable, which anyone can build on. New protocols are constantly proposed. The core is minimal and defines how applications interact with the compositor to render and produce the final output. Control by a single entity is virtually impossible. Wayland ensures everyone has a voice because it's an open protocol which means discussion and development are done in the public.
in _reality_ it gives stack owners full proprietary control.
specifically the wslg stack does not enable Linux gui apps to smoothly integrate with the Windows window manager, because some bits are missing in the Windows Wayland stack, clipboard, window decorations, thumbnails, maximize into a part of the monitor? nope. and no patches taken. supposed you figure where to offer them and how.
It's unfair to claim Wayland is inherently different from X11 in this regard. Both are just specifications, and there are also proprietary implementations of the X11 protocol, primarily for Windows and enterprise settings.
The point is: the X11 spec is much more complete.
> Some gamers certainly believed nonsense such as "all X programs are forced to use ancient drawing primitives and so programs will be much faster with Wayland".
This is incorrect. Kristian Høgsberg has explicitly stated that a primary motivation for Wayland is the reduced need for a central X server, as many programs already bypass it.
A Wayland compositor is even more centralized as it combines compositor, Window manager, and server while in X these could be separate components. I also do not know any program that bypasses the X server. Are you talking about programs that you can start from the text console and which then do graphics directly? Those are very rare.
There are reasons for those architecture differences.
Wayland is an evolution of the previous design. X11's architecture had clients sending drawing commands to the X server, a method that became limited and required extensions over time. Wayland's approach is: applications perform their own rendering into their own separate buffers, then tell the compositor when they are ready. The compositor takes those buffers to produce the final image.
Because those buffers are separate, enhanced security is a direct side effect. Wayland is the result of decades of experience and represents the current way of doing things.
Sorry, no modern X clients sends drawing commands. This is the nonsense I am talking about.
Posting from another account.
I'm aware that extensions exist now, like present, which make it possible to send buffers, similar to how Wayland operates, so you don't have to do things the primitive way.
However, to claim to speak the X protocol, you still need to support the older functionality, that's what I mean by a tremendous amount of functionality to support. The moment you get rid of that old functionality, you've essentially created a new protocol, which is what Wayland is.
How is that point nonsense? I don't want to see X go, but I don't think it's reasonable to prevent progress.
If you know these extension exist (for a long time), why spread the misinformation about "drawing commands" in the first place? A client does not need to support old functionality. A server does for backwards compatibility and this is a good thing! In fact, breaking decades of compatibility is the worst blunder of Wayland. The idea that this is a "tremendous amount of functionality" or a huge burden to maintain is also misleading, first because some drawing commands from the 80s are not a lot of functionality to support from a modern point of view, and also because all this is still being maintained anyway, just much worse because the resources redirected to Wayland. And even if one had deprecated some stuff eventually, this would not have broken compatibility and many other features at the same time as Wayland did.
It's not misinformation, that's how X still works. Clients do all kinds of things. New programs aren't like 80s ones but your X server still must support every operation clients expect.
Wayland doesn't break anything, it's a completely new protocol. Claiming Wayland breaks your use case is like saying systemd broke old init scripts. It did because it's a different system.
Wayland isn't trying to be Xorg 2. It's a protocol. At its core it's only a compositor protocol. Everything built on top is up to the implementation developers.
The logical problem with your argument is that as long as we want to support old clients, we now must support the X server in parallel to Wayland. So there is nothing gained. And the moment we can stop supporting them, we could do this also in X. And yes, Wayland being new and incomplete both creates a huge amount of problem which nobody needs.
Wayland gives us a lot. What you don't realize is that Wayland _is_ X12.
So far Wayland gave me only headaches and I do not see what it offers that X does not already provide. And the fact that Wayland make their case by lying, etc. the drawing commands BS, network transparency does not work (I feature we do use every day), etc. and the fact that important use cases such as accessibility are now treated as an afterthought that there are diverging implementations with inconsistent support for important functionality, ... all this does not build confidence that the developers even remotely know what they are doing outside of their narrow view on the Graphics pipeline itself. And this after decades of effort. Maybe it is too late now to save X, but Wayland was a terrible idea, not the idea of developing Wayland itself as an experiment with open result, but to declare X dead and Wayland its successor long before it was ready and before it was clear that it is actually a better replacement (so far, it isn't).
Those are not lies. I don't think you know what you are talking about. If you knew, you would know that waypipe + xwayland-satellite works even for forwarding X11 clients over waypipe. I use it myself every day, but it's pointless to discuss it with someone who isn't interested in listening, only in spreading the same lies as everyone else.
> Everything built on top is up to the implementation developers.
and that's exactly creating the problem: Window management for example is left as an excercise to the reader. thus (my point above) the WSLg interop for graphcial applications _sucks_ compared to where X Servers already were. and if MS doesn't implement what's needed, it won't come. no way to fix it in the Linux or on the Windows side. the MS Wayland thingie in between tightly controls what is possible.
You're aware of the guideline about throwaway accounts? This isn't good for community (or discussion).
Thanks for pointing that out. I just learned about the policy, my bad.
As far as I can tell, enabling the trusted/untrusted security feature breaks a lot of basic features, including clipboards, XRandR, GPU acceleration, XKB keyboard layouts, and whatnot. It's theoretically available but practically useless.
Xnamespaces looks to be more promising, but as far as I can tell that's still a WIP with little documentation, and from the documentation I can find it looks like it still breaks things like clipboard functionality.
Well, the threat is shared access to resources like clipboards, so securing against this of course breaks the clipboard. Pick your poison.
> Pick your poison.
Permission system? X11 with a permission system is the next logical step for Unix graphics. There is absolutely no need to break 40 years of graphic software, or throw away 40 years of accumulated features.
Yes, but even a permission system can only give a program access to the clipboard or not. You can't deny a program access to the clipboard and complain that the clipboard doesn't work.
> something any good engineering manager should have stopped immediately
Who exactly should and can control the horde of OSS developers?
They were paid by redhat.
[flagged]
Solaris had Trusted Extensions for X11 which shipped with Trusted Solaris 8.
In 2000.
Solaris 10 had it built into the base OS and integrated into both the CDE and GNOME desktops they shipped. With OpenSolaris it was released as open source under the non-GNU CDDL license.
In November 2006.
Wayland was started in 2008.
I don't think I've seen X configured to run as root in probably 15 years. If anybody still does anything like that, they're literally asking for it.
Hmm.. On my Debian ps axuw|grep Xorg says
That looks like the display manager (i.e. login screen) running on vt4, which is probably not where you are logged in. Does it switch to another user when you log in?
Note you have multiple virtual consoles which can have independent X servers.
No, that's actually my real and only Xorg, it's the child process of /usr/libexec/gdm-x-session and that process is owned by my real user id, and the Xorg process provides /tmp/.X11-unix/X1 that e.g. strace -e connect xlsclients shows is the socket it uses. Notice also that it uses a significant amount of memory and has consumed a meaningful amount of CPU time, much more than a dm would do.
Good point about display manager though, I suppose it's not using Xorg then as I do know there is a login screen waiting at vt1 but that's the only Xorg process. Maybe the gdm3 incorporates a Wayland implementation in Debian 13.
I think I ran into some display managers that do not start a new X session for every user. However I was trying out some rather non standard configurations at the time, some of which required root access for driver specific features.
Digging deeper there are mechanisms for long time on internal X side (see https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/Xserv... ) - granted never seen it practically implemented.
And going to rabbit hole there are even proof of concept security implementation named Xnamespace for Xorg fork (needs polishing and much more patches but looks doable. see wip documentation: https://raw.githubusercontent.com/X11Libre/xserver/d2b60a3d6... )
The way X11 developers ended up fixing this is by creating Wayland. This way privileged operations (like keylogging, screen capture, etc) require the cooperation and authentication through the display server.
That sort of solution is cancer if you want to do anything the display server authors didn't think of. I've got a script that I invoke with a global hotkey that determines the window title of the currently focused window and fuzzy matches it against pipewire audio stream names so I can mute the focused window with a single keypress. If I want that to work in Wayland I'm pretty much up shit creek because somebody with their head in the clouds thinks that my needs are super dangerous or something.
Wayland devs for the longest time thought implementing what was needed for accessibility (mainly, global keyboard hooks for Orca to work) was a security problem. Nevermind the fact that nobody hacks X servers, or your wayland compositor, because if I wanted to hook your keyboard with a keylogger, I'd hook it through evdev. And then you wouldn't even know let alone be able to do much about it if I did it properly.
Wayland doesn't say "this is impossible", it says "this is out of scope of the core display protocol, implement this somewhere else".
Which, well, we do. Practically all the X usecases are covered on Wayland systems now. Screen sharing, screen clipping, global hotkeys, file pickers, getting the window title like you said... I can do all of that on KDE, right now, under Wayland.
Can you do it in a way that isn't KDE specific, and will work if you change your DE one day on a whim?
If you change to another DE that has less capabilities than KDE, of course you can't do it. Emacs and LibreOffice Writer will have vastly different capabilities and people can choose what they want based on the capabilities they desire.
And that is exactly the problem. Now things like accessibility (or, really, any feature that the maintainers of the core protocol didn't think were "necessary" because they like minimalism) have to be implemented by each and every compositor. If the compositor doesn't implement it, your screwed unless either you convince them to add it or you add it yourself. Talk about causing huge amounts of fragmentation for absolutely no reason.
The proper thing Wayland should've done is waited until Wayland had reached feature parity with X, then released it to the world and started acting like it's the future.
Wayland was specifically built to support things that aren't desktops, so feature parity with X was never a design goal of Wayland. The idea was that Wayland would be a super-flexible "you give me a window and events, I give you rendered bitmaps" kind of protocol, and then desktop functionality would be layered on top for people who wanted a desktop. Not everything needs to be a desktop (e.g. car infotainment displays, KDE Plasma widgets, etc), and some protocols would be super limited if they had to fit in a desktop mold (e.g. VR displays[0] with apps in non-planar windows).
The main mistake FD.o made is that they didn't get consensus on a "Desktop Profile" extension, so all the DEs wound up implementing their own thing. This is still fixable, just very annoying until we have agreement on this shit. I think that's what you meant by "feature parity with X".
[0] Currently, every desktop VR setup has to have two layers of compositors. VR applications have to communicate with a special VR compositor that then draws normal desktop windows with the contents of what should be hitting each eye of the VR display, all so it can pretend to be two normal displays.
I could say the exact same thing about X, A lot of the problems people had with X historically was that developments goal was to "create mechanisms not policy" and people just wanted a desktop environment that worked.
An antidote on non desktop use of X: the other day I wanted to show a program on my phone, there are many good ways to do this, but I picked none of them. Instead I had just installed a terminal on the phone and noticed they had an X11 package, So A few minutes later I was the proud owner of an X server on a phone. And you know what... It was pretty great. My gaming system load and temps dashboard were displaying just fine.
Despite using X for many, many years, I had never just sat down and played with a bare X server, I had only dealt with it through the lens of a locked down, encumbered desktop system. It was like having a network attached monitor. From whatever system I was using as a desktop system I could just go "display this on that monitor", in this case a phone. Based on that experience I put a raspberry pi on my TV running a bare unprotected X server because having a network attached monitor rocks.
Yeah, pretty much. I would be less disagreeable about Wayland if they had solved this problem early (and yes, they should've thought about this early during Wayland because the most prominent target is desktop environments). But they didn't, and I don't even know if they'll come up with some unified solution that all DEs/WMs can agree on or whether they'll just keep allowing DEs/WMs to do their own thing. Either way, fragmentation is never a good idea on what, I think, many would consider critical functionality. At least, I consider the requirements to implement accessibility to be rather critical, which is the primary reason I still use Xorg.
If I have a kiosk terminal, why would I want the overhead of, say, screensharing? Also, isn't this the point of libraries, so that you only have to implement stuff once, and you can reuse it in different projects? Like you can build on top of wlroots just fine.
> The proper thing Wayland should've done is waited until Wayland had reached feature parity with X
How on Earth would you expect a fundamental protocol to be developed behind closed doors?! Wtf even.
> If I have a kiosk terminal, why would I want the overhead of, say, screensharing? Also, isn't this the point of libraries, so that you only have to implement stuff once, and you can reuse it in different projects? Like you can build on top of wlroots just fine.
Yeah but again this fragments the ecosystem massively. If people really wanted flexibility they could've just made it a configure option or something equivalent?
> How on Earth would you expect a fundamental protocol to be developed behind closed doors?! Wtf even.
Your making a pretty big assumption here, aren't you? I never said it had to be developed behind closed doors. It's the "lets just obsolete X11 even though Wayland can't even replicate a quarter of it's functionality right now now now because of security security security" that irritates me. If they had worked on Wayland and obsoleted it once they had reached feature parity, that would be releasing it to the world. Then they would've had far less friction and the transition would've been a lot smoother. Would it have delayed Wayland by maybe a decade? Sure, but I see little issue with that. IMO that probably would've made Wayland even better.
Who is the supposed agent mastermind singlehandedly developing Wayland and deprecating X11? You do realize there are multiple people working (having worked) on both in their free time and each have agency and their own incentives. Separate people have had enough of maintaining X, while another group of people enjoyed working on Wayland. Some indeed moved from one to another but there were no coordinated attempt at hijacking the Linux graphic stack or whatever..
So you tell us Freedesktop.org people
1. Claiming XFree86 evil
2. Forking it as X.org
3. Shortly after all distros finished switching to X.org, declaring it obsolete and announcing wayland
4. stopping any major development on X.org immediately even though it's was the one and only option at the time
5. and channeling all development resources (not only on the display server, but also downstream users like toolkits, DEs etc.) to rewrite their code for a protocol that wasn't even gonna be usable until a 10+ years later
6. Depraving Linux desktop users from 10-15 years of improvements and making Linux graphis stack stuck in 2000s
wasn't hijacking the Linux graphic stack?
I mean had Steve Balmer wanted to sabotage Linux in desktop he couldn't do better
If you want to continue working on Xorg you can. You could have done that 10 years ago as well.
That's the issue. Because wayland punts on so much functionality that used to be available with standard interfaces in X11, it fragments the ecosystem to such a degree that all these useful little utilities just don't really have a means to grow.
> If you change to another DE that has less capabilities than KDE, of course you can't do it
It's not inherent. If I change to another X DE, I can keep all my other programs and the features they implement.
:(
> Practically all the X usecases are covered on Wayland systems now. ... global hotkeys ...
Are you sure? I looked at that earlier this year for a personal tool I wanted to create and found no way to do it on Wayland (On X, I did it just fine).
I had a long back and forth about this very thing with both Claude and ChatGPT, and neither conversation was fruitful: every option had some dependency (like switching to KDE, or similar).
As I understand, blind people can't use wayland right now.
I know some blind people who tolerate it but yeah, I find it completely unusable at the moment. I haven't tried Gnome recently but last time I tried it I had apps like Bitwarden malfunctioning in some very, very weird ways that just... Never happened on Xorg. If I remember right, it was things like forms not being read properly or something, can't remember off the top of my head now. But it certainly didn't leave me with a good impression; it made me think this Wayland thing was just half-baked. Also, Orca modifiers were passed-through directly to the compositor and Orca wasn't allowed to intercept them either, which made just using my computer feel awkward since I'd always need to remember to turn off caps lock every time I wanted to do something even remotely complicated. I've heard that Gnome has solved this but as I said above, I think this may be a Gnome (and at most KDE) thing, and not something that everybody has decided to just do.
> That sort of solution is cancer if you want to do anything the display server authors didn't think of.
Hey come on man, a locking screen saver is a totally niche application. No demand for that.
xscreensaver works just fine. It only needs to keep nosy roommates out, not the NSA. Not that Wayland would stop spooks anyway.
It doesn’t lock the screen properly under Wayland. There’s an abyss of complaining about Wayland on jwz’s blog.
https://www.jwz.org/blog/2025/07/xscreensaver-wayland-and-lo...
For some weird reason I can't access it, it just redirects me to this image about hacker news. Did he just configure his webserver to just universally display that image? Even if I manually enter the address into my address bar it does that so I assume that that's what he did...
The page sets a cookie when you visit it from hackernews and will redirect you to the image until you delete the cookie.
That’s new. Argh.
like 10-15 years
The cookie is new, AFAIK. The expressed contempt for hners is of course eternal.
The author of xscreensaver holds hn in a certain amount of contempt, yes. Just go with it.
Also balls
Totally unrelated, I like your nickname :)
You can write a Gnome Shell extension or whatever the KDE equivalent is.
That way you also prevent things possible in X11 to be impossible in Wayland, like a window setting it's own position, if you were to want that.
Good. Disallowing software to position its own windows has been a major usability improvement over the X11 days of software making stupid positioning decisions and having to patch it out everywhere...
Yeah, assuming all users and all software should work the same idea is a great way to get people moving to a new platform.
Maybe, just maybe, some people know what they want, and if they want applications that can put themselves in specific corners, why shouldn't the desktop let the applications do that, if the user is OK with it?
... Not allowing windows to determine their own position is also a usability nightmare.
Fixing X11's security would of broken window positioning as well. Since that is a security issue.
The deal here is that the only way to fix X11's security issues is by breaking all those types of workflows and forcing application rewrites to implement them in authenticated ways.
So if you are going have to go and break all that stuff, why not fix a crapload of other problems while you are at it?
Calling Wayland "X13" may have avoided a lot of misunderstandings, but it probably would of caused others.
> Since that is a security issue.
Maybe it's both? There are applications with good reason that need to chose their location themselves, and users who want that type of behavior, so it's definitively not just a security issue.
> The way X11 developers
X.org developers, not X11 developers.
> X11's practical absence of any security mechanisms for user sessions means you should probably not run any kind of low-trust UI program
This has nothing to do with X11 or even UI at all. You should not run any low-trust program whatsoever (outside of a container). Any program that runs as your user can change your ~/.bashrc or any other file on your homedir.
Of course this is a feature that you want, for example when you edit these files with a text editor.
Any application can literally log EVERYTHING! It's good to see wayland getting better everyday
Some oldschool legends are still fixing bugs in xorg.
Alan Coopersmith in particular. He even fixed a bug I reported. :)
(I forgot in which app it was but the bug report should be somewhere still; it is not old, perhaps 2 years ago or 3 years ago. The xorg app in question behaved oddly when doing "--version". I only noticed this because I wrote a ruby script that displays which version of programs are installed, and that one kept on making problems, whereas the others worked fine. After I reported it, Alan fixed this very quickly. I think it was some missing flag in the C program or something like that; right now I can not remember the name of the program ... my brain tries to say xrandr but I think it was not xrandr but a less frequently used program somewhere in the FTP listing ...)
Keith Packard, another legend, was proposing X11 improvements in 2018. [0] He doesn't seem to be paid to work in X11 or Wayland, thus being free to float ideas he likes.
[0] https://keithp.com/x-ideas/
> Bonus points if you have any Tcl/Tk apps running, where you can simply transmit commands for the program to run via the X server.
Back in 1996 the level of X integration in Tk was awesome; I had a shell tool that could make Netscape do stuff by firing MIT magic cookies at it.
In a contemporary setting, it's pretty horrifying.
Didn't Netscape use Motif?
It did, but it could receive messages thanks to MIT Magic Cookies, which you could send because of Tk’s excellent integration with X. I can’t remember now if it was the browser you could also effectively spy on via similar means. Long time ago. I have largely forgotten how my tool worked now but the code I wrote (modified wish shell) might still be out there.
These are all "no way to prevent this, say users of only language where this regularly happens" type problems though.
The send command in Tk is lel, but can easily be effectively closed by rebinding it to a no-op.
You do realize that your web browser is executing code feeded by remote servers (RCE). But it is important to fix the windowing system. /s
Coverity is pretty good about finding these kinds of bugs. Is there a reason why a project as significant as Xorg isn't taking advantage of their gratis access for that tool?
I think the short story is that the people who develop Wayland are the people who used to develop Xorg.
And they’d rather spend their energy on giving you a compelling reason to switch, rather than using it to add to the reasons for staying on a project they now consider obsolete.
You may disagree with their assessment, but you can’t blame them for how they decide to prioritize.
> I think the short story is that the people who develop Wayland are the people who used to develop Xorg.
They certainly say that to people a lot. Oftentimes the person saying it is young enough that I wonder how much time they spent working on X.
I started programming on the Tandy TRS-80. Never made significant X11 contributions.
So I doubt age is the deciding factor ;)
[flagged]
The main pain in linux is graphics. It's a shame.
Graphics is the reason Linux got over 1% desktop market share. When you have a problematic piece of hardware, sure, it sucks. But most setups will run Steam games near native quality out of the box. I'd blame the hardware not Linux.
Xorg is indeed a lot of painful complexity. This being said, the software is not Linux specific, and for modern Linux distributions, it is more and more a legacy technology.
Our chief pain is graphics... graphics and audio... audio and graphics... our two pains are audio and graphics... and wifi hardware support... Our three pains are audio, graphics, and wifi hardware support, and an almost fanatical devotion to the command line.... Our four... no... Amongst our pains... are such elements as graphics, audio.... I'll come in again.
Nobody expects the Linux distribution!
Don't kill xorg! :(
_Roughtly_ speaking, X11 is only there for old games and the steam client. It is even worse with the steam client since the main executable in still 32bits.
> _Roughtly_ speaking
_Strictly_ speaking X11 is only there because, after all those years, Wayland still does not meet expectations.
huh? Nope. x11 is here only for legacy support... and that valve client (which master binary is still a 32bits executable hardcoded on x11 and GL).
How did Twitter get away with taking X.com?
If it was the other way around, would an open source or whatever project have been able to take Twitter.org?
It was from x.com in the late 90s, merged with PayPal, Elon took the domain with him.
Ah forgot about that. Didn't think it'd predate x.org
Would Fil-C have prevented the first or third?
By my reading, it would have prevented all of them.
[flagged]
[flagged]
> Fil-C doesn't provably prevent anything.
It does. I have lots of documentation to show exactly how and why.
> It is a hobby project by a dilettante.
Wow
> It is a hobby project by a dilettante.
You could say the same about thousands of open source projects on which trillion dollar companies depend on. Maybe these kind souls deserve more respect, buddy.
[flagged]
One of the use-cases of Fil-C is to prevent security issues in old C code that's much older than Fil-C itself.
You mean i can compile an old program with Fil-C and my executable will be free of security issues ?
> Probably not seeing how the code for at least the 3rd was written in 1994, some 30 years before Fil-C existed.
How is this possibly the most charitable reading of parents comment, and honestly, do you think that's what they meant? You can't read that in some other way, where maybe parent wasn't actually asking about time traveling but something else?
Yes it was bit uncharitable, but I couldn't resist based on the way he phrased it. It was just a joke.
"Preventing" the vulnerability would indeed require going back to 1994. Since it is a vulnerability that has existed in every display server released since then.
I meant it in the sense of continuing to run old C code like X.org in a safer way without unnecessary rewrites to memory safe languages. These vulnerabilities, like this one that's been in the wild as you say for 30 years uncaught, will continue to be found. Something like Fil-C is really useful in that context.
I also said "would it have" -- I don't really care about timeline. Obviously Fil-C is a recent development, that doesn't make the question I asked any less interesting.
From HN guidelines:
> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
Perhaps next time, resist the urge :)
Considering how nicely Weston with SW rendering runs in Fil-C, I bet that the X server will run fine in Fil-C, too.
Fil-C exhibits the lowest overhead in code that spends its time on primitive bits.
Fil-C exhibits the highest overhead in code that chases pointers.
I'm assuming X is the former. Weston seems to be.
[dead]