Thread: masking the code

masking the code

From
luca.ciciriello@email.it
Date:
I've wrote a PLPGSQL stored procedure for a DB I've to delivery to my
customer. The problem is that I want to hide the code of the stored
procedure. I don't want that my customer is able to read the code of the my
sp.

Do exist a way to mask the code of the store procedure shipped with my DB?

Thanks in advance.

Luca.
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP
autenticato? GRATIS solo con Email.it: http://www.email.it/f

 Sponsor:
 GRATIS: 250 Biglietti da Visita + 1 elegante Porta biglietti metallico!
Spese di spedizione escluse. Offerta limitata, fai in fretta!
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8956&d=20090626



Re: masking the code

From
Pavel Stehule
Date:
hello

2009/6/26  <luca.ciciriello@email.it>:
> I've wrote a PLPGSQL stored procedure for a DB I've to delivery to my
> customer. The problem is that I want to hide the code of the stored
> procedure. I don't want that my customer is able to read the code of the my
> sp.
>
> Do exist a way to mask the code of the store procedure shipped with my DB?
>

no - PostgreSQL doesn't support any form of obfuscation PL code. If
you have superuser rights on database - and your customer not, then
you can REVOKE SELECT right from pg_proc table.

regards
Pavel Stehule



> Thanks in advance.
>
> Luca.
>  --
>  Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP
> autenticato? GRATIS solo con Email.it: http://www.email.it/f
>
>  Sponsor:
>  GRATIS: 250 Biglietti da Visita + 1 elegante Porta biglietti metallico!
> Spese di spedizione escluse. Offerta limitata, fai in fretta!
>  Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8956&d=20090626
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

Re: masking the code

From
"Massa, Harald Armin"
Date:
Luca, in addition to this:

that feature is on the "Features We Do Not Want " list of the
http://wiki.postgresql.org/wiki/Todo list:

Obfuscated function source code (not wanted) Obfuscating function source code has minimal protective benefits because anyone with super-user access can find a way to view the code. At the same time, it would greatly complicate backups and other administrative tasks. To prevent non-super-users from viewing function source code, remove SELECT permission on pg_proc.


best wishes,

HArald

On Fri, Jun 26, 2009 at 10:56 AM, <luca.ciciriello@email.it> wrote:
I've wrote a PLPGSQL stored procedure for a DB I've to delivery to my
customer. The problem is that I want to hide the code of the stored
procedure. I don't want that my customer is able to read the code of the my
sp.

Do exist a way to mask the code of the store procedure shipped with my DB?

Thanks in advance.

Luca.
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP
autenticato? GRATIS solo con Email.it: http://www.email.it/f

 Sponsor:
 GRATIS: 250 Biglietti da Visita + 1 elegante Porta biglietti metallico!
Spese di spedizione escluse. Offerta limitata, fai in fretta!
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8956&d=20090626



--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general



--
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Straße 49
70435 Stuttgart
0173/9409607
no fx, no carrier pigeon
-
LASIK good, steroids bad?

Re: masking the code

From
David Fetter
Date:
On Fri, Jun 26, 2009 at 10:56:34AM +0200, luca.ciciriello@email.it wrote:
> I've wrote a PLPGSQL stored procedure for a DB I've to delivery to
> my customer. The problem is that I want to hide the code of the
> stored procedure. I don't want that my customer is able to read the
> code of the my sp.
>
> Do exist a way to mask the code of the store procedure shipped with
> my DB?

Others have pointed out that there isn't really, along with a bit of a
hack, which doesn't protect you from snooping into the procedure code
if the client has (or can get) database super-user access.

If you don't wish to expose this to clients, don't ship it to them.
If you wish to restrict clients' use of what you do ship them, the
appropriate place to do so is in the license and/or contract.

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

Re: masking the code

From
artacus@comcast.net
Date:

Obfuscated function source code (not wanted) Obfuscating function source code has minimal protective benefits because anyone with super-user access can find a way to view the code. At the same time, it would greatly complicate backups and other administrative tasks. To prevent non-super-users from viewing function source code, remove SELECT permission on pg_proc.


