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.'"
So there are no time based security attacks? (Score:5, Insightful)
Debian keeps getting sillier every day. (Score:1, Insightful)
Is it a security update? (Score:5, Insightful)
probably not much of an issue (Score:4, Insightful)
Debian did the right thing (Score:5, Insightful)
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.
If it was a US daylight saving change (Score:1, Insightful)
Re:probably not much of an issue (Score:4, Insightful)
Anyone who does business with New Zealand might not be aware of the change and the need to update their systems.
E.g. sites hosting NZ content outside of NZ, or even banks doing business with customers in NZ.
The change impacts the world and should be applied to all systems.
Re:So there are no time based security attacks? (Score:1, Insightful)
Either you don't get it or you're a troll. (Score:5, Insightful)
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.
latest is 2007g (Score:1, Insightful)
Re:probably not much of an issue (Score:1, Insightful)
Re:Debian keeps getting sillier every day. (Score:5, Insightful)
This points to a wider problem... (Score:5, Insightful)
What I find truly dumb.... (Score:3, Insightful)
WTF (Score:2, Insightful)
As it's clearly pointed out in the bug report, this package:
1) Has not a security bug, so does not belong to security-updates.
2) Was in volatile for a long time.
3) Is scheduled for the next release of etch.
debian-volatile is a repository for this type of packages (as virus lists, tzdata, et alter) that has information/data changes/updates often. If your time zone has changed or it's about to change, it's your responsability as a sysadmin to upgrade the packages, not Debian's. There were not a bug in tzdata.
Debian is one of the best distros out there, please contribute to make it even better by filling bug reports, but please take a minute to think about what you are doing, and read carefully the developers/mantainers posts or replys, because most of the time they're right.
Re:So there are no time based security attacks? (Score:2, Insightful)
Re:probably not much of an issue (Score:4, Insightful)
debian/stable > debian/testing > debian>unstable > ubuntu/released > debian/experimental > ubuntu/unreleased
Thus, for a home desktop which can break most of the time and where you want the bling, you can afford to run Ubuntu.
I do run Beryl at home, even though it breaks a lot. Beryl, not the new versions of Compiz which after all those months after merge are still a regression, both stability and usability wise. Yet, I wouldn't let it anywhere near a system which shouldn't break. Well, many people actually run Windows in places where stability matters, but I digress. And Ubuntu made Compiz the default...
Re:So there are no time based security attacks? (Score:2, Insightful)
Re:This points to a wider problem... (Score:3, Insightful)
The same thing can be accomplished by shifting working/school hours as by fucking with what should be a constant frame of reference. Besides, if you want to save energy, there are better things to mandate -- CFL usage, tax all cars that make less than 30 mpg average at 100%, etc ...
-b.
Re:Debian actually did release it for Stable. It's (Score:1, Insightful)
Re:Debian actually did release it for Stable. It's (Score:5, Insightful)
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.
Re:What did Debian do for the US DST change? (Score:4, Insightful)
So that does beg the question - if it's okay to do it for the US, why not NZ?
Re:My god! (Score:2, Insightful)
What rubbish. New Zealand's technology industry is more significant to its citizens than the US technology industry is to Americans. As a small country, New Zealand's economy relies more on technological innovation than big countries do, with their natural resources and primary production. I'm not just talking about the famous examples (the electric fence, Rakon) either, but a constant push for more efficient and more valuable secondary production.
Or by significant did you mean significant to you and you alone? Who made you Captain of Industry?
Your guess about the few dozen people is also wrong. I, personally, just me, know a few dozen Kiwi Debian users, and I wouldn't say that's even close to the number that live in my suburb. Free software adoption is alive and well down under - it goes well with the 'number 8 wire' tinkering mentality that is a well-established part of New Zealand culture (Burt Munro and all that).
None of that is to say Debian should break policy - I agree that volatile is where these updates belong. But the arguments you give in favour of the status quo are bullshit.
Re:Debian did the right thing (Score:4, Insightful)
Yes, in fact, it is. Have you ever heard of log timestamps?
This _is_ debian (Score:3, Insightful)
Re:Debian did the right thing (Score:2, Insightful)
That would imply they did the wrong thing last year, when they released patches for the U.S. timezone rule changes in stable for both etch and sarge. And a quote from a Debian developer in March this year:
Re:Volatile versus update (Score:4, Insightful)
And a 100% chance that a change in your timezone will cause your servers to suddenly have the wrong time (assuming default configuration).
No thanks, I'll stick to a platform with a more sane balance between platform stability and not breaking things.
Re:Volatile versus update (Score:5, Insightful)
Re:Volatile versus update (Score:4, Insightful)
Re:Volatile versus update (Score:5, Insightful)
Re:Volatile versus update (Score:5, Insightful)
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:This _is_ debian (Score:2, Insightful)
The title of www.debian.org: "Debian -- The Universal Operating System".
Re:So there are no time based security attacks? (Score:3, Insightful)
Feb 27 01:01:04 umbc9 syslogd: restart
Feb 27 01:01:14 umbc9 telnetd[1803]: connect from annex3.umbc.edu
Feb 27 01:02:15 umbc9 rlogind[1845]: connect from annex1.umbc.edu
Feb 27 01:02:44 umbc9 lpd[1879]:
directory
Feb 27 01:07:08 umbc9 telnetd[1914]: connect from annex1.umbc.edu
Feb 27 01:08:06 umbc9 rlogind[1946]: connect from annex1.umbc.edu
Feb 27 01:10:28 umbc9 rshd[1985]: connect from xxxx@deputy.cs.umbc.edu
Feb 27 01:10:30 umbc9 rlogind[1993]: connect from xxxx@deputy.cs.umbc.edu
Feb 27 01:13:01 umbc9 sendmail[2042]: BAA02041: to=xzy@picard.cs.wisc.edu,
delay=00:00:02, mailer=nullclient, relay=mailhub1.gl.umbc.edu. (130.85.3.11),
stat=Sent (BAA04370 Message accepted for delivery)
Note that this example does not include the timezone; most UNIX implementations do, so at least the logs can be transposed to reflect one's own timezone.
The impact is skewing of post-event analysis of messages in logs. While I agree with the value of your presumption, i.e., logs could be written with timestamps expressed as offsets from the epoch, it's not the way things are done at present. OTOH, if the analysis is crucial, it's trivial to write a [Perl|Tcl] script to filter the logs for less error-prone analysis.
I happen to have written a small app recently to log events with the timestamps written as epoch offsets, because the people who use the logs are in different timezones and want to understand the events' occurrences in their own timezone.
It sure is a security bug (Score:4, Insightful)
Similar problems may exist for SSL (https, ldaps, imaps anyone?) but I'm not sure if a one hour difference would exceed the tolerance in many applications.
Disclaimer: I work for a commercial distributor.
Re:So there are no time based security attacks? (Score:5, Insightful)
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.
Re:Is it a security update? (Score:5, Insightful)
It's not that the updates aren't going to be made, it's just that they're made via point releases, not security updates because they aren't a security bug.
If you don't want to wait for a point release, the packages have been made available already via volatile and the backports area. It's trivial to add these to your sources.list and install the updated package.
You seem to not understand how Debian actually works. The management of Debian, such as it is, are the actual developers; the people who actually sit down and do the work. If you don't like the decisions that they make, you have two choices: jump in and help out or choose to use something different. The former will enable you to make decisions in the areas you work in, the latter means hoping that someone else is going to make decisions that you agree with. Choose whichever you prefer; presuming to dictate to those who actually are doing the work isn't one of those choices.
Re:So there are no time based security attacks? (Score:3, Insightful)
No, the solution is to drop the "security" red herring altogether and concentrate on the truth of the matter. This update is small, simple, and critical in an international economy. It should go without saying that it should be a mandatory, top of the list update for all systems regardless of their status in some bureaucratic development cycle.
Forget the analogies of web browsers, MP3 players, web servers, e-mail clients, IM clients or any of the other thousands of software packages that could in whatever small or large way affect the system and concentrate on this; this update is in force by a major political body recognized around the world. It is fact and computers should at all costs follow the guidelines set by the Real World governing entities. Period. Full Stop.
For any developer to be pedantic enough to marginalize this as "non security" and therefore refuse to put it into the mandatory update pool is harmful and highly irresponsible. Said developer(s) should be reprimanded, not lauded.
For all those reading these threads and responding that a simple command-line update is the proper solution are short sighted and elitist. Not to sound too cliche, but this is just another example of why Linux / FOSS users and advocates are looked down upon by the real forces in the computer industry and why Linux will never be a mainstream standard. Get off your high horses and realize that just because something is usable by the masses doesn't make it technically inferior nor does it make you any less of a geek because you didn't have to hand-roll your latest update.
Re:volatile explained (Score:4, Insightful)
There's a lot I don't understand about the things I use in my day to day life but I still use them. Micro-managing one's operating system is a foolish waste of time and loss of productivity. My operating system exists to grant me access to the tools I've installed to perform tasks relevant to my daily life and career. This is something that should be done right the first time without any political nonsense getting in the way. A timezone patch not stable? Now I've heard it all. Next thing you know my /etc/issue file will be unstable.
Re:So there are no time based security attacks? (Score:4, Insightful)