On 21/12/2007, Merlin Moncure <mmoncure@gmail.com> wrote:
> On Dec 21, 2007 3:18 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> > I have similar patch and it works. There is two isues:
> >
> > * we missing column in pg_proc about state (not all procedures are
> > obfuscated), I solved it for plpgsl with using probin.
>
> I was hoping to avoid making any catalog or other changes to support
> encryption specifically. Maybe your patch stands on its own
> merits...I missed the original discussion. Do you think the code you
> wrote can be adapted to do other things besides encryption?
>
I don't know. It was fast hack that just works. It hat to do
obfuscation, and it do it well.
> > * decrypt is expensive on language handler level. Every session have
> > to do it again and again, better decrypt in system cache or somewhere
> > there.
>
> Doesn't bother me in the least...and caching unencrypted data is
> scary. Also, aes256 is pretty fast for what it gives you and function
> bodies are normally short. The real issue as I see it is where to
> keep the key. How did you handle that?
>
> merlin
>
Simply. I use for password some random plpgsql message text and
compile it. I though about GUC, and about storing password in
postgresql.conf. It's equal to protection level. We cannot protect
code on 100%. If you have admin or superuser account and if you know
some internal, you can simply get code.
http://blog.pgsql.cz/index.php?/archives/10-Obfuscator-PLpgSQL-procedur.html#extended
sorry for czech desc
Pavel