Skip site navigation (1) Skip section navigation (2)

Re: WIP: plpgsql source code obfuscation

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 (view raw or flat)
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



In response to

Responses

pgsql-patches by date

Next:From: Bruce MomjianDate: 2008-01-28 19:12:51
Subject: Re: [PATCHES] Friendly help for psql
Previous:From: Pavel StehuleDate: 2008-01-28 18:56:15
Subject: Re: WIP: plpgsql source code obfuscation

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group