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.

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.

> 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?

> 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.

> 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?

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.

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.

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.

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.

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.

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".

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.

> 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.

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.

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.

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.)

> 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.

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.

> 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.

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?

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.

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 ...

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).

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...

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