Martin Pitt wrote:
> Peter Eisentraut [2009-04-10 14:56 +0300]:
>> I assume the server has the snakeoil certificate installed? In that case,
>> it
>> is correct that the client refuses to proceed, although the exact manner of
>> breaking could perhaps be improved.
>
> Is it really refusing sel
The following bug has been logged online:
Bug reference: 4756
Logged by:
Email address: mattierm...@gmail.com
PostgreSQL version: 8.3
Operating system: Windows xp
Description:Installationproblems
Details:
Failour during installationprocess
Data directory error
Th
Martin Pitt wrote:
-- Start of PGP signed section.
> Peter Eisentraut [2009-04-10 14:56 +0300]:
> > I assume the server has the snakeoil certificate installed?
>
> It is a self-signed certificate indeed (Debian's ssl-cert package).
>
> > In that case, it is correct that the client refuses to proc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
mattierm...@gmail.com wrote:
> The following bug has been logged online:
>
> Bug reference: 4756
> Logged by:
> Email address: mattierm...@gmail.com
> PostgreSQL version: 8.3
> Operating system: Windows xp
> Description:I
Peter Eisentraut wrote:
> On Friday 10 April 2009 08:39:33 Martin Pitt wrote:
> > Tom Lane [2009-04-10 1:15 -0400]:
> > > Martin Pitt writesyuqhom#3:
> > > > The test suite detected one regression in libpq, though: Setting
> > > > $PGHOST now complains about a missing root.crt, although this is o
The following bug has been logged online:
Bug reference: 4757
Logged by: Timofey.Asyrkin
Email address: timoha-...@ngs.ru
PostgreSQL version: 8.3
Operating system: Ubuntu 8.10
Description:to_timestamp returns incorrect result
Details:
Hello everybody,
It looks like
"Timofey.Asyrkin" writes:
> I'm living in Italy and I have a timezone GMT+2 (summer).
> These two queries return the same result:
> 1)select TO_TIMESTAMP( '25/03/2001 02:00:00', 'dd/mm/ hh24:mi:ss' );
> 2)select TO_TIMESTAMP( '25/03/2001 03:00:00', 'dd/mm/ hh24:mi:ss' );
> Result: 2001-0
Martin Pitt wrote:
> I do see the benefit of failing to connect to an SSL-enabled server
> *if* I have a root.crt which doesn't match. But why fail if I don't
> have one?
I have digested this thread, and have done two things: improved the
documentation and posted a patch to make the error message
Bruce Momjian writes:
> In terms of your suggestion about root.crt, I think sslverify != none
> should error if it can't verify the server's certificate, whether the
> root.crt file is there or not. If you are asking for sslverify, it
> should do that or error, not ignore the setting if there is
Bruce Momjian wrote:
> Martin Pitt wrote:
>> I do see the benefit of failing to connect to an SSL-enabled server
>> *if* I have a root.crt which doesn't match. But why fail if I don't
>> have one?
>
> I have digested this thread, and have done two things: improved the
> documentation and posted a
Tom Lane wrote:
> Bruce Momjian writes:
>> In terms of your suggestion about root.crt, I think sslverify != none
>> should error if it can't verify the server's certificate, whether the
>> root.crt file is there or not. If you are asking for sslverify, it
>> should do that or error, not ignore th
Magnus Hagander writes:
> Bruce Momjian wrote:
>> The only other approach would be to add an sslverify value of
>> 'try' that tries only if root.crt exists.
> Doesn't "try" make the whole check pretty pointless, and you can just
> set it to "none" then?
Not at all. What it means is that you con
Magnus Hagander writes:
> The option is there already, it's called "none". That's what people are
> asking for -
No, that is NOT what people are asking for. Please stop attacking a
straw man. What people are asking for is that by default, whether to
make the check or not should depend on whethe
Tom Lane wrote:
> Magnus Hagander writes:
>> Bruce Momjian wrote:
>>> The only other approach would be to add an sslverify value of
>>> 'try' that tries only if root.crt exists.
>
>> Doesn't "try" make the whole check pretty pointless, and you can just
>> set it to "none" then?
>
> Not at all.
Magnus Hagander writes:
> Uh, it's not "on" if it's not "on". I'd rather call them "off", "on" and
> something like "maybe" or "external" or "file". I'd find it very bad if
> you can say "sslverify=on" and then *not* end up getting it because of
> some external factor. That needs to be clear in t
Magnus Hagander wrote:
Bruce Momjian wrote:
Martin Pitt wrote:
I do see the benefit of failing to connect to an SSL-enabled server
*if* I have a root.crt which doesn't match. But why fail if I don't
have one?
I have digested this thread, and have done two things: improved the
documentation an
Tom Lane wrote:
> I am of the opinion that sslverify should have these values:
>
> off = never verify
> on = verify if root.crt is present (default behavior)
> force = verify, failing if root.crt is not present
>
> and the people who actually want to be "sure they're secure" can
Bruce Momjian wrote:
> It would be nice if 'sslverify' mimicked 'sslmode', which has these
> values:
>
> disable
> allow
> prefer
> require
>
> I don't see how we could use 'allow', but 'disable', 'prefer', and
> 'require' seem to work for sslverify, like sslmode.
OK, cra
18 matches
Mail list logo
