On 21/12/2007, Merlin Moncure <mmoncure@xxxxxxxxx> wrote: > On Dec 21, 2007 3:18 AM, Pavel Stehule <pavel.stehule@xxxxxxxxx> 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 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your message can get through to the mailing list cleanly
