Re: Obfuscated stored procedures (was Re: Oracle and Postgresql) - Mailing list pgsql-general
From | Casey Allen Shobe |
---|---|
Subject | Re: Obfuscated stored procedures (was Re: Oracle and Postgresql) |
Date | |
Msg-id | 5F5A7D89-16D6-439B-966A-F6EE9AA7831B@bepress.com Whole thread Raw |
In response to | Re: Obfuscated stored procedures (was Re: Oracle and Postgresql) (David Fetter <david@fetter.org>) |
List | pgsql-general |
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@bepress.com (email/jabber/aim/msn) http://www.bepress.com | +1 (510) 665-1200 x163
pgsql-general by date: