public inbox for [email protected]
help / color / mirror / Atom feedFrom: Daniel Gustafsson <[email protected]>
To: Jacob Champion <[email protected]>
Cc: Jelte Fennema-Nio <[email protected]>
Cc: Heikki Linnakangas <[email protected]>
Cc: Dewei Dai <[email protected]>
Cc: li.evan.chao <[email protected]>
Cc: Michael Paquier <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: Pgsql Hackers <[email protected]>
Subject: Re: Serverside SNI support in libpq
Date: Thu, 18 Dec 2025 01:07:41 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAOYmi+mZ=i55iH44zPqidZfoNDLwPBMD=PUtD03LR2ut+zMEag@mail.gmail.com>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<CAOYmi+mSrV8hRaQkvGDf1Df4cmpv5SeTbTxppyxeonMe6MW8nA@mail.gmail.com>
<[email protected]>
<aa7gx3mychf3m2g67mbslzbxjy3if4enpcflstoa5pol3432x5@ugqz45gsvurq>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<CAOYmi+m2Ks7D4obtXay3y-UNn6CkTNrmr_zWC25vKTdesatafA@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<CAGECzQTWH-bzHcdPo=i09TL_P6_HBBNEkBmr+rpN_J9zVfR2Fw@mail.gmail.com>
<[email protected]>
<CAOYmi+=u=vS1beiog6p5e843uVdout9qZY=pRj4vo=jCVwgGTA@mail.gmail.com>
<[email protected]>
<CAOYmi+mZ=i55iH44zPqidZfoNDLwPBMD=PUtD03LR2ut+zMEag@mail.gmail.com>
> On 18 Dec 2025, at 00:58, Jacob Champion <[email protected]> wrote:
>
> On Fri, Dec 12, 2025 at 3:41 AM Daniel Gustafsson <[email protected]> wrote:
>>> The comment for HostsLine.ssl_ca, and the code that assigns it,
>>> implies to me that host->ssl_ca should never be NULL. Am I missing a
>>> case where it could be?
>>
>> The attached version allows ssl_ca to be omitted from the pg_host config to
>> match the ssl_ca GUC.
>
> Aha! I think ssl_ca should be moved into the "Optional fields" section
> of `struct HostsLine` now.
Ah, yes.
>> I'm still not sure why they pass for me locally with that error, but I've
>> updated to patch to match CI.
>
> There's one diff remaining from my old tests patch: the example.org
> line doesn't set ssl_ca, so I expect
>
>> - expected_stderr => qr/unknown ca/);
>> + expected_stderr => qr/client certificates can only be checked if a root certificate store is available/);
>
> because host_context->ssl_loaded_verify_locations should be false. But
> that doesn't happen... Why?
I'll have a look.
> Just checking my understanding: is the use case for no_sni primarily
> that you should be able to strictly refuse clients who say they're
> talking to someone else -- so you don't want a wildcard -- but you
> still want to gracefully handle clients who don't speak SNI at all?
Yeah, pretty much.
>> + else if (strcmp(host->hostname, "no_sni") == 0)
>> + no_sni_context = host_context;
>
> Will anyone be mad at us for camping on the "no_sni" identifier? I
> know technically underscore isn't allowed in DNS hostnames, buuuut [1,
> 2]
Maybe, but I think that regardless of what we do someone will be mad. The
other option would be to use another single character like '?' or something.
Not sure that will improve readability though.
>> + /* Hostname */
>> + field = list_head(tok_line->fields);
>> + tokens = lfirst(field);
>> + token = linitial(tokens);
>> + parsedline->hostname = pstrdup(token->string);
>
> We should probably check tokens->length to make sure that the user
> hasn't passed more than one token for each field, similar to how
> parse_hba_line() does it.
Good point, will do that.
> Should we support multiple hostname tokens in a single line, though,
> and just copy the settings that follow across all of them?
I've been hesitant to add too much complexity, but perhaps just allowing a
comma separated list is a good middle ground to avoid going full regex?
--
Daniel Gustafsson
view thread (58+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Serverside SNI support in libpq
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox