Re: SSL tests fail on OpenSSL v3.2.0

On Mon Nov 27, 2023 at 6:21 PM CST, Tom Lane wrote:
> Michael Paquier <michael(at)paquier(dot)xyz> writes:
> > Interesting. I have yet to look at that in details, but
> > BIO_get_app_data() exists down to 0.9.8, which is the oldest version
> > we need to support for stable branches. So that looks like a safe
> > bet.
>
> What about LibreSSL? In general, I'm not too pleased with just assuming
> that BIO_get_app_data exists. If we can do that, we can probably remove
> most of the OpenSSL function probes that configure.ac has today. Even
> if that's a good idea in HEAD, I doubt we want to do it all the way back.

As Bo said, this has been available since before LibreSSL forked off of
OpenSSL.

> I'd be inclined to form the patch more along the lines of
> s/BIO_get_data/BIO_get_app_data/g, with a configure check for
> BIO_get_app_data and falling back to the existing direct use of
> bio->ptr if it's not there.

Falling back to what existed before is invalid. BIO::ptr is private data
for the BIO implementation. BIO_{get,set}_app_data() does
something completely different than setting BIO::ptr. In Postgres we
call BIO_meth_set_create() with BIO_meth_get_create() from
BIO_s_socket(). The create function we pass allocates bi->ptr to
a struct bss_sock_st * as previously stated, and that's been the case
since March 10, 2022[0]. Essentially Postgres only worked because the
BIO implementation didn't use the private data section until the linked
commit. I don't see any reason to keep compatibility with what only
worked by accident.

[0]: https://github.com/openssl/openssl/commit/a3e53d56831adb60d6875297b3339a4251f735d2

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