Re: libpq 8.4 beta1: $PGHOST complains about missing root.crt

Hiroshi Inoue wrote:
> Magnus Hagander wrote:
>> Hiroshi Inoue wrote:
>>> 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 and posted a patch to make the error message clearer.
>>>>>
>>>>> 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 no
>>>>> root.crt
>>>>> file. 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?
>>> Yes the snapshot psqlodbc driver already set sslverify to none and can't
>>> change it though it may be differnet from the expected behavior. It was
>>> not so easy to implement because sslverify parameter is illegal for <=
>>> 8.3 libpq and the psqlodbc driver doesn't rely on environment variables
>>> at all.
>>
>> Whatever the default is, if you can't change the value I'd say that
>> makes the ODBC driver pretty darn broken. It would be equally broken if
>> it was set to the default and it wasn't possible to change it.
>
> The psqlodbc driver has its own development cycle and doesn't use new
> core features at once usually. The problem is the default behavior about
> sslverify is incompatible with the 8.3 libpq behavior and the driver had
> to do something with it before 8.4 release. What the snapshot driver
> actualy does is to simply hide the *sslverify* functionality.

I thought you were talking about a release version. If it's just a
snapshot, that is of course Ok. My apologies.

Though it might be easier even in that case to use an environment
variable to override it - that way the user could still override the
ODBC driver if you just checked if the variable was present before you
set it.

//Magnus