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 d0d13dca-1f4b-0043-8b0c-651525abb84e@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
List 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.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH] src/interfaces/libpq/Makefile: fix pkg-config without openssl
Next
From: Peter Eisentraut
Date:
Subject: Re: psql - add SHOW_ALL_RESULTS option