Repository navigation
NET-02 — Canonical transfer/share policy #482
Description
Tracks NET-02 in the authoritative v3 work program and depends on merged NET-01 (#481).
Acceptance scope:
- one canonical policy for Roms, BIOS, Artwork, Screenshots, Themes, and Saves
- five read-write roots and read-only Saves
- private roots, traversal, symlinks, unsafe components, and unbounded writes denied
- same-filesystem atomic publication with cancel/transport-loss preservation
- shared authority consumable by SFTP and future transfer surfaces
- signed Mini Plus durable migration, rollback, listener, key, and cleanup evidence
This issue does not expand product scope beyond SSD202D Miyoo Mini V1-V4, Mini Plus, and Mini Flip/my285. Remote Plus evidence will remain distinct from physical and other-device certification.
Parent program: #434
Activity
boburning commentedon Aug 26, 2026
NET-02 is published as draft PR #483 from exact head
aff110ba73eca83dfd52d18afd26b316caa9e7fd.Host gates are green: 634/634 complete read-only shell suite, 29/29 focused transfer/SSH/network tests, 13/13 dependency/harness checks, exact policy/manifest/provenance/FAT checks, native cancel-safe SFTP protocol probe, and stripped static ARM EABI5 build. Protected signed hardware workflow 32969798436 is queued for the exact PR head.
The PR remains draft until signed durable Mini Plus migration, rollback, listener/key, cleanup, and corrected cancel/scaffolding behavior are evidenced. Remote evidence will not be represented as physical or other-device certification.
boburning commentedon Aug 27, 2026
Signed Full attempt and corrective recovery update:
aff110ba73eca83dfd52d18afd26b316caa9e7fdb073b423and automatically rolled back fromaff110ba; post-recovery aggregate health and listener audit were green and the single authorized key remained intactef9dbec54f0faffc0efd2eaf6cac1009957bb307adds a bounded boot-only carrier wait and is pushed to PR NET-02: add canonical transfer policy #483docs/validation/network/plus-net02-signed-recovery-20260826.jsonThe PR remains draft pending CI, a newly signed exact-head Full artifact, and the corrected durable Mini Plus gate. A maintainer-observed need to hold power continuously during the update/recovery loop is recorded as a physical retest limitation and is not represented as an idle-shell reproduction.
boburning commentedon Aug 27, 2026
Corrected signed candidate
ef9dbec54f0faffc0efd2eaf6cac1009957bb307is rejected and remains unconfirmed.The protected artifact passed signature, exact commit/version, SHA-256, metadata, ZIP CRC, all PR checks, 39/39 focused tests, and 637/637 complete shell tests. Full activation reached Bloom Shell on Mini Plus twice, and the physical UI reported Wi-Fi connected, but the device never appeared anywhere on the LAN /24 by its known MAC and never obtained the prior address. The on-device Quick Settings Wi-Fi row also refused the bounded Left/A disable action, so UI recovery could not restart the lifecycle.
This disproves the initial carrier-only correction: carrier/association is not sufficient evidence that DHCP and the key-only listener path are recoverable. The third boot is now executing the supported automatic rollback to retained known-good
b073b423; no manual payload overwrite is being used.No further Full candidate will be deployed from this branch until the retained logs are collected after recovery and a safer diagnostic proves association, IPv4 assignment, desired listener restoration, and functional UI recovery without relying on the Full update as the first integration test.
boburning commentedon Aug 27, 2026
Recovery correction is now pushed to existing PR #483 as
354cb7fb.The second signed Full attempt (
ef9dbec5) was rejected and automatically rolled back to known-goodb073b423. The confirmed defect was carrier-only readiness: Bloom reported association before wlan0 had a global IPv4 address, while the request path waited without repairing DHCP.The correction now requires carrier plus global IPv4, reports carrier-only state as
acquiring_address, restarts only the fixed inheritedudhcpcpath, and reconciles services from one detached bounded watcher with reuse and stale-lock recovery. It also prevents an already-self-restored network overlay from replaying unavailable optional services during rollback.Validation is green locally: 640/640 complete shell tests, 47/47 focused network/transaction tests, and 31/31 dependency/manifest/provenance/payload tests. The exact current
bloom-wifi(9215ea47...d03bb) passed an isolated BusyBox/ash fixture on the Mini Plus with all live network commands mocked. The device remains on known-goodb073b423with IPv4/route intact, session IDLE, SSH on/running key-only, SFTP/Samba off, and a clean listener audit.No new Full or Warm deployment was performed. PR #483 remains draft pending a separately reviewed corrected signed durable gate.
boburning commentedon Aug 28, 2026
Reopened after a signed Full candidate reproduced the lockout on the Mini Plus. Offline card evidence shows both canonical settings and the active device profile retained Wi-Fi enabled, while the shell displayed Wi-Fi disabled and could not enable it. The defect is a capability deadlock: bloom-platform classified Mini Plus station support as unavailable whenever a powered-off radio removed /sys/class/net/wlan0; bloom-network then rejected enable as no hardware before bloom-wifi could power the radio on. Local corrective commit da54ffed makes qualified Plus capability depend on fixed runtime hardware/backend paths rather than current interface publication. The exact radio-off/no-wlan0 capability test and full bloom-network request-enable integration test pass, along with 18/18 network status and 29/29 bloomctl consumer tests. The failed candidate remains unconfirmed. The card is currently entering the supported automatic rollback to retained known-good b073b42. No new PR was opened and the correction is not pushed until refreshed exact-device evidence prevents another avoidable CI failure.
boburning commentedon Aug 28, 2026
Correction to the preceding recovery note: the unpublished local corrective commit was amended after adding assertions for the legacy UI capability and the exact wifi_disabled status contract. The current unpublished commit is 7ac3d56d3ed7be11e802287ca432d7d8d136c34a; da54ffed is superseded locally and was never pushed.
boburning commentedon Aug 28, 2026
The capability-deadlock correction is now published on the existing PR #512 branch at exact head
97e8ac47569e6cc70efbbdab90de0859ccf2b811; earlier local commit IDs in this issue are superseded and were never pushed.Root cause is confirmed: on Mini Plus, radio-off removes
/sys/class/net/wlan0, while the old capability registry treated that transient interface absence as missing hardware.bloom-network request enabletherefore returnedno_network_hardwarebefore the fixedbloom-wifibackend could power the radio on. The correction keeps qualified Plus radio/station capability reachable from exact fixed runtime paths and preserves Flip behavior.Host validation is green:
wlan0-> radio start -> DHCP/global IPv4 -> detached service reconciliation -> associated statusThe complete-suite latency regression was also corrected without weakening exhaustive gates: repeated core metadata reads are cached within one validation process, and annotation-only provenance tests no longer rehash/rewrite the entire payload identity. Historical PLAT-01 evidence now remains anchored to immutable PR #480 source instead of the mutable current platform file.
Mini Plus evidence remains deliberately partial. The exact 17,120-byte platform candidate (
ccc3d1ad7efd29c8864a2b274c6af1ab6aff5efe9c5098dbe1b542ceaa11258d) restored the physical shell's visible Wi-Fi connected state after one bounded radio-off cycle without reboot/rollback, proving the capability deadlock is removed. But the retained signed known-good image uses the older carrier-only backend and did not regain DHCP/LAN/SSH. That does not certify the current complete stack. No further Full update or repeat radio mutation will be attempted until exact-head CI is green and the coherent current network bundle can be tested with independent recovery confirmation.boburning commentedon Aug 29, 2026
PR #512 exact-head CI is fully green at 32d9c84. The 713-test shell gate completed in 2m28s and scoped static analysis/cppcheck in 23s; test build, ASan, ARM check-build, UI assets, and format all passed. The PR remains draft pending one guarded coherent current-stack Mini Plus validation of radio-off -> DHCP/global IPv4 -> key-only SSH restoration. No further isolated Wi-Fi mutation or Full-update-first test will be used.
boburning commentedon Aug 29, 2026
PR #512 exact-head signed recovery gate is complete. Candidate
0.1.0-dev-32d9c842(archive SHA-256b0572360f334c87d0b34620f3672c91e923f1081914614241472159fc7e02c92, hardware run 33222933815) installed in one boot attempt after the UUID-scoped profile was corrected from persistedwifi=0towifi=1. On the candidate boot, Wi-Fi was enabled and associated,wlan0had a global IPv4/default route, key-only SSH returned, the listener audit was clean, the network transaction was idle, and the four corrected network helpers matched signed hashes. Aggregate health and five verified snapshots passed; the candidate is now exactknown_good. A privacy-safe 4 MiB framebuffer capture had three identical visible pages and showed coherent Bloom Shell with Wi-Fi indication. I deliberately did not repeat a radio-off mutation after recovery because it would sever the sole unattended control path; the powered-off/no-interface re-enable path is exhaustively host-tested. Full evidence and limitations are in #512.