Re: OpenSSL 3.0.0 compatibility

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: OpenSSL 3.0.0 compatibility
Date: 2020-09-22 12:01:18
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> On 22 Sep 2020, at 11:37, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)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. There might 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

> As a more extreme analogy, what if OpenSSL remove a cipher from the legacy provider? Are we then obliged to reimplement it 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 this question briefly.


cheers ./daniel

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Konstantin Knizhnik 2020-09-22 12:52:33 Re: Asynchronous Append on postgres_fdw nodes.
Previous Message Daniel Gustafsson 2020-09-22 11:50:11 Re: Lift line-length limit for pg_service.conf