I completely agree w/ HArald. Its not something we'd want to see in an open source product. That said, I saw yesterday that the latest version of EnterpriseDB has this feature.  So if you want to protect your own IP, then you've got to purchase someone else's.

Scott

Re: masking the code

From
Dimitri Fontaine
Date:
Hi,

Le 26 juin 09 à 10:56, luca.ciciriello@email.it a écrit :
> Do exist a way to mask the code of the store procedure shipped with
> my DB?

There's a way to do it which is not intended to cover this need: write
the procedure code in C, and only ship the .so and .sql, not the .c
code. You'll have to be superuser to load the C coded function, though.

But I don't see the point of hiding procedural code to your customer,
who's getting to see the database structure and data, I guess...

Regards,
--
dim

Re: masking the code

From
Scott Marlowe
Date:
On Fri, Jun 26, 2009 at 1:37 PM, <artacus@comcast.net> wrote:
>
> Obfuscated function source code (not wanted) Obfuscating function source
> code has minimal protective benefits because anyone with super-user access
> can find a way to view the code. At the same time, it would greatly
> complicate backups and other administrative tasks. To prevent
> non-super-users from viewing function source code, remove SELECT permission
> on pg_proc.
>
>
> I completely agree w/ HArald. Its not something we'd want to see in an open
> source product. That said, I saw yesterday that the latest version of
> EnterpriseDB has this feature.  So if you want to protect your own IP, then
> you've got to purchase someone else's.

s/protect/pretend to protect/

Re: masking the code

From
Jasen Betts
Date:
On 2009-06-26, luca.ciciriello@email.it <luca.ciciriello@email.it> wrote:
> I've wrote a PLPGSQL stored procedure for a DB I've to delivery to my
> customer. The problem is that I want to hide the code of the stored
> procedure. I don't want that my customer is able to read the code of the my
> sp.
>
> Do exist a way to mask the code of the store procedure shipped with my DB?

rewrite it in a compiled language.

Re: masking the code

From
Scott Mead
Date:


On Fri, Jun 26, 2009 at 3:37 PM, <artacus@comcast.net> wrote:


I completely agree w/ HArald. Its not something we'd want to see in an open source product. That said, I saw yesterday that the latest version of EnterpriseDB has this feature.  So if you want to protect your own IP, then you've got to purchase someone else's.

   Release 2 of our proprietary Advanced Server 8.3 does include the 'edbwrap' functionality.  It was included based on demand from ISV's who are used to wrapping their code when distributing an app.  

   It is important to note (as many people have already pointed out) that both EnterpriseDB and Oracle's wrap functionality is declared as a 100% guarantee that nobody can read your code.  As with many different types of security (i.e. the 3 foot high fence) this is really just a deterrent to most people who either aren't capable of reverse engineering or are just not interested in the first place.

     

  
--Scott 

Re: masking the code

From
"Jonah H. Harris"
Date:
On Mon, Jun 29, 2009 at 9:31 AM, Scott Mead <scott.lists@enterprisedb.com> wrote:

   It is important to note (as many people have already pointed out) that both EnterpriseDB and Oracle's wrap functionality is declared as a 100% guarantee that nobody can read your code.  As with many different types of security (i.e. the 3 foot high fence) this is really just a deterrent to most people who either aren't capable of reverse engineering or are just not interested in the first place.

s/is declared/is NOT declared/g

:)

--
Jonah H. Harris, Senior DBA
myYearbook.com

Re: masking the code

From
Scott Mead
Date:


On Mon, Jun 29, 2009 at 9:35 AM, Jonah H. Harris <jonah.harris@gmail.com> wrote:
On Mon, Jun 29, 2009 at 9:31 AM, Scott Mead <scott.lists@enterprisedb.com> wrote:

   It is important to note (as many people have already pointed out) that both EnterpriseDB and Oracle's wrap functionality is declared as a 100% guarantee that nobody can read your code.  As with many different types of security (i.e. the 3 foot high fence) this is really just a deterrent to most people who either aren't capable of reverse engineering or are just not interested in the first place.

