Re: Broken SSL tests in master
От | Michael Paquier |
---|---|
Тема | Re: Broken SSL tests in master |
Дата | |
Msg-id | CAB7nPqQNLA505XyKhmpz_zPUx+0QUG0_LJNE_w80Ckm-KQmUfg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Broken SSL tests in master (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Broken SSL tests in master
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: