Re: SSL tests fail on OpenSSL v3.2.0

Tristan Partin <tristan@neon.tech>

From: "Tristan Partin" <tristan@neon.tech>
To: "Tom Lane" <tgl@sss.pgh.pa.us>, "Daniel Gustafsson" <daniel@yesql.se>
Cc: "Bo Anderson" <mail@boanderson.me>, "Michael Paquier" <michael@paquier.xyz>, "Nazir Bilal Yavuz" <byavuz81@gmail.com>, "Andres Freund" <andres@anarazel.de>, "PostgreSQL Hackers" <pgsql-hackers@postgresql.org>
Date: 2023-11-29T16:48:23Z
Lists: pgsql-hackers
On Wed Nov 29, 2023 at 10:32 AM CST, Tom Lane wrote:
> Daniel Gustafsson <daniel@yesql.se> writes:
> > On 29 Nov 2023, at 16:21, Tristan Partin <tristan@neon.tech> wrote:
> >> Funnily enough, here[0] is BoringSSL adding the BIO_{get,set}_app_data() APIs.
>
> > Still doesn't seem like a good candidate for a postgres TLS library since they
> > themselves claim:
> >    "Although BoringSSL is an open source project, it is not intended for
> >     general use, as OpenSSL is.  We don't recommend that third parties depend
> >     upon it.  Doing so is likely to be frustrating because there are no
> >     guarantees of API or ABI stability."
>
> Kind of odd that, with that mission statement, they are adding
> BIO_{get,set}_app_data on the justification that OpenSSL has it
> and Postgres is starting to use it.  Nonetheless, that commit
> also seems to prove the point about lack of API/ABI stability.
>
> I'm content to take their advice and not try to support BoringSSL.
> It's not clear what benefit to us there would be, and we already
> have our hands full coping with all the different OpenSSL and LibreSSL
> versions.

Yep, I just wanted to point it out in the interest of relevancy to our 
conversation yesterday :).

-- 
Tristan Partin
Neon (https://neon.tech)



Commits

  1. Use BIO_{get,set}_app_data instead of BIO_{get,set}_data.