Re: Obfuscated stored procedures (was Re: Oracle and Postgresql)

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