
“This version of XScreenSaver is very old. Please upgrade” - ashitlerferad
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819703#84
======
jarcane
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.

~~~
sanbor
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.

~~~
haddr
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.

~~~
binarycrusader
Because statically linking everything has several negative consequences:

    
    
      * increased storage space
      * increased memory usage
      * increased downtime for updates (since more files have
        to be updated)
      * increased bandwidth usage (total size of download
        for update)
      * potentially increased security risks
    

In short, trading off all of the above to simply avoid proper release
engineering and simplified dependency management is the wrong answer.

Our systems need less downtime and better security; not the opposite, which is
what static linking brings.

That's why Solaris, as an example, does not provide static archives for almost
any of the components that are provided, especially libc.

~~~
gens
statically linking to properly(!) made libraries will only maybe increase
storage space

it will decrease memory usage (as most loaders load the whole library, even
when just one function is used)

more things to upgrade, yes

more bandwidth, yes (not much if one uses binary diffs)

potentially increased security risks, yes. although shared libraries are
bigger security risks

i made an acc just to reply to this. why do people never understand static
linking ?

~~~
binarycrusader
_statically linking to properly(!) made libraries will only maybe increase
storage space it will decrease memory usage (as most loaders load the whole
library, even when just one function is used)_

Most OS linkers already do efficient loading of only the relevant portions of
a shared library since they typically mmap the library file.

In aggregate, static linking the same dependency for multiple programs will
increase memory usage as well despite your assertions to the contrary since
the pages will not generally be shared (yes, I'm aware some OS have page dedup
or compression, etc., but I'm talking about the general case here).

 _more things to upgrade, yes more bandwidth, yes (not much if one uses binary
diffs)_

A binary diff of 100 programs all linking to the same library will still be
larger than the diffs for a single library.

In addition, updating 100 binaries, even with diffs still takes longer than
uprating a single library, which means increased downtime during system
updates.

 _potentially increased security risks, yes. although shared libraries are
bigger security risks_

Code is code; how is shared linking a greater risk? Have any data to back that
up?

 _i made an acc just to reply to this. why do people never understand static
linking ?_

I understand static linking quite well, since my day job is part of a
commercial OS team that coincidentally pioneered dynamic linking technology in
UNIX.

So let's not base our arguments on assumptions about knowledge just because we
disagree.

~~~
gens
>Most OS linkers already do efficient loading of only the relevant portions of
a shared library since they typically mmap the library file.

a page is 4kB (on x86 at least). a function is typically, what, 60 bytes ? 120
maybe ? 240 ? some functions use other functions (fopen()->_open() in libc) so
you can have more then two pages

maybe you are thinking about swapping (or not even lazy loading in the block
layer) ? code has to be in RAM, everything else is insecure

>In aggregate, static linking the same dependency for multiple programs will
increase memory usage as well despite your assertions to the contrary since
the pages will not generally be shared (yes, I'm aware some OS have page dedup
or compression, etc., but I'm talking about the general case here).

not pages, functions (and/or variable objects). when you make a .la on unices
you are making a ar(1) archive out of .o object files. when the linker is
linking the final binary it opens that .la archive and pulls out the relevant
.o objects

so "statically linking to properly(!) made libraries" will reduce overall
memory usage, unless a lot of programs use that (small) library (rarely the
case)

OSX linker does the right thing with their libc. in that out of the many
optimized memcpy()'s it will only load the one that is fast on the particular
cpu

GNU linker loads them all

>Code is code; how is shared linking a greater risk? Have any data to back
that up?

data to back it up ? do you have any data to back up anything you said ?

LD_PRELOAD can be used to replace functions and the user/admin would not
notice it. while the only security flaw with static linking is an
administrative mistake

>I understand static linking quite well, since my day job is part of a
commercial OS team that coincidentally pioneered dynamic linking technology in
UNIX.

>So let's not base our arguments on assumptions about knowledge just because
we disagree.

so go ask them about it

------
johnchristopher
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._

~~~
Jasper_
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...](https://cgit.freedesktop.org/xorg/lib/libX11/tree/modules/im/ximcp/imCallbk.c)
[1]
[https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-20...](https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-2004)

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

[2] [https://github.com/magcius/keylog](https://github.com/magcius/keylog)

~~~
notalaser
> 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](https://bugzilla.gnome.org/show_bug.cgi?id=722106)
in GTK triggered this problem:
[https://bugzilla.redhat.com/show_bug.cgi?id=1064695](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 :-).

------
kuschku
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.

~~~
Elhana
Here is another example:

[https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=811273](https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=811273)

[https://bugs.launchpad.net/ubuntu/+source/nethogs/+bug/15433...](https://bugs.launchpad.net/ubuntu/+source/nethogs/+bug/1543303)

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

------
bithush
Google Cache as the Debian tracker is getting hit hard
[https://webcache.googleusercontent.com/search?q=cache:UoVCY4...](https://webcache.googleusercontent.com/search?q=cache:UoVCY4x_2HMJ:https://bugs.debian.org/cgi-
bin/bugreport.cgi%3Fbug%3D819703#84+&cd=1&hl=en&ct=clnk&gl=uk)

Original link is to post #84 in the conversation.

------
sanbor
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.

~~~
digi_owl
It is also a classic help desk issue.

------
bpchaps
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.

~~~
maxerickson
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)

------
hackerb9
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.

------
jhkaghjkga
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...](https://slackbuilds.org/mirror/slackware/slackware-
current/source/xap/xscreensaver/xscreensaver.no.expiration.date.diff.gz)

~~~
cyphax
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. :(

~~~
morb
Yes, the nag text was removed, but at least xscreensaver gets updates, which
was the whole point.

> patches/packages/xscreensaver-5.34-i486-1_slack14.1.txz: Upgraded. I
> promised jwz that I'd keep this updated in -stable when I removed (against
> his wishes) the nag screen that complains if a year has passed since that
> version was released. So, here's the latest one.

Personally I don't get the point of screesavers at all, since we have monitors
that can be sent sleep/standby mode when they're not used.

~~~
basch
it is a lock screen that prompts for password on wake

[https://www.jwz.org/xscreensaver/toolkits.html](https://www.jwz.org/xscreensaver/toolkits.html)

------
zanny
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...](https://zannyland.wordpress.com/2016/04/02/software-
rants-23-build-a-better-distro-neon-problems/)

~~~
_delirium
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.

~~~
zanny
It should be perfectly reasonable, it is just that within the infrastructure
of projects like Debian and RHEL there are no mechanisms for a developer to
assume responsibility for their own software. The disconnect of both behavior
and authority in pushing new releases vs distributing new releases is a
problem, particularly for user facing applications and collections like KDE or
VLC.

Debian can, and should, freeze their software and provide support for what
they package. But the developer should both be able to ask Debian to remove
it, and to provide it themselves. But not in the traditional insanely bad and
broken Windows "search the Internet for random binaries and use those" method.
We have the capability, fairly easily, to provide a community repository that
crosses distros and lets developers directly ship and update their own
software, we just need to provide the capacity. Tech like appstream is how you
enable it.

~~~
_delirium
As a Debian user, that isn't really what I'm looking for. I like Debian's
release management. For a stable Debian release, I don't want upstream being
allowed to either: 1) push major feature and API changes, or 2) remove the
software entirely. Then I'd have to deal with every random upstream's release
model, whereas today I understand and trust Debian's synchronized release
model.

I think it's fine if this doesn't meet the wishes of how upstream wants to
manage releases. Part of the point of free software is that we have a right to
adapt software to serve our own needs, without needing permission of the
original authors. Rolling-style releases, which get updated whenever upstream
wants to push an update, are a nice option to have. But a Debian-style stable
release model is also a nice option to have. So I'd like both to exist, and
wouldn't want upstream package authors to be able to veto the existence of
stable releases.

~~~
zanny
Its not about vetoing, it is about Debian shipping broken software that is
never updated and it drives developers mad to constantly get the same bug
report for the same broken feature that was fixed _years_ ago upstream.

I personally hope none of my software ends up in Debian Stable, because if it
did anything broken in it at the point of freeze would haunt me for half a
decade.

~~~
_delirium
Well if upstream doesn't want Debian to ship broken software in a stable
version, there's a solution: upstream should improve their quality control and
not ship broken software in the first place. ;)

But I mean, there's no actual obligation to update software. Lots of
redistributors don't update to the latest version for many reasons. Apple
ships old GNU utilities because they don't like GPLv3. FreeBSD ships an old
version of OpenBSD's pf firewall because their patched version is hard to
forward-port. OpenBSD ships a truly ancient gcc for a mixture of technical and
license reasons. And Debian updates software on a fixed stable-release cycle.
I suppose it's fair that upstream can complain about this: GNU and jwz don't
have to be _happy_ that people are shipping old versions of their software.
But people are also probably not going to stop doing it.

------
hartator
Cached:
[https://webcache.googleusercontent.com/search?q=cache:UoVCY4...](https://webcache.googleusercontent.com/search?q=cache:UoVCY4x_2HMJ:https://bugs.debian.org/cgi-
bin/bugreport.cgi%3Fbug%3D819703+&cd=1&hl=en&ct=clnk&gl=us)

------
daveloyall
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...](https://github.com/Zygo/xscreensaver/blame/88cfe534a698a0562e81345957a50714af1453bc/driver/prefs.c#L1663)
(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!
:(

------
castratikron
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...

~~~
digi_owl
> 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.

~~~
ashitlerferad
> only security issues ... will be processed

That isn't actually the policy, for example:

[https://www.debian.org/News/2016/20160402](https://www.debian.org/News/2016/20160402)

~~~
digi_owl
> This update _mainly_ adds corrections for _security_ problems to the stable
> release, along with a few adjustments for _serious_ problems.

------
B1FF_PSUVM
The current version of Zawinski is very old.

------
cstrahan
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...](https://github.com/NixOS/nixpkgs/blob/master/pkgs/misc/screensavers/xscreensaver/default.nix)

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.

------
protomyth
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.

~~~
_delirium
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.

~~~
protomyth
Oh yeah, depending on which one, its a bit slow on the BSD side also. I was
just looking at why you wouldn't back port bug fixes as a matter of policy,
but I'll take your comment as truth although it seems the conversation in the
thread is a bit odd on that point. Thanks.

------
ashitlerferad
Another response to this issue:

[https://mjg59.dreamwidth.org/41085.html](https://mjg59.dreamwidth.org/41085.html)

------
digi_owl
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).

~~~
odinduty
> 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...

------
captainmuon
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.

~~~
sp332
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.

~~~
ashitlerferad
Respecting his request would mean removing xscreensaver which would be bad for
users.

~~~
sp332
I don't see why a package maintainer would patch out the warning instead of
just packaging the new version. But if it comes to that, it's better for the
users to get xscreensaver from a more reliable source than that maintainer.

