On Sep 25, 2008, at 1:16 PM, Christophe wrote:
Without getting into the argument as to the level of security provided, it strikes me that a reasonable approach would be a non- core pluggable language which accepts encrypted strings as functions, decrypts them (using a key compiled into the language module), and passes them on to PL/pgSQL for execution.
The only way this could work is if the key is set at compile time. Using a single key is impossible in an open source product as Greg pointed out, and very stupid in any other. Now I'll ignore the fact that you can reverse engineer the key out of compiled code, as you already acknowledged that - this is still problematic for another reason.
Let's consider the original goal of "I want to keep customers, with full control of the server machine, from being able to see clearly what a function does". In cases where you just want to keep database users from seeing a function code, the implementation should be easy, and that's the only form I see any value in adding, really.
You could add encryption properly by storing the key in an external file with very restrictive permissions, and that would solve the goal of "I don't want people to be able to read function code in pg_dump output", etc., so it takes things a step farther. But of course on customer-controlled boxes, they can read any file they want, defeating the encryption.
So you think "ah I'll just compile it in by requiring ./configure -- key=whatever to compile the thing. Well, now you suddenly have to build every release of PostgreSQL for every single one of those customers - they cannot upgrade or rebuild themselves, without losing all the encrypted functions. Maybe that's something you can accept, but I would say that most people who want to hide code from customers want nothing to do with setting up the database for the customer. In cases where you fully dictate the PostgreSQL build and upgrade policy and mandate it for your clients, this could work, but I'm guessing that's a pretty esoteric corner case.
Cheers, -- Casey Allen Shobe Database Architect, The Berkeley Electronic Press -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
