Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nZWe4-0005tZ-Ft for pgsql-hackers@arkaria.postgresql.org; Wed, 30 Mar 2022 11:37:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nZWe1-0007Kz-Bk for pgsql-hackers@arkaria.postgresql.org; Wed, 30 Mar 2022 11:37:45 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nZWe0-0007Ko-Ba for pgsql-hackers@lists.postgresql.org; Wed, 30 Mar 2022 11:37:45 +0000 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nZWds-0007XG-QJ for pgsql-hackers@postgresql.org; Wed, 30 Mar 2022 11:37:42 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id F00983201D51; Wed, 30 Mar 2022 07:37:34 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Wed, 30 Mar 2022 07:37:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=ILPSQ93TIHY5v0aE844p31SmT3/+eJ9bQk3EcMLAl Fc=; b=Jo5j7FQMbHR8pk9NbNoHJ1wjNfks2mSILY232ovfrwxOKTOHoc06bQFye E5RZDPFXORW6YDBc8mLrs5kB14+4Pwjt//9vq4UaIoy7WeLoaF6hUUqqf5Uep94q XPov7SClRfkQLhXjv9AjWSgq+h0Pqd7aYwP6V46NayCGy3jWzADL5Qe8OCNrbnS1 ccv5ty9RqWbGjyX2r6ra88voniprDfUPv7jOGlykTD/tRtyvT6qmCsb9wMfuyVNl BIK2Cnf25aecaULr9mGFOVQjuWoEcU+xSFO/GM/gpa5RoOAWHciInaFXbAptdAiL gBSVVNMNR7H5ydU0Gr5sQ0ICfz1dA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudeivddggeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvfhfhjggtgfesthejredttdefjeenucfhrhhomheprfgvthgv rhcugfhishgvnhhtrhgruhhtuceophgvthgvrhdrvghishgvnhhtrhgruhhtsegvnhhtvg hrphhrihhsvggusgdrtghomheqnecuggftrfgrthhtvghrnhepfeejgeehteeuhfevvedu leeufedtjeetiefftedvudfhtdeifefgueettdevgefgnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepphgvthgvrhdrvghishgvnhhtrhgruhht segvnhhtvghrphhrihhsvggusgdrtghomh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 30 Mar 2022 07:37:33 -0400 (EDT) Message-ID: Date: Wed, 30 Mar 2022 13:37:31 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH] Accept IP addresses in server certificate SANs Content-Language: en-US To: Jacob Champion , "daniel@yesql.se" , "tgl@sss.pgh.pa.us" Cc: "stark@mit.edu" , "pgsql-hackers@postgresql.org" , "horikyota.ntt@gmail.com" References: <20220318.163857.1357392368287571138.horikyota.ntt@gmail.com> <20220322.133202.1699013732440256188.horikyota.ntt@gmail.com> <5878cc4f261dfac70999be7c10d80e898449e388.camel@vmware.com> <20220323.142007.1816604521514641243.horikyota.ntt@gmail.com> <2da38935f528904f62dd5846767dc53585d8a309.camel@vmware.com> <552429.1648415967@sss.pgh.pa.us> <3F1A8748-DEF8-454C-B7ED-F536CCF7F115@yesql.se> <5EA8D400-9705-463C-B30F-E7A78EE5C8FB@yesql.se> <27dd89aa5bd8fac8fdfdbd33dd460422bcb77d6b.camel@vmware.com> From: Peter Eisentraut In-Reply-To: <27dd89aa5bd8fac8fdfdbd33dd460422bcb77d6b.camel@vmware.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 28.03.22 22:21, Jacob Champion wrote: > On Mon, 2022-03-28 at 11:17 +0200, Daniel Gustafsson wrote: >> Fixing up the switch_server_cert() calls and using default_ssl_connstr makes >> the test pass for me. The required fixes are in the supplied 0004 diff, I kept >> them separate to allow the original author to incorporate them without having >> to dig them out to see what changed (named to match the git format-patch output >> since I think the CFBot just applies the patches in alphabetical order). > > Thanks! Those changes look good to me; I've folded them into v11. This > is rebased on a newer HEAD so it should fix the apply failures that > Greg pointed out. I'm not happy about how inet_net_pton.o is repurposed here. That code is clearly meant to support backend data types with specifically. Code like + /* + * pg_inet_net_pton() will accept CIDR masks, which we don't want to + * match, so skip the comparison if the host string contains a slash. + */ indicates that we are fighting against the API. Also, if someone ever wants to change how those backend data types work, we then have to check a bunch of other code as well. I think we should be using inet_ntop()/inet_pton() directly here. We can throw substitute implementations into libpgport if necessary, that's not so difficult.