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

From: Jacob Champion <pchampion(at)vmware(dot)com>
To: "horikyota(dot)ntt(at)gmail(dot)com" <horikyota(dot)ntt(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Accept IP addresses in server certificate SANs
Date: 2022-02-04 17:06:53
Message-ID: 870040c8f3c6a07acf2ae9d295d0c55f003d81bb.camel@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 2022-02-03 at 16:23 +0900, Kyotaro Horiguchi wrote:
> At Wed, 2 Feb 2022 19:46:13 +0000, Jacob Champion <pchampion(at)vmware(dot)com> wrote in
> > On Mon, 2022-01-31 at 17:29 +0900, Kyotaro Horiguchi wrote:
> > > +#define PGSQL_AF_INET (AF_INET + 0)
> > > +#define PGSQL_AF_INET6 (AF_INET + 1)
> > > +
> > >
> > > Now we have the same definition thrice in frontend code. Coulnd't we
> > > define them in, say, libpq-fe.h or inet-fe.h (nonexistent) then
> > > include it from the three files?
> >
> > I started down the inet-fe.h route, and then realized I didn't know
> > where that should go. Does it need to be included in (or part of)
> > port.h? And should it be installed as part of the logic in
> > src/include/Makefile?
>
> I don't think it should be a part of port.h. Though I suggested
> frontend-only header file by the name, isn't it enough to separate out
> the definitions from utils/inet.h to common/inet-common.h then include
> the inet-common.h from inet.h?

That works a lot better than what I had in my head. Done that way in
v4. Thanks!

--Jacob

Attachment Content-Type Size
v4-0001-Move-inet_net_pton-to-src-port.patch text/x-patch 4.5 KB
v4-0002-libpq-allow-IP-address-SANs-in-server-certs.patch text/x-patch 42.1 KB
v4-0003-squash-libpq-allow-IP-address-SANs-in-server-cert.patch text/x-patch 6.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Sharma 2022-02-04 17:51:24 Re: Synchronizing slots from primary to standby
Previous Message John Naylor 2022-02-04 16:39:12 Re: Stats collector's idx_blks_hit value is highly misleading in practice