Re: WIP: plpgsql source code obfuscation
От | Andrew Dunstan |
---|---|
Тема | Re: WIP: plpgsql source code obfuscation |
Дата | |
Msg-id | 479E26EF.7060207@dunslane.net обсуждение исходный текст |
Ответ на | Re: WIP: plpgsql source code obfuscation (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: WIP: plpgsql source code obfuscation
|
Список | pgsql-patches |
Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.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
В списке pgsql-patches по дате отправления: