Hacker News Reader

Comment by jraph | Hacker News Reader

This is not xscreensaver though. This is important because jwz, xscreensaver's author, has written about this at length [1,2]. He was very careful to make the core of xscreensaver as small as possible to avoid crashes.

[1] https://www.jwz.org/xscreensaver/toolkits.html

[2] https://www.jwz.org/blog/2015/04/i-told-you-so-again/

(open these links in a new tab or by copy-pasting the URL)

View on HN

True, and certainly a fair distinction. Perhaps I should say that a vulnerability of this nature - involving an xscreensaver fork - has occurred in practice.

Yes, your point still stands, this class of bugs is "fatally" present on X11, there is seemingly nothing that can be done about it.

It can actually be avoided on X11 if you're willing to make the screensaver an integral part of the desktop environment. The way KDE has done it since the KDE 4 era at least is by doing the actual screen locking in ksmserver and having the unlock screen and password entry dialog as a seperate process. This has two effects: crashing the password entry dialog or the screensaver will not unlock the desktop, and if you do somehow manage to crash ksmserver the session will immediately terminate, because ksmserver exiting for any reason is how X decides that the session is over. This is a bit like Wayland's solution, except with much less potentially buggy and crashy code in the process responsible for locking the desktop.

I had forgotten about that redirection (and didn't read your note), so I thought you were making a crude joke with that link at first.

The Referer header can't die soon enough. Or HN could implement rel=noreferrer (at least on links to this website) or the relevant CSPs. Or jwz stop doing this redirection but I don't see this happening.

Reply on news.ycombinator.com