Re: [PATCH] Accept IP addresses in server certificate SANs

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Jacob Champion <pchampion(at)vmware(dot)com>, "daniel(at)yesql(dot)se" <daniel(at)yesql(dot)se>, "tgl(at)sss(dot)pgh(dot)pa(dot)us" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "stark(at)mit(dot)edu" <stark(at)mit(dot)edu>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "horikyota(dot)ntt(at)gmail(dot)com" <horikyota(dot)ntt(at)gmail(dot)com>
Subject: Re: [PATCH] Accept IP addresses in server certificate SANs
Date: 2022-03-30 11:37:31
Message-ID: b2f8b8e9-1c9a-57b2-0c8f-1f3c7fbdb5e2@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2022-03-30 11:43:54 Re: SSL/TLS instead of SSL in docs
Previous Message Ivan Panchenko 2022-03-30 11:21:28 Re[2]: On login trigger: take three