Re: crypting prosrc in pg_proc - Mailing list pgsql-hackers

Wouldn't it be better just to hide prosrc from the users you want to 
hide it from? (Note: my SOC student is working on column level privs, 
although unfortunately his work doesn't currently work with SELECT 
privs). In fact, in many cases, depending on the app, you can simply 
remove SELECT priv from public on pg_proc.

There are also some fairly impressive code obfuscators about, that your 
clients might find useful. Of course, debugging the obfuscated code is a 
nightmare, but that's their affair if they want to use it ;-)

cheers

andrew

Hans-Juergen Schoenig wrote:
> the idea is basically to hide codes - many companies want that and ask 
> for it again and again.
>
> i would suggest keys to reside in $PGDATA. we do this for SSL and so 
> already.
>
> initdb could create such keys so that they are unique to every 
> database instance.
> decrypting could be avoided as much as possible basically we should 
> just decrypt on first all and when it changes.
> for pg_dump i would suggest two options:
> a.) pass the keys to dump in a decrypted way
> b.) dump in encrypted way.
>
> i would think that this is a quite valuable features. would be nice to 
> have it.
> maybe we can agree on a nice mechanism here which will be implemented 
> then.
>
> hans
>
>
>
> On Aug 9, 2007, at 3:57 PM, Andrew Dunstan wrote:
>
>>
>>
>> Hans-Juergen Schoenig wrote:
>>> hello everybody,
>>>
>>> one of our customers wants to store the code of interpreted 
>>> procedures (PL/pgSQL, PL/Perl) and so in an encrypted way.
>>> so the idea we had to add one more column to pg_proc telling us 
>>> whether prosrc is encrypted or not. people could chose then whether 
>>> to crypt codes there or not (speed of decryption can be an issue).
>>>
>>> should not be hard to implement ...
>>>
>>> what do people think about this feature?
>>>
>>>
>>
>> Perhaps you could give us a justification for it. Are you intending 
>> to have stored procs contain security sensitive information? Or is 
>> this an attempt to hide closed source code from prying eyes? Where 
>> would the encryption keys be stored? And how would it work with pg_dump?
>>
>> This doesn't sound very well thought out, frankly.
>>
>> cheers
>>
>> andrew
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 7: You can help support the PostgreSQL project by donating at
>>
>>                http://www.postgresql.org/about/donate
>
>
>
> --
> Cybertec Geschwinde & Schönig GmbH
> Gröhrmühlgasse 26, 2700 Wiener Neustadt
> Tel: +43/1/205 10 35 / 340
> www.postgresql.at, www.cybertec.at <http://www.cybertec.at>
>
>