Received: from localhost (unknown [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id 82A1B2E4217 for ; Fri, 21 Dec 2007 10:35:15 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024) with ESMTP id 49311-05 for ; Fri, 21 Dec 2007 10:34:56 -0400 (AST) Received: from momjian.us (momjian.us [70.90.9.53]) by postgresql.org (Postfix) with ESMTP id 586A12E41FD for ; Fri, 21 Dec 2007 10:35:07 -0400 (AST) Received: (from bruce@localhost) by momjian.us (8.11.6/8.11.6) id lBLEYrm01943; Fri, 21 Dec 2007 09:34:53 -0500 (EST) From: Bruce Momjian Message-Id: <200712211434.lBLEYrm01943@momjian.us> Subject: Re: viewing source code In-Reply-To: <20377.1198191718@sss.pgh.pa.us> To: Tom Lane Date: Fri, 21 Dec 2007 09:34:53 -0500 (EST) CC: Merlin Moncure , Alvaro Herrera , "Joshua D. Drake" , Trevor Talbot , "Roberts, Jon" , Kris Jurka , "Jonah H. Harris" , Bill Moran , pgsql-performance@postgresql.org X-Mailer: ELM [version 2.4ME+ PL124 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200712/342 X-Sequence-Number: 28158 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. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster -- Bruce Momjian http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +