Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?

On 06.04.24 19:47, Daniel Gustafsson wrote:
> In bumping we want to move to 1.1.1 since that's the first version with the
> rewritten RNG which is fork-safe by design, something PostgreSQL clearly
> benefits from.

I think it might be better to separate this into two steps:

1. Move to 1.1.0. This is an API update. Change OPENSSL_API_COMPAT,
and remove a bunch of code that no longer needs to be conditional. We
could check for a representative function like OPENSSL_init_ssl() in
configure/meson, or we could just let the compilation fail with older
versions.

2. Move to 1.1.1. I understand this has to do with the fork-safety of
pg_strong_random(), and it's not an API change but a behavior change.
Let's make this association clearer in the code. For example, add a
version check or assertion about this into pg_strong_random() itself.

I don't know how LibreSSL interacts with either of these two points.
That's something that could be clearer.

Some more detailed review on the v6 patch:

* doc/src/sgml/libpq.sgml

This small documentation patch could be committed forthwith.

* src/backend/libpq/be-secure-openssl.c

+#include <openssl/bn.h>

This patch doesn't appear to add anything, so why does it need a new
include?

Could the additions of SSL_OP_NO_CLIENT_RENEGOTIATION and
SSL_R_VERSION_TOO_LOW be separate patches?

* src/common/hmac_openssl.c

There appears to be some unrelated refactoring happening here?

* src/include/common/openssl.h

Is the comment no longer applicable to OpenSSL, only to LibreSSL?

* src/port/pg_strong_random.c

I would prefer to remove pg_strong_random_init() if it's no longer
useful. I mean, if we leave it as is, and we are not removing any
callers, then we are effectively continuing to support OpenSSL <1.1.1,
right?