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

Поиск
Список
Период
Сортировка
От Daniel Gustafsson
Тема Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?
Дата
Msg-id EEB816C4-0902-47BA-AF3E-B51EC5ED9557@yesql.se
обсуждение исходный текст
Ответ на Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?  (Peter Eisentraut <peter@eisentraut.org>)
Ответы Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?  (Jacob Champion <jacob.champion@enterprisedb.com>)
Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?  (Peter Eisentraut <peter@eisentraut.org>)
Список pgsql-hackers
> On 5 Apr 2024, at 23:26, Peter Eisentraut <peter@eisentraut.org> wrote:
>
> On 05.04.24 18:59, Daniel Gustafsson wrote:
>> Attached is a WIP patch to get more eyes on it, the Meson test for 1.1.1 fails
>> on Windows in CI which I will investigate next.
>
> I'm not a fan of the new PGAC_CHECK_OPENSSL.  It creates a second place where the OpenSSL version number has to be
updated. We had this carefully constructed so that there is only one place that OPENSSL_API_COMPAT is defined and that
isthe only place that needs to be updated.  We put the setting of OPENSSL_API_COMPAT into configure so that the
subsequentOpenSSL tests would use it, and if the API number higher than what the library supports, the tests should
fail.

But does that actually work?  If I change the API_COMPAT to the 1.1.1 version
number and run configure against 1.0.2 it passes just fine.  Am I missing some
clever trick here?

The reason to expand the check is to ensure that we have the version we want
for both OpenSSL and LibreSSL, and deprecating OpenSSL versions isn't all that
commonly done so having to change the version in the check didn't seem that
invasive to me.

--
Daniel Gustafsson




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?
Следующее
От: Jacob Champion
Дата:
Сообщение: Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?