On Fri, Jun 23, 2023 at 10:41:06PM +0200, Peter Eisentraut wrote:
> Considering that, yes.
Thanks, applied to 11~13, then.
--
Michael
signature.asc
Description: PGP signature
On 23.06.23 00:22, Michael Paquier wrote:
Also, note that the documentation claims that the minimum version of
OpenSSL supported is 0.9.8, which is something that commit 9b7cd59 has
done, impacting Postgres 10~. So your argument looks incorrect to me?
Considering that, yes.
On Thu, Jun 22, 2023 at 08:08:54PM +0200, Peter Eisentraut wrote:
> The message linked to above also says:
>
>> I'm not sure. I don't have a good sense of what OpenSSL versions we
>> claim to support in branches older than PG13. We made a conscious
>> decision for 1.0.1 in PG13, but I seem to re
On 22.06.23 01:53, Michael Paquier wrote:
Looking at the relevant thread from 2020, this was still at the point
where we did not consider supporting 3.0 for all the stable branches
because 3.0 was in alpha:
https://www.postgresql.org/message-id/3d4afcfc-0930-1389-b9f7-59bdf11fb...@2ndquadrant.com
On Thu, Jun 22, 2023 at 10:02:58AM +0200, Daniel Gustafsson wrote:
> These patches LGTM from reading,
Thanks for double-checking.
> but I think the Discussion link in the commit
> messages should refer to this thread as well.
Of course.
--
Michael
signature.asc
Description: PGP signature
> On 22 Jun 2023, at 01:53, Michael Paquier wrote:
> I have tested the attached patches across 11~13 with various versions
> of OpenSSL (OPENSSL_API_COMPAT exists since 1.1.0), and this is
> working here. Note that I don't have a MSVC environment at hand to
> test this change on Windows, still `
On Wed, Jun 21, 2023 at 10:11:33AM +0200, Peter Eisentraut wrote:
> Backpatching the OPENSSL_API_COMPAT change would set the minimum OpenSSL
> version to 1.0.1, which is newer than what was so far required in those
> branches. That is the reason we didn't do this.
Looking at the relevant thread f
Hi,
On 2023-06-21 10:11:33 +0200, Peter Eisentraut wrote:
> On 21.06.23 09:43, Michael Paquier wrote:
> > On Wed, Jun 21, 2023 at 09:16:38AM +0200, Daniel Gustafsson wrote:
> > > Agreed, I'd be more inclined to go with OPENSSL_API_COMPAT. If we still
> > > get
> > > warnings with that set then I
On 21.06.23 09:43, Michael Paquier wrote:
On Wed, Jun 21, 2023 at 09:16:38AM +0200, Daniel Gustafsson wrote:
Agreed, I'd be more inclined to go with OPENSSL_API_COMPAT. If we still get
warnings with that set then I feel those warrant special consideration rather
than a blanket suppression.
4d
On Wed, Jun 21, 2023 at 09:16:38AM +0200, Daniel Gustafsson wrote:
> Agreed, I'd be more inclined to go with OPENSSL_API_COMPAT. If we still get
> warnings with that set then I feel those warrant special consideration rather
> than a blanket suppression.
4d3db136 seems to be OK on REL_13_STABLE w
> On 21 Jun 2023, at 07:44, Andres Freund wrote:
> On 2023-06-21 11:53:44 +0900, Michael Paquier wrote:
>> I have been annoyed by these in the past when doing backpatches, as
>> this creates some noise, and the only place where this counts is
>> sha2_openssl.c. Thoughts about doing something lik
Hi,
On 2023-06-21 11:53:44 +0900, Michael Paquier wrote:
> Compiling Postgres up to 13 with OpenSSL 3.0 leads to a couple of
> compilation warnings with what OpenSSL considers as deprecated, like:
> sha2_openssl.c: In function pg_sha384_init
> sha2_openssl.c:70:9: warning: SHA384_Init is deprecate
Hi all,
(adding Daniel in CC.)
Compiling Postgres up to 13 with OpenSSL 3.0 leads to a couple of
compilation warnings with what OpenSSL considers as deprecated, like:
sha2_openssl.c: In function pg_sha384_init
sha2_openssl.c:70:9: warning: SHA384_Init is deprecated =
Since OpenSSL 3.0 [-Wdeprecate
13 matches
Mail list logo
