On 28/01/2008, Gregory Stark <[EMAIL PROTECTED]> wrote:
> "Pavel Stehule" <[EMAIL PROTECTED]> 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

> 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!

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?


Reply via email to