Subject: Re: Security information page
From: Simon Riggs <simon@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Magnus Hagander <mha@sollentuna.net>, pgsql-www@postgresql.org
In-Reply-To: <2803.1133111793@sss.pgh.pa.us>
References: <6BCB9D8A16AC4241919521715F4D8BCE92E8A9@algol.sollentuna.se>
	<2803.1133111793@sss.pgh.pa.us>
Content-Type: text/plain
Date: Sun, 27 Nov 2005 17:55:22 +0000
Message-Id: <1133114122.2906.194.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Sun, 2005-11-27 at 12:16 -0500, Tom Lane wrote:
> "Magnus Hagander" <mha@sollentuna.net> writes:
> > Per some discussion last week, I've put together a page with security
> > information. Basically an introduction written by Simon and a table I
> > pulled together by going through the CVE list and matching it up with
> > our cvs versions.
> 
> : All security issues are always fixed in the next major release, when
> : it comes out.
> 
> Perhaps "all known security issues..."  The statement as made is
> hopelessly hubristic.

Agreed. I'm sure Magnus meant that.

> Please remove the statements about how we will respond within X hours or
> days.  That has nothing to do with reality.  (Reality is that we are
> often constrained by CVE publication dates if the fix is trivial, and
> if it isn't trivial then it won't be fixed instantly anyway.)  

The wording was "typically", there is no "will do this" statement, so
its not a binding Service Level Agreement or anything.

In terms of what has happened in the last couple of years, I thought it
was a reasonable statement. It wasn't meant to be hype. If we can agree
a worthwhile and accurate statement I'd ask that we keep it; if we can't
then it should go.

> I'd lose
> the whole paragraph beginning "PGDG's aim ..."

The line about our aim was part of the wording required (not exact, I
hasten to add) for CVE-compatibility...

> I think the bit about "Our goal is to gain and maintain CVE-compatible
> status" is bogus.  As near as I can tell, Mitre's definition of CVE
> compatibility applies to security products (eg, vulnerability scanners)
> which Postgres is not.  You could maybe say that this one web page is
> something that could apply for CVE compatibility status, but are we
> going to jump through those hoops for one web page?  Nyet.

There aren't that many hoops and I have volunteered to do the paperwork.

There isn't much else we need to do, apart from maintain the page.

If it gets more complex, then I'd agree the effort isn't worth it and
withdraw those comments.

> The list seems a bit short; did you look through the release notes for
> items that seem to be security issues?  I suspect there are some that
> don't have CVE names.

OK. I think we should publish this to -hackers and ask people to check
it before we put it up on the site.

Best Regards, Simon Riggs