В Wed, 6 Apr 2022 15:01:42 +0200
Peter Eisentraut <peter.eisentraut@enterprisedb.com> пишет:
> On 06.04.22 11:55, Victor Wagner wrote:
> > And found out that versions 10-13 produce a lot of warnings about
> > deprecated OpenSSL functions.
> >
> > I've found discussion about this problem
> >
> > https://www.postgresql.org/message-id/flat/FEF81714-D479-4512-839B-C769D2605F8A%40yesql.se
> >
> > and commit 4d3db13621be64fbac2faf which fixes problem in the 14
> > version and above. (it seems to me that declaring wish to use
> > outdated API is ugly workaround, but anyway it works)
> >
> > But this commit seems not to be backpatched to versions 13-10.
>
> As was discussed in that thread, we don't actually have precise
> knowledge of what OpenSSL versions we support in versions before
> PG13. So backpatching this could alter or break things that worked
> before.
>
> It seems easier to just disable deprecation warnings if you don't
> want to see them.
>
As far as my understanding goes, "just disable deprication warning" it
is what commit 4d3db13621be64fbac2faf does.
Real fix would be rewrite corresponding parts of code so they wouldn't
use deprecated API. (as it was done with sha2 code in PostgreSQL 14.
which doesn't use openssl version of sha2 at all).
It is quite simple to rewrite digest code to use generic EVP API, but a
bit more complicated with DH parameters, because if EVP API appeared in
0.9.x series and we can rely on it in any version of OpenSSL,
non-deprecated replacement for PEM_read_DHparams is 3.0 only. So we
have to keep 1.1.x compatible version for a while until all major
distribution would change to 3.x.
Really I think that PostgreSQL does something wrong with TLS if it need
to use deprecated functions in be-secure-openssl.c. But it might be
that just OpenSSL team was to slow to catch up new things in the
transport security world, so application (including PostgreSQL) have to
work around it and use too low-level functions, which are now
deprecated.
--
Victor Wagner <vitus@wagner.pp.ru>
