On Fri, 2007-21-12 at 18:05 -0400, Andrew Sullivan <[EMAIL PROTECTED]>
wrote:
> > > 2. Protect the content of a field from _some_ users on a given
> system,
> >
> > I would argue that (2) is reasonably well served today by setting up
> > separate databases for separate users.
>
> I thought act
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 21 Dec 2007 16:47:46 -0500
Andrew Sullivan <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 21, 2007 at 04:19:51PM -0500, Tom Lane wrote:
> > > 2.Protect the content of a field from _some_ users on a
> > > given system,
> >
> > I would argue
On Fri, Dec 21, 2007 at 04:19:51PM -0500, Tom Lane wrote:
> > 2. Protect the content of a field from _some_ users on a given system,
>
> I would argue that (2) is reasonably well served today by setting up
> separate databases for separate users.
I thought actually this was one of the use-cases
Andrew Sullivan <[EMAIL PROTECTED]> writes:
> Hmm; this may be exactly part of the problem, though. It seems there are
> two possible cases in play:
> 1.Protect the content in the database (in this case, function bodies)
> from _all_ users on a given server. This is a case where you want to
On Fri, Dec 21, 2007 at 01:57:44PM -0500, Tom Lane wrote:
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> > ISTM the main issue is how exactly the authenticated user interacts
> > with the actor to give it the information it needs to get the real
> > key. This is significant because we don't want
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> ISTM the main issue is how exactly the authenticated user interacts
> with the actor to give it the information it needs to get the real
> key. This is significant because we don't want to be boxed into an
> actor implementation that doesn't allow tha
On Dec 21, 2007 11:48 AM, Andrew Sullivan <[EMAIL PROTECTED]> wrote:
> 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 bod
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 po
Andrew Sullivan <[EMAIL PROTECTED]> writes:
> On Fri, Dec 21, 2007 at 12:09:28AM -0500, Merlin Moncure wrote:
>> Maybe a key management solution isn't required.
> I like this idea much better, because the same basic mechanism can be used
> for more than one thing, and it doesn't build in a system
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 p
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> On 21/12/2007, Merlin Moncure <[EMAIL PROTECTED]> wrote:
>> ... The real issue as I see it is where to
>> keep the key. How did you handle that?
> Simply. I use for password some random plpgsql message text and
> compile it. I though about GUC, and a
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
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 oth
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 c
On Dec 21, 2007 12:40 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> > On Dec 20, 2007 6:01 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> >> So if you want something other than endless arguments to happen,
> >> come up with a nice key-management design for encr
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> On Dec 20, 2007 6:01 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> So if you want something other than endless arguments to happen,
>> come up with a nice key-management design for encrypted function
>> bodies.
> Maybe a key management solution isn't req
16 matches
Mail list logo
