JAN
14
2004

KDE 3.1.5 Released

Dirk Mueller released today

KDE 3.1.5
, the latest and final release in the KDE 3.1 series.
The release was triggered by a

security issue

that was discovered in the VCF file information reader.
The
ChangeLog
lists the other fixes contained in this release.
KDE 3.2 is expected to be released early February.

Comments

Surprise-surprise indeed, as this bug was fixed four weeks ago. Why do we package an entire KDE release with all the associated packaging delays for a simple security fix?


By Rob Kaper at Wed, 2004/01/14 - 6:00am

Because there are other changes besides
the security fix in 3.1.5 as well. It is an release with months
of bugfix work and translation updates.

Besides that, I remember that there were people threatening me
to do another release. Can't remember right now who that was though.


By Dirk Mueller at Wed, 2004/01/14 - 6:00am

Yes, I have asked you to do a 3.1.5 release in October and I think we both know that's what you're referring too, especially since "people" dramatically becomes singular in your second sentence. But since you succeeded in keeping your statement vague, I won't have to ask you to back up your claims that any threats against you were made.

Now, back to the problem at hand: your release decisions still don't make any sense to me. Which would be fine, except that they hurt KDE users.

The release of KDE 3.1.5 and its bug fixes has nothing at all to do with the need for urgent action regarding security problems. Packagers could easily have had a 3.1.4a or 3.1.4-patchlevel1 out before Christmas, regardless of what other changes had been made in the branch, regardless of whether you wanted to make a 3.1.5 release to wrap up the branch before 3.2 is out. There is simply no excuse to force the repackaging and testing for all of KDE when a security fix needs to be made.

I've said so before when the exact same problem occurred for KDE 3.1.4, so by choosing to make a KDE 3.1.5 release available to packagers instead of just a security update you knowingly and willingly have put KDE users at risk, extending their vulnerability for a prolonged time. I find that irresponsible for a release coordinator of one of the most deployed free software desktop projects.

Once is happenstance, twice is coincidence, three times is enemy action. Please don't let it happen again.


By Rob Kaper at Wed, 2004/01/14 - 6:00am

> Packagers could easily
> have had a 3.1.4a or 3.1.4-patchlevel1 out before Christmas

do you have any proof for that? If not why are you claiming it then?

> I've said so before when the exact same problem occurred for KDE 3.1.4, so
> by choosing to make a KDE 3.1.5 release available to packagers instead of
> just a security update you knowingly and willingly have put KDE users at
> risk

Not at all. We've been over and over it again. Look there are very few binary
packages of 3.1.5. Now compare the kde security announcement date and time
with the date and time of when various linux distributions made their announcement of their updated 3.1.4 (or even older) packages containing this fix, then do your math.

BTW, its the second time you claim to know about the reasons and use this
to spread some FUD. The reasons are not even a secret, and I would have told you when you'd asked first. But you didn't.

So the first time was an accident, the second one a coincidence. What will the
3rd one be?


By Dirk Mueller at Wed, 2004/01/14 - 6:00am

> do you have any proof for that? If not why are you claiming it then?

We're talking about a security patch here, not a full KDE release. Eight business days is a formidable time to recreate existing packages with a small patch incorporated. Any packager who claims to need more time is understaffed or incompetent and shouldn't be taken into consideration by KDE, which, according to our official policies, still releases source tarballs only.

> Not at all. We've been over and over it again. Look there are very few
> binary packages of 3.1.5. Now compare the kde security announcement date and
> time with the date and time of when various linux distributions made their
> announcement of their updated 3.1.4 (or even older) packages containing this
> fix, then do your math.

I'll do the math:

1. If there are very few binary packages of KDE 3.1.5, the current process isn't working, and therefore cannot be justified. It's irrational to defend waiting for binary packages by pointing out that after waiting, there are still very few binary packages.

2. Packaging an entire KDE release apparently takes such a long time for you (if there weren't missing translations or compile problems, I've been misinformed) that we should avoid that process for urgent matters like security releases.

