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

Re: viewing source code

From: Dan Langille <dan(at)langille(dot)org>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Trevor Talbot <quension(at)gmail(dot)com>, "Roberts, Jon" <Jon(dot)Roberts(at)asurion(dot)com>, Kris Jurka <books(at)ejurka(dot)com>, "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, Bill Moran <wmoran(at)collaborativefusion(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: viewing source code
Date: 2007-12-21 14:51:24
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
Bruce Momjian wrote:
> Is this a TODO?
> ---------------------------------------------------------------------------
> Tom Lane wrote:
>> "Merlin Moncure" <mmoncure(at)gmail(dot)com> writes:
>>> I don't really agree that wrapping pl/pgsql with encryptor/decryptor
>>> is a bad idea.
>> It's quite a good idea, because it has more than zero chance of
>> succeeding politically in the community.
>> The fundamental reason why preventing access to pg_proc.prosrc won't
>> happen is this: all the pain (and there will be plenty) will be
>> inflicted on people who get none of the benefit (because they don't give
>> a damn about hiding their own functions' code).  The folks who want
>> function hiding can shout all they want, but as long as there is a very
>> sizable fraction of the community who flat out *don't* want it, it's
>> not going to get applied.
>> Encrypted function bodies avoid this problem because they inflict no
>> performance penalty, operational complexity, or client-code breakage
>> on people who don't use the feature.  They are arguably also a better
>> solution because they can guard against more sorts of threats than
>> a column-hiding solution can.
>> I don't deny that the key-management problem is interesting, but it
>> seems soluble; moreover, the difficulties that people have pointed to
>> are nothing but an attempt to move the goalposts, because they
>> correspond to requirements that a column-hiding solution would never
>> meet at all.
>> So if you want something other than endless arguments to happen,
>> come up with a nice key-management design for encrypted function
>> bodies.

I keep thinking the problem of keys is similar that of Apache servers 
which use certificates that require passphrases.  When the server is 
started, the passphrase is entered on the command line.

Dan Langille -

In response to

pgsql-performance by date

Next:From: Tom LaneDate: 2007-12-21 16:18:58
Subject: Re: function body actors (was: [PERFORM] viewing source code)
Previous:From: Merlin MoncureDate: 2007-12-21 14:45:59
Subject: Re: viewing source code

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