Ecosystem-wide feature/hardening ideas surfaced during the 2026-09 audit #15

New issue

Closed

opened 2026-09-05 02:00:42 +08:00 by Breadway · 0 comments

Breadway commented

2026-09-05 02:00:42 +08:00

Owner

Status (re-verified 2026-09-09): two items were already resolved (struck through below). The five still-open items now have their own tracked issues: BSET-8, CRUMB-10, ECO-21, ECO-22, CLIP-5. The two items left unchecked with no spin-out (breadlock blur, breadcrumbs live-NM CI test) are intentionally kept here as low-priority ideas.

bread-ecosystem (shared crates / CI)

~~CI never runs bread-theme's own test suite.~~ RESOLVED by ECO-5 (check.yml, PR #8), which merged into main on 2026-09-04, before this audit was written. check.yml runs cargo clippy and cargo test --workspace --locked, then again with --features gtk, on main and every feature/** and fix/** branch. bread-theme is a workspace member, so its full suite (including the ECO-6 bind lifecycle tests and the ECO-16 regression test) runs on every push. The original note only looked at dev-bread-theme.yml.
cargo fmt --check isn't gated anywhere yet. (tracked: ECO-21) Both ECO-5 (bread-ecosystem's own check.yml) and BSET-3 (bos-settings') added clippy and test CI but explicitly left fmt ungated because the trees aren't fmt-clean (27 files in bread-ecosystem, more in bos-settings). Worth a follow-up pass to cargo fmt --all each repo once and then gate it, so drift stops accumulating.
bread-theme has no API to write pywal's own colors.json cache format from an in-memory Palette. (tracked: ECO-22) breadpaper's PAPER-2 fix (sync_focused_global) has to shell out to a second wal -i subprocess just to keep ~/.cache/wal/colors.json in sync with a per-output palette that's already computed in memory, because there's no bread_theme::write_wal_cache(&palette)-style helper. The PR body flags this explicitly: "bread-theme exposes no API to write pywal's cache format, hand-rolling it is fragile." Adding one would let breadpaper (and any future consumer) drop a subprocess spawn.

breadlock

background.blur is accepted but unimplemented. Per the README: "background.blur is not implemented, the key is accepted and logs a warning; the surface is drawn unblurred." A hyprlock-style live blur-of-desktop would need a wlr-screencopy capture behind the lock surface, a real, previously-scoped feature that just hasn't been built yet. Kept as an idea, not spun out (large feature, pure visual polish).

breadclip

ignore_rules (the copied-secret heuristic) isn't user-configurable. (tracked: CLIP-5) CLIP-3's PR body notes the original spec called for user-configurable match rules (MIME/app/regex, documented in EVENTS.md); what shipped is a fixed heuristic with no config surface, "simpler, and documented as such." Worth a [ignore] config section for users who want to add or relax patterns (e.g. an internal ticket-ID format that trips the Luhn/OTP heuristics as a false positive).

breadcrumbs

No live-NetworkManager integration test in CI. CRUMB-2's PR body lists a substantial manual smoke-test checklist (status/connect/switch against live NM, first-connect PSK verification, 802.1x, watch reacting within a second, captive portal detection) explicitly marked "needs doing on hermes", i.e. still manual only. The existing tests/common/fake_nm.rs (an in-process D-Bus fake) covers unit-level D-Bus shape, but nothing exercises the CLI against a real NetworkManager in CI. Kept as an idea, not spun out (real NM in CI is infra-heavy; a scripted local smoke test on hermes is the better near-term move).
Config/State files have no locking. (tracked: CRUMB-10) config.rs's Config::save() and state.rs's State::save() do a plain read-modify-write with no flock/lockfile. breadcrumbs watch (long-running) and a concurrent one-shot breadcrumbs add/forget/profile set invocation can race on the same breadcrumbs.toml/state.toml, with whichever fs::write lands last silently winning. Worth a lockfile (flock on a sidecar .lock) given watch is meant to run continuously in the background while the user issues one-shot commands.
~~Non-interactive secret input.~~ RESOLVED by CRUMB-6 (PR #7): --password-stdin on add, documented in the README, with a regression test (add_password_stdin_reads_secret_without_argv_or_warning). CRUMB-8 (PR #8) added the join <ssid> command as the follow-on for connect-by-ssid with no password argument. Both merged 2026-09-05.

bos-settings

Firewall UI advertises service-name rules the backend rejects. (tracked: BSET-8) BSET-5's PR body flags this as an explicit unresolved product call: the Firewall panel's UI hint says "e.g. 8080/tcp ... or a service name like OpenSSH", but the hardened backend validator (firewall.rs, kept strict from f7b114f) is port-only and rejects OpenSSH. Either loosen the backend to the already-available util::valid_cli_value (still argv-safe, blocks flag/;/control injection) or drop the service-name hint from the UI, currently sitting inconsistent between the two.

breadcast

No specific gaps surfaced beyond the bug filed separately (CAST-4): the discovery/pipeline/HTTP-server code was unusually thorough about bounding blocking calls and handling malformed input, so nothing to add here for now.

Consolidated list of feature ideas and hardening gaps noticed while auditing the sibling GTK4/layer-shell apps (breadclip, breadcrumbs, breadcast, breadlock, breadmon, breadpad, breadpaper, breadsearch, breadshot, breadhelp) plus bread-ecosystem's shared crates and bos-settings, on 2026-09-05. Not bugs: each of these is either a documented "not implemented yet" gap, an explicit "not done in this PR" note left in a merged PR's own description, or a natural extension of an existing pattern. One issue, checklist-style, grouped by repo. File individual issues against the relevant repo's project when someone picks one up. **Status (re-verified 2026-09-09):** two items were already resolved (struck through below). The five still-open items now have their own tracked issues: BSET-8, CRUMB-10, ECO-21, ECO-22, CLIP-5. The two items left unchecked with no spin-out (breadlock blur, breadcrumbs live-NM CI test) are intentionally kept here as low-priority ideas. ## bread-ecosystem (shared crates / CI) - [x] ~~**CI never runs `bread-theme`'s own test suite.**~~ RESOLVED by ECO-5 (`check.yml`, PR #8), which merged into main on 2026-09-04, before this audit was written. `check.yml` runs `cargo clippy` and `cargo test --workspace --locked`, then again with `--features gtk`, on `main` and every `feature/**` and `fix/**` branch. `bread-theme` is a workspace member, so its full suite (including the ECO-6 bind lifecycle tests and the ECO-16 regression test) runs on every push. The original note only looked at `dev-bread-theme.yml`. - [ ] **`cargo fmt --check` isn't gated anywhere yet.** (tracked: **ECO-21**) Both ECO-5 (bread-ecosystem's own `check.yml`) and BSET-3 (bos-settings') added clippy and test CI but explicitly left fmt ungated because the trees aren't fmt-clean (27 files in bread-ecosystem, more in bos-settings). Worth a follow-up pass to `cargo fmt --all` each repo once and then gate it, so drift stops accumulating. - [ ] **`bread-theme` has no API to write pywal's own `colors.json` cache format from an in-memory `Palette`.** (tracked: **ECO-22**) breadpaper's PAPER-2 fix (`sync_focused_global`) has to shell out to a second `wal -i` subprocess just to keep `~/.cache/wal/colors.json` in sync with a per-output palette that's already computed in memory, because there's no `bread_theme::write_wal_cache(&palette)`-style helper. The PR body flags this explicitly: "bread-theme exposes no API to write pywal's cache format, hand-rolling it is fragile." Adding one would let breadpaper (and any future consumer) drop a subprocess spawn. ## breadlock - [ ] **`background.blur` is accepted but unimplemented.** Per the README: "`background.blur` is not implemented, the key is accepted and logs a warning; the surface is drawn unblurred." A hyprlock-style live blur-of-desktop would need a `wlr-screencopy` capture behind the lock surface, a real, previously-scoped feature that just hasn't been built yet. Kept as an idea, not spun out (large feature, pure visual polish). ## breadclip - [ ] **`ignore_rules` (the copied-secret heuristic) isn't user-configurable.** (tracked: **CLIP-5**) CLIP-3's PR body notes the original spec called for user-configurable match rules (MIME/app/regex, documented in `EVENTS.md`); what shipped is a fixed heuristic with no config surface, "simpler, and documented as such." Worth a `[ignore]` config section for users who want to add or relax patterns (e.g. an internal ticket-ID format that trips the Luhn/OTP heuristics as a false positive). ## breadcrumbs - [ ] **No live-NetworkManager integration test in CI.** CRUMB-2's PR body lists a substantial manual smoke-test checklist (`status`/`connect`/`switch` against live NM, first-connect PSK verification, 802.1x, `watch` reacting within a second, captive portal detection) explicitly marked "needs doing on hermes", i.e. still manual only. The existing `tests/common/fake_nm.rs` (an in-process D-Bus fake) covers unit-level D-Bus shape, but nothing exercises the CLI against a real `NetworkManager` in CI. Kept as an idea, not spun out (real NM in CI is infra-heavy; a scripted local smoke test on hermes is the better near-term move). - [ ] **`Config`/`State` files have no locking.** (tracked: **CRUMB-10**) `config.rs`'s `Config::save()` and `state.rs`'s `State::save()` do a plain read-modify-write with no flock/lockfile. `breadcrumbs watch` (long-running) and a concurrent one-shot `breadcrumbs add/forget/profile set` invocation can race on the same `breadcrumbs.toml`/`state.toml`, with whichever `fs::write` lands last silently winning. Worth a lockfile (`flock` on a sidecar `.lock`) given `watch` is meant to run continuously in the background while the user issues one-shot commands. - [x] ~~**Non-interactive secret input.**~~ RESOLVED by CRUMB-6 (PR #7): `--password-stdin` on `add`, documented in the README, with a regression test (`add_password_stdin_reads_secret_without_argv_or_warning`). CRUMB-8 (PR #8) added the `join <ssid>` command as the follow-on for connect-by-ssid with no password argument. Both merged 2026-09-05. ## bos-settings - [ ] **Firewall UI advertises service-name rules the backend rejects.** (tracked: **BSET-8**) BSET-5's PR body flags this as an explicit unresolved product call: the Firewall panel's UI hint says "e.g. `8080/tcp` ... or a service name like `OpenSSH`", but the hardened backend validator (`firewall.rs`, kept strict from `f7b114f`) is port-only and rejects `OpenSSH`. Either loosen the backend to the already-available `util::valid_cli_value` (still argv-safe, blocks flag/`;`/control injection) or drop the service-name hint from the UI, currently sitting inconsistent between the two. ## breadcast No specific gaps surfaced beyond the bug filed separately (CAST-4): the discovery/pipeline/HTTP-server code was unusually thorough about bounding blocking calls and handling malformed input, so nothing to add here for now.

Breadway added the

enhancement

label

2026-09-05 02:00:43 +08:00

Breadway closed this issue

2026-09-11 19:02:33 +08:00

Breadway referenced this issue

2026-09-29 08:34:38 +08:00

Dev track builds against dependency main; releases stay on locked tag pins #38

Breadway referenced this issue

2026-10-20 15:49:06 +08:00

Remaining bread consumers still clone into the shared src path (adopt pinned checkout helper) #82