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.
* decrypt is expensive on language handler level. Every session have
to do it again and again, better decrypt in system
On Dec 21, 2007 3:18 AM, Pavel Stehule [EMAIL PROTECTED] 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
Bruce Momjian wrote:
Is this a TODO?
---
Tom Lane wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
I don't really agree that wrapping pl/pgsql with encryptor/decryptor
is a bad idea.
It's quite a good idea, because it
On Dec 21, 2007 9:34 AM, Bruce Momjian [EMAIL PROTECTED] wrote:
Is this a TODO?
I don't think so, at least not yet (it's not clear what if anything
there is to do).
see: http://archives.postgresql.org/pgsql-hackers/2007-12/msg00788.php
merlin
---(end of
On 21/12/2007, Merlin Moncure [EMAIL PROTECTED] wrote:
On Dec 21, 2007 3:18 AM, Pavel Stehule [EMAIL PROTECTED] 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
Is this a TODO?
---
Tom Lane wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
I don't really agree that wrapping pl/pgsql with encryptor/decryptor
is a bad idea.
It's quite a good idea, because it has more than zero
On Fri, Dec 21, 2007 at 12:09:28AM -0500, Merlin Moncure wrote:
Maybe a key management solution isn't required. If, instead of
strictly wrapping a language with an encryption layer, we provide
hooks (actors) that have the ability to operate on the function body
when it arrives and leaves
On Fri, Dec 21, 2007 at 12:40:05AM -0500, Tom Lane wrote:
whether there is a useful policy for it to implement. Andrew Sullivan
argued upthread that we cannot get anywhere with both keys and encrypted
function bodies stored in the same database (I hope that's an adequate
summary of his
It seems like a lot of people only saw hide source code in the
original message, and then went off on tangents that don't have
anything to do with the request.
Again:
On 12/14/07, Roberts, Jon [EMAIL PROTECTED] wrote:
Is it possible yet in PostgreSQL to hide the source code of functions from
I wrote:
That's it. A very simple problem.
It was hinted to me off-list that my mail was fanning the flames, so
to clarify: when I say things like the above, I mean conceptually.
I think there might be a shared pool of knowledge that says it's
anything but simple in practical terms, but that
Trevor Talbot [EMAIL PROTECTED] writes:
Something that looks a lot like encryption of the entire database is
more likely to succeed politically than a simple addition to
PostgreSQL's existing role-based security model? Really?
I guess that you have failed to understand any of the discussion.
On Thu, Dec 20, 2007 at 02:02:57PM -0600, Roberts, Jon wrote:
I'm tired of arguing. You win. I still say this I a needed feature if you
want adoption for enterprise level databases in larger companies. The
security out of the box is not enough
What a classic I want this, and if it isn't
12 matches
Mail list logo
