Re: Obfuscated stored procedures (was Re: Oracle and Postgresql) - Mailing list pgsql-general

From David Fetter
Subject Re: Obfuscated stored procedures (was Re: Oracle and Postgresql)
Date
Msg-id 20080925201445.GD4814@fetter.org
Whole thread Raw
In response to Re: Obfuscated stored procedures (was Re: Oracle and Postgresql)  (Casey Allen Shobe <cshobe@bepress.com>)
Responses Re: Obfuscated stored procedures (was Re: Oracle and Postgresql)
List pgsql-general
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.

>> Well, it isn't, and I don't think Postgres should encourage them to
>> think it is.
>
> Adding such a feature would NOT be encouraging them to think this - the
> documentation could be very explicit about this fact.  Maybe that's what
> Oracle is selling, and that's crappy of them, but that doesn't mean we
> should use that as justification to not add a more appropriate
> implementation.

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.

> 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.

> 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.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

pgsql-general by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Oracle and Postgresql
Next
From: Christophe
Date:
Subject: Re: Obfuscated stored procedures (was Re: Oracle and Postgresql)