Re: SSL SNI

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jacob Champion <pchampion(at)vmware(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SSL SNI
Date: 2021-06-07 09:54:31
Message-ID: 5df46438-c1b4-161c-4669-f6e6ab6797f0@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 03.06.21 20:14, Tom Lane wrote:
> I wrote:
>> It looks like the immediate problem can be resolved by just adding
>> a check for conn->pghost not being NULL,
>
> ... scratch that. There's another problem here, which is that this
> code should not be looking at conn->pghost AT ALL. That will do the
> wrong thing with a multi-element host list. The right thing to be
> looking at is conn->connhost[conn->whichhost].host --- with a test
> to make sure it's not NULL or an empty string. (I didn't stop to
> study this code close enough to see if it'll ignore an empty
> string without help.)

Patch attached. Empty host string was handled implicitly by the IP
detection expression, but I added an explicit check for sanity. (I
wasn't actually able to get an empty string to this point, but it's
clearly better to be prepared for it.)

Attachment Content-Type Size
0001-libpq-Fix-SNI-host-handling.patch text/plain 2.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2021-06-07 10:11:53 Re: Tid scan improvements
Previous Message Aleksander Alekseev 2021-06-07 09:44:42 Re: Fix dropped object handling in pg_event_trigger_ddl_commands