audit: drop the report; the findings belong in the code and the tasks
This commit is contained in:
Fimeg
parent
dd92ecc718
commit
1a73e3f4dc
1 changed files with 0 additions and 114 deletions
|
|
@ -1,114 +0,0 @@
|
|||
# Audit — our own code, 2026-08-03
|
||||
|
||||
Asked for after a night of using the phone. Everything below was checked against
|
||||
the code or the running device; anything I could not confirm says so. Ordered by
|
||||
what I would fix first, not by severity in the abstract.
|
||||
|
||||
## 1. Five protocol filters admit every client, and two of them are keystrokes
|
||||
|
||||
`wayland.rs` creates these with `|_| true` as the filter — the argument whose
|
||||
whole purpose is deciding who may bind:
|
||||
|
||||
| line | global | what binding it buys a caller |
|
||||
|---|---|---|
|
||||
| 477, 484 | data-control (wlr + ext) | read every clipboard and primary selection |
|
||||
| 486 | `ext-session-lock` manager | ask to lock the session |
|
||||
| 513 | `zwp_virtual_keyboard_v1` | **synthesize keystrokes into the focused surface** |
|
||||
| 514 | `input-method` | **intercept and rewrite text input** |
|
||||
|
||||
The last two are the sharp ones. Any process running as uid 1000 can create a
|
||||
virtual keyboard and type into whatever holds focus, or install itself as the
|
||||
input method and read what is typed. That is a keylogger and an injector, from
|
||||
an unprivileged process, with no attestation anywhere in the path.
|
||||
|
||||
Today's ceiling argument — "any uid-1000 process could already run
|
||||
`blueline-screen-toggle`" — does not cover this. Blanking a screen is not
|
||||
reading a password.
|
||||
|
||||
`SO_PEERCRED` is already available at the control socket and unused, and
|
||||
`may_take_lock` is still a uid check. TASK-41 owns all of it and lands at every
|
||||
one of these boundaries or none.
|
||||
|
||||
## 2. A wake leaves no trace in the forensic trail
|
||||
|
||||
`apply_gesture`'s dark-panel branch does:
|
||||
|
||||
```rust
|
||||
self.blank_requested = false;
|
||||
return vec![Action::Unblank, Action::Restore];
|
||||
```
|
||||
|
||||
No `record_decision`. The blank branch records `panel-off` or
|
||||
`lock-before-blank`; the wake branch records nothing. So the trail shows
|
||||
`button-gesture … recognised` and then silence, and **"the button woke it" and
|
||||
"the button did nothing" are the same entry.**
|
||||
|
||||
This cost real time tonight: I could not tell, from the trail, whether a press
|
||||
had been swallowed or had worked. It is a two-line fix and it is the highest
|
||||
value-per-line item on this page.
|
||||
|
||||
## 3. The device flaps `Locked → Observed → Locked` continuously
|
||||
|
||||
Measured on the phone today, `observed_confidence: 0.20`, transitions
|
||||
alternating with nothing else between them. Every one is a trail entry, so the
|
||||
trail is mostly this.
|
||||
|
||||
Same shape as the light-sensor oscillation fixed on 2026-07-28 (confidence
|
||||
pulsing 0.50→0.70→0.50 in 1.2 s, toggling `promote_idle` across the 0.6 band):
|
||||
a confidence sitting on a threshold with no hysteresis. The fix there was an
|
||||
asymmetric debounce, and the same argument applies here.
|
||||
|
||||
Not yet established: whether the fingerprint sensor is the source. It is a
|
||||
candidate — TASK-44 records that arming generates its own edge, and that a
|
||||
re-arm-on-every-interrupt loop produced a 1444-event run. Casey reports the
|
||||
fingerprint sensor "sometimes locks the display", which is consistent with a
|
||||
storm of wake-class input driving state transitions, but I have not tied a
|
||||
specific event to a specific lock and will not claim it.
|
||||
|
||||
What *is* ruled out: the fingerprint does not enter as a button.
|
||||
`buttons.rs::classify` maps `KEY_WAKEUP` to `KeyDisposition::Wake`, not to
|
||||
`Report { button: Power }`, so it cannot be resolving as a power tap.
|
||||
|
||||
## 4. Recognised, and bound to nothing
|
||||
|
||||
A running theme, and worth counting in one place:
|
||||
|
||||
- **Volume keys** — sessiond recognises the gesture; only power-tap is bound
|
||||
(TASK-51 §3). Second-most-used control on the device.
|
||||
- **`navigation.rs`** — holds TASK-37's policy, both tiers and the predictive
|
||||
drag. Nothing calls it.
|
||||
- **`furniture_at()` returns `None`** — so `Route::Shell` is unreachable and the
|
||||
pill cannot be addressed as furniture.
|
||||
- **Gestures other than the three-finger tap** — drag and drag-end resolve and
|
||||
are dropped (deliberate, but it is the same shape).
|
||||
|
||||
Each is a decision, not a bug. The concern is that the count keeps growing.
|
||||
|
||||
## 5. Shipping paths that silently do not ship
|
||||
|
||||
- **viewtop is still a hand-copied binary in `/usr/local/bin`** — TASK-25.
|
||||
`souveraine/CLAUDE.md` names this exact pattern as the one that silently never
|
||||
updates, and it is how sessiond sat five days stale.
|
||||
- **`blueline-usb-gadget` is NOT INSTALLED on the phone.** It was packaged
|
||||
precisely to fix the stale-usb0 tether, and the device still does not have it,
|
||||
so that failure recurs on every cold boot.
|
||||
- **`build-cross.sh` has no `--release`** — line 45 takes `debug/`, line 46 only
|
||||
prefers `release/` if it happens to exist. "aarch64 built" therefore produced
|
||||
a 137 MB debug compositor. Pass `--release` or change the default.
|
||||
|
||||
## 6. Documentation that is now false
|
||||
|
||||
- `START-HERE.md` §6: *"away from home the phone has no wifi — the SSIDs are
|
||||
pinned to the home network."* It joined a foreign SSID on 2026-08-02 and sat
|
||||
there working. Fixed in `phone-triage.sh`; the prose still says it.
|
||||
|
||||
## Not audited
|
||||
|
||||
The QML surface tree, the kernel, and PAF. This pass covered `souveraine/src/
|
||||
sessiond`, `souveraine-viewtop/crates`, and the device's live state.
|
||||
|
||||
## Connects to
|
||||
|
||||
TASK-41 (attestation at every boundary — §1 is entirely its scope), TASK-51
|
||||
(§4's list is mostly its punch list), TASK-25 (§5), TASK-44 (§3's open
|
||||
question), `LOCK-DPMS-LESSONS.md` §1.
|
||||
Loading…
Reference in a new issue