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
Hello,
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 require that the pri
17 matches
Mail list logo
