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-04-01 14:07:34
Message-ID: d0d13dca-1f4b-0043-8b0c-651525abb84e@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 31.03.22 20:15, Jacob Champion wrote:
> On Thu, 2022-03-31 at 16:32 +0200, Peter Eisentraut wrote:
>> Why add a (failry complicated) pg_inet_pton() when a perfectly
>> reasonable inet_pton() exists?
>
> I think it was mostly just that inet_aton() and pg_inet_net_ntop() both
> had ports, and I figured I might as well port the other one since we
> already had the implementation. (I don't have a good intuition yet for
> the community's preference for port vs dependency.)
>
>> I would get rid of all that refactoring and just have your code call
>> inet_pton()/inet_ntop() directly.
>>
>> If you're worried about portability, and you don't want to go through
>> the effort of proving libpgport substitutes, just have your code raise
>> an error in the "#else" code paths. We can fill that in later if there
>> is demand.
>
> Switched to inet_pton() in v12, with no #if/else for now. I think this
> should work with Winsock as-is; let's see if the bot agrees...

I have committed this.

I have removed the inet header refactoring that you had. That wasn't
necessary, since pg_inet_net_ntop() can use the normal AF_INET*
constants. The PGSQL_AF_INET* constants are only for the internal
storage of the inet/cidr types.

I have added a configure test for inet_pton(). We can check in the
build farm if it turns out to be necessary.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2022-04-01 14:09:55 Re: psql - add SHOW_ALL_RESULTS option
Previous Message Tom Lane 2022-04-01 13:59:01 Re: [PATCH] src/interfaces/libpq/Makefile: fix pkg-config without openssl