Re: [kde-announce] KDE Security Advisory: Konqueror Referer Authentication Leak

On Die, 29 Jul 2003, Rob Kaper wrote:

> Why does it take 18 days to release a security update?

It takes the time it needs to ship the fix. 

> Why do KDE users and developers have to be vulnerable for an extended period
> of time based on the responsiveness of packagers? 

This bug exists for about 5 years and you start arguing that 18 days is an 
extended period of time? Can you further elaborate why?

> "We then give them a reasonable amount of time to prepare binary packages."
> 
> Who is the KDE Security Team to decide this "reasonable amount of time" and
> why doesn't the entire KDE contributor base get a say in this?

Because it would take much longer to wake up > 1000 contributors and ask 
them what they consider a "reasonable amount of time" than the 18 days it 
took to put the fix out. 

Furthermore, as you were told on kde-core-devel already, but I'll repeat it 
here again just for you: 

- it was the KDE security teams decision to delay the announcement of the 
  vulnerability, till the actual fix in form of source packages (KDE 3.1.3)
  is available. 

- 3.1.3 tarballs were supposed to be done on July 14th. However, thanks
  to several late minute build fuckups (as usual) they were not in a 
  compileable state till July 16th. The packagers received the final 
  tarballs, the advisory and the patches by then. 

- Due to other pending problems it was impossible to release KDE 3.1.3
  on July 21th like initially planned. Instead, the announcement had
  to be delayed for about another week. 

At neither point of time anybody of the security team, the packager team or 
whatever other secret KDE group you suspect to sabotage KDE's release 
process thought about "Ah, nahh, we won't put out the fix we have ready 
today, instead we'll go on vacation for 14 days and then do it when we come 
back". 

There were good reasons to hold back the 3.1.3 release, thats for sure, but 
its not the time to talk about it yet. 

> In what way are we an open project when OS vendors / binary package
> providers are given special treatment over users and contributors?

We don't give them a special treatment at all. In fact, they're crazy as 
nuts on us because we only gave them 4.5 days to generate over 4.5GB of 
binary packages. You can do better? 

Furthermore, remember that packagers don't just have to rebuild the 3.1.3 
release (which they meanwhile have scripts for). Instead they have to apply 
the patch manually to half a dozen versions on several architectures, 
generate new packages, test them, send them to the Quality Assurance team 
and get them approved for announcement. A rule of thumb for something like a 
kdelibs update this is at least 5 days of work. Remember that KDE is the 
default GUI for many distributions, and if they accidentally tend to break 
something with their security update a lot of users will be unhappy. 

> *reason* I run a vanilla Slackware with many compilations from source:
> source tarballs are faster to fix than waiting for new packages. That is, in
> a world were source tarballs don't depend on the availability of binary
> packages.

So, lets put it under a different perspective: How many security updates did 
you see released today for this vulnerability from different binary 
package vendors?

Do you want to do a bet on how long it will take till the first one releases 
an update?

> Just answer one question: who decided that 18 days was "a reasonable time"
> and under what authority?

Just answer one question: Why do you think that 18 days was a "unreasonable 
time"?

If you can't give reasons for that, then there is nothing to talk about. 


-- 
Dirk