> On 7 May 2025, at 06:34, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Thomas Munro <thomas.munro@gmail.com> writes:
>> On Wed, May 7, 2025 at 1:18 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Anyone know anything about where to submit LibreSSL bugs?
>
>> I think it's done with sendbug on an OpenBSD box, or perhaps you can
>> just write a normal email to the bugs@openbsd.org or
>> libressl@openbsd.org list, based on:
>> https://www.openbsd.org/mail.html
Bugs are frequently reported, and dealt with, on the libressl mailing list.
> Thanks, I'll look into reporting it tomorrow. In the meantime,
> I couldn't help noticing that the backtraces went through
> lib/libssl/tls13_legacy.c, which doesn't give a warm feeling
> about how supported they think our usage is (and perhaps also
> explains why they didn't detect this bug themselves). This is
> evidently because we set up the SSL context with SSLv23_method(),
> per this comment in be_tls_init():
>
> * We use SSLv23_method() because it can negotiate use of the highest
> * mutually supported protocol version, while alternatives like
> * TLSv1_2_method() permit only one specific version. Note that we don't
> * actually allow SSL v2 or v3, only TLS protocols (see below).
>
> This choice seems to be more than 20 years old, though the above
> comment defending it dates only to 2014. I wonder if it's time to
> revisit that idea.
The use of SSLv23_method() comes from us supporting 1.0.2, the replacement
TLS_method() was introduced in 1.1.0 and SSLv23_method() was turned into an
alias of TLS_method() in OpenSSL commit 32ec41539b5.
Since we no longer support 1.0.2 we can apply something like the (lightly
tested) attached which should be a no-op as we already use TLS_method() but via
an alias.
There's likely more OpenSSL code we can modernize, hopefully we can make some
progress on that during the v19 cycle.
--
Daniel Gustafsson
