Re: WIP: plpgsql source code obfuscation

From: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "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:14:48
Message-ID: 162867790801281014r53bb212co74a5d3cd2ca10f6@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

On 28/01/2008, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> > Maybe a better TODO would be to do this task in the way that has
> > previously been suggested:
> > http://archives.postgresql.org/pgsql-hackers/2007-08/msg00258.php
> > I'm certainly not happy about any proposal to put a password/key in a
> > GUC var - that strikes me as a major footgun.
>
> We didn't really have a better solution to the key management problem,
> though, did we? At least I don't see anything about it in that thread.
>
> However, I definitely agree that a separate loadable PL is the way to go
> for functionality of this sort. There is no way that a dependency on
> pgcrypto is going to be accepted into core, not even in the (ahem)
> obfuscated way that it's presented here.
>

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.

My patch is only solution for some users, and I know about problem
with dependency.

Reagards

Pavel Stehule
> regards, tom lane
>

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Gregory Stark 2008-01-28 18:37:15 Re: WIP: plpgsql source code obfuscation
Previous Message Tom Lane 2008-01-28 17:58:48 Re: WIP: plpgsql source code obfuscation