X-Original-To: pgsql-bugs-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 6FFE5D9075; Fri, 25 Nov 2005 13:20:34 -0400 (AST) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 42287-05; Fri, 25 Nov 2005 17:20:31 +0000 (GMT) X-Greylist: from auto-whitelisted by SQLgrey- X-Greylist: from auto-whitelisted by SQLgrey- Received: from candle.pha.pa.us (candle.pha.pa.us [64.139.89.126]) by svr1.postgresql.org (Postfix) with ESMTP id 81CA5D774A; Fri, 25 Nov 2005 13:20:27 -0400 (AST) Received: (from pgman@localhost) by candle.pha.pa.us (8.11.6/8.11.6) id jAPHKN412761; Fri, 25 Nov 2005 12:20:23 -0500 (EST) From: Bruce Momjian Message-Id: <200511251720.jAPHKN412761@candle.pha.pa.us> Subject: Re: BUG #2052: Federal Agency Tech Hub Refuses to Accept In-Reply-To: <1132827194.4347.27.camel@localhost.localdomain> To: Simon Riggs Date: Fri, 25 Nov 2005 12:20:23 -0500 (EST) CC: Tom Lane , Stephen Frost , pgsql-hackers@postgresql.org, Ferindo Middleton , pgsql-bugs@postgresql.org X-Mailer: ELM [version 2.4ME+ PL121 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.023 required=5 tests=[AWL=0.023] X-Spam-Score: 0.023 X-Spam-Level: X-Archive-Number: 200511/261 X-Sequence-Number: 13625 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. > > 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