Skip to content

fix(warning): exempt the status probe from the plaintext warning - #176

Merged
cayossarian merged 1 commit into
mainfrom
fix/status-probe-warning
Sep 1, 2026
Merged

fix(warning): exempt the status probe from the plaintext warning#176
cayossarian merged 1 commit into
mainfrom
fix/status-probe-warning

Conversation

@cayossarian

Copy link
Copy Markdown
Member

What

Exempts /api/v2/status from the plaintext-transport warning, version 3.4.1. This closes the residue of SpanPanel/span#264: a panel that merely advertises itself on the network produced the credential-naming warning once per boot when discovery probed it — against a device nobody has configured, where no pin can exist because trust-on-first-use has not happened, and where the only available action is configuring the panel, whose flow pins before any credential moves. It is the line that led an operator to remove a healthy emulator.

Slot mechanics

The probe fires first in every flow, so under the old behavior it spent the once-per-host warning slot — a genuinely credential-bearing plaintext call behind it then said nothing. The exemption returns before the host is marked, the same property the CA download's 3.4.0 exemption has, so the warning migrates to whichever call actually deserves it. Registration, passphrase rotation, the FQDN calls (which carry a bearer token), and the schema fetch warn exactly as before.

Limits, stated in the docstrings rather than implied

  • The status body informs decisions — proximityProven, the serial an identity check reads — and a plaintext answer is one anything on the path can write. The controls for that are the panel's own registration gate and the pin a consumer's flow acquires, not a log line.
  • A consumer can probe a configured, pinned host's status without its context, and no warning will say so anymore — so a consumer owes every probe of a configured host the entry's own transport. (The HA integration's one such probe, the Supervisor-discovery host check, is being moved onto the entry's pin in security(rest): ride the pinned CA at runtime, and fail closed with repairs span#265.)

Verification

1216 passed / 7 skipped, ruff and mypy clean, coverage 96%. Three new tests, each observed failing first: the status probe never warns, the detection probe never warns, and a midpoint-asserted slot test proving the warning now belongs to the credential-bearing call. Reviewed adversarially at high effort; the review's factual findings (docstring over-claims, a one-way constant pointer) are folded in, and its two integration-side observations are addressed in span#265.

The status endpoint is the detection probe — most prominently the request
zeroconf discovery makes against a device nobody has configured, once per
boot, where no pin can exist because trust-on-first-use has not happened and
the only action available is configuring the panel, whose flow pins before
any credential moves. Warning on it named credentials the call never
carries, for an action nobody could take; it is the line that made an
operator remove a healthy emulator (SpanPanel/span#264's residue).

The probe also no longer spends the once-per-host slot. It fires first in
every flow, so it previously claimed the warning that a genuinely
credential-bearing plaintext call behind it deserved — the same
slot-squatting the CA download's 3.4.0 exemption fixed. Registration,
passphrase rotation, the FQDN calls and the schema fetch warn exactly as
before.

The exemption's limits are stated rather than implied: the status body
informs decisions — proximityProven, the serial an identity check reads —
whose controls are the panel's own registration gate and the pin a
consumer's flow acquires, not a log line; and a consumer probing a
configured host owes that probe the entry's own transport, because no
warning will say so anymore.
@cayossarian
cayossarian merged commit af76532 into main Sep 1, 2026
6 checks passed
@cayossarian
cayossarian deleted the fix/status-probe-warning branch September 1, 2026 04:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant