Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Debian Bug Software Linux

Debian Refuses To Push Timezone Update For NZ DST 435

Posted by kdawson from the does-anyone-really-know-what-time-it-is dept.
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.'"
This discussion has been archived. No new comments can be posted.

Debian Refuses To Push Timezone Update For NZ DST More

Debian Refuses To Push Timezone Update For NZ DST

Comments Filter:

  • So there are no time based security attacks? (Score:5, Insightful)

    by DrXym ( 126579 ) on Sunday September 30, 2007 @07:02AM (#20800369)
    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? (Score:5, Informative)

      by Lennie ( 16154 ) on Sunday September 30, 2007 @07:10AM (#20800419)
      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.

      • Re: (Score:2, Insightful)

        by Anonymous Coward
        I understand the reasoning behind putting it in volatile, but why not enable volatile by default during installation? The individuals who need to disable it will know how. And, most importantly, the individuals who don't have a clue how to enable it (most likely desktop users) will not have to worry about it. Remember, Debian aims to make their OS usable for everyone (a lofty goal but it is the project's goal nonetheless). However, it is not necessarily a requirement of that goal to force users to become ma

        • Re:So there are no time based security attacks? (Score:5, Informative)

          by thegnu ( 557446 ) <[moc.liamg] [ta] [ungeht]> on Sunday September 30, 2007 @09:06AM (#20801113) Journal

          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.

          • Comment removed (Score:4, Informative)

            by account_deleted ( 4530225 ) on Sunday September 30, 2007 @09:32AM (#20801273)
            Comment removed based on user account deletion
            • This is the debian *STABLE* branch. In testing I imagine they would do it quickly...well, within a week.

              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:So there are no time based security attacks? (Score:5, Insightful)

                by myowntrueself ( 607117 ) on Sunday September 30, 2007 @01:59PM (#20803005)
                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.

                • Re: (Score:3, Informative)

                  by xenocide2 ( 231786 )
                  Have you actually used Debian testing? Or Debian at all? I admit it's a complex beast, and gotten more complex since I left, as this whole article revolves around a misunderstanding between sysadmins and developers. New packages start off in unstable (or experimental if the uploader thinks it's too buggy to consider for regular use), and if, after ten days without a major bug report, the package is placed in testing. Unstable is a rocky ride, but so many people use it that most developers are highly concern

          • Re:So there are no time based security attacks? (Score:4, Funny)

            by ozbird ( 127571 ) on Sunday September 30, 2007 @11:38AM (#20802123)
            Debian is considered the stable distribution.

            The way it was explained to me, Debian is the stale distribution.

      • Volatile versus update (Score:5, Informative)

        by DrYak ( 748999 ) on Sunday September 30, 2007 @09:20AM (#20801209) Homepage

        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 (Score:4, Insightful)

          by Wdomburg ( 141264 ) on Sunday September 30, 2007 @10:13AM (#20801555)
          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.

          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)

            by tylernt ( 581794 ) on Sunday September 30, 2007 @11:47AM (#20802171)
            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. ;)

  • In defense of the Debian team... (Score:2, Funny)

    by Anonymous Coward
    ... maybe it just isn't time.

  • Is it a security update? (Score:5, Insightful)

    by Anonymous Coward on Sunday September 30, 2007 @07:04AM (#20800383)
    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.

    • Re: (Score:3, Interesting)

      by jabuzz ( 182671 )
      So pray explain why they pushed a timezone update for the US changes earlier in the year? As another poster said the reputation of Debian is being ruined by the ineptitude and down right stupidity of the management.

      • Re:Is it a security update? (Score:5, Insightful)

        by dondelelcaro ( 81997 ) <don@donarmstrong.com> on Sunday September 30, 2007 @01:59PM (#20803007) Homepage Journal

        So pray explain why they pushed a timezone update for the US changes earlier in the year?

        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.

        the reputation of Debian is being ruined by the ineptitude and down right stupidity of the management.

        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.

  • Apple are just as bad (Score:5, Interesting)

    by kiwioddBall ( 646813 ) on Sunday September 30, 2007 @07:04AM (#20800389)
    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.
    • A great post covering the response to the NZ Daylight Savings change by the various vendors posted on the excellent 'geekzone' website :
      http://www.geekzone.co.nz/freitasm/3856 [geekzone.co.nz]
      This demonstrates how committed vendors are to smaller markets.

    • Debian actually did release it for Stable. It's in (Score:5, Informative)

      by Anonymous Coward on Sunday September 30, 2007 @07:44AM (#20800557)
      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 (Score:5, Insightful)

        by RAMMS+EIN ( 578166 ) on Sunday September 30, 2007 @08:33AM (#20800881) Homepage Journal
        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.

        • Re:Debian actually did release it for Stable. It's (Score:4, Informative)

          by pherthyl ( 445706 ) on Sunday September 30, 2007 @11:24AM (#20802023)
          That's why I love it too. I really don't like the distributions where you get a big bunch of packages as a release, which you are then basically stuck with until the next release (at which point you have to upgrade and cross your fingers, or reinstall). Like Ubuntu, you get a whole ton of packages, and there are always a few that have a subtle bug. But since you're on one release, you don't get the fix until six months later (of course, you can install it separately, but it's a pain). With Debian, if an app is broken in some way, I get the fix as soon as that developer releases a new version, without affecting any other package.

          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:Debian actually did release it for Stable. It's (Score:4, Informative)

        by ewen ( 218843 ) on Sunday September 30, 2007 @02:14PM (#20803085) Homepage

        The person who filed the bug report doesn't like this and thinks that the package should be in the security fix repository.

        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

    • You don't understand, all you have to do is..."apt-get update && apt-get -u install tzdata"

      Right. Let's see my Granny - or the average Corporate Joe - doing that.

      This is why people are NOT switching to Linux...people here bitch about stealth windows updates, (quite correctly, in my opinion), but don't always recognise the upside.

      I keep trying to promote BSD (server), Ubuntu (desktop) etc. to my customers, (which include Gov. departments) and friends, and this kind of bs just does not help. It's fi
      • This is debian, and there is a simple command-line based solution. Debian isn't aimed at grannies or the average corporate joe. Its primary user base is geeks and sysadmins who need rock-solid systems. And it does a damn good job of that. It also servers as a great reference implementation for others (ubuntu, et al) to customise and optimise for more specific uses.

  • probably not much of an issue (Score:4, Insightful)

    by FudRucker ( 866063 ) on Sunday September 30, 2007 @07:05AM (#20800393)
    i would imagine anyone in New Zealand smart enough to install Debian is also smart enough to fix this manually...

    • Re:probably not much of an issue (Score:4, Insightful)

      by Dr. Evil ( 3501 ) on Sunday September 30, 2007 @07:11AM (#20800425)

      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: (Score:2)

      by Lennie ( 16154 )
      You don't need to, it's in volatile.

      Where it belongs according to Debian policy.

  • Debian did the right thing (Score:5, Insightful)

    by Anonymous Coward on Sunday September 30, 2007 @07:09AM (#20800411)
    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.
    • What the AC said. As a matter of principle, pushing non-security "security" updates that change functionality is asking for trouble. The updated time zone package has been available for months, a national time zone change should be common knowledge, and anyone in NZ who has not yet installed it is ignorant, or negligent, or both. This article submission is indeed a troll.

    • Re: (Score:2)

      by strredwolf ( 532 )
      The problem is that timezone data is time sensitive. NZ folks already know about the time zone changes, and Debian admins over there are pulling their hair out over how Debian has handled such information. Of course they know it's in volatile, being pushed for the next Etch update. They're probably ether slapping it in now, manually compiling the data, or looking at moving away from Debian. Debian, however, dropped the ball because it had to be put out to the public before today. Typical Debian politic
      • It *was* put out to the public before today. It was put out to public months ago. Go to volatile--which is where it belongs--and download it.

    • Re: (Score:2)

      by Skapare ( 16644 )

      If I were in NZ and installed a fresh new Debian system today, I believe it would be within reason to expect it to behave correctly with respect to things like time. The fact that Debian is structured to not have this feature is, IMHO, a very serious drawback to Debian. There was a similar, less serious, issue many years ago that turned me away from considering the use of Debian.

      • If I were in NZ and installed a fresh new Debian system today, I believe it would be within reason to expect it to behave correctly with respect to things like time. The fact that Debian is structured to not have this feature is, IMHO, a very serious drawback to Debian.

        So, name one operating system released at the time that Debian Etch was released or before, that contained this time zone update out of the box. I don't think you can, because their publishers would have had to be psychic or have a super-dup

    • Re:Debian did the right thing (Score:4, Insightful)

      by Andy Dodd ( 701 ) <atd7@@@cornell...edu> on Sunday September 30, 2007 @09:06AM (#20801111) Homepage
      "This update is not security-related"

      Yes, in fact, it is. Have you ever heard of log timestamps?

      • Re: (Score:3, Informative)

        by julesh ( 229690 )
        "This update is not security-related"

        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 occu

  • OB (Score:5, Funny)

    by Hognoxious ( 631665 ) on Sunday September 30, 2007 @07:21AM (#20800465) Homepage Journal

    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!

  • With my FreeBSD hats... (Score:5, Interesting)

    by MavEtJu ( 241979 ) <<gro.ujtevam> <ta> <todhsals>> on Sunday September 30, 2007 @07:33AM (#20800515) Homepage
    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.

  • Keep in mind that this conversation is from a subset of the Debian developers, the glibc team/group. They are correct in saying that this is not a security fix, and that's not how they planned on releasing the update. Its clear from this statement "It will go through etch/updates when the new point release will be issued, andwe missed the previous window because the bug was open a few days before the last release, and it couldn't make it sorry. So we pushed it in any other place we have access to, namely

  • This points to a wider problem... (Score:5, Insightful)

    by b0s0z0ku ( 752509 ) on Sunday September 30, 2007 @07:41AM (#20800543)
    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.
    • Yup, and switch the whole world to UTC while we're at it. Brilliant (no really, I'd like it), except it's not going to happen. Too much inertia and not enough interest.
  • ... to allow Debian warships back in their ports.

  • What I find truly dumb.... (Score:3, Insightful)

    by TW Atwater ( 1145245 ) on Sunday September 30, 2007 @07:44AM (#20800565)
    ...is daylight savings time.
  • > The final comment (at this writing), from madcoder, says 'The package sits in volatile
    > for months. Please take your troll elsewhere.'"

    He's right. That is exactly what volatile is for.

  • WTF (Score:2, Insightful)

    by fmaresca ( 739871 )
    this article is about? It's about a sysadmin who's blaming Debian for not doing her job?
    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 responsabil
    • They're only right in the context of the system that they created and only on the point that this is not a security fix. Where they are wrong is the fact that the update, which had been written some time ago, did not make it into the normal system updates _as planned_ because of timing. To me the problem is why did a fix that was available for months take so long to get into the normal update stream? Ubuntu was able to make that happen in less than a week...

      When processes fail to serve your customers you

      • Re: (Score:2)

        by thsths ( 31372 )
        > To me the problem is why did a fix that was available for months take so long to get into the normal update stream?

        volatile is the normal update stream. It deals with all the changes that are not bug fixes, but become necessary because the environment changes. Which is exactly what this is about.

        > When processes fail to serve your customers you have a problem with your process.

        I think Debian decided long ago to rather do it right than to serve the masses (if both are conflicting). And I think it did
        • No, Volatile is _not_ the normal update stream. When the US decided to update DS volatile was not even considered as an option, the changes went into the normal updates long before the change took affect on the ground. This is _not_ an example of Debian doing things the "right way" but rather them not being able to match their own processes to get updates in a timely fashion.

      • Re: (Score:2, Informative)

        by fmaresca ( 739871 )
        Ubuntu, although Debian based, it's a completely different distro, and it's goal it's aimed at a different target. Ubuntu is capable of push updates/upgrades largely because the quality assurance is made upstream (in Debian itself).

        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 th
  • Can't we put the blame here where it belongs: on the idiots who keep foisting Daylight Saving Time nonsense on us? For god's sake, people, if you think there's some benefit in waking up at a different time of day, then change your freaking alarm time, not the time time.

    • Re: (Score:2)

      by C_Kode ( 102755 )
      It's not about what you believe to be correct. It's about what people use. Maybe it's you (and Debian maintainers) that have the problem here. Think about it. All the commercial OSs release the update, yet someone that controls something that is non-profit decides he is right and everyone else is wrong. The reason the commercial OSs release it? Because people use it!

      • Re:The real culprit here (Score:4, Informative)

        by johnw ( 3725 ) on Sunday September 30, 2007 @10:47AM (#20801779)

        All the commercial OSs release the update, yet someone that controls something that is non-profit decides he is right and everyone else is wrong. The reason the commercial OSs release it? Because people use it!
        You seem to have failed to read the article. The Debian people *have* released the necessary package ages ago, and it will be rolled into the next release of Etch. The OP's complaint is that they didn't put it in the security updates. Since it isn't a security update it would have been quite wrong to put it in the security updates.

        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.
  • Well, since there are no end users that use Debian, i guess their entire userbase are more then capable to just do the patch themselves, right?

    No elitism here ..

    ( Yes this is sarcasm. Rather short sighted of the Debian crew )
  • Good for Debian. I can't tell you how much of a pain in the ass timezone alterations are. The US one sucked big time. I wish more companies raised their middle finger to this shit. Talk about a waste of time, because it isn't as if most IT workers/organizations DON'T HAVE ENOUGH TO DO ALREADY. PLUS, if you are an international shop, knowing that some other country has legislated a timezone change could bite you. It's because of crap like this that I advise my customers to just run GMT.
  • Near as I can tell, the US DST change went into tzdata2007d - so it's not in the one in stable either (unless I got the timeline wrong).

    So - what did Debian do for that? If they left it in volatile, then the NZ guys haven't got anything to complain about, really - at least the Debian folks are consistent (in this scenario)

  • I think you mean GMT *plus* 13. (Score:5, Informative)

    by novakreo ( 598689 ) on Sunday September 30, 2007 @01:09PM (#20802679) Homepage

    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.

  • It sure is a security bug (Score:4, Insightful)

    by Chris Snook ( 872473 ) on Sunday September 30, 2007 @01:15PM (#20802707)
    Several security protocols mandate close time synchronization to minimize the risk of replay attacks, so failure to deploy this time zone change causes a denial of service. In particular Kerberos is impacted, and increasing the permissible time skew by a few orders of magnitude on every box in the domain, which not all implementations support, creates a substantial risk unless you're set up for ticket pre-authentication, which puts a greater load on the server, is not well supported by all clients, and is thus often not enabled. Admittedly, if you're using a network of Debian stable machines, you should be okay, but god forbid someone should use a Debian stable box in an Active Directory deployment.

    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:It sure is a security bug (Score:4, Informative)

      by igb ( 28052 ) on Sunday September 30, 2007 @02:40PM (#20803285)
      Protocols mandate close synch of UTC. If they required clock-on-the-wall time to be synchronized then they wouldn't work across time zone boundaries. I manage a network with staff in six timezones, between UTC-8 and UTC+9, some of them with non-integer offsets, with (from memory) four different sets of DST rules, including one (Japan) that doesn't do daylight saving. I know about the timezones because I'm a clock geek sad enough to know the difference between UTC and GMT. But I don't need my systems to understand it (aside from shouting at bloody Apple for thinking BST, UTC+1, is called BDT). That's because everything that cares about timing (Clearcase, WebDAV, SVN, NFS, Make...) works in UTC.

Slashdot Top Deals

Every nonzero finite dimensional inner product space has an orthonormal basis. It makes sense, when you don't think about it.

Close