MIME-Version: 1.0
References: <88986722-5A72-4DEC-8750-BDBF67FF8C01@yesql.se>
 <7E77028B-5A3A-436B-9046-8E9992E9F94A@yesql.se>
 <Z1jeINLtB05YMVOY@paquier.xyz>
 <E51258CD-C7B2-4BB1-AB9C-A3DD2B6592D0@yesql.se>
 <F4222274-15C0-40E4-84FB-8FC1355BB8B2@yesql.se>
 <CAOYmi+mSrV8hRaQkvGDf1Df4cmpv5SeTbTxppyxeonMe6MW8nA@mail.gmail.com>
 <0BC5B9B1-6503-4563-AAC6-33DEF264AE3F@yesql.se>
 <aa7gx3mychf3m2g67mbslzbxjy3if4enpcflstoa5pol3432x5@ugqz45gsvurq>
 <F585452A-1F69-4658-A7E8-D1273AC663ED@yesql.se>
 <aLT9xVsTVp0j3zWy@paquier.xyz>
 <80F4F8F4-8E4F-4B6F-866B-D837057C1192@yesql.se>
 <D9F6F14D-FCB1-48B5-9CBC-AE89FA0AEF4C@yesql.se>
 <CAOYmi+m2Ks7D4obtXay3y-UNn6CkTNrmr_zWC25vKTdesatafA@mail.gmail.com>
 <0C53C316-C24E-4307-807B-D825CA3F7254@yesql.se>
 <DD77A37A-BFCA-4819-A029-1A41E2443D8E@gmail.com>
 <378D83FA-338C-4EA1-BC60-397BE08D0F01@yesql.se>
 <2025112617144938459246@163.com>
 <0217DEFA-9684-4A77-A005-D30EBEF155C4@yesql.se>
 <afb479af-2fe7-4790-ad11-437a326329b5@iki.fi>
 <5D0E78E0-EA79-480E-ABD3-B1EF0156BF8B@yesql.se>
 <f621264b-26a6-4b7a-8982-3820b7d6d397@iki.fi>
 <CAGECzQTWH-bzHcdPo=i09TL_P6_HBBNEkBmr+rpN_J9zVfR2Fw@mail.gmail.com>
 <785C0B88-7068-4576-AF55-251D06CEC112@yesql.se>
 <CAOYmi+=u=vS1beiog6p5e843uVdout9qZY=pRj4vo=jCVwgGTA@mail.gmail.com>
 <FB2759EB-C8DB-49FA-800F-7010C65EB8DF@yesql.se>
In-Reply-To: <FB2759EB-C8DB-49FA-800F-7010C65EB8DF@yesql.se>
From: Jacob Champion <jacob.champion@enterprisedb.com>
Date: Wed, 17 Dec 2025 15:58:10 -0800
Message-ID: 
 <CAOYmi+mZ=i55iH44zPqidZfoNDLwPBMD=PUtD03LR2ut+zMEag@mail.gmail.com>
Subject: Re: Serverside SNI support in libpq
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Jelte Fennema-Nio <postgres@jeltef.nl>,
 Heikki Linnakangas <hlinnaka@iki.fi>,
	Dewei Dai <daidewei1970@163.com>, "li.evan.chao" <li.evan.chao@gmail.com>,
	Michael Paquier <michael@paquier.xyz>, Andres Freund <andres@anarazel.de>,
	Pgsql Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAOYmi%2BmZ%3Di55iH44zPqidZfoNDLwPBMD%3DPUtD03LR2ut%2BzMEag%40mail.gmail.com>
Precedence: bulk

On Fri, Dec 12, 2025 at 3:41=E2=80=AFAM Daniel Gustafsson <daniel@yesql.se>=
 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.

> 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 =3D> qr/unknown ca/);
> +       expected_stderr =3D> qr/client certificates can only be checked i=
f a root certificate store is available/);

because host_context->ssl_loaded_verify_locations should be false. But
that doesn't happen... Why?

> Adding a boolean GUC which turns ph_hosts (and thus SNI) on or off can pe=
rhaps
> fix both complaints?

Sounds reasonable, I think.

--

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?

> +           else if (strcmp(host->hostname, "no_sni") =3D=3D 0)
> +               no_sni_context =3D 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]

> +   /* Hostname */
> +   field =3D list_head(tok_line->fields);
> +   tokens =3D lfirst(field);
> +   token =3D linitial(tokens);
> +   parsedline->hostname =3D 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.

Should we support multiple hostname tokens in a single line, though,
and just copy the settings that follow across all of them? That would
allow you to collapse

    example.org  server.crt  server.key
    example.com  server.crt  server.key
    sub.example.com  server.crt  server.key
    *  other.crt  other.key

into

    example.org,example.com,sub.example.com  server.crt  server.key
    *  other.crt  other.key

or even

    @my-hostnames.txt  server.crt  server.key
    *  other.crt  other.key

Then you'd have a fighting chance at automatically generating the
lists, especially since we don't do wildcards yet.

--Jacob

[1] https://github.com/netty/netty/pull/8150
[2] https://github.com/openssl/openssl/issues/12566