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

Re: WIP: plpgsql source code obfuscation

From: Zoltan Boszormenyi <zb(at)cybertec(dot)at>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-patches(at)postgresql(dot)org, Hans-Juergen Schoenig <hs(at)cybertec(dot)at>
Subject: Re: WIP: plpgsql source code obfuscation
Date: 2008-01-30 08:54:24
Message-ID: 47A03B40.2000002@cybertec.at (view raw or flat)
Thread:
Lists: pgsql-patches
Hi,

Pavel Stehule írta:
> On 29/01/2008, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>   
>> Am Montag, 28. Januar 2008 schrieb Pavel Stehule:
>>     
>>> this patch define new function flag - OBFUSCATE. With this flag
>>> encrypted source code is stored to probin column. Password is stored
>>> in GUC_SUPERUSER_ONLY item - it is similar security like SQL Server
>>> does (where privileged users can access system tables with source code
>>> or can use debugger).
>>>       
>> Have you thought about a solution that applies the regular access privileges
>> to pg_proc in order to hide some content from less privileged users?
>>     
>
> it's second way, and maybe better. It can close way to table
> definitions too (and this request is adequate too). But you cannot to
> hide complete column, visibility depend on content and it can be slow,
> complex :(. Encrypt, decrypt aren't fast too.
>
> Pavel
>   

We made a similar encrypted plpgsql for a customer.
It was a fork of plpgsql from 8.2.x and uses pgcrypto internally.
Functions are cached the same way by the backend as regular
plpgsql functions, hence fast. The hashkey of the cached function
is the hash of the already encrypted function so it doesn't need to be
decrypted every time it's looked up. Only the first run of a function is
slower where it is needed to be decrypted for compilation.
The pgcrypto dependency can be lifted and similar Obfuscate() and
Deobfuscate() functions can be used as in the WIP patch posted here.
The encrypted body is stored inside prosrc in our solution and
dumpable/restorable just fine.

Best regards,
Zoltán Böszörményi

-- 
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
http://www.postgresql.at/



In response to

pgsql-patches by date

Next:From: Zeugswetter Andreas ADI SDDate: 2008-01-30 09:56:47
Subject: Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable
Previous:From: Guillaume SmetDate: 2008-01-30 02:07:10
Subject: Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable

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