Managed role provisioning sends SCRAM-SHA-256 verifiers, never a password, and only when one changes (#3910)

[erikdarlingdata]

Closes #3910.

CHANGELOG: this PR carries no CHANGELOG edit. Its entry lands with the batched splice.

Why

Managed role provisioning sent every role's plaintext password on every service start: CREATE ROLE ... PASSWORD '<pw>' inside the guard's DO block, then ALTER ROLE admin/viewer/mcp LOGIN NOSUPERUSER PASSWORD '<pw>'. Any surface that records statement text could capture the live credentials of all three login roles.

The concrete path: an unmarked role with the same name (an operator-created mcp, say) makes the DO block raise on every start. The default log_min_error_statement = error then writes STATEMENT: and the whole batch, all three passwords included, to the store's own log. The store-log sweep kept that for 400 days, and the viewer role reads it through get_store_log. #3899's track_utility = off and #3920's log masking each close one surface. This fix removes the plaintext at the source.

What changes

• ScramSha256Verifier computes PostgreSQL's SCRAM-SHA-256 verifier client-side: PBKDF2-HMAC-SHA-256 plus the RFC 5802/7677 keys, a 16-byte random salt, and 4096 iterations. PostgreSQL stores a string already in that format as-is, which is what psql's \password does. The password never appears in any statement. A leaked verifier is not a login: the passwords are 32 random alphanumerics.
• BuildProvisioningSql takes verifiers and refuses anything else, a plain password first of all. That is where "never the password" is enforced, not just hoped for; the verifier's shape admits no quote, so the interpolation stays escaping-safe.
• Steady state sends no PASSWORD clause. EnsureProvisionedAsync reads pg_authid.rolpassword (it is the superuser owner) and re-asserts a role's password only when the stored verifier no longer accepts the credential file. That happens for a missing role, an MD5 hash from an older store, or a regenerated file. The CREATE branch still carries a fresh verifier, for a role that does not exist yet. The start log says which roles were re-asserted.
• Docs: the README's managed-provisioning paragraph; provision-roles.sql, which now recommends a verifier or psql's \password so a BYO store's passwords stay out of every statement too; and the Field stores cannot tell us which query is slow: preload pg_stat_statements in the managed store and surface it by role #3899 comments that said provisioning sends passwords every start.

Test plan

• RFC 7677's worked exchange: ServerSignature over the RFC's own AuthMessage matches v=, and the server's client check (SHA-256 of ClientProof XOR ClientSignature equals StoredKey) holds for the derived keys.
• The verifier round-trips and a fresh salt is used each time. Non-verifiers (MD5, plaintext, a truncated verifier, one carrying a quote, iterations 0) verify nothing.
• The builder refuses seven non-verifier shapes, carries only verifiers of the generated passwords (never the passwords), and re-asserts only the roles it is told. The re-assert plan is pinned for a stored match, a different password, MD5, and a missing role.
• Live on the bundled runtime (DARLING_TEST_PGRUNTIME), the real EnsureProvisionedAsync on a migrated cluster:
  • our verifier logs in and a wrong password is refused;
  • a verifier PostgreSQL computed itself verifies here;
  • the unmarked-role failure path's log carries verifiers and none of the three passwords;
  • every role logs in with its credential file;
  • a second start re-asserts nothing and leaves the stored verifiers byte-identical.
• Full Darling.Tests (12,503) and Lite.Tests (5,124) after rebasing onto The store's statement text and store log keep no literal: a one-pass SQL lexer, an allowlist reader, masking for every retained log class, and stricter conf parsing (#3899) #3920 and Store-object convergence re-runs hourly on a plain-PostgreSQL store too, not only at restart (#3913) #3932. The only Darling failures are the three runtime-version pins my local rig (18.4) can't meet against dev's 18.6 pin. The one Lite failure was the known AnalysisPassTokenThreadingTests flake, which passes on re-run; this PR touches no Lite code.
• After merge: DARLING01's first start with this build logs "Role passwords: unchanged" (its PostgreSQL-computed verifiers already accept the credential files), and the Viewer, the web dashboard and MCP still log in.

🤖 Generated with Claude Code

https://claude.ai/code/session_018Z4T51J4E6L8fjriPHpsif