Live data from Hacker News

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

bugs.debian.org

41–50 of 105 posts

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

#41
post #34
post #30

Earlier quoted context omitted.

Maybe distros like Debian are more stability/security oriented than feature oriented. New version of software often contain new features that it may introduce new bugs. Debian guarantees that when you install their distro things are going to work and are kind of secure. The tradeoff of having all the software in the distro being checked by people that have tested and checked that everything works well and smooth it's…

Spot on. I was always puzzled why some software just can't come statically compiled. I suppose not all apps can be distributed like that, but most of them can. I can't even remember how many hours I wasted on trying to compile a new version of some program, just to learn the infinite tree of dependencies, newer versions of existing libraries required, build prefixes tweaking etc... Most of that time could have been s…

Because any (possibly security-relevant) update to a library would mean that all software linking it statically has to be rebuilt.

In reality that of course doesn't happen, so programs linking statically or including their own versions of shared libraries never get security updates for the included libraries.

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

#42
post #34

Earlier quoted context omitted.

Spot on. I was always puzzled why some software just can't come statically compiled. I suppose not all apps can be distributed like that, but most of them can. I can't even remember how many hours I wasted on trying to compile a new version of some program, just to learn the infinite tree of dependencies, newer versions of existing libraries required, build prefixes tweaking etc... Most of that time could have been s…

Because any (possibly security-relevant) update to a library would mean that all software linking it statically has to be rebuilt. In reality that of course doesn't happen, so programs linking statically or including their own versions of shared libraries never get security updates for the included libraries.

If you want the perfect example of that problem, look to Windows.

A couple of years back Microsoft discovered some kind of issue with their redistributable dlls.

They patched Office etc, but could only offer a scanner that would check each and every dll to see if it was of a vulnerable version. And asked users to pester third party software providers for updates if the scanner found any.

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

#43
post #18

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…

But why can he vouch that libX11 is any more secure? The library that runs complex input method code on every key-press, that has had CVEs in it? [0] [1] [0] https://cgit.freedesktop.org/xorg/lib/libX11/tree/modules/im... [1] https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-20... Not to mention that I can still write a keylogger that bypasses jwz's xscreensaver. [2] [2] https://github.com/magcius/keylog

> But why can he vouch that libX11 is any more secure? The library that runs complex input method code on every key-press, that has had CVEs in it? [0] [1]

GTK (at least the 2.x series, I don't know if that's changed in 3.x) uses libx11. There's a good chance that, if there's a major flaw in libx11 which can be exploited, a GTK-based program is vulnerable to it. GTK is pretty massive, so it likely introduces issues of its own.

E.g. this bug: https://bugzilla.gnome.org/show_bug.cgi?id=722106 in GTK triggered this problem: https://bugzilla.redhat.com/show_bug.cgi?id=1064695 .

> Not to mention that I can still write a keylogger that bypasses jwz's xscreensaver. [2]

You can write a keylogger that bypasses pretty much anything that's X-based.

To, uh, to put it bluntly, ditching X11 for something saner would be the correct approach. Stacking stuff on top of X11 makes the problem worse; not stacking anything leaves it pretty bad. I'm not overly optimistic about Wayland, but I guess we'll have to wait and see :-).

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

#44
post #23

Frankly, this is a very good example why I inevitably give up on using Debian. It is not the software writers' fault that your distro can't be arsed to keep its package system up-to-date. Even the unstable branch is routinely multiple versions behind on software. The idea of linking end-user software versioning to the operating system version itself was always a dumb idea, but has become even more absurd over time. N…

> It is not the software writers' fault that your distro can't be arsed to keep its package system up-to-date.

That's it. Ubuntu releases every six months, it's not upstream's problem that an up-to-date version of your stable distro is using the program released in September 2014 (17 months ago). As XScreenSaver 5.32 was released in November 2014 and Debian stable was released in April 2015, you have to wonder why in those five months why it was not 5.32 which was released, or even 5.31, but 5.30 which was released seven months before.

