Re: [PATCH] Accept IP addresses in server certificate SANs
От | Jacob Champion |
---|---|
Тема | Re: [PATCH] Accept IP addresses in server certificate SANs |
Дата | |
Msg-id | 26dd7e4b482832323e38ba6f08e3651b5c2c5817.camel@vmware.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Accept IP addresses in server certificate SANs (Peter Eisentraut <peter.eisentraut@enterprisedb.com>) |
Ответы |
Re: [PATCH] Accept IP addresses in server certificate SANs
|
Список | pgsql-hackers |
On Wed, 2022-03-30 at 13:37 +0200, Peter Eisentraut wrote: > 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. Horiguchi-san had the same concern upthread, I think. I replaced that code in the next patch, but it was enough net-new stuff that I kept the patches separate instead of merging them. I can change that if it's not helpful for review. > 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. Is this request satisfied by the implementation of pg_inet_pton() in patch 0003? If not, what needs to change? Thanks, --Jacob
В списке pgsql-hackers по дате отправления: