Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id D44972E4270 for ; Fri, 21 Dec 2007 10:51:41 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 13302-04 for ; Fri, 21 Dec 2007 10:51:27 -0400 (AST) Received: from supernews.unixathome.org (supernews.unixathome.org [216.168.29.4]) by postgresql.org (Postfix) with ESMTP id AD4C32E3EAD for ; Fri, 21 Dec 2007 10:51:35 -0400 (AST) Received: from localhost (localhost [127.0.0.1]) by supernews.unixathome.org (Postfix) with ESMTP id 081511702F; Fri, 21 Dec 2007 14:51:34 +0000 (GMT) X-Virus-Scanned: amavisd-new at unixathome.org Received: from supernews.unixathome.org ([127.0.0.1]) by localhost (supernews.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcqobvB8j2zm; Fri, 21 Dec 2007 14:51:27 +0000 (GMT) Received: from [192.168.80.128] (ismtp.afilias.com [216.217.55.254]) by supernews.unixathome.org (Postfix) with ESMTP id 36C3117028; Fri, 21 Dec 2007 14:51:26 +0000 (GMT) Message-ID: <476BD2EC.70204@langille.org> Date: Fri, 21 Dec 2007 09:51:24 -0500 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Thunderbird 2.0.0.9 (X11/20071207) MIME-Version: 1.0 To: Bruce Momjian CC: Tom Lane , Merlin Moncure , Alvaro Herrera , "Joshua D. Drake" , Trevor Talbot , "Roberts, Jon" , Kris Jurka , "Jonah H. Harris" , Bill Moran , pgsql-performance@postgresql.org Subject: Re: viewing source code References: <200712211434.lBLEYrm01943@momjian.us> In-Reply-To: <200712211434.lBLEYrm01943@momjian.us> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200712/345 X-Sequence-Number: 28161 Bruce Momjian wrote: > Is this a TODO? > > --------------------------------------------------------------------------- > > Tom Lane wrote: >> "Merlin Moncure" 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 - http://www.langille.org/