Re: Serverside SNI support in libpq
| От | Heikki Linnakangas |
|---|---|
| Тема | Re: Serverside SNI support in libpq |
| Дата | |
| Msg-id | 4b9923d6-65f3-46d5-8360-462f8381fbee@iki.fi обсуждение исходный текст |
| Ответ на | Re: Serverside SNI support in libpq (Daniel Gustafsson <daniel@yesql.se>) |
| Ответы |
Re: Serverside SNI support in libpq
|
| Список | 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
В списке pgsql-hackers по дате отправления: