Re: [PATCH] Accept IP addresses in server certificate SANs - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [PATCH] Accept IP addresses in server certificate SANs
Date
Msg-id b2f8b8e9-1c9a-57b2-0c8f-1f3c7fbdb5e2@enterprisedb.com
Whole thread Raw
In response to Re: [PATCH] Accept IP addresses in server certificate SANs  (Jacob Champion <pchampion@vmware.com>)
Responses Re: [PATCH] Accept IP addresses in server certificate SANs  (Jacob Champion <pchampion@vmware.com>)
List pgsql-hackers
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.



pgsql-hackers by date:

Previous
From: Ivan Panchenko
Date:
Subject: Re[2]: On login trigger: take three
Next
From: Daniel Gustafsson
Date:
Subject: Re: SSL/TLS instead of SSL in docs