Re: [PATCH] Avoid mixing custom and OpenSSL BIO functions

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: David Benjamin <davidben(at)google(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Peter Eisentraut <peter(at)eisentraut(dot)org>
Subject: Re: [PATCH] Avoid mixing custom and OpenSSL BIO functions
Date: 2024-11-29 19:57:43
Message-ID: 37DB2E05-503D-49EA-8B17-7B31C92F09AD@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 29 Nov 2024, at 19:36, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> David Benjamin <davidben(at)google(dot)com> writes:
>> Thanks! I got asked about release branches, so I thought I'd pass it along:
>> how do you all handle merges to release branches and would it make sense to
>> merge this change? On the one hand, nothing is actively on fire yet, but
>> the current setup does risk breakage if OpenSSL ever migrates BIO_s_socket
>> to their new size_t-clean internals.
>
> We theoretically could back-patch 6f782a2a1, as it doesn't appear to
> introduce any ABI-breaking changes. (The new field in struct Port
> could be an issue, but it looks like it fits into what was padding
> space, so probably fine.) However, I'm not sure that it's attractive
> to do so from a risk/benefit standpoint. That code's received only
> minimal testing so far, and the problem it's fixing is as yet
> hypothetical.
>
> On balance I think I'd vote against a back-patch now. We could
> reconsider next year once PG v18 has gotten a reasonable amount of
> beta testing.

I agree with all of the above.

--
Daniel Gustafsson

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2024-11-29 20:17:54 Re: UUID v7
Previous Message Marcos Pegoraro 2024-11-29 19:46:54 Re: UUID v7