fix(cli): honor --db-url sslmode - #5980
Conversation
|
@codex review |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3cfb4d401b
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 070775c56f
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
|
@codex review |
|
Codex Review: Didn't find any major issues. What shall we delve into next? Reviewed commit: ℹ️ About Codex in GitHubCodex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback". |
## TL;DR `--debug` silently disabled TLS on every database connection ## Problem `debug.SetupPGX` nulled `config.TLSConfig` so its wirelogging proxy could read plaintext frames. It runs after sslmode resolution, so `--debug` overrode an explicit `?sslmode=require` with no warning, sent the session unencrypted, and failed with `no pg_hba.conf entry ... no encryption` on SSL-enforcing projects that worked fine without the flag. Still live on the TS shell: which forwards `--debug` to the Go binary for `migration squash`, `db test`, `db remote commit|changes` and bootstrap's push step. ## Sol: The proxy now does libpq's SSLRequest handshake itself with the `tls.Config` pgx resolved, then hands pgx an in-memory pipe. It has to own TLS because `DialFunc` sits below it, which is why the original just nulled it. Frames decrypt in process, the socket stays encrypted, verification is unchanged, and a refusal fails the dial instead of continuing in plaintext.... Also drops the now false `SSL connection is not supported with --debug flag` hint from both shells. It was never true in TS, where `--debug` has never disabled TLS. ## Ref - Fixes supabase#5872 - Related supabase#5873 via supabase#5980
2 participants
TL;DR
sslmodefrom--db-urlnever reached the connectionPGSSLMODEand libpq'spreferdefault decided TLS instead....Problem
pgconn.ParseConfigfoldssslmodeintoTLSConfig/Fallbacks, butToPostgresURLserialises onlyRuntimeParams, soConnectByConfigStream's round-trip drops it.--db-url?sslmode=require+PGSSLMODE=disable?sslmode=disable?sslmode=verify-fullvs untrusted certSolution
Replay the TLS state pgconn already resolved instead of round-tripping it through a string. Code-assembled configs (local, linked, proxy) have a nil
Fallbacksslice, whichParseConfignever produces, so they keep libpq's defaults.TS already behaves this way; this brings the go-cli to parity for the commands still routed thru it...
Ref