Does anyone remember July 2002 to June 2005, almost three years between Debian releases? I do. You can point figures for why that happened, but it makes little sense to point them at the upstreams who make your distribution possible.

At the end of the day, the message jwz put in the code is crystal clear - if you are unhappy with the message and don't plan to keep your distro somewhat up to date, he'd prefer you just rip out xscreensaver from the distro and use an alternative. It doesn't make sense to compare him to a terrorist setting bombs as someone did in the thread.

It goes back to the initial reply. For all the gnashing of teeth and finger-pointing and name-calling and effort to deal with this and other issues due to old packages - if Debian channeled all of that energy and effort into a shorter, saner release cycle, it would be much more beneficial to everyone. If stable Debian was as current as the last release of Ubuntu or Fedora or OpenSuse etc., this discussion would have never taken place.

P.S. One good reason to download XScreenSaver 5.34 is the additional Android functionality. XScreenSaver 5.35 will possibly have much-expanded Android functionality when it is released (or if not, then 5.36 or one soon after). If you have Android Studio and an Android device (or emulator), compile it and give it a whirl. Once it gets into shape more for users, an APK will probably be put up, and possibly even a Google Play app. So if you're an Android developer, give it a whirl. Send an e-mail to the folks in the android/README with any bugs, questions, comments, patches etc. Probably best to e-mail first before doing the work on major patches. Give it a spin.

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

#45

Earlier quoted context omitted.

Was that a security issue or just a crash?

It would lead to the screen becoming unlocked, iirc. Edit: Just to add a bit more detail. xscreensaver locks the screen by putting a window across it that grabs ownership of input devices. Thus if it crashes, the window goes away and the inputs released.

I think that's basically how all the X11 screenlockers work, sadly.

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

#46
post #6

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,…

Here is another example:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811273

https://bugs.launchpad.net/ubuntu/+source/nethogs/+bug/15433...

It doesn't work at all and bug is fixed upstream, but fix only goes to unstable.

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

#47

Earlier quoted context omitted.

It would lead to the screen becoming unlocked, iirc. Edit: Just to add a bit more detail. xscreensaver locks the screen by putting a window across it that grabs ownership of input devices. Thus if it crashes, the window goes away and the inputs released.

I think that's basically how all the X11 screenlockers work, sadly.

Yes. But xscreensaver only use straight xlib to paint any UI elements. JWZ's argument is that this reduce the chance of bugs vs using the likes of GTK or Qt to draw password prompts etc.

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

#49
post #34

Earlier quoted context omitted.

Spot on. I was always puzzled why some software just can't come statically compiled. I suppose not all apps can be distributed like that, but most of them can. I can't even remember how many hours I wasted on trying to compile a new version of some program, just to learn the infinite tree of dependencies, newer versions of existing libraries required, build prefixes tweaking etc... Most of that time could have been s…

Because any (possibly security-relevant) update to a library would mean that all software linking it statically has to be rebuilt. In reality that of course doesn't happen, so programs linking statically or including their own versions of shared libraries never get security updates for the included libraries.

I wouldn't move from a package system to an "everything has to be statically compiled" system. But it would be a nice option to have when most of the software in your distro it's ok but you want to run some app without upgrading your whole distro/OS.

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

#50
post #34

Earlier quoted context omitted.

Spot on. I was always puzzled why some software just can't come statically compiled. I suppose not all apps can be distributed like that, but most of them can. I can't even remember how many hours I wasted on trying to compile a new version of some program, just to learn the infinite tree of dependencies, newer versions of existing libraries required, build prefixes tweaking etc... Most of that time could have been s…

Because any (possibly security-relevant) update to a library would mean that all software linking it statically has to be rebuilt. In reality that of course doesn't happen, so programs linking statically or including their own versions of shared libraries never get security updates for the included libraries.

In the same way as you upgrade library you can just upgrade your software...
Post reply on HN