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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 29 July 2003 14:46, Rob Kaper wrote:
> On Tue, Jul 29, 2003 at 11:38:08AM +0200, Dirk Mueller wrote:
> >         07/03/2003 Notification of [email protected] by George Staikos
> >         07/10/2003 Fixed in KDE CVS.
> >         07/11/2003 OS vendors / binary package providers alerted and
> >                    provided with patches.
> > 	07/29/2003 Public Security Advisory by the KDE Security team.
>
> Why does it take 18 days to release a security update?

It was waiting for KDE 3.1.3 to be released.

> "If an immediate fix is not considered necessary a security alert is issued
> via dot.kde.org, bugtraq and [email protected]"
>
> As I do not recall a security alert on July 11th, I assume that an
> "immediate fix" *was* indeed considered necessary. In what way is 18 days
> even close to "immediate" ?

Compared with patching it in CVS HEAD and waiting for 3.2 to be released, I 
think 18 days is reasonably immediate. If KDE 3.1.3 hadn't been planned so 
close by already the advisory had been sooner. 

> Why do KDE users and developers have to be vulnerable for an extended
> period of time based on the responsiveness of packagers? What is the exact
> policy for releasing security fixes? 50% of packages done? All packages
> done? SuSE packages done?
>
> http://www.kde.org/info/security/policy.php is not clear on this.
>
> "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?

The idea is to reduce the time between the problem becoming widely publicized 
and most of our userbase being able to upgrade to a fixed version in order to 
keep the overall risk for our userbase to a minimum.

This is based on the assumption that most of our userbase depends on binary 
packages and that publication of the vulnerability increases the risk to 
unpatched systems.

> In what way are we an open project when OS vendors / binary package
> providers are given special treatment over users and contributors?
>
> "Applications will be evaluated on a case by case basis by the current
> members. The main criteria is the extent to which someone can be helpful in
> excuting [sic] the security policy as described here. That includes a
> willingness not to disclose issues prematurely."
>
> How come the security policy has been locked down, as the "team" can only
> be extended by those who want to execute the policy as described? In what
> way does the KDE Security team justify the special privileges over the KDE
> release process they have taken?

Feel free to suggest improvements to the process.

> Please do not reply with the "black hat", "white hat", "Red Hat" arguments.
> I am fully aware of it and - to a certain degree - can even follow the
> logic, up to the point where it breaks:
>
> Why should users of system A have an extended period of vulnerability
> because system B has a slow packaging and distribution process? There is a
> *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.

I don't think the advantage of having a fix a few days earlier available to 
source-users weighs up against the advantage of having the fix not 
immediately available to binary-users after it has been publicized. Keep in 
mind that this particular problem has been present in KDE for the last 5 
years or so.

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

Dirk and I made the decision to wait for KDE 3.1.3 

Cheers,
Waldo
- -- 
[email protected] -=|[ SuSE, The Linux Desktop Experts ]|=- [email protected]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE/JpCON4pvrENfboIRArdSAJsGgNhFKFZNVmbxTtGpCULDcqGOCACfamr6
g4+euhu3k2a4wWhpfOy5wqQ=
=2fXX
-----END PGP SIGNATURE-----