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?
The point is, you need to *know*. "try" makes no sense. If we want to be
sure it never fails to connect, we disable security by default - setting
sslverify to "none". For those who care about security, we document
clearly how to enable it, and make it very clear that we ship with this
part of the security system disabled by default.
(shipping in this way, btw, will be considered a bug by anybody in the
security community. But that's a different community than ours, and at
least there's a builtin way to fix it)
Inventing a switch that makes it more or less impossible to figure out
if you are going to be secure or not makes no sense. When dealing with
security, maybe is the same as no, and you have to *know*.
//Magnus