s/is declared/is NOT declared/g

  Yes!  Jeez, this cold is getting to me.  Thanks Jonah... :

  It is important to note (as many people have already pointed out) that both EnterpriseDB and Oracle's wrap functionality is NOT declared as a 100% guarantee that nobody can read your code.

--Scott 

Re: masking the code

From
Scott Mead
Date:



On Mon, Jun 29, 2009 at 9:35 AM, Jonah H. Harris <jonah.harris@gmail.com> wrote:
On Mon, Jun 29, 2009 at 9:31 AM, Scott Mead <scott.lists@enterprisedb.com> wrote:

   It is important to note (as many people have already pointed out) that both EnterpriseDB and Oracle's wrap functionality is declared as a 100% guarantee that nobody can read your code.  As with many different types of security (i.e. the 3 foot high fence) this is really just a deterrent to most people who either aren't capable of reverse engineering or are just not interested in the first place.

s/is declared/is NOT declared/g

  Yes!  Jeez, this cold is getting to me.  Thanks Jonah... :

  It is important to note (as many people have already pointed out) that both EnterpriseDB and Oracle's wrap functionality is NOT declared as a 100% guarantee that nobody can read your code.

--Scott


:)

--
Jonah H. Harris, Senior DBA
myYearbook.com


Re: masking the code

From
Torsten Zühlsdorff
Date:
Jasen Betts schrieb:

>> I've wrote a PLPGSQL stored procedure for a DB I've to delivery to my
>> customer. The problem is that I want to hide the code of the stored
>> procedure. I don't want that my customer is able to read the code of the my
>> sp.
>>
>> Do exist a way to mask the code of the store procedure shipped with my DB?
>
> rewrite it in a compiled language.

And hope, that the customer could not read the result.


Greetings,
Torsten

Re: masking the code

From
Greg Stark
Date:
On Mon, Jun 29, 2009 at 2:31 PM, Scott Mead<scott.lists@enterprisedb.com> wrote:
> As with many different types of security (i.e. the 3 foot high fence) this
> is really just a deterrent to most people who either aren't capable of
> reverse engineering or are just not interested in the first place.

Someone I know used to work at a nuclear power and research facility
(No Dave, someone else) and told me an interesting story.

The facility in question was often beset by protesters who invariably
managed to scale the perimeter fence. He asked one of the security
guards one day why they didn't build a better fence since the
run-of-the-mill fence was obviously not up to the task for such a
large perimeter against determined foes.

The answer was that the fence was not there to keep people out at all.
It's purpose was in fact to ensure that when they prosecuted it would
be impossible for anyone to claim they hadn't realized they were
trespassing...


--
greg
http://mit.edu/~gsstark/resume.pdf

Re: masking the code

From
Dave Page
Date:
On Tue, Jun 30, 2009 at 4:40 AM, Greg Stark<gsstark@mit.edu> wrote:
> On Mon, Jun 29, 2009 at 2:31 PM, Scott Mead<scott.lists@enterprisedb.com> wrote:
>> As with many different types of security (i.e. the 3 foot high fence) this
>> is really just a deterrent to most people who either aren't capable of
>> reverse engineering or are just not interested in the first place.
>
> Someone I know used to work at a nuclear power and research facility
> (No Dave, someone else) and told me an interesting story.

Yet bizarrely it's almost identical in meaning to a story I did tell
you not so long ago...

(assuming you mean me of course!)

:-)

> The facility in question was often beset by protesters who invariably
> managed to scale the perimeter fence. He asked one of the security
> guards one day why they didn't build a better fence since the
> run-of-the-mill fence was obviously not up to the task for such a
> large perimeter against determined foes.
>
> The answer was that the fence was not there to keep people out at all.
> It's purpose was in fact to ensure that when they prosecuted it would
> be impossible for anyone to claim they hadn't realized they were
> trespassing...
>
>
> --
> greg
> http://mit.edu/~gsstark/resume.pdf
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>



--
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com