On Fri, Dec 2, 2016 at 8:36 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, Dec 1, 2016 at 4:42 PM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>> On Fri, Dec 2, 2016 at 5:17 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> On Thu, Nov 24, 2016 at 4:38 PM, Andreas Karlsson <andreas@proxel.se> wrote:
>>>> As you can see, after the patch libpq will now look at hostaddr rather than
>>>> host when validating the server certificate because that is what is stored
>>>> in the first (and only) entry of conn->connhost, and therefore what PQhost()
>>>> return.
>>>>
>>>> To me it feels like the proper fix would be to make PQHost() return the
>>>> value of the host parameter rather than the hostaddr (maybe add a new field
>>>> in the pg_conn_host struct). But would be a behaviour change which might
>>>> break someones application. Thoughts?
>>>
>>> I think that the blame here is on the original commit,
>>> 274bb2b3857cc987cfa21d14775cae9b0dababa5, which inadvertently changed
>>> the behavior of PQhost. Prior to that commit, even if "hostaddr" was
>>> used, PQhost would still return whatever value was associated with the
>>> "host" parameter, but now it ignores "host" and returns "hostaddr"
>>> instead. That's busted. I've pushed a trivial fix, and the SSL tests
>>> now pass for me.
>>
>> + if (conn->connhost != NULL &&
>> + conn->connhost[conn->whichhost].type != CHT_HOST_ADDRESS)
>> return conn->connhost[conn->whichhost].host
>> I think that's still incorrect. If a connection string defines a
>> comma-separated list of host, and hostaddr is defined as well,
>> PQhost() would return the comma-separated list, not the IP of the host
>> it is connected to. Am I reading that incorrectly?
>
> Correct, but I'm defining that as user error. If hostaddr is
> specified, host is not used to decide what to connect to, so it makes
> no sense for it to be a string of multiple host names. If we allowed
> multiple hostaddrs, as has been proposed, then we'd need to be more
> clever about this.
Would it be better to return NULL instead then. Falling back to a
comma-separated list of hosts, or the default values does not sound
much appealing either.
--
Michael