From: | David Fetter <david(at)fetter(dot)org> |
---|---|
To: | Casey Allen Shobe <cshobe(at)bepress(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bill Moran <wmoran(at)collaborativefusion(dot)com>, Greg Smith <gsmith(at)gregsmith(dot)com>, Jonathan Bond-Caron <jbondc(at)openmv(dot)com>, 'Postgres General List' <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Obfuscated stored procedures (was Re: Oracle and Postgresql) |
Date: | 2008-09-25 20:14:45 |
Message-ID: | 20080925201445.GD4814@fetter.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-www |
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(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
From | Date | Subject | |
---|---|---|---|
Next Message | Christophe | 2008-09-25 20:16:44 | Re: Obfuscated stored procedures (was Re: Oracle and Postgresql) |
Previous Message | Bruce Momjian | 2008-09-25 20:10:30 | Re: Oracle and Postgresql |
From | Date | Subject | |
---|---|---|---|
Next Message | Christophe | 2008-09-25 20:16:44 | Re: Obfuscated stored procedures (was Re: Oracle and Postgresql) |
Previous Message | Bruce Momjian | 2008-09-25 20:10:30 | Re: Oracle and Postgresql |