> BTW, its the second time you claim to know about the reasons and use this
> to spread some FUD. The reasons are not even a secret, and I would have told
> you when you'd asked first. But you didn't.

There simply is *no* reason why a dozen modules have to be repackaged for a small security fix, so I didn't ask. If you can explain to me why releasing all of KDE, including games and toys and whatnot was absolutely necessary for fixing the VCF security issue and thus justified the known risk of packaging delays, I'll take back my complaints.

At the moment I don't mind that 3.1.5 took a month. But I do mind that you consider security issues so unimportant that they can simply be shipped with the next full release.

Giving packagers a patch to repackage their existing and tested builds will be magnitudes faster than requiring them to repackage all of KDE.


By Rob Kaper at Thu, 2004/01/15 - 6:00am

> 1. If there are very few binary packages of KDE 3.1.5, the current process
> isn't working, and therefore cannot be justified. It's irrational to defend > waiting for binary packages by pointing out that after waiting, there are
> still very few binary packages.

so now, if you only could draw the conclusion from this that the reason for
the announcement date was not the KDE 3.1.5 release, then I'd be happy.

It might have been a coincidence, or a convenient happening, that 3.1.5
was released by the same time the KDE security announcement was. But the 3.1.5
release had no influence whatsoever on the security announcement (it was
rather the other way around, given that the security announcement took so long, there was no problem with doing 3.1.5 at the same time, which was requested from many sides).

Just because we're caring for our users we don't do the "look, you're vulnerable, here's the patch. now try to figure out how to install a gcc compiler and then have a fun evening" way of disclosing security bugs. That might be inconvenient for the 2% of the users that know how to recompile KDE,
but for the rest of our user base it is not.

Rob, if you're so clever into packaging business, why don't you give them
a helping hand instead of just complaining?

If you're caring so much about early fixing for security bugs, why don't
you go and actually look at the sources if there are bugs, and then fix them?

The KDE whining department is IMHO already fully staffed.


By Dirk Mueller at Thu, 2004/01/15 - 6:00am

I'm afraid he's right. You cannot have a whole KDE release to fix a single security problem, no matter what other improvements have been made and people simply cannot wait this long. Remember, with Lindows, Xandros and others using KDE, with potentially many people in businesses using KDE, patching a whole desktop with a completely new version is just plain stupid. It should be possible to compile a patch, run it, patch a system and increment the version so people know it has been patched. This should be done quickly and easily, and it certainly can be for commercial users, through the use of services like Lindows' Click and Run.

We also need a system so commercial interests can test these patches with the people at KDE. People criticize Microsoft for this; KDE needs to learn how to do it, and it should be substantially less painful.

This sounds like a problem for the new 'Quality Team'.


By David at Thu, 2004/01/15 - 6:00am

one last time I repeat it just for you: the security problem announce
was not delayed because of 3.1.5. Thats it.

and therefore the whole point becomes mood..


By Dirk Mueller at Thu, 2004/01/15 - 6:00am

OK, I admit I'm not familiar as to why it was delayed. Why was it? There could have been a problem in finding the correct fix - it happens.

The point is that people should have an intermediate small patch as soon as possible to correct the problem quickly. 3.1.5 can still be released, and I'm not saying that such intermediate releases should not happen. They definitely should, and with the installation technology available around on Linux this can be a heck of a lot less painful for end-users than on Windows.

I hope I've made my reasoning a bit clearer.


By David at Thu, 2004/01/15 - 6:00am

> one last time I repeat it just for you: the security problem announce
> was not delayed because of 3.1.5. Thats it.

Then you have to admit, that the glibc-, Kernel-, Mozilla- and Gnome people are way faster than KDE. Even most companies don't need one month to write a security announcement.

Don't let "Opensource" stand for "slow with security updates"!


By Asdex at Thu, 2004/01/15 - 6:00am

There was not a one month delay. There was a 2 hours
delay between the time the vulnerability was published and the
time you were able to do your (binary package) update.

And kernel updates is a good question: How long was the time
between the public disclosure (!) of the ptrace bug, and the
time the 2.4.23 kernel was released? It was a matter of several
months.

Or do you mean the recent mremap vulnerability? How long do you
think the kernel developers did know about the problem? Do you
really believe that > 20 linux distributions are able to release
an updated kernel, the central part of their distribution,
within the very same hour (!) of the public disclosure?

Just because we're honest with our time frame doesn't mean
that we're slow. It just means that we're honest. We didn't
tell anyone publically that there was a problem until the fix(!)
was available.

It doesn't matter when the security problem was found
in the source. Two timeframes are important:

a) when was the problem introduced.

b) how long, since the vulnerability was public, do you
have to wait to fix your system.

If you compare these two timeframes then you see that
the KDE team does an excellent job in providing
secure software.


By Dirk Mueller at Thu, 2004/01/15 - 6:00am

BTW: Some vendors or software authors just silently fix security problems
unless somebody publishes a the vulnerability before a fix was employed. They
don't even announce it. They just silently check in a fix and move on.

Please note that the KDE team does not do that. We do a full detailed
announcement of security problems to give you the chance to have a system
that is as secure as possible. That might give us some bad credit among
those who judge the security of software by counting the number of
advisories that exist for it, but hey, I think our way is providing
better security by not hiding information.


By Dirk Mueller at Thu, 2004/01/15 - 6:00am

Oh I completely agree Dirk, and I do think that having intermediate releases is the correct decision. I absolutely agree that this SHOULD NOT CHANGE. You've got to give everyone the chance to be as up to date as possible quickly and easily and in a structured manner - something Microsoft does not manage. I should know, I patch Windows 2000 machines on an all too regular basis. No wonder Microsoft to run around with this, because there is no structure to it.

I just think that discussing something different for security releases in the future may be a good idea. It is good to see a separate patch available for people with 3.1.4 in the announcement, and I think I misunderstood that. Sorry.

I don't think anyone should feel threatened by a discussion on this and I don't think anyone should be bashing release managers at all. I just hope there can be some sensible dialogue.


By David at Fri, 2004/01/16 - 6:00am

> the KDE team does an excellent job in providing secure software.

I want to strongly agree here.

Ever heard of GNOME doing anything for security? Did they ever do an audit, do hey scans for potential vunerable code or publish security advisories (don't say they write bug-free software!). Does GNOME provide checksums for their release or cryptocraphically signed tarballs? Not at all. Or search their website whom to contact if you discover a vunerability.

Or take Mozilla. Look at the Mozilla 1.6 release notes and you read "Several security-related bugs were fixed in 1.6". Any details? Any patches? No.

OpenOffice.org seems to take the GNOME approach, "we have no security bugs or will not tell you about them".


By Anonymous at Fri, 2004/01/16 - 6:00am

Yep. I'm afraid you're right there. I think Gnome and Open Office in particular are in a mood where they are hacking away thinking they are going to take over the world. Nobody seems to have thought about security unfortunately.


By David at Fri, 2004/01/16 - 6:00am

> There was not a one month delay. There was a 2 hours
> delay between the time the vulnerability was published and the
> time you were able to do your (binary package) update.

That's right, now I remember the bugtraq announcement.

What has been misleading was the dot.kde.org article: "The release was triggered by a security issue that was discovered in the VCF file information reader."

Obviously this release was NOT triggered by a security issue.

> And kernel updates is a good question: How long was the time
> between the public disclosure (!) of the ptrace bug, and the
> time the 2.4.23 kernel was released? It was a matter of several
> months.

The patch has been posted instantly. What Marcelo did, was really bad, Alan Cox did a better job on kernel 2.2.


By Asdex at Fri, 2004/01/16 - 6:00am

> Not at all. We've been over and over it again. Look there are
> very few binary packages of 3.1.5.

I have a silly question (but are serious): -How does one applay this kde*.xdelta files?

Thanks.

Jostein


By Jostein Chr. An... at Thu, 2004/01/15 - 6:00am

by using the old tarballs, bunzip2'ing them,
then running

xdelta patch .xdelta

then you can bzip2 the new tarball, and you got one
that is equivalent to the full sized one.


By Dirk Mueller at Thu, 2004/01/15 - 6:00am

Thanks answering! :-)

I just dropped this url in Konqueror (strange that I haven't thought about using wildcards before):

ftp://ftp.kde.org/pub/kde/stable/3.1.5/src/*.xdelta

After that, it was just drag and drop to the HD.

Dowload and getting new tarballs have never been easier. Thanks for the great work the KDE of you are doing! :-)

Jostein


By Jostein Chr. An... at Thu, 2004/01/15 - 6:00am

Is it the newest fashion that people attack release managers and accuse them of not doing their work?

As for the "people in October" that was us, KOffice developers, see bug #66142. A new KDE 3.1 was not released, as nobody ever found a fix for the bug. We finally found a work-around for KOffice on KDE 3.1 in mid-December.

Also I must tell that I am absolutely not understanding why you seems scandalized that a new KDE 3.1 release has been made.


By Nicolas Goutte at Thu, 2004/01/15 - 6:00am

> Also I must tell that I am absolutely not understanding why you seems
> scandalized that a new KDE 3.1 release has been made.

In contrary, I'm extremely satisfied that a new KDE 3.1 release has been made.

I'm pissed however that a security update *wasn't* made and instead was incorporated into a full release which is known to take longer.

As for the KOffice problem, I recall that almost immediately after the request for a new release was made it was revoked again. I certainly didn't see any threats from the KOffice team.


By Rob Kaper at Thu, 2004/01/15 - 6:00am

From the perpective of one of the users you're trying to protect: You really do have a point here, I think, however the matter could have been dealt with in a more professional manner. You're concerned with the credibility and reliability of KDE, I take it - I think you don't improve either by attacking the release manager this way, in public. On the contrary, I think that's quite embarassing, although probably more for you than for KDE. You can accomplish a lot more with a friendly "Don't you think this could have been done better? Here's what I propose: [...]" than with "You're an irresponsible fool; acknowledge my superior reasoning." - the former promotes a spirit of teamwork, you know. Something pretty important in a good release manager, by the way.

Aside from that, I do think that increasing KDE's security response times is a noble goal.

But hey. I'm just a user.


By Eike Hein at Thu, 2004/01/15 - 6:00am

> Aside from that, I do think that increasing KDE's security response times is a noble goal.

Well, I kinda meant to say the opposite - let's make it "improve KDE's security respond times". Guess I'm still somewhat sleepy. ;-D


By Eike Hein at Thu, 2004/01/15 - 6:00am

Releasing a full KDE after a security problem has always have been the policy.

That is for users neither wanting to patch their KDE source nor wanting to use anonymous CVS (perhaps because they do not want to compile.)

So may be it was not announced clearly enough. But it is not a reason to hurry a new KDE release. Better wait a few days than to have to redo the same a few weeks later because of a big bug. And all this is not an excuse for attacking a release manager.

As for KOffice, well, I just meant that the delay was perhaps the reason why no KDE 3.1.5 was released during that period. The request was never rewoked from the KOffice side, but it is difficult to release anything when a fix cannot be found. (KDE 3.2 fixed the problem by rewriting a part of the file dialog code. Unportable to KDE 3.1.)

Have a nice day!


By Nicolas Goutte at Thu, 2004/01/15 - 6:00am

> Releasing a full KDE after a security problem has always have been the
> policy.

That doesn't make the policy right though.

> That is for users neither wanting to patch their KDE source nor wanting to
> use anonymous CVS (perhaps because they do not want to compile.)

No, packagers make binary packages for these users. The issue at hand is whether to let them package a full release or an update.


By Rob Kaper at Thu, 2004/01/15 - 6:00am

> Also I must tell that I am absolutely not understanding why you seems scandalized

That's typical for Rob, not contributing much (outside kdegames) or regularly to KDE but you can be sure that it's a (clueless) criticism when you see a mail from him. And he is important and needs attention, hence not writing in the right places/mailing lists but prefering blogs/news sites. Feel free to ignore anonymous comments.


By Anonymous at Thu, 2004/01/15 - 6:00am

To be honest, I find your anonymous personal attack quite coward. Obviously you need attention too. If you really believe in your own words, you would not comment here. So please, either refrain from these types of comments, or at least be open about it.

The way Rob brings his critique isn't mine, but from my point of view, he has a valid point in that it makes little sence to distribute a whole new KDE version and let so much time to by when, IMHO, a patch would have sufficed. Many bugs were NOT fixed but are fixed in the 3.2 release. Since that one is due in a couple of weeks, I think it would have made more sence to just release a patch against 3.1.4 soon, and have the rest of us wait for 3.2.


By André Somers at Thu, 2004/01/15 - 6:00am

but there have been a lot of translation improvements in KDE 3.1.5 that will benefit a lot of people.


By ac at Thu, 2004/01/15 - 6:00am

> Obviously you need attention too. If you really believe in your own words, you would not comment here.

Wrong view, I do believe in the correctness and power of my words and hence see no need to back them with my name. And attention for "Anonymous"? Be serious, it's a collective term under which different people post.


By Anonymous at Thu, 2004/01/15 - 6:00am

Ok, lets explain again: There was only a security patch advisory. However,
we're not releasing it in pure source form only - since it makes little sense for end users. They want full binary package updates, provided by their vendor.

Therefore, before we announce a vulnerability that was not public before (!),
we give the vendors an reasonable amount of time to prepare an update.

This might take sometimes longer when there is christmas and a lot of far(!)
more critical security bugs.

Take a look at what had to be updated recently, and how much more important
those updates were than the one from KDE. There was *absolutely* no reason
to rush it out, and the way it was done was the best possible way.

Ask yourself this question: Did you know about the problem 4 weeks ago?
Did Joe hacker know about it 4 weeks ago? If not, then why do you care
if it took 4 weeks to provide an update?


By Dirk Mueller at Fri, 2004/01/16 - 6:00am

what prevents making a patch that addresses that security issue?
I don't understand the need for a 'full release'. How about RPMs, is it possible to make an RPM patch? I think SUSE uses RPM patches, but I can't be sure.


By RMS at Thu, 2004/01/15 - 6:00am

KDE Security Advisory: VCF file information reader vulnerability
Original Release Date: 2004-01-14
URL: http://www.kde.org/info/security/advisory-20040114-1.txt

[...]
4. Solution:

As a workaround, remove the kfile_vcf.desktop file.

Users of KDE 3.1.x are advised to upgrade to KDE 3.1.5. A patch for
KDE 3.1.4 is available for users who are unable to upgrade to
KDE 3.1.5.

5. Patch:

A patch for KDE 3.1.4 is available from
ftp://ftp.kde.org/pub/kde/security_patches :

26469366cc393e50ff80d6dca8c74c58 post-3.1.4-kdepim-kfile-plugins.diff

6. Time line and credits:

15/12/2003 KDE developer Dirk Mueller discovers vulnerability.
15/12/2003 Patches for the vulnerability are applied to CVS and
release preparations for KDE 3.1.5 are started.

14/01/2004 Public advisory.

Bye

Thorsten


By Thorsten Schnebeck at Thu, 2004/01/15 - 6:00am

will debian sarge use Kde 3.2 or rely on the slow 3.1 version ?


By jo at Wed, 2004/01/14 - 6:00am

Hello,

if we are realistic, it will at least include 3.2 and at the time it will be very old already. ;-9

Yours,
Kay


By Debian User at Wed, 2004/01/14 - 6:00am

> ...and at the time it will be very old already.

Didn't you really want to say
"...and at the time *I* will be very old already"?

;-)


By cm at Wed, 2004/01/14 - 6:00am

Noway, they are uploading 3.1.4 packages as far as I know.
And Sarge could be there faster then you think.
http://lists.debian.org/debian-devel/2004/debian-devel-200401/msg00264.html


By Also Debian User at Thu, 2004/01/15 - 6:00am

KDE 3.1.5 for the most part is already in sid. KDE 3.2 might go in but only if sarge is held up quite a bit. Currently people in charge think it is going to release within the next month.


By Chris Cheney at Thu, 2004/01/15 - 6:00am

So, is 3.2 finally on a freeze, as indicated by http://developer.kde.org/development-versions/kde-3.2-release-plan.html
?

Thanks !


By MandrakeUser at Wed, 2004/01/14 - 6:00am

Yes, we are following the release plan schedule so far. On Monday, we entered "deep freeze", meaning only commits that address "showstopper" bugs are allowed.


By LMCBoy at Wed, 2004/01/14 - 6:00am

Fantastic, thank you for the quick answer.

I am running KDE 3.2 from mandrake-cooker, I think it is synced with CVS. I am really really impressed with 3.2. The start up time is much faster here, the rest of the desktop usage seems lighter though the change is not so spectacular. The new PIM is very slick, it simply rocks. And I like that it really builds from 3.1, so that the user won't feel a sharp transition. This is a sign of maturity.

KDE has matured so well that in many areas the only changes that we really need for 3.3 are mostly usability issues (it can always be made more usable ;-) . Some other areas such as PIM, Office, etc are of course under heavy development these days ...

Cheers !


By MandrakeUser at Wed, 2004/01/14 - 6:00am

I think we still need to innovate and come up with a kLife suite, you know, for everything else you do in life that kOffice does not provide. Doesn't everybody else agree?
-Will


By Will Stokes at Wed, 2004/01/14 - 6:00am

What applications would such a package contain?

Alternatively, what rules do you apply to determine whether the package belongs in kLife or not?

Why do you choose those rules?

Brad


By Brad Hards at Wed, 2004/01/14 - 6:00am

I can see the idea, although I'm not sure I like it.

KDE - base package

KOffice - Tools for work (Word Processor, Spreadsheet, etc)

KLife - Easy tools for home (Photo album maker, Jukebox music player, etc)

I don't agree because the home user will want to write Grandma or balance their budget with KWord and KSpread, and the office user will want to use the photo album maker to put together a thing about the office picnic. And the executive will want to listen to ABBA and Queensryche in their office (with the door shut - and no, I'm not making that example up).

--
Evan


By Evan "JabberWok... at Wed, 2004/01/14 - 6:00am

The queensryche I can understand...but ABBA as well?


By mabinogi at Wed, 2004/01/14 - 6:00am

KLife could include KBoy- and KGirlFriend, some kind of virtual Tamagotchi that you could pet every now and then and who at random intervals compliments you for your code: "Wow, that's some nice code you are doing there!". :) KCoffeeMaker could also be a handy thing to have...


By Jan Ekholm at Thu, 2004/01/15 - 6:00am

Hey... Shouldn't that be KoffeeeMaker? Anyway - It has my vote - It's required!


By Lars at Thu, 2004/01/15 - 6:00am

you mean we should "innovate" by copying apple's iLife?
I'm not against the idea, but its not innovation.


By ac at Wed, 2004/01/14 - 6:00am

If noone has copied it before, then it´s innovation ;-)


By Roberto Alsina at Wed, 2004/01/14 - 6:00am

LOL! Right on.

I think a KLife suite would be great, but there's no need to make it a separate project. We just have to wait, and the applications will come.


By Spy Hunter at Thu, 2004/01/15 - 6:00am

Clearly nobody catches my sarcasm, although Apple is onto something. Right now kde is a collection of programs. I don't believe there is a cohesive goal any kde developers have formulated that tries to achieve a kde release which provides the most improtant packages to users (not developers). koffice is a start in the right direction, but as my post before mentioned, there are other bundles of applications or types of applications joe user would like to have on his system.

kLife does not exist, but various iLife like applications do. :)
Mad Man ~ iTunes
Album Shaper ~ iPhoto

none of these or other similar packages onlinux "work together" though. should they? how? in what ways apple hasn't already tried? :)
-Will


By Will Stokes at Wed, 2004/01/14 - 6:00am

Pages