Re: OpenSSL 3.0.0 compatibility

Поиск
Список
Период
Сортировка
От Daniel Gustafsson
Тема Re: OpenSSL 3.0.0 compatibility
Дата
Msg-id 42147C0A-3119-4F49-AF30-01DB71A0637A@yesql.se
обсуждение исходный текст
Ответ на Re: OpenSSL 3.0.0 compatibility  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы Re: OpenSSL 3.0.0 compatibility
Re: OpenSSL 3.0.0 compatibility
Список pgsql-hackers
> On 22 Sep 2020, at 11:37, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
>
> On 2020-09-18 16:11, Daniel Gustafsson wrote:
>> Since we support ciphers that are now deprecated, we have no other choice than
>> to load the legacy provider.
>
> Well, we could just have deprecated ciphers fail, unless the user loads the legacy provider in the OS configuration.
Theremight be an argument that that is more proper. 

Thats a fair point.  The issue I have with that is that we'd impose a system
wide loading of the legacy provider, impacting other consumers of libssl as
well.

> As a more extreme analogy, what if OpenSSL remove a cipher from the legacy provider?  Are we then obliged to
reimplementit manually for the purpose of pgcrypto?  Probably not. 

I don't think we have made any such guarantees of support, especially since
it's in contrib/. That doesn't mean that some users wont expect it though.

Another option would be to follow OpenSSL's deprecations and mark these ciphers
as deprecated such that we can remove them in case they indeed get removed from
libcypto.  That would give users a heads-up that they should have a migration
plan for if that time comes.

> The code you wrote to load the necessary providers is small enough that I think it's fine, but it's worth pondering
thisquestion briefly. 

Absolutely.

cheers ./daniel


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

Предыдущее
От: Daniel Gustafsson
Дата:
Сообщение: Re: Lift line-length limit for pg_service.conf
Следующее
От: Konstantin Knizhnik
Дата:
Сообщение: Re: Asynchronous Append on postgres_fdw nodes.