Debian Refuses To Push Timezone Update For NZ DST

Jasper Bryant-Greene writes "Although a tzdata release that includes New Zealand's recent DST changes (2007f) has been out for some time, Debian are refusing to push the update from testing into the current stable distribution, codenamed Etch, on the basis that 'it's not a security bug.' This means that unless New Zealand sysadmins install the package manually, pull the package from testing, or alter the timezone to 'GMT-13' manually, all systems running Debian Etch in New Zealand currently have the incorrect time, as DST went into effect this morning. As one of the last comments in the bug report says, 'even Microsoft are not this silly.' The final comment (at this writing), from madcoder, says 'The package sits in volatile for months. Please take your troll elsewhere.'"

So there are no time based security attacks?

[DrXym (126579)]

Assuming there are, or even the possibility that one could be crafted, it seems quite justifiable to call this a security fix. And aside from that, it's just dumb not to include it.

Re:So there are no time based security attacks?

[Lennie (16154)]

It's in volatile (where it should be), it's just one line in /etc/apt/sources.list, which should probably already be there and an apt-get update && apt-get -u install tzdata

done.

Volatile versus update

[DrYak (748999)]

It's in volatile (where it should be)

The whole FA is a big mis-understanding of what the various repositories are and what they purpose are.

• stable - litteraly means stable, as in mountain rocks. Once a distribution hits this status, it normally shouldn't change a bit.
• non-US - the USA have some pretty wierd laws concerning patents and cryptography. There are a lot of software that can be made available in the USA (because it infringes patent that can only exist in the USA system, or because it is a cryptographic software whose strengh is declared too high and considered as a weapon), but the same software can safely be used everywhere else in the world. non-US contains software that is as imuable as stable, but that is specifically banned in the USA.
• updates or security - as it names implies, standart updates release for stable version of debian, only provide fixes to bugs that could be abused for exploits. All fixes retain the same exact version, only patching the hole (i.e.: firefox 2.0.0.1 isn't upgraded to firefox 2.0.0.6. Instead it's iceweasel 2.0.0.1-1 that is patched to 2.0.0.1-2 the exact same source code, except for the security fix). In the very unlikely case that after 3 fucking years of development in testing state, there is still a bug that prevents a program to start, the corrected version (same version just patched) will appear here.
• volatile - this are packages that can change version, because their functionnality needs it. Virus scanning engine clamav is there for exemple (because to catch new threats, some times the engine it self needs to be updated, not only the signatures). Timezone goes there too (a computer won't be hacked with a bad timetable. therefore it's not in security)
• volatile-sloppy - for non critical upgrades. Gaim/Pidgin goes there for exemple. It's not critical to the function of the computer, but never the less, IM network companies like microsoft regularily changes their protocoles just to break compatibility with 3rd party clients. Thus clients needs to be upgraded to newer versions from time to time. But because newer version MAY break some compatibility with older distribution, older config files, or old user scripts, it is separated from volatile.
• backports - newer version of software, for those who constantly whine because Debian release are 3 years appart. Usually it's package from testing recompiled in stable environment
• testing - This is much closer to what other distribution call a release. It has more up to date packages, but isn't completly bleeding edge, is somewhat stable. This will become the next stable once everyone in debian is happy and decide to definitely freeze it
• vendors, like samba or 3rd parties maintain their own repositories with software compiled against stable, if you like updating your software to latest version.

More information about voltile, at the corresponding debian site [debian.org].

Debian is quite popular among some admins because of this. You know, once you install debian on a server, that your installation will still get critical security fixes for the next 3-4 years. But nothing else will change a bit. 0% chance that an upgrade may break your configuration file. 0% risks that all the scripts that you manually wrote will suddenly stop functionning because of subtle differences between version 1.8.6.9 and 1.8.6.10 in some obscure software. (which are things that could occasionally happen with other distribution ) NO dependency hell once you start using updated software (like a 3rd party repository targeting a library version 2.0.9, but the distro having updated to 2.0.11. Very rarely it can happen between openSUSE and packman).

But as AC said in this thread, maybe the installation procedure of Debian should give

Re:Volatile versus update

[Ultra64 (318705)]

Maybe he said 'fucking' because he fucking wanted to.

Re:Volatile versus update

[dctoastman (995251)]

People who reduce themselves to bitching about curse words contribute nothing to the conversation at hand.

Re:Volatile versus update

[tylernt (581794)]

I solved this problem by changing wholesale to GMT/UTC on all of our servers, Linux and Windows. Now we never have to worry about another stupid DST or TZ change again, including MS charging $4K for a patch that should be free. It also makes life easier for people outside our TZ who use our servers.

I just learned that I go to work at 3pm in the morning and head home at 11pm. It's not hard. I wish the world would switch to GMT, it would make everything so much easier. Businesses can have summer hours if they wish to take advantage of the longer days.

Of course, the desktops are all still on local time. There would be a pitchforks-and-torches uprising if you tried to change that. ;)

Re:So there are no time based security attacks?

[thegnu (557446)]

I understand the reasoning behind putting it in volatile, but why not enable volatile by default during installation?

Debian is considered the stable distribution. They move glacially slow, and are, if you use their stable repo, stable as hell. If you want bleeding edge by default, install their bleeding edge version.

Otherwise, if you want Debian, install Debian.

Oh, and in response to the even-Microsoft-would-not-be-so-foolish comment: Of course not. They demonstrated their level-headed thinking when they charged $4000 for a time zone update for Windows 2000. A server OS. When you can do it for free [slyck.com] if you know how. Debian should charge NZers $4000 Canadian (OUCH!), then they would be respected.

Re:So there are no time based security attacks?

[myowntrueself (607117)]

This is the debian *STABLE* branch. In testing I imagine they would do it quickly...well, within a week.

Sure, and if you want to put up with the possibility that, eg, trying to use tab-completion will cause your shell to dump core then, by all means, use testing.

'Stable' cannot, in the real-world really mean 'nothing changes except security updates'. The world does not work like that, as this demonstrates.

Is it a security update?

[by Anonymous Coward]

Some systems may rely on the "wrong" timezone for their continued operation, so if it is indeed not a security update, and the policy for automatic updates is "security only", then not pushing the update is correct. If you need the timezone update, get it. It's not like they hide it from you.

Apple are just as bad

[kiwioddBall (646813)]

They haven't rolled out a patch for OSX either. There are several folks on Apple in NZ who are just as disappointed.
Meanwhile, Microsoft rolled out a patch on Windows Update - Microsoft users on Automatic Updates rolled over without even knowing anything had changed.

Debian actually did release it for Stable. It's in

[by Anonymous Coward]

It's in volatile repository.

Volatile is specificly designed to take into account things like this. It's for updates to packages, like anti-virus software, and similar things that change over time.

Nobody actually reads the fucking articles do they? The guy that posted the article is a troll and selectively took quotes out of context.

What SlashDot says:
"Although a tzdata release that includes New Zealand's recent DST changes (2007f) has been out for some time, Debian are refusing to push the update from testing into the current stable distribution, codenamed Etch, on the basis that 'it's not a security bug.' This means that unless New Zealand sysadmins install the package manually, pull the package from testing, or alter the timezone to 'GMT-13' manually, all systems running Debian Etch in New Zealand currently have the incorrect time, as DST went into effect this morning. As one of the last comments in the bug report says, 'even Microsoft are not this silly.' The final comment (at this writing), from madcoder, says 'The package sits in volatile for months. Please take your troll elsewhere.'"

What is actually in the Bug Report:
----SNIP----
The fix is already in the volatile archive (see
http://volatile.debian.org/ [debian.org] in the etch-proposed-update archive and it
will also appear in the next release of etch. Alternatively you can also
download the new version by hand and use dpkg -i.
----SNIP----

ALSO:
----SNIP----
>>> I would recommend re-opening this bug and upgrading its severity until the fix has been
>>> applied.
>> That won't change anything as it is now out of control of the glibc team.
>>
>
> And these mission-critical updates aren't put into security, why?
>

Because it's not a security bug.
----SNIP----

NO SHIT. It's _not_ a security bug. Why should the Debian Security team be forced to deal with something that is not security? Think about it for a whole two seconds.

The tzdata was updated a long time ago and is in a Debian repository that is specificly setup to deal with changes like this.
The person who filed the bug report doesn't like this and thinks that the package should be in the security fix repository.

It's fucking stupid. It's not a security bug. The package has been fixed for a long time. It doesn't have to be installed manually. It CAN be installed manually.

Get a grip people.

Re:Debian actually did release it for Stable. It's

[RAMMS+EIN (578166)]

This is what usually happens when something Debian-policy-related happens and is touted as silly:

1. I think: How silly of them. Just like Debian to do something stubborn and annoying like that.
2. Then I read the argumentation, the policy that led them to the decision.
3. I find myself agreeing with the policy and thus accepting the decision as the Right Thing.
4. I find someone, usually in the Debian project itself, has come up with a solution for those who don't like the decision.

The more time passes, the more I like Debian. They have policies that are good and they stick to them. When the policy causes them to do something that people don't like, they provide a workaround. With Debian, you can have your cake and eat it. Exclusively free software? Check. Proprietary software when you do want it? Check. Stable system that stays the same for years? Check. Recent versions of packages when you want them? Check. Support in the package manager for mixing and matching? Check. Oh, and they had dependencies figured out and working well long before any other distro I'm aware of. Debian isn't perfect, but it comes frighteningly close sometimes.

Debian did the right thing

[by Anonymous Coward]

In my opinion, Debian did the right thing here.

This update is not security-related, so has no business being in the security update section. That's perfectly OK - Debian's security updates are completely safe to apply 99% of the time, because they do not change functionality. They only fix security bugs. Unlike Microsoft, Debian are not in the practice of shipping automatic updates that change functionality.

The update has been posted to the volatile repository, which is intended for things that change frequently, like timezone data. It can be installed from there right now - any of these people complaining could have simply installed the patch at any time over the past several months. The update has also been pushed to the updates repository, for inclusion in the next point release of Etch.

I don't see the problem here.

OB

[Hognoxious (631665)]

This means that unless New Zealand sysadmins install the package manually

Imagine the overtime if both of them had to come in on a Saturday morning!

Re:OB

[BladeMelbourne (518866)]

Their sheep will be so lonely.

With my FreeBSD hats...

[MavEtJu (241979)]

As the person who did the latest timzeone updates to RELENG_5, RELENG_6 and HEAD (but not to the security-only branches RELENG_5_5 and RELENG_6_2) I say: They're right.
As the person who maintains the misc/zoneinfo port I say: They're right.

This points to a wider problem...

[b0s0z0ku (752509)]

abolish DST! It was silly in the early 1900s when the majority of workers worked in factories, mills, or on farms. It's sillier in 2007. Get rid of that stupidity once and for all.

Re:This points to a wider problem...

[Aladrin (926209)]

There have been studies that showed it doesn't really reduce energy usage. The only thing left is having more daylight for your picnics.

http://www.google.com/search?client=opera&rls=en&q=daylight+savings+time+doesn't+save+energy&sourceid=opera&ie=utf-8&oe=utf-8 [google.com]

I think you mean GMT *plus* 13.

[novakreo (598689)]

This means that unless New Zealand sysadmins install the package manually, pull the package from testing, or alter the timezone to 'GMT-13' manually

I hope no one actually follows the summary's suggestion of manually setting GMT-13 as the timezone. Given that NZ is now GMT+13, you'd be 26 hours behind.

Either you don't get it or you're a troll.

[babbling (952366)]

Debian have promised their users that only security updates will be rolled out and that they will not release any updates that change the normal behavior of programs. They do this because Debian gets run on lots of mission-critical servers where they don't want a program changing its behavior via an "update".

Rolling clocks forward by two hours is a pretty huge change in behavior for some servers, and there isn't much of a security risk in not rolling out the update automatically, so they're not going to.

They're doing the right thing.

Re:Dropped debian back in '01.

[Lennie (16154)]

It's Debian policy to update stable in point-releases, to have security updates through security.debian.org and packages that _need_ regular code updates (like the clamav virus scanner) in volatile. This timezone change is in volatile.

Nothing to see here, move along.

Re:Debian keeps getting sillier every day.

[Ewan (5533)]

I dont think the correct time is a bleeding edge feature is it?

Re:Debian keeps getting sillier every day.

[fbjon (692006)]

You're right, it's not bleeding-edge but rather a volatile feature. Hence the fix is in volatile [debian.org], just like TFS says.

It all sounds like a shitstorm in a chamber pot to me.

Re:probably not much of an issue

[Bloater (12932)]

> In this case: bling = my computer knowing what time it is.

If you're running debian then it was apparently updated automatically ages ago. The article seems to be about a bug reported by somebody who chose to turn off updates except for security fixes. Naturally, then, they didn't get this update - they then asked for these things to be considered security bugs in future.

I disagree with the bug reporter. Anywhere time is used in a security mechanism (and there are many) it should be using UTC or be robust against timesaving measures (eg, only be used for approximate deadlines to improve odds). In which case a timesaving change is not needed for security. Security bugs are therefore in the application not the time metadata (except adjustments to UTC which definitely *would* be security issues).

In short - debian users' arses (and clocks) are covered just fine.

Re:Google Groups in Konqueror

[Slashcrap (869349)]

This isn't an isolated incident either. You cannot browse Google Groups in Konqueror. In the bug report they legitimately argue that it's Google's fault for not adhering to standards, but they still lost me as a user, and undoubtedly others also. http://bugs.kde.org/show_bug.cgi?id=140531 [kde.org] [kde.org]

Firstly, this is offtopic and has nothing to do with Debian. Secondly either Google or the KHTML team must have fixed it because I couldn't reproduce the bug in Konqueror.

When you say they've lost you as a user, do you just mean Konqueror? If so, is there anything we can do to lose you as a Linux user as well?