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
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 |