Re: Removal of support for OpenSSL 0.9.8 and 1.0.0

Поиск
Список
Период
Сортировка
От Daniel Gustafsson
Тема Re: Removal of support for OpenSSL 0.9.8 and 1.0.0
Дата
Msg-id A2B74FEB-2FEB-48CE-BE31-78CDD8298A3C@yesql.se
обсуждение исходный текст
Ответ на Removal of support for OpenSSL 0.9.8 and 1.0.0  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Removal of support for OpenSSL 0.9.8 and 1.0.0  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> On 5 Dec 2019, at 09:32, Michael Paquier <michael@paquier.xyz> wrote:

> From the point of view of the code, the cleanup is not actually that
> amazing I am afraid, a jump directly to 1.1.0 would remove much more
> because the breakages were wider when we integrated it.  Anyway, those
> cleanups are part of 0003.  I thought that this would have resulted in
> more cleanup :(

While expected, it's still disappointing.  Until we can drop 1.0.2 there isn't
too much to gain, and that will likely be reasonably far into the future given
that it's the final version that can run the FIPS module.

> I think that 0001 is a fix we need to do

+1

> 0002 is debatable still LibreSSL should support it and we fail to detect
> SSL_clear_options properly,


LibreSSL has SSL_clear_options in all versions, as does OpenSSL even at the
level of support we have as of now.  The only issue with 0002 is support for
older NetBSD releases, as is documented in the comment and commit message.

NetBSD 5.x shipped a custom OpenSSL identified as 0.9.9, which is a version of
their own invention.  NetBSD 6.0 (which shipped in October 2012) ships 1.0.1u,
which has SSL_clear_options as well as SSL_OP_NO_COMPRESSION.  So, this patch
is not really debateable if we are dropping support for 0.9.8 and 1.0.0.

opossum is the only animal in the buildfarm on NetBSD 5, and it has been silent
for close to a year now (coypu is on NetBSD 8).  Requiring opossum to build
without OpenSSL (if/when) it comes back seems a reasonable ask.  NetBSD 5.x has
been EOL for quite some time too.

+1 on applying this instead of trying to fix the autoconf check.

> 0003 does not really much additional value.  Or we put
> into the balance for 0003 the argument that we can use TLSv1.2 for all
> configurations, which is safer but we have the configuration to
> enforce it.

I think the TLSv1.2 argument is the most compelling one, the changes are a wash
in terms of code maintainability.  Raising the minimum supported version
doesn't really have any downsides though, and should be quite uncontroversial
(and as noted in the other thread, prariedog and gaur are ready for the change
so buildfarm breakage should be limited to an animal that doesnt build
anymore). Overall, +1.

cheers ./daniel


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

Предыдущее
От: Neha Sharma
Дата:
Сообщение: [EUC_CN] Failed to connect through user created user/database usingsimplified Chinese characters
Следующее
От: Sergei Kornilov
Дата:
Сообщение: Re: Sketch of a fix for that truncation data corruption issue