Re: Serverside SNI support in libpq
| От | Heikki Linnakangas |
|---|---|
| Тема | Re: Serverside SNI support in libpq |
| Дата | |
| Msg-id | e733621c-2737-4887-8ba8-9c33a7107247@iki.fi обсуждение исходный текст |
| Ответ на | Re: Serverside SNI support in libpq (Heikki Linnakangas <hlinnaka@iki.fi>) |
| Список | pgsql-hackers |
On 17/12/2025 11:03, Heikki Linnakangas wrote: > On 12/12/2025 13:41, Daniel Gustafsson wrote: >> 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. I was thinking that the boolean GUC would be called something like "read_pg_hosts_file = on / off", which feels unnatural. But thinking about this more, if the GUC is called something like "enable_sni = on / off", that feels much better, and I like that more than my suggestion of specifying the path to the pg_hosts file. - Heikki
В списке pgsql-hackers по дате отправления: