Thread: Re: [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept

Re: [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept

From
"Magnus Hagander"
Date:
> > All known CVE problems are resolved in 8.0.4.
>
> I was unaware of this. I've looked at the release notes and
> searched the archives, but this doesn't seem to be mentioned
> by CVE number. (The vulnerabilities and their resolutions are
> described, just without direct cross reference to their CVE number.)
>
> Do we have an on-project description of this? If
> we-as-a-project know this, it seems straightforward to write it down.
>
> 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).
>
> Thoughts?

How about a simlpe webpage that has more or less a table with:
CVE-number  |   present in releases  |  fixed in releases
CVE-number  |   present in releases  |  fixed in releases
CVE-number  |   present in releases  |  fixed in releases

etc?

Perhaps also a link to an advisory of our own?


Yeah, looking around a bit, it looks like unless you're on -hackers,
it's kinda hard to know. Any reason we don't publish security pulletins
to bugtraq for example?

//Magnus


Re: [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept

From
Simon Riggs
Date:
On Thu, 2005-11-24 at 15:09 +0100, Peter Eisentraut wrote: 

> We really should write the CVE numbers into the commit messages and the 
> release notes.

I think that would be good.


On Thu, 2005-11-24 at 12:35 +0100, Magnus Hagander wrote:
> > > All known CVE problems are resolved in 8.0.4.
> > 
> > I was unaware of this. I've looked at the release notes and 
> > searched the archives, but this doesn't seem to be mentioned 
> > by CVE number. (The vulnerabilities and their resolutions are 
> > described, just without direct cross reference to their CVE number.)
> > 
> > Do we have an on-project description of this? If 
> > we-as-a-project know this, it seems straightforward to write it down.
> > 
> > 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. 

> How about a simple webpage that has more or less a table with:
> CVE-number  |   present in releases  |  fixed in releases
> CVE-number  |   present in releases  |  fixed in releases
> CVE-number  |   present in releases  |  fixed in releases

..and I think we should do this too.

Have to say I'm a bit worried about overloading Tom and Bruce, who write
most of the security patches and relevant release notes.

Anybody else volunteer to maintain the web page?

Best Regards, Simon Riggs



Re: [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept

From
"Andrew Dunstan"
Date:
Simon Riggs said:
> On Thu, 2005-11-24 at 15:09 +0100, Peter Eisentraut wrote:
>
>> We really should write the CVE numbers into the commit messages and
>> the  release notes.
>
> I think that would be good.
>
>

A security page on the web site that summarised the info would be good too.

cheers

andrew




Re: [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept

From
Tom Lane
Date:
"Andrew Dunstan" <andrew@dunslane.net> writes:
>> On Thu, 2005-11-24 at 15:09 +0100, Peter Eisentraut wrote:
>>> We really should write the CVE numbers into the commit messages and
>>> the  release notes.

> A security page on the web site that summarised the info would be good too.

Not to mention a lot easier to create after-the-fact ...
        regards, tom lane