“This version of XScreenSaver is very old. Please upgrade”

Heh, looks like its another popcorn moment.

BTW: i guess this is an argument for having feature release and bugfix only releases. Or at the very lease make it easy for distros to backport bugfixes (though i guess most will argue to give distros the middle finger and pull everything from git or equivalent).

Google Cache as the Debian tracker is getting hit hard https://webcache.googleusercontent.com/search?q=cache:UoVCY4...

Original link is to post #84 in the conversation.

I’ve seen similar issues with several (!) Debian packages again and again.

Upstream has fixed lots of bugs, critical crashes, and CVEs, and Debian stable takes weeks or months to backport them, and even then only the CVEs. Not even fixing major usability bugs.

I’ve seen users on versions so old where nothing is able it interoperate with them anymore, and the users unable to compile from source themselves.

Currently, the solution I’ve seen from several such upstream sources was to offer a ppa or custom apt repository, and to let users install that.

The usability of debian – especially stable and oldstable – is severely hurt by maintainers not backporting these things, and it adds a lot of work for upstream.

Especially for fast moving things – like compilers, programming languages, networking software – this is a severe issue, and Debian is just ignoring it away, and patching the warnings upstream might have added away as well.

________________________

If Debian wishes to remove the warnings from Upstream, they should actually backport all bugfixes themselves – as they claim they do.

________________________

Btw, I won’t be able to answer to comments on this for another hour, as I’ve exhausted my hourly limit on HN comments – as always.

> For the record, the timebomb for 5.34 will go off on 2017-04-01, ie, shortly after stretch's expected release date.

Debian always providing with fun...

I can't find it on his website at the moment but he has an excellent explanation of why gnome-screensaver is inherently insecure. If I remember correctly it boils down to something like: `nobody can guarantee that gnome-screensaver is secure because it relies on GTK which nobody can prove or guarantee that it's 100% secure because there's too much code to check.`.

edit: found it:

I am as close to certain as I can be that there is no action a user can take on their input devices that will cause the current Xlib-based lock dialog in xscreensaver to unlock. That's because it's a small amount of code that I have stared at and tested for a very long time. It is a small enough piece of code that I (believe I) know every possible path through it.

Introduce N layers of widget library, general text field handling, compose processing, input methods, I18N... and all bets are off. Who knows what bugs wait lurking in there; who knows which particular combinations of which libraries are a security-bug timebomb.

Let me put that another way:

The GTK and GNOME libraries have never been security-audited to the extent that their maintainers would be willing to make the claim, "under no circumstances will this library ever crash."

One can, within a reasonable doubt, make that claim about libc, or even about Xlib, but not about anything the size of GTK. It's just too big to be sure. This is not a criticism of GTK or GNOME or their authors: it's simply a truth about any piece of software of that size.