Skip site navigation (1) Skip section navigation (2)

Re: Specification for Trusted PLs?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: David Fetter <david(at)fetter(dot)org>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Magnus Hagander <magnus(at)hagander(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Specification for Trusted PLs?
Date: 2010-05-21 18:12:09
Message-ID: AANLkTinr7UhByQm8eQwJNWMVjtkPPCxdvgHERkh302o4@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, May 21, 2010 at 1:58 PM, David Fetter <david(at)fetter(dot)org> wrote:
> On Fri, May 21, 2010 at 01:45:45PM -0400, Stephen Frost wrote:
>> * David Fetter (david(at)fetter(dot)org) wrote:
>> > That is *precisely* the business we need to be in, at least for the
>> > languages we ship, and it would behoove us to test languages we don't
>> > ship so we can warn people when they don't pass.
>>
>> k, let's start with something simpler first tho- I'm sure we can pull in
>> the glibc regression tests and run them too.  You know, just in case
>> there's a bug there, somewhere.
>
> That's pretty pure straw man argument.  I expect much higher quality
> trolling.  D-.

I'm sorely tempted to try to provide some higher-quality trolling, but
in all seriousness I think that (1) we could certainly use much better
regression tests in many areas of which this is one and (2) it will
never be possible to catch all security bugs - in particular - via
regression testing because they typically stem from cases people
didn't consider.  So... can we get back to coming up with a reasonable
definition, and if somebody wants to write some regression tests, all
the better?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-05-21 18:21:37
Subject: Re: Specification for Trusted PLs?
Previous:From: Tom LaneDate: 2010-05-21 18:11:12
Subject: Re: Specification for Trusted PLs?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group