Summary
Proxied (SSH-tunneled) Postgres connections can't currently do verified TLS. buildProxiedPostgresConnection (packages/server/src/service/connection.ts:939) builds the PooledPostgresConnection pointing at the local tunnel endpoint (127.0.0.1:<localport>) and passes no ssl, so the pg driver verifies the certificate against 127.0.0.1 rather than the real DB host — meaning tunneled TLS is limited to no-verify (encrypt, don't verify).
Fix
Upstream malloydata/malloy#2968 (merged 2026-07-08) adds an ssl passthrough to @malloydata/db-postgres. Once it's available here, set ssl on the proxied connection:
new PooledPostgresConnection({
name,
host: endpoint.host, // loopback IP → pg keeps servername (survives the DNS-host overwrite)
port: endpoint.port,
username: pg.userName,
password: pg.password,
databaseName: pg.databaseName,
ssl: { servername: <real DB host from pg config>, ca: <trusted CA if not in the default store>, rejectUnauthorized: true },
poolMin: 1,
poolMax: 20,
});
Because endpoint.host is the loopback IP, pg keeps our servername (it only overwrites servername with host for DNS-name hosts), so verification runs against the real DB hostname through the tunnel.
Dependency: malloy suite bump to 0.0.423+
- The
ssl field is on main but not yet released — latest published @malloydata/* is 0.0.422 (cut before the merge). It'll ship in the next release (~0.0.423).
- Publisher pins 14
@malloydata/* packages at ^0.0.415 and they move in lockstep, so picking this up means bumping the whole suite 0.0.415 → 0.0.423 (~35 package-touching commits across core/render/dialects, not just db-postgres). Do this ssl wiring as part of / after that suite upgrade, with a full build + test pass. (@malloydata/malloy-explorer is separately pinned and can stay.)
Notes
- An interim shim (subclassing
PooledPostgresConnection to inject ssl against the current 0.0.415 pin) was considered and declined — not needed short-term, and the suite upgrade is required regardless.
- Docs for the new property: malloydata/malloydata.github.io#327.
Acceptance
- A proxied Postgres connection through the tunnel verifies the real server certificate (via
servername + trust store / ca); a wrong servername/cert fails to connect.
- Connections with
ssl unset behave exactly as today.
Summary
Proxied (SSH-tunneled) Postgres connections can't currently do verified TLS.
buildProxiedPostgresConnection(packages/server/src/service/connection.ts:939) builds thePooledPostgresConnectionpointing at the local tunnel endpoint (127.0.0.1:<localport>) and passes nossl, so the pg driver verifies the certificate against127.0.0.1rather than the real DB host — meaning tunneled TLS is limited tono-verify(encrypt, don't verify).Fix
Upstream malloydata/malloy#2968 (merged 2026-07-08) adds an
sslpassthrough to@malloydata/db-postgres. Once it's available here, setsslon the proxied connection:Because
endpoint.hostis the loopback IP, pg keeps ourservername(it only overwritesservernamewithhostfor DNS-name hosts), so verification runs against the real DB hostname through the tunnel.Dependency: malloy suite bump to
0.0.423+sslfield is onmainbut not yet released — latest published@malloydata/*is0.0.422(cut before the merge). It'll ship in the next release (~0.0.423).@malloydata/*packages at^0.0.415and they move in lockstep, so picking this up means bumping the whole suite0.0.415 → 0.0.423(~35 package-touching commits across core/render/dialects, not just db-postgres). Do thissslwiring as part of / after that suite upgrade, with a full build + test pass. (@malloydata/malloy-exploreris separately pinned and can stay.)Notes
PooledPostgresConnectionto injectsslagainst the current0.0.415pin) was considered and declined — not needed short-term, and the suite upgrade is required regardless.Acceptance
servername+ trust store /ca); a wrongservername/cert fails to connect.sslunset behave exactly as today.