Magnus Hagander wrote:
> 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.
Unfortnately enviornment variables are application wide and aren't
appropriate at all for the driver which should set the properties
on the fly per e.g. connection according to the DSN or the connection
string.
regards,
Hiroshi Inoue
