On 28/01/2008, Gregory Stark <stark@enterprisedb.com> wrote:
> "Pavel Stehule" <pavel.stehule@gmail.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!
>
