On Fri, 2005-11-25 at 12:20 -0500, Bruce Momjian wrote:
> Simon Riggs wrote:
> > On Fri, 2005-11-18 at 09:32 -0500, Tom Lane wrote:
> > > All known CVE problems are resolved in 8.0.4.
> >
> > It seems like we need a much clearer resource for security admins to
> > check our compliance levels. This could be a source of similar
> > refusal-to-implement PostgreSQL at other installations, so could almost
> > be regarded as an advocacy issue. Other software projects have been
> > criticized badly for their security response and info dissemination - I
> > don't believe that applies here, but it does indicate the general
> > requirement and its priority. i.e. don't just fix the bugs, tell
> > everyone you've fixed the bugs.
> Well, as the original poster mentioned, they were looking for a reason
> _not_ to use PostgreSQL, and if that is the goal, you can find a reason,
> error numbers or not.
I think that's true, but it should be our goal to remove all excuses so
that people have to face up to the real issues. I see this as advocacy
in many ways.
> I am not excited about referencing error numbers from someone else. We
> know our errors better than anyone else, so I don't see the point.
I think if you don't want to put those on the release notes, thats fine;
we know you're busy. Others have spoken in favour of a web page,
separate from the release notes, and as Tom points out its easier to do
it that way retrospectively anyway.
*We* do know our errors, but thats not the point. CVE is becoming an
accepted standard for referring to security exposures and we should
follow this trend. http://www.cve.mitre.org/about/introduction.html
CVE isn't just somebody else's bugtrack numbers, they're big.
Debian, Gentoo, RedHat, IBM, CA etc already do this.
Unless somebody else wants to do this, I'll discuss on -www how we can
get a page up on the .org site with this info on, so that we can be "CVE
compatible".
Best Regards, Simon Riggs
