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