Thread: OpenSSL deprectation warnings in Postgres 10-13
Collegues! I've tried to build all supported versions of PostgresSQL in the Ubuntu 22.04 which is soon to be released. 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. In 2020 it probably haven't be a problem, as OpenSSL 3.0.0 was in alpha stage, but this month first mainline Linux distribution which uses openssl 3.0.x is going to be released. It seems that we need to backpatch this commit into all supported versions of PostgreSQL, because there are more and more distributions switched to OpenSSL 3.0.x. Apart from Ubuntu I can see at least RH 9 beta and experimental packages for Debian which probably would be ready in time for Debian 12. -- Victor Wagner <vitus@wagner.pp.ru>
> On 6 Apr 2022, at 11:55, Victor Wagner <vitus@wagner.pp.ru> wrote: > I've tried to build all supported versions of PostgresSQL in the Ubuntu > 22.04 which is soon to be released. > > And found out that versions 10-13 produce a lot of warnings about > deprecated OpenSSL functions. Thanks for testing. Does it cause any issues other than compiler warnings? -- Daniel Gustafsson https://vmware.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.
В 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>
>> 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. But as stated above, there is no set of supported versions defined so there is definitive value we can set for OPENSSL_API_COMPAT in the backbranches. > 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). That wouldn't help for 10-13 since that's a change unlikely to be back ported into a stable release. -- Daniel Gustafsson https://vmware.com/
On 06.04.22 16:02, Victor Wagner wrote: >> 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. I meant compile with -Wno-deprecated.