fix: two guards that could not fail — an empty OIDC secret, and a KEX pin that never pinned (ASVS 11.6.2)

[wshallwshall]

Wave-0 corrections — two guards that could not fail, and the documents that believed them

Three commits, two unrelated defects, one register entry. Neither defect moves the ASVS headline count;
both change whether it can be defended.

---

1 · fix(auth) — an EMPTY oidc_client_secret is a MISSING one

The guard that makes a missing OIDC client secret fail at config load read:

if self.oidc_client_secret is None and self.oidc_client_secret_ref is None:

That is not the shape a missing secret usually takes. MEFOR_AUTH_OIDC_CLIENT_SECRET= in a service
wrapper — or an NSSM environment entry with an empty value — yields "", and "" is not None.

Reproduced before the fix, with a working control so the repro proves something:

MEFOR_AUTH_OIDC_CLIENT_SECRET	before
client-s3cret	accepted (control)
""	accepted, oidc_client_secret == ''
" "	accepted
absent	refused

Only the absent case fired. The missing list ten lines above in the same validator already uses
if not value for all five pinned endpoints — this one line was the only place in the validator that
disagreed with its own siblings, which is why it read as correct.

Severity, stated accurately: this is not an auth bypass. An empty client_secret reaches the IdP at
the token exchange and is rejected there, so the effect is a federated login that is broken instead of
refused — diagnosed from a proxy log rather than a startup message. The defect is that a fail-at-load
guard silently became a fail-at-first-login one.

Whitespace is stripped for the emptiness test only; a secret with meaningful surrounding whitespace
still binds byte-for-byte (asserted). The same test now covers oidc_client_secret_ref, or an empty ref
would satisfy "one of the two is set" while naming no provider entry.

Mutations: restore is None → red (4 failed). Make the guard reject every secret → red on the
positive control. The second is the one that matters — without it, both refusal tests stay green under
a guard that refuses everything, and "a raise happened" is not the claim being made.

---

2 · fix(tls) — the approved KEX groups were never pinned (ASVS 11.6.2)

harden_kex_groups pins via SSLContext.set_groups "where available (Python 3.13+)".
set_groups is a Python 3.15 API — typeshed guards it at sys.version_info >= (3, 15), alongside
the get_groups that will finally make the pin assertable. Measured here: Python 3.14.6 / OpenSSL
3.5.7, hasattr(ctx, "set_groups") is False, so APPROVED_KEX_GROUPS reaches zero of its six call
sites.

That much was suspected. This was not — real handshakes against the actual build_api_ssl_context,
identical at tls_min_version 1.2 and 1.3:

client pinned to one group	result
X25519, secp384r1, prime256v1	accepted (positive controls)
ffdhe2048	ACCEPTED
ffdhe3072	ACCEPTED
secp521r1	ACCEPTED
secp224r1	refused — NO_SUITABLE_GROUPS
sect571r1	refused — NO_SUITABLE_GROUPS

ADR 0092 §4(b) asserts the opposite: "a real handshake test proves a client offering only a
non-approved FFDHE group is refused — runtime enforcement". That test reached its assertion only through
a client-side set_groups, so it hit pytest.skip on every interpreter this project runs on. A skip
was concealing a false assertion, and the ADR cited it as proof — worse than an untested claim, because it
reads as evidence.

Method, stated because the probe could have lied too. The client pins one group via set_ecdh_curve,
which was validated as a genuine constraint first: a server pinned to prime256v1 refuses a client
pinned to secp384r1 (NO_SUITABLE_KEY_SHARE) while the unpinned-server control accepts it. Without that
step, a probe that constrained nothing would have reported "everything accepted" for a context that was in
fact restrictive — the two answers look identical.

Severity, bounded. The inherited list is forward-secret, so the property the TLS 1.2+ floor guarantees
still holds, and the genuinely weak curves are refused. This is a conformance gap against an internal
allow-list — wider than policy, not weak. 11.6.2 is Partial and stays Partial.

What changes in code

harden_kex_groups now returns the list it actually pinned (None today). A control that cannot
report whether it did anything reports success forever — that is how a call at six sites with zero effect
survived three assessments. The failure path returns None too: previously a pin that raised logged a
warning and then fell off the end, so a caller could not distinguish "pinned" from "tried and failed". Its
# pragma: no cover is gone, because a stand-in context now drives that branch.

The three tests standing over this asserted (a) the call does not raise, (b) it no-ops without the API,
(c) a string constant has three names. All three pass identically whether or not a group is ever pinned.
Replaced with an unconditional receipt whose failure message is the re-derivation instruction — an
if hasattr(...) branch here would restore exactly the property being removed. The skipping handshake
test is replaced by one that measures the accepted set and cannot skip, asserted as invariants rather
than an exact table (the set comes from the linked OpenSSL and a CI leg may differ): every approved group
must get in, and some non-approved group must get in.

Five mutations, both directions:

	mutation	expected
M1	report a pin never made	inertness receipt red
M2	revert to the old no-return shape	reporting test red
M3	failed pin reports the list	raising test red
M4	probe accepts everything	measurement red
M5	probe refuses everything	measurement red

M2 is why it needs its own test: under M2 the inertness test stays green (measured rc=0),
because a function with no return also yields None. assert pinned is None therefore proves nothing
about the reporting.

Swept the siblings, because "is anything else inert?" deserves a measurement, not a claim.
tls_policy.py has exactly three getattr-guarded best-effort sites; all three were driven here:

site	verdict
set_groups (harden_kex_groups)	INERT — the subject of this PR
VERIFY_X509_STRICT (harden_verify_flags)	LIVE — present (32), flag verifiably ORed in (32768 → 32800)
_hashlib.get_fips_mode (fips_attestation)	LIVE — returns False, not None (None = undeterminable = a vacuous attestation)

Documents corrected, because the claim had spread to five

• config/tls_policy.py — the "3.13+" docstring and the module summary.
• docs/PHI.md §4 — bullet rewritten; the section marker changed from [BUILT — WP-L3-10 code half] to
  [PARTIAL — the 1.2+ floor and the cipher validator are enforced; the group pin is INERT until Python 3.15].
• docs/ASVS-L2-PHASE0-CHANGES.md — the same sentence, the same error.
• docs/adr/0092 §4(b) — struck through in place and withdrawn by a dated amendment naming all three
  wrong assertions. The ADR's decision is unaffected (its forward-secrecy dependency is the TLS 1.2+
  floor, which is enforced); §4(a) and §4(c) were re-confirmed and stand.
• docs/BACKLOG.md — the "runtime-KEX enforcement … handshake-tested" clause inside a shipped banner.
  Prose-only; banner invariant untouched, test_backlog_status_check.py green.

Deliberately not touched: docs/security/ASVS-L3-ASSESSMENT.md and the other dated assessments carry
the same claim and say on their face "Retained unmodified for diffing and audit history." The
scorecard-of-record and register corrections are vaulted (docs/security/ is git-ignored here).

Deliberately not built, and it is an option rather than an oversight: set_ecdh_curve exists and
genuinely pins, but takes exactly one curve name — it cannot express a preference list, and pinning
through it would refuse two of the three approved groups. A [tls] single-curve knob is a real hardening
option with a real interop bill (an MLLP client pinned to X25519 refuses a P-256-only server — a realistic
shape for older Java/.NET interface engines). Shipping it as though it closed 11.6.2 would be the lenient
reading this project has already retracted twice.

---

3 · docs(adr-0034) — record the CodeQL dismissal from PR #53

py/insecure-protocol, HIGH, messagefoundry/config/tls_probe.py, dismissed won't fix on the repo.
The rule is factually right and does not apply: the probe offers TLS 1.0/1.1 because a successful
handshake at a withdrawn version is the finding it exists to produce. The GitHub dismissal comment is
capped at 280 characters, so ADR 0034 is where the argument has to live. Includes the convergence note —
the anchor is tls_probe.py:146, so this will re-fire as a new alert number on any line drift above
it; re-dismiss with the recorded rationale rather than re-triaging.

---

Verification

ruff check · ruff format --check (976 files) · mypy --strict (257 modules) · full suite on the
pre-rebase tree 9614 passed, 719 skipped; targeted re-run after rebasing onto the merged main
343 passed.

The one failure in the full run is the known environmental test_installed_metadata_matches_dunder_version
— the editable install's metadata (0.3.0) vs __version__ (0.3.2); the test's own comment names the
case and the remedy. CI installs fresh.