To quote Matthew Garrett: "I think the real problem with Xscreensaver is that JWZ thinks it's an app and Debian think it's critical infrastructure"

xscreensaver is widely used (including by Slackware in many circumstances) as the mechanism that locks and unlocks inactive desktop logins.

Sometimes it is, and sometimes it isn't. Hopefully everyone who has contributed to this thread has read and digested Matthew's relevant blog post? Particularly the first few paragraphs? What you need to do is to use your experience every time to make the call: backport a patch, or upgrade to a new version, or decide it's bollocks and ignore it completely. You can't simply make an inflexible rule that says "always backport, never upgrade." But inflexible rules have been Debian's lifelong fetish

We all know, jwz included, that the licence permits distros to modify and redistribute xscreensaver as they wish. If a distro wishes to be rude and barely legal, it is of course free to do so, but that comes at a reputational cost -- just like putting nag screens in your software is rude and comes at a reputational cost. jwz has been putting up with this for way more than a decade. Hopefully everyone who contributed to this thread has read and digested the "previously" links jwz posted? Especially this one: no good deed goes unpunished [2003]? If jwz seems to be a little bit crazy, this is the reason.

So what would Slackware itself use to lock inactive logins instead of xscreensaver? gnome-screensaver? I wonder what that requires these days....

And Firefox has almost exactly the same situation. Patrick had to push an upgrade from 31.8.0esr to 38.1.1esr in 14.1/patches when support for 31 was terminated. I don't remember anybody telling Patrick that he was doing the wrong thing in August last year; quite the reverse, people were asking for it. Firefox even has a nag screen, though there's a checkbox to stop that. (If only jwz had provided a checkbox, we would have been spared this teachable moment.)

I'm not defending Mozilla, they are on an Escher staircase of their own devising, but Patrick has to do what Patrick has to do.

And again, the same with PHP just ten weeks ago (Wed Feb 3 22:39:25 UTC 2016) though at least there's no nag screen. Yeah, I know, PHP is fractally broken and this is just another shard:

But I don't remember anyone suggesting PHP should be dumped on SBo, or did I miss that?

1 members found this post helpful.

David, I totally understand both sides. Users can be jerks, especially when they perceive there is a problem with your software. I know there are reasons to upgrade software beyond the versions released in stable versions of distros. There are many examples within Slackware of Pat doing just that (as you have mentioned).

And I will admit, I didn't know that xscreensaver was the only method included in Slackware to lock your desktop after a period of inactivity. If figured, as with many programs in Slackware, there was alternatives included with the OS. That does change my thought on sending it to SBo. If it is a vital security function, then it should remain within the OS unless there is a viable alternative (no idea on the viability of gnome-screensaver, but like you, I would assume it'd have a hefty dependency list).

If there are valid security concerns with older versions of xscreensaver, and there are not patches available to fix them, then by all means, those security concerns should be weighed against the possibility of new bugs being introduced by upgrading. I'm sure Pat has done that for Firefox, PHP, openssh, and all the other programs that were upgraded due to security reasons. If there were a serious security issue with xscreensaver, Pat would do what he does with those other programs and determine if the update is worth the potential instability it might add.

I think it all comes down to this line from you...

Putting out security updates is a good thing. I don't think anyone can argue with that. I applaud jwz for his time and effort over the years to develop and maintain xscreensaver. But to put in a timer to tell users to update that is not permanently dismissable without altering the source? I still think that is unacceptable as a developer. He could've put in a timer that stated something along the lines, "This software is X number of days old. There are new versions available (possibly not yet available from your repos -- contact your package manager for updates). Please do not report bugs without upgrading to the latest version first." And then he could add a checkbox to never show the message again. If that checkbox was there, this entire thing would be moot.

If there's serious security issues with xscreensaver, the software will either get patched or upgraded by the various distros. If there isn't any security issues, then the software will likely remain at that "stable" version until the next distro release occurs. That is the way it happens with pretty much any other program on pretty much any distro (that has a stable release).

1 members found this post helpful.

Xubuntu has dropped XScreensaver in favor of "light-locker." I don't know if other members of the Ubuntu family have also made the switch.
BTW, KDE has its own "internal" screen locker system, but I disable it and use XScreensaver.

https://github.com/the-cavalry/light-locker

Also, there is xautolock which can be used in combination with xlockmore, xtrlock or other locker tools.
https://archive.debian.net/slink/x11/xautolock