▲ 84 points
back
99 comments
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. No other operating system but Linux (and possibly some BSDs) does this to the extent that the distro model does.
I'm not limited to awkward work-around manual install methods just because the version of Notepad++ linked to Windows 8.1 hasn't been updated since it was released. The whole scenario is absurd.
Yes, package repos are nice, but not when it means I'm perpetually multiple versions behind on common software just because a handful of nerds are trying to do the job of Github and Sourceforge combined, instead of just building an easier method of installing and updating third-party software.
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 going delay updating the packages.
But the idea of having a distro it's something that offers you that. That someone took the work of packaging and testing, so you can install things and everything works.
I think that if more software would be offered statically compiled with all the libraries (like many apps in OSX), then we would be able to try the latest release of Gimp when it's released, instead of having to waste time trying to compile from source or waiting for being included in the next release of the distro.
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 saved.
> 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.
New versions of software also fix old stability and security bugs.
If software became more secure with age, then the older your version of gnome screensaver, the more secure it would be ( https://www.jwz.org/blog/2015/04/i-told-you-so-again/ ).
Debian doesn't guarantee you anything. "stable" isn't bug free, what you're getting is a lack of newness. "stale" would be a better choice of word. It's not necessarily better, it's just not changing.
> No other operating system but Linux (and possibly some
> BSDs) does this to the extent that the distro model does.
> Even the unstable branch is routinely multiple versions
> behind on software.
> 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.
It's called 'unstable' for a reason. New stuff breaks. Often.
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.
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]
> 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 :-).
Didn't know that screen locks were supposed to defeat keyloggers. I thought they existed to stop people walking up to an unattended computer and mess around.
Anyways, if i am reading the CVE right it is about how X11 can be provoked into maxing out its stack. Possibly annoying for those trying to use X11, but not something that leaks data.
The more i see "security" discussed on HN, the more i feel that there needs to be a ranking system. All to often it seems like people are operating with a binary definition of security, putting anything with a CVE in the insecure bin.
I believe this blog post http://blog.martin-graesslin.com/blog/2015/01/why-screen-loc... is relevant to the conversation and the key logger part (but I am out of my league to comment about it).
Then again he got egg on his face recently because the xscreensaver lock screen would crash if the display output was switched (or some such).
Was that a security issue or just a crash?
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.
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.
If you want a specific bug fixed in stable, there are avenues to doing that:
https://www.debian.org/doc/manuals/developers-reference/pkgs...
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.
Here in Argentina it's common to find people that works dealing with customers or in the street that are very rude and kind of sociopaths. For what I have read in threads like this one, software developers that have to deal with many users/developers like Linus Torvalds, Theo de Raadt, and Jamie Zawinski end up suffering the same symptom.
It is also a classic help desk issue.
Man, it's really weird to see this after just installing Debian after using arch for about a year. And sure enough, that message popped up, I tried to update it and the repos were outdated. Brother..
My worst experience with their repos was with logstash having a bug where it would annoyingly install logstash-web with an auto-start. But..... the package had a typo in its startup script and caused the JVM to restart over and over and over. This was at an HFT shop, so sure enough.. I got a call the next morning that all trading was stopped until it was fixed.
I don't understand how these sorts of things issues happen for so long on such a popular distro...
*arch is nice and all, but holy crap does AUR need some better standards with what's acceptable. After spending an asinine amount of time trying to figure out why every 5th package won't build where devs closing bug reports with, "Did you try $BASICTROUBLESHOOTING".. I'm pretty much done.
I've only been using Arch for a few months, but my mental model of AUR is that I shouldn't expect anything to work.
(this isn't out of frustration, I read early on that it was for sharing preliminary packages and discarded all expectations)
Debian does not have a logstash or logstash-web package. When complaining about "their repos" did you mean elastic.co's repos?
This is a good example of why I do use Debian.
Debian has never had the goal of being the latest shiny thing on the block. And that's why people people keep coming back to it. Sure, over the years I've dabbled with RedHat, Ubuntu, Mint, and so on, but then repeatedly I rediscover, that, oh yeah, security and stability actually matter.
Debian Stable cuts the right balance for me by incorporating the latest security patches but not the latest features/bugs. This is a heck of a lot more work for the Debian maintainers than simply rubber stamping whatever the upstream software developers release, but it's proven worth it.
My only disappointment in Debian here is that they didn't catch this time bomb and disarm it preemptively.
And at least OpenSuSE and Slackware just patched the warning out already -- probably after getting hit by it in the past.
See for example the patch in Slackware: https://slackbuilds.org/mirror/slackware/slackware-current/s...
Oh wow, I didn't expect that from Slackware... I hadn't noticed that the message is gone, I guess. I can't help but to think it is kind of rude to keep using xscreensaver but not honor the request of its author. It's purely the principle of the thing because I agree that the message is ugly. That's not in true Slackware spirit imho (in the sense that this is a less-than-necessary patch). I am a little bit disappointed. :(
I don't (ever) link my own psychotic blog rants on HN (not because I value anything close to a reputation, but because I don't want to inflict my stupid on others) but I wasted an hour last evening on an exceedingly long tirade fairly congruent with this debacle.[1]
On topic though, nobody wants to develop the way distributions want you to - basically maintain branches of every release you make for the lifetime of the distros where you backport bug fixes but not feature additions. Very little software, even libraries, is ever developed like that, and it is part of the reason why Linux desktops are a Mess™. And practically, you often cannot even do this. Your feature additions will optimize code that your bug fixes interact with, and trying to keep them separate is an exercise in masochism.
The TLDR answer is the sooner we can get a community software repo with open signups that developers push new releases to that supports appstream / xdg-app infrastructure the better. Distributions can still freeze the world and maintain all the stability they want, but we need to also let developers take responsibility for their own software on desktop releases.
https://zannyland.wordpress.com/2016/04/02/software-rants-23...
> On topic though, nobody wants to develop the way distributions want you to - basically maintain branches of every release you make for the lifetime of the distros where you backport bug fixes but not feature additions.
I'm pretty sure that's not how Debian wants to handle software. The whole point of Stable is that packages won't get any new updates, with the single exception of security fixes. Regular bugs are not supposed to be fixed, because doing so introduces uncertainty - you might be introducing new bugs or changing expected behavior.
jwz here seems to be arguing that distros shouldn't be allowed to freeze his software, even if they do it themselves and maintain the branch themselves. He wants only current versions of his software shipped, and old versions disabled once they reach a certain age. I don't think this is an entirely reasonable demand, at least for open-source software.
Having used Gobolinux for some years now, i find the xdg-app thinking a case of shooting twee twee birds with AA guns.
*nix already have a mechanism called soname in place that allow versioned libs to live side by side. Gobolinux makes good use of it, along with symlinking, to allow multiple versions to be installed side by side.
You find similar, tho more elaborate, systems in place in NixOS/Guix.
xdg-app on the other hand comes out of the RPM/DEB camp, where there can only be one canonical version of every package installed at any one time. So to get around that they device a system where you basically build a new system for each and every "package".
What that effectively does is replacing dependency "hell" for dll hell (hello Windows).
I'm glad I read the bug discussion before this discussion.
1. jwz is sorta famous and cool, I think. I've heard of him before this (and I'm not exactly hip!).
2. Debian is well known, too! /understatement
3. jwz put a timebomb in xscreensaver.
4. The timebomb displays a message if current date > source code date + 18 months.
5. The timebomb has been there for at least three years. See https://github.com/Zygo/xscreensaver/blame/88cfe534a698a0562... (Unofficial repo)
6. I'm with Debian on this one. Sorry, jwz.
7. I really, really, really like xscreensavers and want it to stay in Debian! :(
Huh. Ran into this behavior yesterday, coincidentally.
I also think there's another bug with xscreensaver where it will capture and "hang on" to your keyboard after you've unlocked the machine. Maybe it's time to switch...
> I also think there's another bug with xscreensaver where it will capture and "hang on" to your keyboard after you've unlocked the machine.
You sure you are running the latest version?
That is the origins of this message. That Debian (and perhaps other distros) would fail to push xscreensavers in a timely manner, resulting in JWZ getting emails about issues he had long since fixed.
This seems to stem from a policy that only security issues (resulting in a CVE being published) will be processed, while usability issues are left in place until the next major stable release is rolled out.
I can see two reason for this.
A: that the thinking around stable is heavily server oriented. Thus anything but CVEs being excluded result in reduced risk of production breakages. This even though Debian is a generic distro that can be molded into desktop or server usage depending on what gets installed.
B: that the rigidity of traditional package management do not allow a piecemeal updating process. This because updating a package removes the old package in the process. Thus if you want to bump up the xscreensaver version, and it hard depends on a newer lib somewhere in the dependency chain, you end up with an unresolvable conflict unless you also update everything else that depends on the same lib.
... to another distro that actually ships up to date software?
The current version of Zawinski is very old.
I would recommend looking at NixOS. We're not perfect either, but we generally do a much better job at keeping our shit up to date:
https://github.com/NixOS/nixpkgs/blob/master/pkgs/misc/scree...
If there's something you need that's outdated, a fix is as trivial as opening an issue on GitHub, or sending a Pull Request with the revision and SHA256 bumped.
I'm more on the BSD-side, so can someone give an explanation on why bug fixes are not being back ported? I understand long term stable, but I thought that was more an API thing.
The Debian policy states that all software in stable stay at the same version, with patches backported from upstream. I'm not sure it really makes sense as a general policy; at least I'm pretty sure there could be exceptions for some packages with little dependancies, such as xscreensaver.
Slackware 14.0 which is way older than Jessie and even older than Wheezy, comes with the latest, 5.34 xscreensaver in its update stream.
There's no policy against backporting bugfixes, it just doesn't always happen due to lack of developers. If upstream doesn't provide backported bugfixes, it requires someone else to volunteer the time/resources to do it. For some packages, companies sponsor long-term maintenance branches, or particularly interested volunteers take it upon themselves to do it. For other packages, nobody steps up to do the work, so it doesn't happen.
I've found BSD ports pretty similar (mainly pkgsrc is the one I use). Some are very actively maintained, and others are much less actively maintained. Resources are limited, so pkgsrc maintenance happens only to the extent that someone makes it happen.
Another response to this issue:
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).
> 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...
After skimming the thread, I'm tempted to say: tell jwz "tough luck" and keep xscreensaver, with the message patched out, just out of spite. After all, he put it under a permissive license, so he should not be surprised that people actually use that license to do whatever they want.
He admits as much in the post, so you don't really have any cause for spite. Respecting his request would improve everyone's experience.