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%.

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.

Since this is a very large change, I would like to get a lot of testing on this before calling it ready for release. Please beat on it, eyeball it, throw whatever you can at it, and see if you can make it crash. Particularly, see if can make it crash and unlock.

Let me know if any of these things don't work by default:

• There should be no compilation errors that "configure" didn't warn you of first.
• Locking should work, specifically unlocking.
• The "xscreensaver-systemd" program should be running in the background.
• Fonts and font sizes in the unlock dialog should look sensible.
• Custom fonts should have been installed and used (e.g. "memscroller" should be using an OCR font).
• Fading and un-fading should be smooth on all screens.

Things that it would be nice to have some testing on, if you have the means:

• Non-English locales.
• Passwords containing non-Latin1 characters.
• Unixen that are not Linux.
• Linuxen that are not Debian or Fedora.
• Hot-swapping monitors willy-nilly.
• Laptops with flaky power management.
• HiDPI monitors.
• PBP monitors ("two HDMI one cup").
• Kerberos.
• Exotic PAM authentication methods, such as USB or bluetooth fobs, or fingerprint readers.
• Any PAM setup that prompts for more than one input.
• Does XScreenSaver interact sanely with remote desktop clients or games that grab the mouse for long periods?
• Exotic input devices: do you have a controller that does not present as key-press or mouse-motion, and does XScreenSaver recognize it as user activity?

Launch it as "xscreensaver -log log.txt" and if anything goes wrong, send me the entire log file, and as many other details as you can about your system and what was going on at the time.

If there were any compilation problems, send me the entire output from "configure" and "make", as well as the "config.log" file.

Please note, this is a BETA release. Do not download this unless you are willingly participating in the testing of software that is probably flaky! And above all, do not distribute this version to other users.

Do send me email and let me know what systems you've tried it on and how that went.

Thanks!