Security Policy

[Christoph Cullmann]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 10 March 2003 23:15, George Staikos wrote:
> On Monday 10 March 2003 16:19, Waldo Bastian wrote:
> > I broadly agree with that but with two nuances:
> > * I think it is important to alert users to a threat and to provide them
> > with information on how to eliminate that threat, but I don't think that
> > publishing detailed exploit information is in the interest of the user.=
 *
> > I think it's justified to delay the publishing of information when there
> > is actively being worked on either a) a better impact analysis or b) a
> > fix for the problem. Once you disclose the threat there will be increas=
ed
> > attention for that vulnerability so it's very important to provide
> > correct information and credible solutions to eliminate that threat at
> > the time of disclosure. I also think that it is counter-productive to
> > have multiple publications in short succession on a single issue since I
> > think that that blurs the attention of the users that you try to reach.=
 I
> > think perhaps the most critical element of a security update is the user
> > having actually applying the update. For that, effective and efficient
> > communication with the user is vital IMO. So I think that the goal shou=
ld
> > be to get it right and complete the first time.
>
>   An additional note:  In the past (up until, I guess, the mid-late
> 1990's), it was often the case that exploits were just posted to bugtraq
> and the fixes would come later.  The new accepted policy for handling
> security holes is to contact the developers in private, organise a patch
> and press release date with the affected parties, and release as quickly =
as
> possible,
> simultaneously.  security@ addresses are generally used as contact points,
> and considered to be private.
Which sounds like a good way to:
a) ensure the users gets the informations they need and want as quick as=20
possible (without opening all doors for people using published exploits to=
=20
hack them even before the real problems are found)
b) developers have the chance to fix the problem or at least document the r=
eal=20
impact right and provide correct workarounds or even patches

cu
Christoph

=2D --=20
Christoph Cullmann
KDE Developer, kde.org Co-Maintainer
http://www.babylon2k.de, cullmann@kde.org
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+bSUdyPjDGePm9UIRAqH2AJ9zhZQbfMdDbm5nQeJwr05oZhqK2QCeJIqv
H9t0D13ozf5ajl6CpoZLgD8=3D
=3D42i4
=2D----END PGP SIGNATURE-----