Re: BUG #5559: Full SSL verification fails when hostaddr provided

Do the docs need any more updating?

---------------------------------------------------------------------------

Tom Lane wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > Perhaps I was being a bit overzealous in my last response, sorry about
> > that. If the point here is that people who are using hostaddr are in an
> > environment where DNS is non-functional or actively broken, then yes,
> > just bombing out would probably be fine.
>
> Well, if your environment includes broken DNS then you are clearly going
> to get nowhere anyway with Kerberos auth, no? The point of hostaddr is
> *not* to try to avoid that problem. Rather, it's to allow the
> application to shift the time expense of the forward DNS lookup to some
> other place than its PQconnect() call. If you've got an app where the
> cost of PQconnect() is that critical, you're likely going to want to
> avoid Kerberos auth anyway, so I don't think it's all that important
> exactly how the two features play together.
>
> As the code stands in HEAD, I think everything is nicely
> self-consistent: host is what we believe the server name is for
> authentication purposes, and hostaddr is an optional pre-looked-up
> address corresponding to that. There is nothing in this suggesting
> that we should be expected to try to generate an authentication name
> from hostaddr alone. In particular, the fact that Kerberos is capable
> of trying to do that is at odds with the other three code paths where
> the server name is needed for authentication. I don't feel any need
> to expose Kerberos' peculiarity here.
>
> regards, tom lane
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ None of us is going to be here forever. +