Re: OpenSSL 3.0.0 compatibility - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: OpenSSL 3.0.0 compatibility
Date
Msg-id 42147C0A-3119-4F49-AF30-01DB71A0637A@yesql.se
Whole thread Raw
In response to Re: OpenSSL 3.0.0 compatibility  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: OpenSSL 3.0.0 compatibility
Re: OpenSSL 3.0.0 compatibility
List 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 by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Lift line-length limit for pg_service.conf
Next
From: Konstantin Knizhnik
Date:
Subject: Re: Asynchronous Append on postgres_fdw nodes.