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

On Sun, Dec 19, 2010 at 5:13 PM, Christopher Head <chris2k01(at)hotmail(dot)com> wrote:
> On Wed, 14 Jul 2010 18:35:55 -0400
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>> > Do the docs need any more updating?
>>
>> No doubt, but it's a bit premature to consider that while we're still
>> arguing whether the code needs to change more.
>>
>>                       regards, tom lane
>>
>
> Sorry to bother everyone, but AFAICT this discussion kind of
> disappeared. Did I perhaps get dropped from CC? I'm interested to know
> what the final resolution of this is.

I don't think there ever was any more discussion.

> My own thought would be:
> "host" means the thing you intended to connect to: a unique identifier
> for the server, probably (usually) the hostname, and also the thing
> that goes in a certificate. Should (probably) never be omitted.
>
> "hostaddr" means the thing you actually send your TCP SYN packet to:
> maybe an IP address if you want to save a DNS lookup, maybe even
> "localhost" if you want to use an SSH tunnel (or even some other
> hostname if you have an even stranger tunnel set up), but purely a
> "network-layer" thing about *how to get to* the server, and not a
> "user-trust-layer" thing about *who the server is*. If omitted,
> defaults to being equal to "host".
>
> I don't know if that's what was intended, but that's what I thought
> they would mean.

Me, too. I reread the original discussion of this topic and I'm still
a little fuzzy on it, but the issue that was under discussion seems to
be what information we pass to external auth libraries like GSSAPI or
Kerberos, given that we have host and hostaddr to choose from.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company