[kde-announce] KDE Security Advisory: Konqueror Referer
Authentication Leak
Dirk Mueller
mueller at kde.org
Tue Jul 29 20:56:16 CEST 2003
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
More information about the Kde-policies
mailing list