PostgreSQL Bugs - Re: BUG #2052: Federal Agency Tech Hub Refuses to Accept

Author

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

Simon Riggs

2005-11-24, 7:23 am

On Fri, 2005-11-18 at 09:32 -0500, Tom Lane 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. 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?

Best Regards, Simon Riggs

Stephen's detailed reply to CVE worries copied below for context:
On Fri, 2005-11-18 at 10:08 -0500, Stephen Frost wrote:
> * Ferindo Middleton (fmiddleton@verizon.net) wrote:
>
> I think this was fixed in 8.0.2...
>
>
> This appears to have been fixed in 8.0.1.
>
>
> The CVE says it only affected pre-8.0 releases and I'm inclined to
> believe it.
>
>
> Contrib modules are only an issue if you install them. If you don't
> need them, don't install them. Don't know if this was fixed but
> honestly I expect it was, the Postgres folks don't just sit around on
> their hands when CVE's come out.
>
>
> Looks like this was fixed in 8.0.2..
>
>
> This appears to have been fixed in 8.0.3.
>
>
> This appears to have been fixed in 8.0.3.
>
> It looks like these were all fixed rather quickly after they were
> discovered and brought to the attention of the PostgreSQL team.
> http://www.gsa.gov/networx -> Networx Hosting Center -> NHC User
> Instructions, Executive Summary.
>
> No software is without bugs. It would be foolish to assume that you can
> deploy a system once and never have to update it for newly discovered
> security vulnerabilities. If you'd like a comparison to a product
> they may be allowing elsewhere you might consider looking at Oracle's
> track record for fixing security issues. It's rather... poor. There
> have been a number of articles to this affect on bugtraq recently, you
> shouldn't have too much trouble finding good examples.
>
> Enjoy,
>
> Stephen

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql
.org so that your
message can get through to the mailing list cleanly

Bruce Momjian

2005-11-25, 11:24 am

Simon Riggs wrote:
> On Fri, 2005-11-18 at 09:32 -0500, Tom Lane wrote:
>
> 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).

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 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.

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Simon Riggs

2005-11-25, 1:24 pm

On Fri, 2005-11-25 at 12:20 -0500, Bruce Momjian wrote:
> Simon Riggs wrote:
[color=darkred]
> 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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Tom Lane

2005-11-25, 1:24 pm

Simon Riggs <simon@2ndquadrant.com> writes:
> 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".

IMHO we should do that in any case, whether or not we mention CVEs
in our release notes or CVS logs in the future. So go for it...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Sponsored Links