Fix BMC token-extract fail-open: jq -r '.token // empty' makes a missing token an empty file reported Converged (gunbc.host_effect_realize realize_bmcweb_token_extract_body); sweep the jq -e class

[gunbai-bot]

The defect

gunbc.host_effect_realize realize_bmcweb_token_extract_body ran:

jq -r '.token // empty' <login response>

jq's // alternative makes an absent or null .token a run that prints nothing and exits 0. The fold read jq_run.success, took its success arm, wrote jq_run.stdout — the empty string — to srv3_bmcweb_token_path, and then reconciled on the write's success. So a rejected or malformed BMC login produced an empty credential file reported as Converged: DESIGN §5's fabricated plausible output, at a credential seam.

Ten sibling jq call sites do the same job with -er. The -e was missing at exactly the one site handling a credential.

The fix — the verdict exists before the write

• bmcweb_token_extract_jq_args passes -e. That is jq's documented contract for "absence must be loud": exit 1 when the last output is null/false, exit 4 when the filter produced no output.
• bmcweb_token_extraction_verdict folds (success, stdout) into BmcwebTokenExtracted { token: NonEmptyStr } | BmcwebTokenExtractRefused { reason }, and blank stdout refuses too.
• Only the BmcwebTokenExtracted arm reaches Filesystem.Write. An empty credential file is now unreachable, not detected afterwards.

The post-hoc shell.Test.IsNonEmpty in gunbc.srv3_os_install_actuate srv3_bmcweb_login is deleted with the climb (§4b dissolution-on-climb, production handling only). It read the file this fold had just written — validation standing where construction was available — and a converged extract can no longer have written an empty one.

Executed evidence, both directions

The pure argv + verdict functions were extracted carrying the pre-fix semantics first, the witnesses were run against that tree, and only then was the fix applied. Every row below is an observed gunbc run verdict, not a prediction.

witness (test.claim.srv3_host_effect_apply_witness)	pre-fix	post-fix
witness_bmcweb_token_extract_argv_demands_a_value	false	true
witness_bmcweb_token_extract_absent_token_refuses_typed	false	true
witness_bmcweb_token_extract_blank_token_refuses_typed	false	true
witness_bmcweb_token_extract_present_token_extracts_trimmed	false	true
witness_bmcweb_token_extract_jq_nonzero_refuses_typed	true	true (positive control)

Neighbours re-run green post-fix: witness_bmcweb_token_extract_ssh_transport_refuses_typed, witness_bmcweb_session_login_argv_uses_curl_authority_not_serialize_bash, witness_srv3_receipt_emit_apply_converges_in_process, plus bmc_fan_converge_witness_test and srv3_os_install_actuate_witness_test entries covering the two touched extdeps modules.

Class census — CORRECTED

A correction first, because the original census was wrong. I reported three sites of one class and claimed two of them had no consumers. openbmc.JsonProjection.SensorIntegerValue has two live consumers in extdeps.bmc.openbmc_fan_control (openbmc_sensor_value, openbmc_sensor_threshold_result). My probe was a grep whose zero result I accepted without a control that must hit. Caught by sharp-ant-396 (argv-migration lane), verified by read, and both extdeps edits are now withdrawn.

The real finding is one site, gunbc.host_effect_realize realize_bmcweb_token_extract_body — the defect above.

Withdrawn, with reasons:

• openbmc.JsonProjection.SensorIntegerValue — not a fail-open at all. openbmc_sensor_integer_projection_result already decodes empty stdout to OpenBmcSensorValueAbsent, a distinct third state beside Refused and Observed. Absence is modeled, not read as a value. Adding -e would have collapsed Absent into Refused on a live sensor path — a state-space collapse, the opposite of the repair I called it.
• extdeps.tools.jq jq.Json.ExtractRaw — genuinely consumer-free, but -e is still wrong here: it sets exit status from the last output and returns 1 on false or null, which are legitimate values of an arbitrary filter. That changes the operation's contract rather than hardening it. "Exactly one nonempty string" is a decode over the observation, not a flag.

Judged clean, unchanged (unaffected by the correction): ProjectFanConfig (raises jq error()), the ten -er extraction ops in openbmc_password_ssh_transport and openbmc_fan_control, the jq empty JSON-validity probe, the jq -e boolean equality probe, and gunbc.roadmap_provider_events codex_provider_event_projection_filter.

What -e is and is not doing at the credential site

-e stays in bmcweb_token_extract_jq_args, where a token is required to be a nonempty string and false/null is never a legitimate answer. But the wall is bmcweb_token_extraction_verdict, not the flag:

• -e still exits zero on an empty string, which this seam must refuse — so the blank arm is load-bearing and the flag is defence in depth.
• Consequently the fail-open is closed even if the argv regressed to // empty: jq would exit 0 with empty stdout, and the blank arm refuses.

The argv witness therefore asserts the filter carries no absence-swallowing alternative — the defect exactly as found — and no longer pins the -e spelling, which the argv-migration lane will delete when it replaces these flattened argv arrays.

Notes

• Independent of Stand up Spark serving end to end: model materialization, unit observation, and the credential-bound privilege bootstrap #8377; branched from current main.
• main is red repo-wide (witnesses check, ~469 failing on main itself). Nothing here touches that population — the change is five .dag files, and every witness in its own closure was executed green above.
• Citations are module + symbol per DESIGN §3; no file:line.

🤖 Generated with Claude Code

[gunbai-bot]

CI red at 564073f is pre-existing on main, measured by difference

witnesses fails, but failed=0. The whole red comes from the BUDGET-REFUSED class, and that class is byte-identical to main's own run.

	main @ 59653f5 (run 32177951514)	this PR @ 564073f (run 32180692108)
planned / executed / terminal	9420	9425
passed	8951	8956
failed	0	0
known_red_held	367	367
stale_quarantine	5	5
budget_refused	102	102

The two deltas are the same number, and it is mine: +5 planned, +5 passed — exactly the five witnesses this PR adds. Nothing moved into failed, known_red_held, stale_quarantine, or budget_refused.

Rosters compared at identity grain, not by count: comm -13 over the sorted BUDGET-REFUSED <module>.<fn> rows from both runs is empty — no row is refused on this branch that is not already refused on main. Same for the five STALE-QUARANTINE rows (all in dissolution_census, extdeps_scope_placement_gate_loudness, root_d_checkpoint_scalar_declared_arity, and rust_test_fixtures_import_closure; none in a module this PR touches).

The refusals themselves are the known shape — wall/cpu overruns of 1–4 ms against a 1552 ms ceiling (cost at least 1553ms against 1552ms) in v2.test.execution.pick_ingested_*, v2.test.claim.identity_captured_navigation.roster_gate, and v2.test.claim.live_read_classification_test, plus one 22 s row in v2.test.manual.grounding_lens_whole_tree. None of them is in this PR's resolve closure.

So there is nothing here for me to fix, and I am not going to touch the budget rows: shaving someone else's 1 ms overrun to turn this check green would quiet the signal that makes the real problem rank, and the refusal is correct — those rows genuinely went undecided.

The earlier red at d656ce0 was mine (a source annotation inside a declaration body, §4c) and is fixed in 564073f; strict preparation now passes and the fold runs to completion.

— sent from eager-wren-138

🤖 Generated with Claude Code

[gunbai-bot]

Small addition to the record, since review 53532 scoped its verification to the .dag surface: I swept the non-.dag surface too (*.rs, *.yml, *.yaml, *.sh, *.md), with a control to confirm the probe could hit.

There are no jq invocations in workflows, Rust, or shell — .github/**/*.yml has none at all. The only occurrence outside .dag is one line in docs/runbooks/srv3-nbd-proxy-ws-upgrade-dry-run.md, which carries the identical incantation:

| jq -r '.token // empty'

I am deliberately not changing it. It is a hand-run operator procedure, and unlike the .dag site it is not defective: the token stays in a shell variable and the very next line is test -n "$TOKEN" || { echo "FAIL: no session token from /login"; exit 1; }, so absence stops the procedure rather than propagating. The post-hoc check that was wrong in the realization — because there it stood downstream of a file write that had already happened — is the correct shape here, where nothing has been committed to disk and the guard gates the next step.

So the whole-repo population of this defect is one site, and it is the one this PR fixes.

— sent from eager-wren-138

🤖 Generated with Claude Code

[gunbai-bot]

Receipt re-measured at the current head, since both this PR and main have moved since my earlier comment. Conclusion is unchanged.

	main @ 2c65eea (run 32184548531)	this PR @ 459b816 (run 32185219206)
planned / executed	9421	9426
passed	8952	8957
failed	0	0
known_red_held / stale_quarantine / budget_refused	367 / 5 / 102	367 / 5 / 102

Delta is again exactly +5 planned, +5 passed — this PR's five witnesses, all green. comm -13 over the sorted refused rows is empty for both BUDGET-REFUSED (103/103) and STALE-QUARANTINE (5/5): nothing is refused here that is not already refused on main.

failed=0 on both sides. The witnesses check cannot go green on this branch because it does not go green on main either, and no change to this PR can alter that.

— sent from eager-wren-138

🤖 Generated with Claude Code