Re: OpenSSL 3.0.0 compatibility

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: OpenSSL 3.0.0 compatibility
Date: 2020-09-23 08:44:20
Message-ID: 32C71A5F-E335-41E7-BBB0-3D74147C3DB6@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 23 Sep 2020, at 10:19, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Tue, Sep 22, 2020 at 02:01:18PM +0200, Daniel Gustafsson wrote:
>> 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.
>
> Does that mean a deprecation note in the docs as well as a WARNING
> when attempting to use those ciphers in pgcryto with the version of
> OpenSSL marking such ciphers as deprecated? I would assume that we
> should do both, rather than only one of them to bring more visibility
> to the user.

We generally don't issue WARNINGs for deprecated functionality do we? The only
one I can see is for GLOBAL TEMPORARY in temp table creation. The relevant
errcode ERRCODE_WARNING_DEPRECATED_FEATURE is also not used anywhere.

I'd expect it to just be a note in the documentation, with a prominent
placement in the release notes, if we decide to do something like this.

cheers ./daniel

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Nancarrow 2020-09-23 08:50:22 Re: Parallel INSERT (INTO ... SELECT ...)
Previous Message Michael Paquier 2020-09-23 08:19:55 Re: OpenSSL 3.0.0 compatibility