Magnus Hagander <mag...@hagander.net> 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 the naming of the value
> if we go down that path.
I guess you didn't think through the implications of the sslmode
comment, but: this is all merest self-delusion. If a hostile server is
trying to fool you, all he needs to do is configure his pg_hba.conf to
accept your connection in non-SSL mode, and your super duper
guaranteed-to-work ssl verification doesn't do a thing.
So unless you think you can persuade us to change the default sslmode to
"require", you're wasting your time making the above argument.
>> BTW, what in the world prompted us to use "cn" as an allowed value for
>> sslverify? It looks for all the world like a typo for "on".
> Eh, what would you call it? It enables verification of the cn field in
> the certificate. Another option I considered was "full", but someone
> said that was bad - can't recall if that was on-list or off ATM.
I would call it "on", and put the hostname behavior control somewhere
else. Overloading a security-sensitive parameter's meaning isn't a
particularly safe design, eh? Especially with a value that people
can't even read correctly if their eyes are a bit bleary.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
