Skip site navigation (1) Skip section navigation (2)

Re: WIP: plpgsql source code obfuscation

From: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
To: "Gregory Stark" <stark(at)enterprisedb(dot)com>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Andrew Dunstan" <andrew(at)dunslane(dot)net>, pgsql-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: WIP: plpgsql source code obfuscation
Date: 2008-01-28 18:56:15
Message-ID: 162867790801281056w24c4811fu21da69b80e7de83@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-patches
On 28/01/2008, Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
> "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> writes:
>
> > Do you thing some binary module that load some encrypted sources from
> > files? It can be possible too. But if source code will be stored in
> > pg_proc, then we need third method. Some like "obfuscate" (prev. are
> > validate and call"), because we can't to store plain text to prosrc
> > col.
>
> Is there a reason you couldn't, for instance, provide a function which takes
> source code and encrypts it. Then you would write dump the data it spits into
> your function declaration like:
>
> CREATE FUNCTION foo() returns integer AS $$
> ... base64 encoded data
> $$ language "obfuscated:plperl";
>

it's solve problem with dump well, but it's similar to my solution.
"obfuscated:plperl" can be virtual language - we can have one common
handler, because there is same work. I am not sure. This doesn't care
any better security, only add some other necessary external toolkit.
With obfuscate column or obfuscate language (it carry same
information) I can use prosrc and I have not problem with dump too. It
is true, so obfuscate languages move dependency to out of core - but
it is more complex.


> "obfuscated:plperl"'s handler function would just decrypt it and pass it off
> to plperl.

you need same handler for plpgsql, python, sql, ... so why don't do it
generally?

Pavel
>
> There is a validator function which gets called when you create a function but
> I don't think it has any opportunity to substitute its result for the original
> in prosrc. That might be interesting for other applications like compiled
> languages, though I think they would still want to save the source in prosrc
> and the bytecode in probin.
>
> --
>   Gregory Stark
>   EnterpriseDB          http://www.enterprisedb.com
>   Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!
>

In response to

pgsql-patches by date

Next:From: Andrew DunstanDate: 2008-01-28 19:03:11
Subject: Re: WIP: plpgsql source code obfuscation
Previous:From: Hans-Juergen SchoenigDate: 2008-01-28 18:44:58
Subject: Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group