Re: Serverside SNI support in libpq
Heikki Linnakangas <hlinnaka@iki.fi>
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Daniel Gustafsson <daniel@yesql.se>,
Jacob Champion <jacob.champion@enterprisedb.com>
Cc: Jelte Fennema-Nio <postgres@jeltef.nl>, 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>
Date: 2025-12-17T09:03:07Z
Lists: pgsql-hackers
On 12/12/2025 13:41, Daniel Gustafsson wrote: >> On Wed, Dec 3, 2025 at 1:57 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote: >>> Maybe. I'm not a big fan of magic-file-exist configurations >> >> Me neither. (I especially don't like the idea of ignoring a >> certificate+key setting that a user has taken the time to put into a >> config.) +1 > I wonder if the way forward is to do both? Heikki has a good point that when > working with pg_hosts.conf it should be clear from just that file what the > final config will be, and in the previous version that wasn't the case since > the ssl_snimode GUC set operation modes. At the same time, Jacob has a point > that overriding configuration just because pg_hosts exists isn't transparent. > > Adding a boolean GUC which turns ph_hosts (and thus SNI) on or off can perhaps > fix both complaints? If the GUC is on, pg_hosts - and only pg_hosts - is used > for configuring secrets. By using the * fallback and no_sni rule in pg_hosts > all variations of configs can be achieved. If the GUC is off, then the regular > SSL GUCs are used and pg_host is never considered (and thus SNI is not > possible). > > Such a GUC wouldn't make the patch all that much different from what it is > right now. What do you think about that middleground proposal? I like that. Instead of a boolean GUC, it could perhaps be a path to the pg_hosts file. I haven't thought this through but somehow it feels more natural to me than a "read this file or not" setting. - Heikki