fix: ssl_mode=require/verify-ca/verify-full silently allows plaintext

[aesslinger]

Summary

build_pool never called cfg.ssl_mode(...) on the deadpool_postgres::Config. Left as None, the underlying tokio_postgres::Config defaults to SslMode::Prefer (confirmed in tokio-postgres-0.7.18/src/config.rs:255) — negotiate TLS if offered, silently accept plaintext otherwise. So ssl_mode=require/verify-ca/verify-full built the right rustls verifier (that's what #35/#37/#40 fixed) but never actually enforced TLS at the protocol level.

This is security-relevant, not just a correctness bug: a user opting into "TLS or nothing" got an unencrypted connection with no error if the server couldn't/wouldn't negotiate TLS.

Fixes #43.

Discovery context

Found during a post-merge sanity pass on main after #35/#37/#40/#41/#42 landed. Confirmed via git log/git show that this predates all six recently-merged PRs — present since client.rs was first staged in #3, not a regression from any of them.

Fix

Added resolve_ssl_mode, mapping this plugin's ssl_mode strings to deadpool_postgres::SslMode, matching the builtin driver's build_postgres_configurations (src-tauri/src/pool_manager.rs) mapping exactly:

• disable → Disable
• allow/prefer → Prefer (no behavior change — already tokio_postgres's default)
• require/verify-ca/verify-full → Require (the actual fix)
• unset/unknown → unmapped (no behavior change)

Wired into build_pool right after cfg.manager = Some(...).

Testing — exact local setup and results against a real SSL-enabled server

Automated tests only prove the mapping function is correct and that the bug reproduces against a non-SSL server. To be sure the fix doesn't break real TLS connections, I stood up a second local instance with actual TLS enabled and drove the built binary against it directly, alongside the existing non-SSL fixture.

Setup (both via Podman, run locally, not part of the repo or CI):

• Port 54320: plain postgres:16, no SSL — matches CI's live-db-integration fixture exactly.
• Port 55432: fresh postgres:16 with a real self-signed cert generated via openssl req -x509 -newkey rsa:2048, ssl = on set in postgresql.conf, restarted, confirmed via SHOW ssl; → on.

Manual repro against the built binary, piping raw JSON-RPC requests into ./target/debug/postgresql-plugin, run against the fix (current code):

ssl_mode	Target	Expected	Actual result
disable	non-SSL (54320)	connects (plaintext)	{"id":1,"jsonrpc":"2.0","result":null} ✅
unset	non-SSL (54320)	connects (default Prefer, unchanged)	{"id":1,"jsonrpc":"2.0","result":null} ✅
prefer	SSL-on (55432)	connects (opportunistic TLS)	{"id":1,"jsonrpc":"2.0","result":null} ✅
require	non-SSL (54320)	fails — this is the fix	{"error":{"code":-32603,"message":"Connection failed: ... error performing TLS handshake"},...} ✅
require	SSL-on (55432)	connects (real TLS handshake succeeds)	{"error":{"code":-32603,"message":"... error performing TLS handshake"}} ❌ — see "Related finding" below

Before/after on the actual bug (require against the non-SSL server) — done via the automated live-DB test, not a second manual binary run: temporarily commented out the one new line (cfg.ssl_mode = resolve_ssl_mode(...)) in client.rs, rebuilt, ran the new test — confirmed ssl_mode_require_fails_against_a_server_without_tls fails against that reverted code (connects over plaintext, matching the original bug). Restored the line, rebuilt, confirmed the test passes.

Automated tests:

• Unit tests (resolve_ssl_mode_* in client_tests.rs): every mapping case, written first and confirmed failing to compile before the function existed.
• Live-DB regression test (ssl_mode_require_fails_against_a_server_without_tls in tests/live_db.rs): runs against CI's real postgres:16 fixture (no SSL). Confirmed Red before the fix, Green after (see above).

Related finding, filed separately (explains the one row above that didn't pass)

Row 5 above (require against the real SSL-enabled server) failed with a TLS handshake error — expected to succeed, since require should accept any cert without validating it. Root-caused: build_tls_connector's needs_cert_validation check only matches verify-ca/verify-full, so require falls through to the final with_platform_verifier() branch, which does validate against the OS trust store — contradicting the function's own doc comment ("require forces TLS without certificate validation") and the builtin's actual behavior (NoCertVerifier, no validation at all for require). Confirmed via git show 9986b1e that this predates every PR from this session, including this one — a second, distinct, pre-existing bug (different root cause: cert validation vs. protocol-level enforcement) found only because I tested this fix against a real TLS server rather than stopping at the non-SSL repro. Filed as #44, intentionally out of scope here.

Test plan

• cargo test --lib --bins — 111/111 pass (107 previous + 4 new)
• cargo test --test live_db (against a live non-SSL PostgreSQL 16 instance) — 8/8 pass, including the new regression test, verified Red-then-Green against a temporarily reverted client.rs
• Manual repro against real non-SSL and real self-signed-cert SSL-enabled PostgreSQL instances (exact commands/results above)
• cargo clippy --all-targets -- -D warnings — clean
• cargo fmt --all -- --check — clean
• cargo build --release — clean
• npx markdownlint CHANGELOG.md — clean

[github-actions]

Version suggestion

Based on this PR's title (fix) and the prerelease:beta label:

Current	1.0.0-beta.7
Suggested next tag	v1.0.0-beta.8

This is informational only — no tag or release is created automatically yet.