by The two articles are cute and pretty accurate.
The blog post from JWZ is bitter, not constructive and contains some nonsense.
We were expecting it. You don’t go telling people I told you so for 20 years and then not catch the opportunity to do it once more when it happens again. And it did happen again, yes, so enjoy the moment. Let’s have one more I-told-you-so moment, if it can help us react even more and make things better for 5.0, let’s embrace it.
If you are not running XScreenSaver on Linux, then it is safe to assume that your screen does not lock.
No. As mentioned above KDE has a distinct locker and so has light-locker, so no, XScreensaver isn’t the only design which is safe from library/toolkit crashes.
You will recall that in 2004, which is now seventeen years ago, I wrote a document explaining why I made the design trade-offs that I did in XScreenSaver, and in that document I predicted this exact bug as my example of, “this is what will happen if you don’t do it this way.”
He did indeed and that design choice made a lot of sense. It provided a higher level of safety though he didn’t address the needs people had.
JWZ’ message of wisdom needs to be more pragmatic if it wants to be heard and taken seriously. If I tell you “don’t go out of your house, you’ll die” and come to your funerals 17 years later to tell your friends I had told you so, well, sure, I’ll have a point but who cares? People want to play with knives, go out of their house, drive cars fast on highways and go across the street. Telling them it’s inherently unsafe just misses the point if that’s what they want to do. People want a pretty lock screen, they do. So let’s work on that.
I wish JWZ had thought about a design that combined safety and a rich greeter, because at the time it would have provided a solution along with the warning. Instead the warning was lost because the provided solution did not address the need. And by the time we had solutions, the warning had been mostly dismissed because it wasn’t pragmatic.
Looking at light-locker and KDE they seem to have gone further than JWZ’s reflexion and provided a solution to the actual user’s need while keeping the promise of safety.
When we first saw and shipped light-locker this didn’t hit us, because we had already replaced xscreensaver with alternatives (gnome-scrensaver and mate-screensaver at the time), i.e. we had already accepted the security risk to address the need that was left vacant. By the time we saw the likes of light-locker, that warning was mostly forgotten about. It’s true, and it’s a pity.
When cinnamon-screensaver was written it was replacing gnome-screensaver, and again it didn’t have that warning in mind because at the time we hadn’t thought of doing what light-locker did, and doing what xscrensaver did (i.e. going toolkitless) simply wasn’t acceptable.
And they went and made that happen.Repeatedly.
True, they did, and we did right now. Because they had to. JWZ misses the point on this. You can’t ask people to not do what they want to do and what they expect to be able to do. If they want to cross the road, you’ll need to make it safe for them to do so. And you know what? It will never be as safe as NOT crossing the road. Having some wise guy telling them NEVER TO doesn’t help, at all.
Every time this bug is re-introduced, someone pipes up and says something like, “So what, it was a bug, they’ve fixed it.” That’s really missing the point. The point is not that such a bug existed, but that such a bug was even possible. The real bug here is that the design of the system even permits this class of bug. It is unconscionable that someone designing a critical piece of security infrastructure would design the system in such a way that it does not fail safe.
I can see where JWZ is coming from. Though I’d like to point out GNOME rewrote their solution from scratch (I’ve no idea what design they used by the way), and so did we. I’m not sure these GNOME devs are the same as before and we certainly aren’t. We are indeed making mistakes people did before us, and we did fix that bug pretty fast and patted ourselves on the back when it was done, but I don’t think you can say we’re satisfied and calling it “job done”. This immediately makes us think as how we can prevent it from happening again, we have that separation of greeter/locker on our roadmap and it is very much planned to go ahead for 5.0.
An incendiary blog post and all the social media hype that goes with it will certainly help in making us care even more, but the mere fact that this happened in our code (this is OUR code right now, not just gnome-screensaver or something from upstream we’d just ship) and with our design is enough to make us want to review it.
Especially when I have given them nearly 30 years of prior art demonstrating how to do it right, and a two-decades-old document clearly explaining What Not To Do that coincidentally used this very bug as its illustrative strawman!
Xscreensaver didn’t do it right. Not crossing the street isn’t the safest way to cross the street.
He exposed an issue, he didn’t give a solution. There is a need which is not addressed here, there is a danger which is, there is a solution which has been given by other projects, not xscreensaver. It will need to be properly audited, but to me light-locker and KDE seem to have the best solution at the moment both in terms of safety and in terms of features.
This same bug keeps cropping up in these other screen lockers for several reasons.
Writing security-critical code is hard. Most people can’t do it.
Locking and authentication is an OS-level problem. And while X11 is at the heart of the OS of a Linux desktop computer, it was designed with no security to speak of, and so lockers have to run as normal, unprivileged, user-level applications. That makes the problem even harder.
This mistake of the X11 architecture can never, ever be fixed. X11 is too old, too ossified, and has too many quagmire-trapped stakeholders to ever make any meaningful changes to it again. That’s why people keep trying to replace X11 — and failing, because it’s too entrenched.
As always, these bugs are terrible because bad security is worse than no security. If you knew for a fact that your screen didn’t lock, you would behave appropriately. Maybe you’d log out when you walked away. Maybe you wouldn’t use that computer for certain things. But a security placebo makes you behave as if it’s secure when in fact it is not.
I absolutely agree with all of this.
One of the infuriating parts of these recurring bugs is that the screen-locker part of XScreenSaver isn’t even the fun part! I do not enjoy working on it. I never have. I added it in response to demand and necessity, not because it sounded like a good time.
I can understand this. I hate working on security myself, I think most of us do. We love doing cool things with technology not restrict ourselves because a few people abuse everything they can and ruin the party if we don’t force ourselves to think of every little way they can use A or B against other people.
Sigh.
Xscreensaver has been a great project. We’ve been shipping it for a while and it made users happy at the time. It’s also the codebase for its fork gnome-screensaver, which people have been using for years. So as a project we owe it a lot. The design choices its dev made were inspirational also because they explained the danger of relying on libs and toolkits in something like a locker, which had to be as crashsafe as possible. It failed in providing a solution to a need people had though while continuing to address that danger.
I’ll go even further. What JWZ did in xscreensaver is the source to a key principle we use very often (although it’s hard because people kinda push us the other way). We try to not implement features we don’t need and not rely on libs/toolkits if we don’t have to.
With that said, I have on message for JWZ. Don’t be that guy. It’s too easy to just tell people no to cross the street. Work with us on building that safest path. I would enjoy an audit of light-locker from you much more than a stupid I-told-u-so blog post. Don’t be bitter, be part of the solution.
Mint-screensaver and Cinnamon-screensaver, being forks and descendants of Gnome-screensaver, have inherited this license violation and continue to perpetuate it. Every Linux distro is shipping this copyright- and license-infringing code.
- mint-screensaver does not (and never did) exist.
- cinnamon-screensaver is written from scratch.
- gnome-screensaver is discontinued.
- mate-screensaver was forked from gnome-screensaver and is still active, so maybe that one has a licensing issue?? I don’t know.
- xfce-screensaver was forked from mate-screensaver afaik… so maybe here as well. We use light-locker in Xfce so I’m not really sure.
- Not every distro is shipping mate-screensaver or xfce-screensaver, no.
- These copyright and license infringements have to be explained more in details. I’d suggest to contact interested parties (MATE and Xfce projects) directly.
I eagerly await hearing how they’re going to make this right.
Writing a spiteful blog post about a non-related topic isn’t the best way to get answers. How about contacting Xfce and MATE directly?
If you contact me JWZ, I tell you what I’d like. I’d like you to put your money where your mouth is and be as brilliant as you once were. I want you to use your expertise to audit the design of light-locker and the minimalistic locker KDE uses (https://github.com/KDE/kscreenlocker/blob/master/abstractlocker.cpp). I want you to come at us again in 6 months time when we’ve split our greeter away from our locker and get you to say “no, it’s still not enough.. cause of A and B”, or “ah yes, that’s cool.. that’s both a good looking greeter and a safe locker”.
We also wear the distro hat and we also ship mate-screensaver and xfce-screensaver. If there is indeed a licensing issue, let’s see how it unfolds with interested parties. We won’t be judges in this, I’m sure you can have a talk with them. On our side we can continue to ship these screensavers or simply replace them with light-locker.
