From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, pgsql-patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: WIP: plpgsql source code obfuscation |
Date: | 2008-01-28 19:03:11 |
Message-ID: | 479E26EF.7060207@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Tom Lane 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.
>
Yeah. Maybe we could have the GUC var contain the name of a key file
rather than the key itself. If we require that the name be relative to
the datadir that might be tolerably secure.
> 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.
>
>
>
If we do anything in core it could be to make provision for an
obfuscation/encryption hook via a loadable module.
Various interesting encoding issues could arise with dumping and
restoring transformed program text - I haven't thought that through yet.
But I agree a simple PL wrapper makes sense to start with, at any rate.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2008-01-28 19:12:51 | Re: [PATCHES] Friendly help for psql |
Previous Message | Pavel Stehule | 2008-01-28 18:56:15 | Re: WIP: plpgsql source code obfuscation |