On Mon, Feb 05, 2007 at 11:28:13AM -0800, Josh Berkus wrote:
> WWW core team,
>
> I need a way to coordinate with you around preparing postgresql.org
> for upcoming releases, especially for security releases where it's
> critical that the timing be tight. Due to some issues with this
> last release, pgsql-www obviously isn't the right venue.
I think we need to separate this into two issues:
1. Publishing vulnerabilities only after we've distributed the fix, and
2. Publishing the fact that a minor point release is on its way in
order that organizations be able to schedule upgrades.
I see these as separable announcements, with what appear to be
opposing motivations.
For getting upgrades in the pipeline, sooner is better than later.
Quite a few outfits have processes that take two weeks or more before
the upgrade actually goes through. Giving them a heads-up on this is
a good thing, and serious users know that we don't do minor point
releases for the sheer thrills of it, i.e. just knowing that something
is coming is enough reason for them to schedule the aforementioned
upgrade.
For vulns, it's really a Good Idea to let as little about them as
possible get out in advance of the fix. It's this part that is
sensitive information.
So here's my proposal. As soon as we have a pretty good idea of when
we are going to do a minor point release, we should let the public
know with a generic, "Point releases coming. Get ready to upgrade"
kind of message.
When we find and characterize vulns, we put out at least the severity
on some specific private list--which one is TBD--when known so
mirrors, packagers, etc. can make it a priority to make those updates
available ASAP.
As far as the details of vulns, those should only get published as
part of the post-distribution announcement.
Cheers,
D
--
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter
Remember to vote!
