Received: from localhost (unknown [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id 23D4E2E00C9 for ; Fri, 21 Dec 2007 01:59:41 -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 07432-02 for ; Fri, 21 Dec 2007 01:59:23 -0400 (AST) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 632772E36EB for ; Fri, 21 Dec 2007 01:40:17 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.1/8.14.1) with ESMTP id lBL5e5IL026812; Fri, 21 Dec 2007 00:40:05 -0500 (EST) To: "Merlin Moncure" cc: "Alvaro Herrera" , "Joshua D. Drake" , "Trevor Talbot" , "Roberts, Jon" , "Kris Jurka" , "Jonah H. Harris" , "Bill Moran" , "pgsql performance" , "Pgsql Hackers" Subject: Re: function body actors (was: viewing source code) In-reply-to: References: Comments: In-reply-to "Merlin Moncure" message dated "Fri, 21 Dec 2007 00:09:28 -0500" Date: Fri, 21 Dec 2007 00:40:05 -0500 Message-ID: <26811.1198215605@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200712/337 X-Sequence-Number: 28153 "Merlin Moncure" writes: > On Dec 20, 2007 6:01 PM, Tom Lane wrote: >> So if you want something other than endless arguments to happen, >> come up with a nice key-management design for encrypted function >> bodies. > Maybe a key management solution isn't required. If, instead of > strictly wrapping a language with an encryption layer, we provide > hooks (actors) that have the ability to operate on the function body > when it arrives and leaves pg_proc, we may sidestep the key problem > (leaving it to the user) and open up the doors to new functionality at > the same time. I think you're focusing on mechanism and ignoring the question of whether there is a useful policy for it to implement. Andrew Sullivan argued upthread that we cannot get anywhere with both keys and encrypted function bodies stored in the same database (I hope that's an adequate summary of his point). I'm not convinced that he's right, but that has to be the first issue we think about. The whole thing is a dead end if there's no way to do meaningful encryption --- punting an insoluble problem to the user doesn't make it better. (This is not to say that you don't have a cute idea there, only that it's not a license to take our eyes off the ball.) regards, tom lane