Re: WIP: plpgsql source code obfuscation

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Pavel Stehule" <pavel(dot)stehule(at)gmail(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:37:15
Message-ID: 87hcgxpzj8.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

"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";

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

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

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Hans-Juergen Schoenig 2008-01-28 18:44:58 Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable
Previous Message Pavel Stehule 2008-01-28 18:14:48 Re: WIP: plpgsql source code obfuscation