XScreenSaver 6.00 is out now, including iOS and Android.I have significantly refactored the XScreenSaver daemon, the component of the XScreenSaver suite that provides screen locking on X11 systems.
These changes greatly reduce the amount of code running in the "critical" section: the part of the code where a crash would cause the screen to unlock. That critical section is now only around 1,800 lines of code, a reduction of roughly 87%.
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. -- Antoine de Saint-Exupery
My approach with XScreenSaver, as I've written about extensively, has always been to minimize the amount of code in the critical section: to link with as few libraries as possible, and to sandbox as much of the rest as possible in separate processes. This approach has worked out very well; XScreenSaver has had an excellent security track record over these last three decades. Not perfect, but pretty damned good. Especially as compared to its putative "competition".
But, it still contains quite a lot of code, and keeping up with new operating system features like hot-swapping of monitors, new ways of detecting user activity and so on, has caused more and more code to creep into it. Remember that XScreenSaver predates not only HDMI, but USB! I wrote the first version on a 1-bit monochrome display.
So I stepped back and took a fresh look at the whole thing from the perspective of, "what needs to be here?" In addition, dropping support for X11 systems more than fifteen years old -- an eminently reasonable thing to do -- allowed me to simplify the flow of control a lot.
The new design looks like this:
- xscreensaver
- The daemon. Links with Xlib and nothing else.
- Requires the XInput2 extension, standard since X11R7 in 2005.
- Handles grabs, idle detection, and client messages.
- Maps no windows.
- xscreensaver-gfx
- Launched by xscreensaver to blank the screen.
- Launches the screenhacks as sub-processes.
- Handles monitor reconfiguration, fading, visuals, etc.
- If it crashes, the desktop will momentarily be visible, but the keyboard and mouse will remain grabbed and the screen will remain locked.
- xscreensaver-auth
- Launched by xscreensaver to authenticate the user.
- Draws the unlock dialog, and talks to PAM.
- Exit code indicates success or failure, so if it crashes, that has the same behavior as "incorrect password".
The old XScreenSaver daemon contained 14.5k lines of code in a single executable. The new one contains 12.5k lines across three different executables -- a 14% reduction overall. But as I said earlier, the critical section -- the process whose crash will result in an unlock -- now contains only 1.8k lines -- an 87% reduction. This is great not just because it reduces the attack surface, but also because it's easier to understand and audit.
This release went through a fair amount of alpha and beta testing, but as always, email me if you can make it break.
Though this release was primarily focused on X11, there are some improvements to the other platforms as well, most notably that both macOS and iOS have a cycling "random mode" now.
At work, my team is refactoring a giant confusing background daemon written in Java into a bunch of tiny little processes that talk to each other. It is so nice to be able to keep a program's entire codebase paged into my brain at once.
Thus ensuring that there will be work for the next generation of programmers to do - by handling the undocumented and unexpected failure modes of your brand new distributed system with unknown coupling.
In all honesty, I'm finding the new microservice era to be much more approachable than the umpty million lines of hairy legacy from previous generations. A lot of the distributed system stuff has really matured, and API deployment, testing techniques, chaos routers, etc make splitting stuff across the network (or locally) much less scary than it was.
There will always be work for the next generation, ofc.
I thought the UNIX philosophy was "Do one thing, and do it well". Makes it easier to understand/work with a program a little bit at a time and to isolate (not load) different modules.
"Random mode" makes me happier than it should, really.
iOS cycling mode! Pandemic means I work from home now. For a whole year I've spent working hours with a small touchscreen device sat on my desk running Linux and playing music with XScreenSaver on random. I like this setup. The device has issues that have made me start wondering what other smallish touchscreen device would able run XScreenSaver on random whilst playing music. The iOS XScreenSaver getting cycling mode means after my Easter work break that device is being replaced with an old iPad I never got around to getting rid of.
My previous comment was supposed to end with the words thank you. Thank you!
Hi jwz!
I've read an article recently that I think you could like and is kinda related to this blog post. It's about software underproduction, aka "a term used to describe software that is low in quality but high in importance". If you don't care or don't have time to read it all (it's not that long though) I suggest you to just scroll a bit to the second graph and enjoy the software in 6th place. Here it is: https://mako.cc/copyrighteous/identifying-underproduced-software
BTW I'm a happy xscreensaver user since about 2004, love it, and I'll add I'm not really fluent in English so I hope this message makes sense.
I just want to take a moment to say thank you. As someone that grew up with AfterDark on old school Macs I was ridiculously happy when I discovered xscreensaver so many years ago.
Thank you for years of enjoyment!
Extremely naïve thought/question:
Re. momentary visibility of desktop on xscreensaver-gfx process crash (since that could def. leak sensitive info)... could the dæmon create another fullscreen(s) window in a separate process with like ~z-order - 1 beneath the xscreensaver-gfx process's window(s) so that the desktop is always hidden?
And/or repaint that underlying "cover" window with a screenshot of the desktop (s) for savers that play with those pixels?
If that would work (I don't know anything about X programming), it would mean more or less no code of any complexity running in the process that paints the cover window(s)...?
Yes, but having the daemon map and manage that window adds complexity to the critical section, and I don't think it's necessary. It's pretty unlikely that xscreensaver-gfx itself will ever crash; we're talking about the second or third line of defense at this point.
Beat me to it!
And gotcha.
But, the dæmon wouldn't map the window, it would just start a 4th "xscreensaver-cover" process that would do all the work...
Maybe you could reuse the same code that manages xscreensaver-gfx, with only a few different parameters (namely z-ordering)?
And my final spam on the subject, this xscreensaver-cover process's code would be fixed and non-interactive with less-audited savers...
(I missed that -gfx launches the savers as subprocesses, so after too many words I'm thinking you've thought of this, and my idea adds nothing...)
I am curious though, if with your knowledge of X and various window managers, if absolutely never revealing the desktop is something that's theoretically possible, or if that it can (albeit rarely) happen is an artefact of the (mis)design of X?
As long as you don't have "grab desktop images" selected, it shouldn't ever be revealed unless xscreensaver-gfx crashes.
Obv. a straight-up screenshot on said underlying cover window would also briefly leak info on -gfx process crash, so maybe (assuming this isn't unpossible) an option to scramble/fake/randomize a "cover" desktop for savers that futz with underlying pixels in some creative way.
Haha if this is totally hairbrained, please gently explain why - and I can learn something about X Windows 😋
Hi, sush a pleasure to see you maintain that piece of art for so long. I toly aproove your aproach in the design of Xscreensaver.
I'm very pleased to see that some ppeople care abour the quality of their work and try to preverse their technical independence despite the trend of jailing coders in vendor frameworks and bloating the code with unessary "coolness"
Thanks for all these years of care.
An anonymous user of this piece of art since 2002 !
a while ago one of my usb-aged colleagues asked "what's a screensaver even do? why?" i realized it wasn't as dumb of a question as i first thought. my answer was "locks your screen when you go to the bathroom." are screens still in need of saving?
Your question is covered in the FAQ.
Plus, this is still a thing.
The rest of us just get a kick outta staring at this handsome chap:
So burn-in can happen with OLED displays, but is the problem better, worse or the same as old CRTs?
Who cares? Maintenance of your monitor has zero relevance to why XScreenSaver was written, or why people choose to run it.
Don't jump up my ass. I just thought the guy I was replying to might have an answer to the question I was actually asking, which is independent of the need for XScreenSaver.
i consider no install complete without the latest xscreensaver so i have no doubt they are required, if not necessary. i live for the occasional split-second "oh-fuck!" moment when i see a solaris bsod on my mac. noseguy+fortune, xjack, and xflame (or running decayscreen on someone else's workstation, back in the day) are each worth the price of admission. i was just curious if modern screens could burn in like CRTs did. sounds like "some pedantic jerk" is saying they do not.
I noticed a change in behavior for this new version of XScreenSaver that somewhat bothers me. I wouldn't call it a bug, or even particularly hard to adapt to, but I thought I should mention it, in case it was both unintended and possible to revert without ruining security or overcomplicating things again.
In previous versions of XScreenSaver, the unlock dialog would catch the first keystroke you entered as part of the password even if you had not pressed ESC or wiggled the mouse or whatever to bring up the dialog first. In 6.00, say my password was "qwerty", if I arrive back at my computer, type "qwerty", and hit enter, it will not unlock like I'd expect because the "q" pulled up the unlock dialog, and then "werty" was entered as the password. I obviously could get in the habit of wiggling my mouse or hitting a key before typing in my password, so it's not a huge deal, it's just an extra step in the process that wasn't necessary before.
Anyway, like I said, it's not a huge deal, and I'm not even sure it's possible to put it back the way it was before without adding complexity back in, or even if that's a thing that people would want. I kinda wish I'd messed around with the betas some so i could've noticed this earlier and asked then, but oh well. Regardless, I love XScreensaver, keep up the good work!
Yeah, I know that's annoying if you were used to it, but with the new division of labor it would have been pretty difficult (and added a lot of complexity) to make that work. Get in the habit of tapping shift first, I guess. Which is how the macOS unlock dialog works too, which makes this be "best practices" I guess...
Alright, thanks for the reply letting me know I should go ahead and start fixing my habit! I kinda figured it might be something like that, so no worries, if it's for the sake of smaller, more easily auditable code, then I'm all for it.
Any chance of an Apple TV version? Would look great on a big 4K screen
I have no idea how to accomplish that or if it's even possible, and I don't have an Apple TV.
It looks like all you need to do is add tvOS as a compile target to your iOS project. But of course, this is Apple; I would be completely unsurprised to find that you need to obtain some kind of certificate first.
But you don't understand, that competition has a rich greeter!
Literally "tornado warning app" mentality.
Sounds like agile mentality to me. "So, it has serious security bugs, big deal, we'll fix it in a month, in the meantime, enjoy our new emojis!"
Painless build on bullseye i386. All good.
Ok. Here's how to get xscreensaver-systemd working in the world of KDE 5.
The underlying problem is that ksmserver runs lock screen duties, and even if you turn off that stuff in the settings, it's still squating over the DBus end point thingy that other processes are going to contact to say things like, "I'm playing a video", or "The lid has closed". We need it to stop doing that by invoking it with --no-lockscreen, but we can't just restart it after a session has started, as it's the parent process for kwin_x11. We need to make whatever starts ksmserver do the right thing.
How to do this depends on which of three epochs the plasma-workspace package is in:
KDE 5.00 → 5.16: startkde shell script launches ksmserver
This includes Debian <= buster, Fedora <=31, openSUSE <=15.1, Raspbian Stable (2021-03-16), Ubuntu <= 18.04 (and maybe up to 19.10).
Horrible hard coded paths means that we can't just copy startkde into /usr/local/bin and make our changes — we need to modify in place then tell the package system not to clobber our file on upgrade. This is what I did on a Debian buster system, but it'll work fine on Ubuntu:
Then log out and log in again.
Success is measured by xscreensaver-systemd runnning and ksmserver's process line including --no-lockscreen.
5.17 → 5.20: startplasma-{x11,wayland} launches ksmserver
Includes Debian Testing (2021-03-16), Fedora 31 updates, 32, 33, FreeBSD ports, openSUSE 15.2, 15.3, Raspian Testing (2021-03-16), Ubuntu 20.04, 20.10 (and possibly 19.10, 19.04).
The "everything is terrible forever" epoch, as some dev who needed to support Wayland took a look at the startkde bash, noped right out and rewrote it in C++. To be fair, bash is kinda horrible, and that's some tidy C++, but it does condemn us to rebuilding startplasma-x11 from source.
This is what I did on Ubuntu Focal (20.04):
And log out and log in again, as above.
5.21+ systemd starts ksmserver
Includes Debian Experimental (2021-03-16), Fedora Rawhide (2021-03-16), openSUSE Leap (2021-03-16), Ubuntu 21.04 (unreleased)
I do not live in this exciting new world, but I speculate from a glance at the source code, that you should be able to run:
systemctl edit plasma-ksmserver.service
Put this in the file you get to edit:
[Service]
ExecStart=/usr/bin/ksmserver --no-lockscreen
Then log out and in again. And maybe take back one or two rude things you said about Lennart Poettering. Just a couple though.
Folks with Redhat/SuSE/Arch/etc clues, feel free to add what you do on those systems to the comments.
"This is the year of Linux on the desktop."
While the Linux desktop environments have made great strides in obfuscation over the years I feel the availability of source code is holding them back from capturing the true mystery of the Windows desktop cargo cult experience.