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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs