> > 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.
> >
> > Or, at very least, put stronger security warnings onto the
> releases.
> > (My own advice is always to watch for announcements and
> stay current).
>
> 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.
Sure - but it can be used as a good tool to prove such a person *wrong*.
Because it's an easy to find place.
> 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.
Point 1: Where do you go today to find a list of fixed security issues
in PostgreSQL, and where they are fixed? There is no central list of
this. This is the important point - to create such a list. (IMHO, of
course)
Point 2: CVE is pretty much the industry standard for naming
vulnerabilities. This is what people *use*. There's no reason *not* to
provide it as a cross reference. But sure, we shouldn't list only the
ones that have CVE numbers - if there are any that doesn't, they should
be listed as well. If you read up on CVE you will find that their only
function is to provide a common way to refer to a vulnerability, no
matter who talks about it, without any risk to get it wrong.
//Magnus
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
