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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company