Feedback-ID: i131946ab:Fastmail
Message-ID: <3224e5c6-5385-c33c-b024-f002fdeec21e@enterprisedb.com>
Date: Fri, 24 Jun 2022 13:11:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.10.0
Subject: Re: BUG #17522: While using --with-ssl=openssl and
 PG_TEST_EXTRA='ssl' options, SSL test fails on OpenBSD 7.1
Content-Language: en-US
To: Michael Paquier <michael@paquier.xyz>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jacob Champion <jchampion@timescale.com>,
 Kyotaro Horiguchi <horikyota.ntt@gmail.com>, byavuz81@gmail.com,
 pgsql-bugs@lists.postgresql.org
References: <dc372104-a17d-a2de-bd6a-d9b5b3c7a829@enterprisedb.com>
 <20220621.092753.452165241922345774.horikyota.ntt@gmail.com>
 <CAAWbhmjffOGEqKa2F0hzz+pm8sYTgcda5PVjNGMDzykv4nZzhg@mail.gmail.com>
 <CAAWbhmiTjZnFVLPrVprCmV7HQcG+r3cJqj2zP80sfLNkCsCROg@mail.gmail.com>
 <CAAWbhmiTezhY+9z9gidpWZ9Y7Wpms5COS0A2a2ongJj_0+1wRg@mail.gmail.com>
 <3091666.1655846153@sss.pgh.pa.us>
 <CAAWbhmha67e+=zMmZoTKzb6UxGQGorUzq9-E+cDhffXkDVcB3A@mail.gmail.com>
 <3515417.1655914607@sss.pgh.pa.us>
 <CAAWbhmjdPS7A76gUXVPis8Zhmztk3c3Gbe94bUyqK-Qu=0utMA@mail.gmail.com>
 <3523929.1655915505@sss.pgh.pa.us> <YrQBYI2YOQmqm/tY@paquier.xyz>
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
In-Reply-To: <YrQBYI2YOQmqm/tY@paquier.xyz>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/3224e5c6-5385-c33c-b024-f002fdeec21e%40enterprisedb.com>
Precedence: bulk

On 23.06.22 08:00, Michael Paquier wrote:
> On Wed, Jun 22, 2022 at 12:31:45PM -0400, Tom Lane wrote:
>> Jacob Champion <jchampion@timescale.com> writes:
>>> Moving from lax to strict validation means plenty
>>> of IETF spec reading to make sure we don't throw away useful hostnames
>>> by accident.
>>
>> True.  I'd be content to disallow '/' and move on.
> 
> It does not seem like this is strictly forbidden, either.  This set of
> rules would be RFC 1035, section 2.3, I guess:
> https://datatracker.ietf.org/doc/html/rfc1035
> 
>> Or we could just drop this test case.
> 
> I'd be fine with that.  Disabling the SNI, as proposed upthread, would
> also be fine.

I have proceeded with removing the test.