Re: Direct SSL connection and ALPN loose ends
Heikki Linnakangas <hlinnaka@iki.fi>
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Michael Paquier <michael@paquier.xyz>
Cc: Jacob Champion <jacob.champion@enterprisedb.com>,
Peter Eisentraut <peter@eisentraut.org>, Robert Haas
<robertmhaas@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-07-23T17:32:29Z
Lists: pgsql-hackers
Attachments
- v2-0001-Fix-fallback-behavior-when-server-sends-an-ERROR-.patch (text/x-patch) patch v2-0001
- v2-0002-Add-test-for-early-backend-startup-errors.patch (text/x-patch) patch v2-0002
- v2-0003-Add-tests-for-errors-during-SSL-or-GSSAPI-handsha.patch (text/x-patch) patch v2-0003
On 16/07/2024 09:54, Michael Paquier wrote:
> On Mon, Jun 24, 2024 at 11:30:53PM +0300, Heikki Linnakangas wrote:
>> 0002: This is the main patch that fixes the SSL fallback issue
>
> + conn->failed_enc_methods |= conn->allowed_enc_methods &
> (~conn->current_enc_method);
>
> Sounds reasonable to me.
>
> It's a bit annoying to have to guess that current_enc_method is
> tracking only one method at a time (aka these three fields are not
> documented in libpq-int.h), while allowed_enc_methods and
> failed_enc_methods is a bitwise combination of the methods that are
> still allowed or that have already failed.
Yeah. In hindsight I'm still not very happy with the code structure with
"allowed_enc_methods" and "current_enc_methods" and all that. The
fallback logic is still complicated. It's better than in v16, IMHO, but
still not great. This patch seems like the best fix for v17, but I
wouldn't mind another round of refactoring for v18, if anyone's got some
good ideas on how to structure it better. All these new tests are a
great asset when refactoring this again.
> + if (IsInjectionPointAttached("backend-initialize-v2-error"))
> + {
> + FrontendProtocol = PG_PROTOCOL(2,0);
> + elog(FATAL, "protocol version 2 error triggered");
> + }
>
> This is an attempt to do stack manipulation with an injection point
> set. FrontendProtocol is a global variable, so you could have a new
> callback setting up this global variable directly, then FATAL (I
> really don't mind is modules/injection_points finishes with a library
> of callbacks).
>
> Not sure to like much this new IsInjectionPointAttached() that does a
> search in the existing injection point pool, though. This leads to
> more code footprint in the core backend, and I'm trying to minimize
> that. Not everybody agrees with this view, I'd guess, which is also
> fine.
Yeah, I'm also not too excited about the additional code in the backend,
but I'm also not excited about writing another test C module just for
this. I'm inclined to commit this as it is, but we can certainly revisit
this later, since it's just test code.
Here's a new rebased version with some minor cleanup. Notably, I added
docs for the new IS_INJECTION_POINT_ATTACHED() macro.
--
Heikki Linnakangas
Neon (https://neon.tech)
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Add tests for errors during SSL or GSSAPI handshake
- ef7fa900fb58 18.0 landed
-
Add test for early backend startup errors
- 20e0e7da9bc0 18.0 landed
-
Fix fallback behavior when server sends an ERROR early at startup
- f06a632a77ed 17.0 landed
- c95d2159c1dd 18.0 landed
-
Fix outdated comment after removal of direct SSL fallback
- 5afebbe529ab 17.0 landed
- cc68ca6d420e 18.0 landed