Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vVnRG-0084hC-1j for pgsql-hackers@arkaria.postgresql.org; Wed, 17 Dec 2025 09:03:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vVnRF-00BWFF-0h for pgsql-hackers@arkaria.postgresql.org; Wed, 17 Dec 2025 09:03:17 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vVnRE-00BWF6-2V for pgsql-hackers@lists.postgresql.org; Wed, 17 Dec 2025 09:03:17 +0000 Received: from lahtoruutu.iki.fi ([185.185.170.37]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vVnRD-0017Pt-15 for pgsql-hackers@lists.postgresql.org; Wed, 17 Dec 2025 09:03:16 +0000 Received: from [10.0.2.15] (unknown [130.41.208.2]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: hlinnaka) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 4dWSWJ4yDXz49Pwn; Wed, 17 Dec 2025 11:03:08 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1765962191; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vEN5VL+MjJN1/gvACzkatxm/1S41wOPBw31hA1uaOc0=; b=WRtbVjIQtznGHhu0VSSO87ZrJeY1s+OS/7HOY2LHO5EAD6vOSW7sledJJBjWhAyOLC+NMq K+XEnZ+7Xgfa2kM/oBBJQXBto4PBQoyEcS+A7KOxY1hH9UsKkJmc8JYKYTARU0YbZyXJj9 JYdy/Fd9cSnG09GVlSBCsEbeGtT24imDMZV9Is+do9b1MceV1iQ9OyHrGz3/lxtvV4xpD/ lzxn1jwgIMc+iGCbzgOSPI/b7JNRWARZYFvAslV/GQKJbEs8DwDiwl6RwNpNtDf8zy1Brp G+V5v7/C555uIYCzUFc/1Z7M3dpKfpeHX/9+DjEwWpOqtnVX6L3Ar4fPp6e2pg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1765962191; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vEN5VL+MjJN1/gvACzkatxm/1S41wOPBw31hA1uaOc0=; b=KMHGNIkN0lu5yrnrir2RAssrIK6HFUBSEFY7gdfcl2ToEHN17AL4rnBXDbuePyMM7KhrD+ z80YYZFylZnUowCTAuCPb1DXQpa92QFN7UXaReHwF27+2DFNN/CgCg6z6y2c1ebw3v10ro cBplEfRcMsLprumqk9jesz0s0+ON0+dBJxdjiSSYk6XUdWK93lbRu/8Fk6q4YV4wFwOvgv vfKmxWUBz7ccYkgfqfsiToYwgKYpOfwxmzP8TdUITqSwRm4+p+KaeTXNDbz5qXi3tX20/N s+BtcR0MQcquJA672NnMmxfF4MJIVfacvcT0o99b8OzAjUY+Z1dIxT/mNBM6Hw== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=hlinnaka smtp.mailfrom=hlinnaka@iki.fi ARC-Seal: i=1; a=rsa-sha256; d=iki.fi; s=lahtoruutu; cv=none; t=1765962191; b=qGrCYnmscG5xWiLsbIAF+RuNOgrty+IPctP9Owax4TeNeyx4A9Dct9n0UQuVzuX7yDzdB2 zvSGexENY7+LdGmloFJSVlDnOB2aeeT0ptdQzS+90ShJKNFs0AT8yXNk1bmlsNl01y+M8Y 52+2xvSenMkHpwDxd3MnsxaZxVGgJE2IwMZrDHUp3OP03nlmoMBblN8pct96EeI5SLVTLP fyfj04+HdeNbcs4oMlkYcuYNAAkyfvjOJ9zhIrcc6HlDZ70Hr8+vH8tJJfAVUnKi8n4Qry vKxJn/VpxKU+1zp+BDdig2QQHYrsdiwWVKw/qO5ta8qItwUa76Bn3K83ovDpkQ== Message-ID: <4b9923d6-65f3-46d5-8360-462f8381fbee@iki.fi> Date: Wed, 17 Dec 2025 11:03:07 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Serverside SNI support in libpq To: Daniel Gustafsson , Jacob Champion Cc: Jelte Fennema-Nio , Dewei Dai , "li.evan.chao" , Michael Paquier , Andres Freund , Pgsql Hackers References: <88986722-5A72-4DEC-8750-BDBF67FF8C01@yesql.se> <80F4F8F4-8E4F-4B6F-866B-D837057C1192@yesql.se> <0C53C316-C24E-4307-807B-D825CA3F7254@yesql.se> <378D83FA-338C-4EA1-BC60-397BE08D0F01@yesql.se> <2025112617144938459246@163.com> <0217DEFA-9684-4A77-A005-D30EBEF155C4@yesql.se> <5D0E78E0-EA79-480E-ABD3-B1EF0156BF8B@yesql.se> <785C0B88-7068-4576-AF55-251D06CEC112@yesql.se> Content-Language: en-US From: Heikki Linnakangas In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 12/12/2025 13:41, Daniel Gustafsson wrote: >> On Wed, Dec 3, 2025 at 1:57 AM Heikki Linnakangas 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