Thread

  1. Re: Serverside SNI support in libpq

    Heikki Linnakangas <hlinnaka@iki.fi> — 2025-12-17T09:03:07Z

    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