Debian Refuses To Push Timezone Update For NZ DST 435
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.'"
Re:So there are no time based security attacks? (Score:5, Informative)
done.
Re:Debian are refusing to push the update (Score:3, Informative)
Re:Dropped debian back in '01. (Score:5, Informative)
Nothing to see here, move along.
Debian actually did release it for Stable. It's in (Score:5, Informative)
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:So there are no time based security attacks? (Score:2, Informative)
Re:This points to a wider problem... (Score:5, Informative)
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]
Re:probably not much of an issue (Score:5, Informative)
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:Debian keeps getting sillier every day. (Score:5, Informative)
It all sounds like a shitstorm in a chamber pot to me.
Re:WTF (Score:2, Informative)
Basically, as a sysadmin you have at least five different options using Debian or Debian-derived distros:
1) Stable (codename Etch): you are at the topline in terms of stability/security, although the packages here are not the latest upstream releases. You have to handmade some things now and then. Fixes and regular updates through security/updates and volatile. Aimed at production servers. Scheduled releases.
2) Testing (codename Lenny): you are in middle land between top stability and latest releases. For some time now, security fixes are available in security/updates. May you have a develop system to test your things with the newer versions of software before they make into stable. Frequent updates.
3) Unstable (codename Sid): latest versions from upstream, new packages. Aimed as a development/maintainers, sid has no security updates, so your in your own here. Most of the time is usable in day to day work as a desktop. Lots of updates every day. You will be busy apt-getting.
4) Mixed system: you have the possibility to start from one of stable/testing/unstable and mix into it packages for other releases, getting specific versions of some packages and letting the rest of the system follow the default release version.
5) Debian derived distro (like Ubuntu): may it have different targets, or narrowed ones, like desktop users, or some language speakers, or software collections and tools for specific disciplines, or any other purpose. If you're in any of these segments, may be you have to consider using one of them. Outside this segments, your best choice probably is one of the above. Also, different distros has different policies regarding updating, software included, versions and integration testings, so you must read their documentation carefully.
So, if as a sysadmin you don't have time or knowledge to deal with this kind of things, and your choice was stable, you're plain wrong. Stable _is_ for sysadmins who knowns what are doing, and _do_ it.
Now, if you're very busy, and have no time to cope with this sysadmin duties, may be you have to had choose Lenny (testing), because (although I'm not recommending it to production environments) it's perhaps the best trade off between stability/security (as mentioned above, has security updates) and newer upstream versions and ease of maintain. Tools like cron-apt exists to make your life easier if you're short of resources/time/IT people or you're lazzy.
Regarding of the timeline in releases of Etch, this is how the world is. If the original report was filled near the end of the pointed release preparation, there was no chances of updating the package for _that_ release, so it will be included in the next one. So, this updated package is ready available in Lenny/Sid, but has to wait for the next Etch release to be available there, and this is why Ubuntu has it updated in a week _after_ Debian maintainers updated the package in Lenny/Sid. This is possible for Ubuntu because it has nothing like stable.
Regarding other posts about how this kind of things (quality, security and stability control) are making difficult the wider adoption of GNU/Linux, please go and grab any other OS out there that fullfills your expectations in every aspect; we'll be here waiting for your comments about it.
Re:So there are no time based security attacks? (Score:5, Informative)
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:My god! (Score:4, Informative)
That won't address the issue at all. NTP makes sure the system clock is synchronized with UTC. The issue here is how much offset from UTC should be used for times that are displayed to users.
Volatile versus update (Score:5, Informative)
The whole FA is a big mis-understanding of what the various repositories are and what they purpose are.
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
Comment removed (Score:4, Informative)
Re:The real culprit here (Score:4, Informative)
The complaint amounts to "You should have put it in the wrong place because I was looking in the wrong place and didn't find it." People who actually bother to think about what they're doing use Debian precisely *because* you can rely on them sticking to the rules.
Re:Debian actually did release it for Stable. It's (Score:4, Informative)
And it's really not that complicated to use. Even things like nvidia drivers are just a m-a autoinstall nvidia away. Sometimes it takes a while, but eventually I find Debian makes things like that very simple and integrated.
Re:So there are no time based security attacks? (Score:4, Informative)
The point is, stable is supposed to be stable, and only changed for very good cause (which this is), and then only after considerable testing...which this hasn't had. An exception is made for security fixes because it's considered *necessary* to patch vulnerabilities. Otherwise, no. Even if you don't see how it could cause a problem, you don't include changes without considerable review and testing. That's what stable means.
OTOH, if you choose to import it from another repository...it's your choice. And simple to do. (I'll grant that I don't understand the "volitile" response. The repositories I'm aware of are stable, testing, unstable, and experimental. Presumably volitile has something to do with the stable branch.)
Given all that...I don't see how the timezone file could cause a problem, and I don't see why it should have set in the volitile repository for weeks. Perhaps nobody would test it before they needed it?
Re:Debian did the right thing (Score:3, Informative)
Yes, in fact, it is. Have you ever heard of log timestamps?
If you are using log timestamps for security-sensitive applications, you really should be using UTC (or at least a timezone that doesn't have daylight saving changes), because otherwise you will get ambiguities cropping up: there is a one hour window every year for which the timestamps will repeat an hour later making it impossible in some circumstances to tell when exactly stamps left during these two hours occurred. This has substantially worse security consequences than merely not adjusting your clock for DST, which can always be corrected for later.
I think you mean GMT *plus* 13. (Score:5, Informative)
Re:Debian did the right thing (Score:3, Informative)
It is a shame that the updated tzdata package did not enter the Debian ("etch") 4.0r1 point release... I would welcome an explanation for why this was the case, but then again this is Slashdot, not LWN.
Re:Debian actually did release it for Stable. It's (Score:4, Informative)
FTR, actually that's not the case. Someone else who stumbled onto the problem near the last minute doesn't like the fact that it didn't go into the main repository or security repository. I -- the person who filed the original bug -- am perfectly happy with the fix going into the volatile archive, and patched the servers I manage months ago. (I think it's rather unfortunate it missed the 4.0r1 point release, and unfortunate (but understandable) that there's no patch for Debian Sarge ("oldstable"), but otherwise the situation seems to have been handled fine. For Debian Sarge it works okay to take the NZ or Pacific/Auckland timezone file from a patched Etch system and put it onto the Sarge system.)
Ewen
Re:It sure is a security bug (Score:4, Informative)
Re:I think you mean GMT *plus* 13. (Score:3, Informative)
Actually it's correct. The POSIX standard specifies the timezones backwards.
See, e.g.: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4813746 [sun.com]
Clever, eh?
Re:So there are no time based security attacks? (Score:3, Informative)
This misunderstanding about timezones is based on where changes go. Security updates to packages in stable go to the "security" repo. Things like clamav definitions change on a regular basis and reside in volatile. This particular repo is news to me, but I don't admin Debian boxes. The developers believe the update should belong in volatile and not security. That is all. Stable remains stable.
Re:So there are no time based security attacks? (Score:4, Informative)
it is not a security update so it doesn't go in the security repositry
it is already in the volatile repositry
it is already in etch-pryoposed-updates which means it will probablly be in the next point release of etch
pushing a point release of stable is not something that has been taken lighly, lots of CDs to build and push out to mirrors, lots and lots of testing.
Sure the US changes got better treatment, how much of that was luck and how much of it was being one of the largest (in terms of computer using population) countries arround is hard to tell.
If you can't live with the way debian stable releases work choose another distro. If you can't manage your IT infrastructure such that deploying local patches is not unreasonably difficult fire your IT staff.