Even if we don't fully disclose bugs, it is very important to have
notifications about them.
Types
I can see several types:
New bugs
Newly reported (i.e. currently confidental) bugs are described vaguely,
with an workarournd, if one exists. E.g.
"A major security problem has been found in the OJI implementation
shipping with mozilla0.6, which gives an attacker read access to
arbitary local files and directories, if and only if you are behind a
proxy. To protect yourself, we strongly suggest to either disable Java
or the HTTP proxy until the bug is fixed."
Unfixed, disclosed bugs
Since we will probably disclose bugs after a certain amount of time, no
matter if fixed or not, it makes sense to announce it, if such an expire
happened. *
Fixed bugs
For distributors, it is very important to know about fixed security
bugs, so the distributors can package the fix, inform their users and
deliver the fix whenever they want. *
This actually hit me recently. A bug was found and fixed in NSS by
2000-11-07, but it has been posted about it only 3 weeks later. If I
knew earlier about it, Beonex Communicator Linux 0.6 wouldn't have to
ship with that bug at all. This example also shows, that *every* major
bug should be reported: The NSS team probably believed that noone used
that particular code (freebl) yet, so they didn't have to notify
anybody. (At least, that's the most honorable explanation I have.) (BTW:
wtc said sorry already, so no need to punish them further. This is just
an example to prove my point of the importance of such notifications.)
Procedure
I propose to create moderated group .security.announce.
New bugs
The default owner or a delegate would have the reponsibility to post
about a new bugs within hours. The delegates could be located all over
the world, so anybody would always be available. I guess (somebody else
please correct me) that obscuring bug descriptions and proposing
workarounds, i.e. posting the notification, is usually relatively easy.
Unfixed, disclosed bugs
As said in the footnote, these posts could ideally be created by a script.
Fixed bugs
Immediately after the checkin (e.g. while waitng for tinderbox to
clear), the assignee describes the bug in more detail and the fix and
posts that.
Ideally, a release engineer would also create an approriate fix
distribution, e.g. an XPI file containing the fixed library only.
However, this must not hold back the post by more than a few hours.
*Bugzilla would provide that info, too, but Bugzilla doesn't support
emailing about changes in queries, and polling bugzilla queries via HTTP
every day / few hours is not very comfortable.
However, we could write a script that performs such a search e.g. each
hour, and if a new bug appears in that query, the script posts about that.
