Re: WIP: plpgsql source code obfuscation

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: WIP: plpgsql source code obfuscation
Дата
Msg-id 7112.1201554278@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: WIP: plpgsql source code obfuscation  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: WIP: plpgsql source code obfuscation  (Gregory Stark <stark@enterprisedb.com>)
Re: WIP: plpgsql source code obfuscation  (Andrew Dunstan <andrew@dunslane.net>)
Re: WIP: plpgsql source code obfuscation  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-patches
Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> 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.

My recollection is that certain cryptography laws make hooks for crypto
just as problematic as actual crypto code.  We'd have to tread very
carefully --- "general purpose" hooks are OK but anything narrowly
tailored to encryption purposes would be a hazard.  This is one reason
that I'd prefer to see it as an external PL rather than embedded in core.

> Various interesting encoding issues could arise with dumping and
> restoring transformed program text - I haven't thought that through yet.

I think we have already solved that with md5 passwords, and could easily
reuse the same kind of approach.  You just base64 encode the crypted
text (or whatever you need to do to avoid funny characters in it), and
make sure that there's some way to distinguish already-crypted from
not-already-crypted function bodies.

            regards, tom lane

В списке pgsql-patches по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: WIP: plpgsql source code obfuscation
Следующее
От: David Fetter
Дата:
Сообщение: Re: Auto-explain patch