On Dec 20, 2007 6:01 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > "Merlin Moncure" <mmoncure@xxxxxxxxx> writes: > > I don't really agree that wrapping pl/pgsql with encryptor/decryptor > > is a bad idea. > > 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. The actor is basically a callback taking the function source code (as text) and returning text for storage in pg_proc. Perhaps some other house keeping variables such as function name, etc. are passed to the actor as parameters as well. The actor operates on the function body going into pg_proc (input actors) and going out (output actors). In either case, the function 'body' is modified if necessary, and may raise an error. The validator can be considered an actor that doesn't modify the body. Ideally, the actors can be written in any pl language. Naturally, dealing with actors is for the superuser. So, I'm suggesting to extend the validator concept, opening it up to the user, giving it more power, and the ability to operate in both directions. The actor will feel a lot like a trigger function. Now, everything is left to the user...by adding an 'encryption' actor to the language (trivial with pg_crypto), the user can broadly encrypt in a manner of their choosing. A clever user might write an actor to encrypt a subset of functions in a language, or register the same language twice with different actors. Since the actor can call out to other functions, we don't limit to a particular key management strategy. Another nice thing is we may solve a problem that's been bothering me for years, namely that 'CREATE FUNCTION' takes a string literal and not a string returning expression. This is pretty limiting...there are a broad range of reasons why I might want to modify the code before it hits pg_proc. For example, with an actor I can now feed the data into the C preprocessor without giving up the ability of pasting the function body directly into psql. This isn't a fully developed idea, and I'm glossing over several areas (for example, syntax to modify actors), and I'm not sure if it's a good idea in principle...I might be missing an obvious reason why this won't work. OTOH, it seems like a really neat way to introduce encryption. comments? is it worth going down this road? merlin ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
