On Mon, Sep 14, 2009 at 07:39:47PM +0200, Saleem EDAH-TALLY wrote:
> OK guys, I would never have thought about modifying libpq to steal
> confidential data, and I have never used debuggers in this respect
> at all.
>
> So super gurus can yet do the bad thing.
It doesn't take any kind of guru to
nm...@netcourrier.com ("Saleem EDAH-TALLY") writes:
> OK guys, I would never have thought about modifying libpq to steal
> confidential
> data, and I have never used debuggers in this respect at all.
>
> So super gurus can yet do the bad thing.
Since this thread was published, anyone capable of
Sam Mason writes:
> On Mon, Sep 14, 2009 at 05:45:14PM +0200, Saleem EDAH-TALLY wrote:
>> Le Monday 14 September 2009 16:13:45, vous avez écrit :
>>> "Secure wallet" is an exercise in self-delusion.
>>
>> Not really. How can a user extract data from a container, by whatever
>> name we call it, if
OK guys, I would never have thought about modifying libpq to steal confidential
data, and I have never used debuggers in this respect at all.
So super gurus can yet do the bad thing.
Nevertheless 99% of users are not super gurus who could do such nasty things
but a few of them could use an une
Le Monday 14 September 2009 16:13:45, vous avez écrit :
> "Secure
> wallet" is an exercise in self-delusion.
Not really. How can a user extract data from a container, by whatever name we
call it, if he does not have the key to open it ?
Could you please instruct how to achieve this ?
--
Sent
On Mon, Sep 14, 2009 at 05:45:14PM +0200, Saleem EDAH-TALLY wrote:
> Le Monday 14 September 2009 16:13:45, vous avez écrit :
> > "Secure
> > wallet" is an exercise in self-delusion.
>
> Not really. How can a user extract data from a container, by whatever
> name we call it, if he does not have the
On Mon, Sep 14, 2009 at 09:40:47AM +0200, Saleem Edah-Tally wrote:
> >a separate application server
>
> Well this can be a solution in a trustworthy and friendly environment, on
> which I can't count.
There must be some mis-communication going on; the above is how things
tend to be done on the I
On Mon, Sep 14, 2009 at 12:17:55PM -0400, Tom Lane wrote:
> Sam Mason writes:
> > On Mon, Sep 14, 2009 at 05:45:14PM +0200, Saleem EDAH-TALLY wrote:
> >> How can a user extract data from a container, by whatever
> >> name we call it, if he does not have the key to open it ?
>
> > Exactly the same
"Saleem Edah-Tally" writes:
> I would have been more at ease if libpq could manage a PKCS12 cert. or some
> secure wallet/keystore that contains both the public and private keys for SSL
> traffic. Neither the end user nor any admin would have to provide the
> password
> to access the keys insi
>a separate application server
Well this can be a solution in a trustworthy and friendly environment, on
which I can't count.
I would have been more at ease if libpq could manage a PKCS12 cert. or some
secure wallet/keystore that contains both the public and private keys for SSL
traffic. Neith
>a separate application server
Well this can be a solution in a trustworthy and friendly environment, on
which I can't count.
I would have been more at ease if libpq could manage a PKCS12 cert. or some
secure wallet/keystore that contains both the public and private keys for SSL
traffic. Neith
On Sun, 2009-09-13 at 12:04 -0300, pgsql-general-ow...@postgresql.org
wrote:
> >A user must have the TRUNCATE privilege to truncate a table or be the
> >tables owner.
>
> Well the TRUNCATE example I mentioned is perhaps not explicit of what
> I meant
> to say. A user who can modify data in a cli
Saleem EDAH-TALLY wrote:
This concerns use of postgresql.key private key file on the client side.
psql can't establish a connection. with an encrypted postgresql.key file. If
I'm wrong here, the following is invalid and please show me the steps I'm
ignoring.
An application using libpq would
> An application using libpq would require that the private unencrypted key be
> deployed to the end user, together with the public key and trust cert. This
> would mean if the end user is curious enough and computer litterate, he can
> bypass the client application and make a direct connection
>A user must have the TRUNCATE privilege to truncate a table or be the
>tables owner.
Well the TRUNCATE example I mentioned is perhaps not explicit of what I meant
to say. A user who can modify data in a client application can also modify
data if he connects directly to the database, bypassing t
> An application using libpq would require that the private unencrypted key be
> deployed to the end user, together with the public key and trust cert. This
> would mean if the end user is curious enough and computer litterate, he can
> bypass the client application and make a direct connection
16 matches
Mail list logo
