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

[Rob Kaper]

On Tue, Jul 29, 2003 at 07:56:16PM +0200, Dirk Mueller wrote:
> > Why does it take 18 days to release a security update?
> 
> It takes the time it needs to ship the fix. 

I would say that three business days should be enough for any
self-respecting, commercial, professional distribution. I'm talking about
the security fix here, no a complete KDE upgrade.

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

Because that's what extended means.

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

That's why I mailed policies and not kde-core-devel. I think a more specific
time frame in the policies would be a good thing.

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

The advisory states they were informed the 11th. The unplanned compile
problems are another good argument to have released the fix as a patch
or 3.1.2a instead of waiting for 3.1.3.

I appreciate this information, but the next time, could it please be
communicated earlier? I haven't received such detailed updates before,
despite asking.

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

There is special treatment, because they get informed on security and
packaging problems while others aren't. You can argue in favor of that
special treatment, but until I can subscribe to either list, it can't be
denied.

There would not have been a need to generate that amount had the security
fix been released seperately of the 3.1.3 release.

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

None for Slackware, none for SuSE, none for Debian..

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

So basically, the current policy isn't working? If we go by the "majority of
users" rule, most of them will not go to kde.org to download an update but
will just catch it in their distributions update cycle.

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

It's unreasonable because by your admission above, it doesn't benefit the
majority of our users and in the meanwhile only hinders those most closely
involved with the project.

Rob
-- 
Rob Kaper     | "They that can give up essential liberty to obtain a little
cap at capsi.com | temporary safety deserve neither liberty nor safety."
www.capsi.com | - Benjamin Franklin, Historical Review of Pennsylvania, 1759
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-policies/attachments/20030731/513db20b/attachment.bin