masking the code

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

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&amp;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?

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

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

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

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/

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.

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

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.

http://www.enterprisedb.com/docs/en/8.3R2/oracompat/EnterpriseDB_OraCompat_8.3-211.htm#P15495_739546
http://www.databasejournal.com/features/oracle/article.php/3382331/Oracles-Wrap-Utility.htm
http://download-west.oracle.com/docs/cd/B10501_01/appdev.920/a96624/c_wrap.htm

--Scott

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

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

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

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

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