i would recommend dont publish in HTML/JS as with a simple View Page Source any browser client can figure out what is doing what also i would shy from Scripting macro languages as they are not compiled modules and anyone with a text editor can easily see your code Functions and procedure are another story as one would need DB access to view..so someone who is doing a simple query with Toad or sqlplus suddenly sees this interesting procedure hmm..
can the more proprietary routines be placed in a compiled language like Java and then use PL/Java packaging to pull in the packages you need? ? Martin ______________________________________________ Disclaimer and confidentiality note Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission. > CC: pgsql-general@postgresql.org > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Subject: Re: Obfuscated stored procedures (was Re: [GENERAL] Oracle and > Postgresql) > Date: Thu, 25 Sep 2008 16:38:18 -0700 > > 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 > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general _________________________________________________________________ Want to do more with Windows Live? Learn “10 hidden secrets” from Jamie. http://windowslive.com/connect/post/jamiethomson.spaces.live.com-Blog-cns!550F681DAD532637!5295.entry?ocid=TXT_TAGLM_WL_domore_092008
