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

On Sep 25, 2008, at 1:14 PM, David Fetter wrote:
> On Thu, Sep 25, 2008 at 01:05:26PM -0700, Casey Allen Shobe wrote:
>> On Sep 15, 2008, at 7:19 PM, Tom Lane wrote:
>>> The problem is that the people who ask for this type of feature are
>>> usually imagining that they can put their code on
>>> customer-controlled machines and it will be safe from the
>>> customer's eyes.
>>
>> That's a broken expectation. All that can realistically be expected
>> is database/catalog-level constraints.
>
> It's far from clear that those offer protection of any reasonable
> kind.

Define "protection". If there is no effective way to query the
catalog and see function code at the SQL level, this is a complete and
effective form of protection - it's just not protection from somebody
with server-level access.

> You've got the burden of proof exactly backwards there. It's on you
> or anyone who cares to to explain why it might be a good idea to add
> this "feature," understanding that every feature has a maintenance
> cost and is a potential source of bugs.

I don't personally want this feature. But I can see where it's
valuable in some contexts, and if the understanding is correct, it can
be used responsibly. People misuse basic SQL all the time, but that
doesn't mean the basic SQL should be nonexistent or stupider.

You do have a very valid point in indicating the added maintenance
cost of any new feature, but protecting stuff at the SQL level is not
a complicated thing to do, and well, people concerned with this
feature can be the ones maintaining it - there seems to be a good many
already and existence of the feature would attract more. Could this
be implemented via a contrib/ module?

>> As for the expectation above - could pl/pgsql be made compilable?
>> It would seem easy to translate pl/pgsql code into C and compile a
>> C function. That *could* go onto customer-controlled machines and
>> be safe from the customer's eyes.
>
> No, it would not. As many others have mentioned, "strings" does a
> pretty good job on such stuff, let alone the impossibility even in
> theory of hiding what a program does from someone with access to run
> it using arbitrary inputs, even when they have no binary to examine.

I am not saying that C is an encryption technique. It does however
protect code from customer eyes. People are often not trying to truly
encrypt a protected algorithm, but removing maintainability, adding
cost to theft, and hiding code that's badly done.

>> FWIW, I think most people who want to hide code aren't concerned
>> about
>> IP, they're concerned about clients seeing embarrassingly bad/sloppy
>> code. But there *are* some very real and legitimate needs for this,
>> though it's a small minority of those who think they do.
>
> Please elucidate those needs in detail, then explain why it might be
> PostgreSQL's job to meet them.

See my other posts talking about chipmakers. We should NOT add this
feature /for/ idiots, but the fact that idiots will inevitably end up
misusing any feature should not be a justification for not
implementing it.

Cheers,
--
Casey Allen Shobe
Database Architect, The Berkeley Electronic Press
cshobe(at)bepress(dot)com (email/jabber/aim/msn)
http://www.bepress.com | +1 (510) 665-1200 x163