Files
ruvnet--RuView/v2/crates/wifi-densepose-cli
Dragan Spiridonov c72bbc15dd fix(auth): close /api/field bypass, two fail-opens, and a self-disarming test
Findings from a qe-court adversarial round (4 prosecutors across 2 vendors).
Each was verified against the code before being accepted; the ones below
reproduced, the rest are reported in the PR thread rather than acted on.

FATAL — `/api/field` was reachable with no credential, on both listeners.
The gate protected `/api/v1/*` by prefix. `/api/field` is the REST sibling of
`/ws/field` and serves the same signed FieldEvent stream — live presence, pose,
vitals. `/ws/field` was gated in this PR; its twin one path segment over was
not. Measured with RUVIEW_API_TOKEN set and no credential supplied:

    /api/v1/models  401      (control)
    /ws/field       401      (gated by this PR)
    /api/field      200      on :8080 AND :8765

Fixed by inverting the gate to deny-by-default with an explicit anonymous
allowlist (`/`, `/ui`, `/health`, `/oauth/`). A route added at a new path is
now gated because nobody exposed it, rather than exposed because nobody
protected it — the same inversion already applied to the scope gate.

FATAL — the wiring test disarmed itself exactly when it mattered.
`Server::start` returned an Option that all five tests turned into `return`,
so a server that failed to boot produced "5 passed" with zero assertions run,
and cargo swallows the skip line without --nocapture. The one test that
observes real wiring — the guard against both shipped bypasses — was silent
for any change that breaks startup, including a boot panic in the auth path.
It now panics with the child's stderr.

MAJOR — a malformed client-id list silently disabled the audience check.
An empty allowlist is the opt-out sentinel in verify.rs. `RUVIEW_OAUTH_CLIENT_IDS=","`
is non-empty, passes the guard, then filters to an empty Vec — turning the
audience boundary off with no log and admitting a token minted for any other
Cognitum product. Only a literal `*` may opt out now; anything else that parses
to nothing warns and falls back to the default. Same fail-open shape as the
scope denylist this PR already had to invert.

MAJOR — credentials were world-readable for a window on every refresh.
`fs::write` creates at 0666 & !umask (0644 by default), and both writers
chmodded afterwards. The existing permissions test asserted on the FINAL file
and passed throughout. Affected the CLI refresh token (rotated with reuse
detection — a thief who presents it first takes the session family) and the
browser session secret (the HMAC key for every session; stealing it forges any
account at any scope). Both now create with mode 0600 via OpenOptions.

MAJOR — ui/sw.js cached authenticated API responses.
Closing the /oauth/ leg left the /api/ leg open. `networkFirst` cached every
successful response, keyed by URL alone, purged by nothing at sign-out: sign in
as A, load sensing data, sign out, sign in as B, lose the network, and B is
served A's data with no authorization check. API responses are now network-only
— which is also the correct behaviour for a live sensing dashboard, where
replaying a stale reading can show a room occupied after the person left — plus
a cache purge on sign-out.

CI — 40 of ruview-auth's 87 tests never ran.
The workspace runs --no-default-features, which switches off the `login` and
`pkce` features. Measured: 47 tests vs 87. The whole interactive sign-in path —
credential storage, single-flight refresh, the file lock, the loopback callback
— was green locally and never executed in CI. Added an --all-features step.
(Checked the sensing-server for the same problem and did NOT find it:
bearer_auth's 49 and browser_session's 15 do run under CI flags.)

Tests: +2 wiring tests (one fails against the old gate with
"http port served /api/field to an anonymous caller", passes after), +3 UI
service-worker tests, +3 CLI scope tests, +1 temp-file permission test, +1
client-id parsing test. wifi-densepose-cli/src/auth.rs had zero tests and
builds its own scope string, so the library's least-privilege test said nothing
about what the CLI requests.

Verified: ruview-auth 61+25+2 pass (--all-features), sensing-server bearer_auth
50, browser_session 15, auth_wiring 7, workspace 25 suites clean, UI 22.

Co-Authored-By: Ruflo & AQE
2026-07-23 11:48:59 +02:00
..

wifi-densepose-cli

Crates.io Documentation License

Command-line interface for WiFi-DensePose, including the Mass Casualty Assessment Tool (MAT) for disaster response operations.

Overview

wifi-densepose-cli ships the wifi-densepose binary -- a single entry point for operating the WiFi-DensePose system from the terminal. The primary command group is mat, which drives the disaster survivor detection and triage workflow powered by the wifi-densepose-mat crate.

Built with clap for argument parsing, tabled + colored for rich terminal output, and indicatif for progress bars during scans.

Features

  • Survivor scanning -- Start continuous or one-shot scans across disaster zones with configurable sensitivity, depth, and disaster type.
  • Triage management -- List detected survivors sorted by triage priority (Immediate / Delayed / Minor / Deceased / Unknown) with filtering and output format options.
  • Alert handling -- View, acknowledge, resolve, and escalate alerts generated by the detection pipeline.
  • Zone management -- Add, remove, pause, and resume rectangular or circular scan zones.
  • Data export -- Export scan results to JSON or CSV for integration with external USAR systems.
  • Simulation mode -- Run demo scans with synthetic detections (--simulate) for testing and training without hardware.
  • Multiple output formats -- Table, JSON, and compact single-line output for scripting.

Feature flags

Flag Default Description
mat yes Enable MAT disaster detection commands

Quick Start

# Install
cargo install wifi-densepose-cli

# Run a simulated disaster scan
wifi-densepose mat scan --disaster-type earthquake --sensitivity 0.8 --simulate

# Check system status
wifi-densepose mat status

# List detected survivors (sorted by triage priority)
wifi-densepose mat survivors --sort-by triage

# View pending alerts
wifi-densepose mat alerts --pending

# Manage scan zones
wifi-densepose mat zones add --name "Building A" --bounds 0,0,100,80
wifi-densepose mat zones list --active

# Export results to JSON
wifi-densepose mat export --output results.json --format json

# Show version
wifi-densepose version

Command Reference

wifi-densepose
  mat
    scan        Start scanning for survivors
    status      Show current scan status
    zones       Manage scan zones (list, add, remove, pause, resume)
    survivors   List detected survivors with triage status
    alerts      View and manage alerts (list, ack, resolve, escalate)
    export      Export scan data to JSON or CSV
  version       Display version information
Crate Role
wifi-densepose-mat MAT disaster detection engine
wifi-densepose-core Shared types and traits
wifi-densepose-signal CSI signal processing
wifi-densepose-hardware ESP32 hardware interfaces
wifi-densepose-wasm Browser-based MAT dashboard

License

MIT OR Apache-2.0