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

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?
Дата
Msg-id ZHFkwZKYcgq0zk37@paquier.xyz
обсуждение исходный текст
Ответ на Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?  (Jacob Champion <jchampion@timescale.com>)
Ответы Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?  (Daniel Gustafsson <daniel@yesql.se>)
Список pgsql-hackers
On Fri, May 26, 2023 at 09:10:17AM -0700, Jacob Champion wrote:
> Can X509_get_signature_nid be moved to the required section up above?
> As it is now, anyone configuring with -Dssl=auto can still pick up a
> 1.0.1 build, which Meson accepts, and then the build fails downstream.
> If we require the function instead, Meson will ignore 1.0.1 (or, for
> -Dssl=openssl, complain before we compile).

Yes, I was wondering a bit if something more should be marked as
required, but just saw more value in removing all references to this
function.  Making the build fail straight when setting up things is OK
by me, but I am not convinced that X509_get_signature_nid() would be
the right choice for the job, as it is an OpenSSL artifact originally,
AFAIK.

The same problem exists with OpenSSL 1.0.0 on HEAD when building with
meson?  CRYPTO_new_ex_data() and SSL_new() exist there.

> t/001_ssltests.pl has a reference to 1.0.1 that can probably be
> entirely deleted:
>
>     # ... (Nor for OpenSSL
>     # 1.0.1, but that's old enough that accommodating it isn't worth the cost.)

Not touching that is intentional.  It sounded useful to me as an
historic reference for LibreSSL ;)
--
Michael

Вложения

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

Предыдущее
От: vignesh C
Дата:
Сообщение: Re: Implement generalized sub routine find_in_log for tap test
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: Implement generalized sub routine find_in_log for tap test