Re: Serverside SNI support in libpq

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Dewei Dai <daidewei1970(at)163(dot)com>, "li(dot)evan(dot)chao" <li(dot)evan(dot)chao(at)gmail(dot)com>, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Andres Freund <andres(at)anarazel(dot)de>, Pgsql Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Serverside SNI support in libpq
Date: 2025-12-03 23:27:53
Message-ID: 785C0B88-7068-4576-AF55-251D06CEC112@yesql.se
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 3 Dec 2025, at 22:27, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> wrote:
>
> On Wed, 3 Dec 2025 at 17:57, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>>> I really want to make it possible for anyone who don't want SNI to keep using
>>> postgresql.conf and get the exact behavior they've always had. Do you agree
>>> with that design goal?
>>
>> Yeah, that's fair.
>
> What if we make it so that if a pg_hosts.conf file exists, then the
> ssl_cert_file/ssl_key_file configs are ignored? And by default initdb
> would not create a file (or it would, but with the same default
> settings that we have now).

Maybe. I'm not a big fan of magic-file-exist configurations but.. I'm trying
out a few different options to see which seems the most reasonable, and this is
for one of them.

> Basically it would be:
> 1. If the file does not exist, use the "off" behaviour
> 2. If the file exists, use the "strict" behaviour

It will really be "strict" *or* "default" based on whether or not '*' is set as
a wildcard hostname (which can be argued is just a version of strict).

--
Daniel Gustafsson

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2025-12-03 23:33:55 Re: BUG #19095: Test if function exit() is used fail when linked static
Previous Message Chao Li 2025-12-03 23:24:36 Re: Cleanup shadows variable warnings, round 1