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 1w2Npc-000Eyk-0r for pgsql-hackers@arkaria.postgresql.org; Tue, 17 Mar 2026 06:23:08 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w2Npb-00Gbrh-0h for pgsql-hackers@arkaria.postgresql.org; Tue, 17 Mar 2026 06:23:07 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w2Npa-00GbrZ-2r for pgsql-hackers@lists.postgresql.org; Tue, 17 Mar 2026 06:23:06 +0000 Received: from mail-yw1-x112c.google.com ([2607:f8b0:4864:20::112c]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w2NpY-00000000Ybq-0Fd3 for pgsql-hackers@lists.postgresql.org; Tue, 17 Mar 2026 06:23:06 +0000 Received: by mail-yw1-x112c.google.com with SMTP id 00721157ae682-79827d28fc4so47449387b3.1 for ; Mon, 16 Mar 2026 23:23:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1773728583; cv=none; d=google.com; s=arc-20240605; b=URYgAc+LMRrSG7N4AFIZlM2+9NLAiW/4av00sZjySf9w9xA/AZZGIzze826gAEhApf HXUXkvfdY9X+Xx6gRuCyycJ5WXiDfEePo79cMdVtQ9LEwr0BpPwy7ACUulx9R70G8zTl mD7k4TkcuXAcXNgKMzyl9rS8IBo7nukImR7KAx830hgTeFvJpKYESq52I4sIajKKprAD t8BW80atS5ryVFvhPON5QoJIqnH70QR9cEqg/RRqQRX0t/3XAxBFy+bnuhOVE6tPieCB shDU2kJIRAh/DuuJAzRZIdhiQHrup1yl2CmSUsIKBPdgs4sc65Sm64jLCMvJcn7927hF nPqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=p9tS8zBRzfH1P1sFav337DuB+k0wAtipMXhruDUyY7A=; fh=wC9y8tqI1VO0+GnwsahGFSed4d2JcbTRIR/HgPFOGfQ=; b=Yn0A0FcKLuHMvwv0KIG0mzYF5/aTF7sFHF+mICq5eFbD/T/wvL3PoxoCk9S2o09Jcv dZOyzrBBjctYbwSjAmOiCFfj45LlCiNslv5DVMMYqHlZa0oYF7B1V+1ShdP18rGkMQan nuw10cMQI/mgZx4bo6hihG+1lhJoDb5oOJx08VJWGl7a4HTX5Xk8AKEc/t1jKbcKLUz4 W63/TU/p8FwubDaKphwxF6YYK0EXeYswEvSMf6ac6bYjKR8LMfYzumfMdD2Is9jlqr28 ULy/VyMNk7OZ45QM8yeWuwHJWsHaTMMO8LfS/Fs0xyIed+g/CzwvMXLDda8MXaUOfOcb LSjw==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=percona.com; s=google; t=1773728583; x=1774333383; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=p9tS8zBRzfH1P1sFav337DuB+k0wAtipMXhruDUyY7A=; b=G7zTb0Ff8fwi2tEzUnsY951uF2iArEd8kzPo3O9uR2CVBUrX6BE0p1FbObIVTAbBUB xvwscYV+Jh28CdoW1Tn5qyPKgXwhjOqWJat2vtsQZzPxhXGfV5SNoeX8LPf0T54+SaEZ 7jis1i+zkLvOrZbVdJM5JJv1ezZNIkTIu2wzc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773728583; x=1774333383; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=p9tS8zBRzfH1P1sFav337DuB+k0wAtipMXhruDUyY7A=; b=FUK25+Jb+WLYFTBIWzLhQ9VnvKYF+ZosiTDWIielQ131F0bqIKCq7/mtFOOVg0C+y7 XSSldWItw+GVd5CY+EvQAuOr26b7QI6lWJiitXwmMgYovLQj6tXqK02cOv7RFinZQsAU r9nfadb63S+oTQUAO4ME3cwQ1khTdMELBDhxQ3uxKxfdaT/vgCecYDzmK7oBVM9h7+Di PsGpUiR021cqjtCIeG60pNjVIad+KhzX2VrCIuN55/PHaSkBIYU4BOaPPu2Z/SustnkO HSaB8qbXbmesZxBl+aXSIvP4je7mslRrF8RgUyee7mBhUZGPd+PiHdEdZ5cDrk2rCZHT rvqA== X-Forwarded-Encrypted: i=1; AJvYcCXfftQTuw5xmz8+KgHsJJm9ioR4ttBnc3ownep31Am32V9LB2rqn3F9Tj5y5Z/2Jd7sBT68i+NGKQN1FjEY@lists.postgresql.org X-Gm-Message-State: AOJu0YwIV8kgAe9BAZInXnQveS5PszPU+JDaN17URCySspIUwAHVDt0G FN0blzYq9ZK6ovBZDebj0x4q1Y6ILahDjOQqoErCydE8cR1Z/1LUiPRrs4qjg7tK/xR8xAMe9ot rnCUHnytFNE6zhLzLPAyzSpEGEsVwfVgrhKXoof505cydutL8JQVp/Q41nGPYjxWATuATiq2fJ3 swPHrBgFAjeGneOmWUm1z0nbuLD1kOiMkFBB4iLLvizJqD6ISwvDlXxtf75J8ylUkhAbn2+Obh0 h+IG+OWVlpewUz5v/6i4LTu+3ZqKkDuQGFiSPEjiAEVlW9dt0gz+pBe3n7J5wMhO74= X-Gm-Gg: ATEYQzzd6L9D+j6ecgz+1dTAPI5yVdFpGbfJ2yr9pUbSktXv/DQnrrQJZ1zomvKd624 qnJVqsPN9ME+lM31BhlminAWa5P1y7nMbC1ltjtwu4C5DYfM2dFe5sRKVcxK2q2dMwNGr/0LU2a zteyQQSMAPznpcn+/l0P5Dk6WY2VBCt4lmCkeOhmn2dd3o9xgK26LqJ+VCfZggxw2KTcCv71b9A /DbonZtegPiqwXrPwZ4mdjTp5QXtboJ6XnGyXXEsIK0SesJxFHo5dYXvVaNnIdtk3xRiQvdObZN lBEHxzlfIGGuKz2mHzzwdlDna3Q0S10bbfnJQD20heBKoKQRRzDir4Lv7R5nnA/FUo4H X-Received: by 2002:a05:690c:288:b0:797:4722:f8a7 with SMTP id 00721157ae682-79a1c26723bmr155338427b3.61.1773728583024; Mon, 16 Mar 2026 23:23:03 -0700 (PDT) MIME-Version: 1.0 References: <88986722-5A72-4DEC-8750-BDBF67FF8C01@yesql.se> <7E77028B-5A3A-436B-9046-8E9992E9F94A@yesql.se> <0BC5B9B1-6503-4563-AAC6-33DEF264AE3F@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> <01412917-C42E-4238-97E2-707C32940DDD@yesql.se> <1C38F269-E552-4F78-9E88-E91CEDB12F35@yesql.se> <23D19F69-A8DE-4F89-99F6-5FC48762CE4D@yesql.se> In-Reply-To: <23D19F69-A8DE-4F89-99F6-5FC48762CE4D@yesql.se> From: Zsolt Parragi Date: Tue, 17 Mar 2026 06:22:53 +0000 X-Gm-Features: AaiRm51QTyfN6z1RloaTWcbJXUuhtV3NzHRvQmXAybEjOR5c04XRAuwIkW8E2E8 Message-ID: Subject: Re: Serverside SNI support in libpq To: Daniel Gustafsson Cc: Jacob Champion , Jelte Fennema-Nio , Heikki Linnakangas , Dewei Dai , "li.evan.chao" , Michael Paquier , Andres Freund , Pgsql Hackers Content-Type: text/plain; charset="UTF-8" X-CLOUD-SEC-AV-Sent: true X-CLOUD-SEC-AV-Info: percona,google_mail,monitor X-Gm-Spam: 0 X-Gm-Phishy: 0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > I'm a bit surprised that the .dat > file processing doesn't error out keys that aren't part of the DSL for defining > GUCs but clearly it doesn't. Fixed. This also surprised me, I wrote a patch to improve this [1]. I only have a few mostly stylistic comments, otherwise the patch looks good. + if (isServerStart) + { + if (host->ssl_passphrase_cmd && host->ssl_passphrase_cmd[0]) + { + SSL_CTX_set_default_passwd_cb(ctx, ssl_external_passwd_cb); + SSL_CTX_set_default_passwd_cb_userdata(ctx, host->ssl_passphrase_cmd); + } + } + else + { + if (host->ssl_passphrase_reload && host->ssl_passphrase_cmd[0]) + { + SSL_CTX_set_default_passwd_cb(ctx, ssl_external_passwd_cb); + SSL_CTX_set_default_passwd_cb_userdata(ctx, host->ssl_passphrase_cmd); + } The start path checks ssl_passphrase_cmd for null, the reload doesn't. + if (openssl_tls_init_hook != default_openssl_tls_init) + { + ereport(WARNING, + errcode(ERRCODE_CONFIG_FILE_ERROR), + errmsg("SNI is enabled; installed TLS init hook will be ignored"), Won't this spam the log with one warning per hosts line? It might be okay/acceptable, but there isn't anything line specific in this warning. + * file. The list is returned in the hosts parameter. The function will return + * a HostsFileLoadResult value detailing the result of the operation. When + * the hosts configuration failed to load, the err_msg variable may have more + * information in case it was passed as non-NULL. + */ +int +load_hosts(List **hosts, char **err_msg) Comment says HostsFileLoadResult, but the return type is int. +typedef enum HostsFileLoad +{ + HOSTSFILE_LOAD_OK = 0, + HOSTSFILE_LOAD_FAILED, + HOSTSFILE_EMPTY, + HOSTSFILE_MISSING, + HOSTSFILE_DISABLED, +} HostsFileLoadResult; Is the HostsFileLoad vs HostsFileLoadResult difference intentional? +#ifdef USE_ASSERT_CHECKING + if (res == HOSTSFILE_DISABLED) + Assert(ssl_sni == false); +#endif Do we need this ifdef? And I also found a typo (distncnt): + /* + * At this point we know we have a configuration with a list + * of distnct 1..n hostnames for literal string matching with + * the SNI extension from the user. [1]: https://www.postgresql.org/message-id/CAN4CZFP%3D3xUoXb9jpn5OWwicg%2Brbyrca8-tVmgJsQAa4%2BOExkw%40mail.gmail.com