Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
KDE GUI

KDE 3.1 Delayed - For A Very Good Reason 31

Posted by timothy from the measuring-twice dept.
woobieman29 writes "KDE.news reported on Saturday that the KDE 3.1 release that was scheduled for this week has been delayed until early January. This is happening due to some security concerns that have arisen during a security audit of the 3.1 CVS tree. Kudos to the KDE team for making sure that the product is fully baked before release.!"
This discussion has been archived. No new comments can be posted.

KDE 3.1 Delayed - For A Very Good Reason More

KDE 3.1 Delayed - For A Very Good Reason

Comments Filter:
  • Software release delayed over a security concern. Great! Now if the BIG makers of software (and OSs) would take this up.
    • Oh, and I forgot. First post.

      Imagine the mess we'd be in if Microsoft could do this? Half of my gripes with M$ software stem from bugs and security holes. Now that they've become a monopoly by killing the competion, as opposed to outselling them via a offering a better product, they could take the time to squash bugs and plug holes. If all my practical reasons for disliking M$ go away, I'm left with nothing but dislike for their business practices...which are subjective decisions. That would certainly be a major blow to the anti-M$ crowd.

      • Re:Thank God (Score:3, Insightful)

        by Randolpho ( 628485 )
        You know... Microsoft gets a big bum rap for a lot of its security holes. I will admit they tend, like every other major software company out there to release programs that need a patch or two, but (aside from those dreaded buffer overflows, which they still can't seem to get around) most of the stuff that is considered a "security hole" by the fine *nix crowd is really what they claim it is; a feature.

        You can blame market research for finding the desire for those "features", to be sure, but a lot of this stuff was put there because people wanted it there.
        • Please direct me to the user(s) that claimed that being able to format your hard disk by visiting a website [extremetech.com] is a feature, and not a bug. I'd like to introduce them to my friend, Mr. Aluminum Bat.

          If adding features to your product introduces potential for known exploits that didn't previously exist (the potential, not the exploits), then you don't add the features. Doing so is brain-dead. And *that* we can scream at Microsoft for.

          If I know that language X was designed to be sandboxed by a bytecode interpreter, and I remove that sandbox, then I'm perfectly responsible for any behavior that didn't get contained by that code.
          • Please direct me to the user(s) that claimed that being able to format your hard disk by visiting a website [extremetech.com] is a feature, and not a bug. I'd like to introduce them to my friend, Mr. Aluminum Bat.
            Sure [crackmonkey.org], happy now?
        • Regardless of what users ask for, if they do not have the bugs worked out of a "feature" or they aren't able to provide a convience without introducing a security hole, then they aren't technically equipted to provide that feature yet and should not. It's part of the trust buisnesses provide microsoft millions for, security, security and stablity is first, next comes user interface. If you keep up the security and stablility, then there is plenty of time to work on the user interface. If you develope thinking about features first and fixing bugs and closing the holes you've already got second then your always going to sit where microsoft is (quality, stability, and security-wise, not profit wise, their code has nothing to do with their place in the market).

          Microsoft actually spends more time developing new features than fixing bugs... as a programmer I can tell you, working out the kinks in a program takes longer than writing a first draft (ie microsoft final release).

          For starters it gives people a false idea of where technology is... Microsoft releases "features" and "conviences" before they are safe and bug free... this is technology that doesn't really exist yet in a stable and/or secure state (although there are other alternatives of the same "features" that are usually put out not long thereafter by those who were working on the same thing but bothered to run a debugger.).

          I'm not saying every other developer is more responsible than microsoft, I'm saying microsoft is irresponsible.

          They aren't the only ones, they are just the only ones with a 90+% desktop market monopoly that shapes the minds of those first getting into computers.

          People complain about those who single out microsoft. i can't speak for anyone else, but for the most part when i complain about microsoft it is due to something bad they are doing, that is bad because of, or a largely impacting issue because of their blatant monopoly.

      • You still wouldn't be able to reconstruct the system to do anything else than what you've been given dialog settings for. Unless the Windows Registry is considered as efficient a way to configure things as configurations files + man pages + source. Or rebuilding that is considered part of the bugsquashing campaign. Which it should be, given the design.

        And then there's the price. And spirit. Like, what fun would it be running around rebooting machines instead of chatting in irc about configuration details?-)

  • RC? (Score:5, Insightful)

    by Trusty Penfold ( 615679 ) <jon_edwards@spanners4us.com> on Monday December 09, 2002 @11:23PM (#4850636) Journal

    Obviously delaying the release until the security holes are fixed is the only course of action.

    Since the betas and RC are now going to be exposed to the world for longer, are the security holes going to be disclosed so that we can take some action to secure our systems that are running these pre-release builds?

    • Re:RC? (Score:5, Informative)

      by GreyWolf3000 ( 468618 ) on Monday December 09, 2002 @11:53PM (#4850911) Journal
      Since the betas and RC are now going to be exposed to the world for longer, are the security holes going to be disclosed so that we can take some action to secure our systems that are running these pre-release builds?

      I'm not going to karma whore and give you links to the holes themselves, but this [kde.org] is a good place to start. They disclose holes as they happen; it's open source. Systems that choose to run thes pre-release builds accept such risks anyways.

    • Re:RC? (Score:3, Insightful)

      by RAMMS+EIN ( 578166 )
      ``Since the betas and RC are now going to be exposed to the world for longer, are the security holes going to be disclosed so that we can take some action to secure our systems that are running these pre-release builds? ''
      They don't have to. After all, betas and even RCs are clearly not guaranteed to be bug free. Developers don't even have the moral obligation to support them. If you are concerned about [security] bugs, run a stable version.
    • Just downgrade them to stable. They're PRE RELEASE builds ya know. They might not work right...

  • Good for Them (Score:5, Funny)

    by MBCook ( 132727 ) <foobarsoft@foobarsoft.com> on Monday December 09, 2002 @11:28PM (#4850681) Homepage
    This is good to see. Not only are they doing this for security, but this means it won't have too many bugs when it's released (which doesn't seem to be the case with alot of software these days).

    In other news, uppon reading this, Microsoft declared a company wide day of laughing, stating "...this is the most rediculus strategy we've ever seen! Why if we did this, we'd still be working on DOS 4 or 5." Later in the conversation, the spokesperson asked to take back that statement and said if we printed it the BSA would come after us for liscenses.

    Gotta go, there is a knock on the door...

  • How about some links to what was so suspcious?
    • That's on a need to know basis, and you don't. :)

      Well, I suppose they could tell you, but then they'd have to kill you.
    • First of all, here's a link to the story [kde.org] on The Dot, and Dirk Mueller's explanation [kde.org]. In summary, the Hackademy Audit Project discovered some bugs in KDE 3.0 some time ago, which have been fixed in 3.0.5 and 3.1RC4 (which was not released to the public). However, this also started a KDE-internal security audit, which, while not being completed yet, warranted a delay of the release. As soon as the audit is completed, a security fix release for 3.0 (3.0.6?) will hit the servers, along with patches for 2.2 and KDE 3.1. If you are interested in what exactly has been discovered, I suggest looking in the KDE mailing list archives [kde.org].
  • And yet, when Microsoft delays their products (even though they delay them for a long time), they get severely criticized.

    Sure, they might not say they're doing security audits, but who can blame them? They have many corporate partners who would see security auditing as an indication of flawed software.

    Just keeping things in perspective.

    • Could be... since until the longhorn statement microsoft has had a really bad history of early releases their gonna need time to figure out how to look for bugs. First they have to get tutorials and figure out how to use debuggers and such. It might also confuse their programmers when they see a piece of code after the initial draft, they might scratch their heads and twitch in their cubicle not really understanding why someone would want them to look at code they already wrote.

      Or maybe they are waiting for the monopoly lawsuits to have time to blow over so nobody will be looking very close. They could also be giving people time to swallow the XP license, I mean, if they delay the next release the subscribers might think "that wasn't so bad" and then they will start churning them out at their usual release cycle, what is that, 200mb of first draft code (that never goes past first draft) a week?
    • People give microsoft a hard time about delaying releases because they have purposefully made unrealistically optimistic announcements of release dates in the past to stifle competition. An example: Borland announces Turbo Basic and Microsoft quickly preannounces Quick Basic 3 to chill the market. Furthermore, there is evidence that this was the intent. A microsoft internal memorandum stated, "The best way to stick it to Philippe is preannounce ... to hold off Turbo buyers." For a monopoly like microsoft, this action is illegal under antitrust laws.

      See http://www.law.gwu.edu/facweb/claw/Vaporware.htm
      for the full story. That is where I got this example from, but there are many others.

Slashdot Top Deals

"Why can't we ever attempt to solve a problem in this country without having a 'War' on it?" -- Rich Thomson, talk.politics.misc

Close