[mscarborough]

Directly below the supposedly juicy "I don't think this is worth it" comment is a merged PR linked to this issue.

In that PR they changed the render loop rather than implement the "not worth it" suggested solution. At no point was it marked as WONTFIX.

[hpfr]

Yes, they fixed the bug, which is good, but if you read jwz’s post, the issue is that these bugs don’t fail safe. A screen locker shouldn’t crash to an unlocked session. The design of a screen locker should take into account that bugs and crashes will exist and strongly prioritize failing safely.

[shawnz]

Actually, Xscreensaver doesn't fail safe either. If it crashes, the same issue will occur. I don't know why the post implies otherwise. Jwz says it himself in the linked article:

> But if xscreensaver crashes, the screen is unlocked, and our attacker is now logged in as the person who locked their screen.

EDIT: To clarify I meant that jwz' blog post is the one which implies otherwise.

[dmm]

I just said swaylock, a wayland screenlocker, had the same architectural flaw as all X11 screenlockers: when it crashes the screen unlocks. Wayland was supposed to be better but it isn't, apparently.

Xscreensaver attempts to mitigate this by being as simple as possible to prevent crashes. swaylock doesn't do this either, apparently. Several crashes have been reported in the past year alone.

I was just expressing disappointment in the lack of interest in fixing #1.

[josefx]

His approach was basically to leave out complex features that could crash when possible and document why doing that was necessary. As far as he thinks a better solution is not possible with how Linux interacts with screen lockers. Modern implementations seem to do the inverse, include as much complexity as possible and fix every security critical exploit after the fact.