On Mon, Oct 10, 2005 at 01:40:40PM +0200, Martin Schulze wrote:
> Ulf Harnhammar wrote:
> > > In light of the current problems with upstream, maybe you could
> > > stick a big note in capital letters enclosed in dashes, bars or
> > > other significant characters at the top your your mail? Not sure
> > > if that would help, but it may be worth a try.
> >
> > It is worth trying.
> >
> > Perhaps we should write a document about how we want upstream developers to
> > behave? (Don't panic, wait until the release date, add CVE/CAN entry,
> > anything else?)
Here's what I would say, based on past experience:
---------------------------------------------------------------------------
Notes to upstream developers regarding security bugs
-----------------------------------------------------
The Debian Security Audit team is trying to find as many security bugs
in the software distributed by Debian as possible. Security bugs
can be anything from a remote code execution to a configuration that
might reveal sensitive information to remote systems. We disclose this
bugs only in private e-mail to the Debian Security Team, to the Debian
package maintainer and to the upstream developer (you). The Security Team
forwards the issues we find to vendor-sec, a private mailing list of open
source vendors, since security bugs we find might be found in other
free software distributions (we have a lot of software in common after all).
If we find a bug in your software we will notify you. So here's the
steps we expect from you:
1.- Don't panic! [ Security bugs are common as is nothing to be ashamed of ]
2.- Don't make it public inmediately (by publishing a notice on your web
site or mailing an announce mailing list) since that means exposing all
the users of software running it and the distributions that ship it.
3.- Review the bug and make sure it's relevant. If you don't understand
the issue we will gladly describe it to you. We don't usually write
exploit code for issues, however, our game is finding bugs, not
exploiting them.
4.- If relevant, work with us to produce a patch (we might send you a
patch fixing the issue, but we appreciate you review it, as you know
more about your own code).
We will assign the bug a CVE name (see http://cve.mitre.org) if you
cannot get one yourself, please make sure you use that CVE name
in the program changelogs and announcements as that will help people
crossreference your information with other information sources.
5.- Once a patch is found, fix it in your source tree. Don't make it public,
yet.
6.- Talk with us to find a proper an announcement date when you will be
able to provide either a new upstream release or publish a patch in
your website or mail it through your mailing lists. We want to
coordinate with you so that both our DSA (Debian Security Advisory) and
the advisories of other distributions are shipped at the same time, if
possible.
7.- Release the bugfix and the relevant information when the announcement
date is due. We will do likewise with the DSA (although our bugfixes
might take more time to publish, as they are compiled for all our
supported architectures - 11 currently)
Also, try to make sure that the type of bugs we find in your software
don't appear in other parts you've written (even in unreleased code).
We can provide pointers to in-depth documentation regarding secure coding
if you want to invest time in learning about that issue. We are sure that
your users will really appreciate (security) bug-free code.
---------------------------------------------------------------------------
How does the above sound? Notice that it's targeted to naive developers
(those that make silly security bugs) rather than experienced developers. The
tone probably needs to be downplayed a bit for the later just so they don't
get offended :-)
Regards
Javier
signature.asc
Description: Digital signature
_______________________________________________
Debian-audit mailing list
Debian-audit@xxxxxxxxxxxxx
http://shellcode.org/mailman/listinfo/debian-audit
|
