From 1426b4ecfe8be8b6d41f4d0213171b0c0d62cb5f Mon Sep 17 00:00:00 2001 From: windyboy Date: Fri, 21 Aug 2026 08:57:53 +0800 Subject: [PATCH] docs: matrix_e2ee v0.3.12/v0.3.9 notes; gw/ubnt IPv6 re-verification; agent sandbox SSH quirk (2026-08-20) --- AGENTS.md | 13 ++++++++++++ docs/home-assistant-matrix.md | 39 ++++++++++++++++++++++++++++++----- hosts/gw.md | 5 +++++ hosts/ubnt.md | 5 +++++ 4 files changed, 57 insertions(+), 5 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index e1da488..b373a5f 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -18,6 +18,19 @@ Also readable as `agent.md` (symlink → this file). 6. Default SSH access (`ssh -4 windy@`) is for focused diagnostics, imperative upstream procedures, and incident work. Prefer **IPv4** from this WSL client (AAAA often exists but IPv6 route does not). + + > **Agent sandbox SSH quirk (verified 2026-08-20):** the agent shell runs in + > a sandboxed user namespace — system files such as + > `/etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf` appear owned by `nobody`, + > so plain `ssh` aborts with `Bad owner or permissions on ...`. Always use + > `ssh -F /dev/null` from the agent shell and pass options explicitly + > (`~/.ssh/config` is skipped; e.g. `ssh -F /dev/null -p 2222 + > -i ~/.ssh/id_ed25519 windy@repo.windy.me`). `sudo` never works in the + > sandbox (`NoNewPrivs`, no capabilities, `/` read-only). The host itself is + > healthy — to inspect or act on the real host from the sandbox use + > `/mnt/c/WINDOWS/system32/wsl.exe -u root -- ` (real root: keep + > read-only unless a change is approved). + 7. Record each material VPS operation, incident, configuration change, or verification outcome in the corresponding **Linear `vps` project**. Include scope, action, verification, and remaining follow-up; never put passwords, diff --git a/docs/home-assistant-matrix.md b/docs/home-assistant-matrix.md index 0d06f80..2651012 100644 --- a/docs/home-assistant-matrix.md +++ b/docs/home-assistant-matrix.md @@ -179,8 +179,10 @@ automation: ## matrix_e2ee (custom E2E integration) Custom integration [`windyboy/ha-matrix-e2ee`](https://github.com/windyboy/ha-matrix-e2ee), -release **v0.3.0** (W1N-180/#32: bot-initiated device verification wizard), -deployed on `hass.windy.lan` 2026-08-18 (upgraded from v0.2.10). +release **v0.3.12** (Matrix activity events + push diagnostics), deployed on +`hass.windy.lan` 2026-08-20 (upgraded from v0.3.2, W1N-182/#34 emoji-wait +wizard fix; v0.3.9 brought the Connection health binary sensor, SAS/command +allowlist split, URL normalization and single-entry enforcement, W1N-156/W1N-190). Runs a dedicated bot with a **persistent E2EE device identity**. - Domain `matrix_e2ee`; Config Flow (UI) with YAML import migration, not in HACS. Does **not** @@ -212,6 +214,13 @@ Runs a dedicated bot with a **persistent E2EE device identity**. optional `emojis`, optional `expires_at`; `expires_at` added v0.1.3) - `matrix_e2ee_fingerprint` (`user_id`, `device_id`, `ed25519`, `curve25519` — public keys only; added v0.1.3) + - `matrix_e2ee_message_received` (`room_id`, `sender`, `event_id`; added v0.3.12 + activity events) + - `matrix_e2ee_verification_done` (`transaction_id`, `user_id`, `device_id`; + added v0.3.12) +- v0.3.12 also adds an `event.` platform entity (`Bot activity`, + `event_types: ["message", "command", "verification_done"]`) and a diagnostic + Connection binary sensor (`binary_sensor.*_connection`, CONNECTIVITY class). - `notify.matrix_e2ee` is **not implemented** (upstream deferred) — notifications must call `matrix_e2ee.send_message` (message + room_id). - Commands fire Home Assistant events only; the integration never calls @@ -240,8 +249,10 @@ matrix-nio [examples](https://matrix-nio.readthedocs.io/en/latest/examples.html) [element-android#6832](https://github.com/vector-im/element-android/issues/6832), Element [device-verification](https://element.io/features/device-verification). -`matrix_e2ee` supports three verification paths (the v0.3.0 wizard automates -the bot-initiated flow): +`matrix_e2ee` supports three verification paths (the wizard — v0.3.0 +bot-initiated, reworked in v0.3.1/v0.3.2 to wait for a peer-initiated inbound +SAS from the user's Matrix client with emoji comparison — automates the SAS +flow): ### 1. SAS (mutual, manual confirmation since v0.1.4) @@ -284,8 +295,26 @@ the bot-initiated flow): dropped when the peer device was unknown (W1N-170/W1N-172); `VERIFICATION_TIMEOUT_SECONDS` 600→240 (fires before nio's `_max_age`). - **v0.2.11**: `receive_mac_event` no longer overrides canceled state (W1N-179/#31). +- **v0.3.12**: Matrix activity events (`matrix_e2ee_message_received`, + `matrix_e2ee_verification_done`) + `event.` Bot activity entity + Connection + diagnostic binary sensor. +- **v0.3.9**: SAS driver gate split from the command allowlist — new + `verification_peer_users` option (W1N-156/#41); SAS/sync logs demoted + warning→info/debug (W1N-188/#38); Connection health binary sensor + (W1N-185/#40); URL normalization + single-entry enforcement (W1N-190/#42). +- **v0.3.8**: `m.key.verification.done` handshake completion for + request-based SAS (W1N-183/#35). +- **v0.3.2**: wizard waits for the inbound SAS to show emojis before moving + to the compare step (`_wait_for_inbound` requires `latest_sas_snapshot()` to + return `emojis`) — W1N-182/#34. +- **v0.3.1**: verification wizard now waits for a peer-initiated inbound SAS + (options flow no longer starts verification from the bot; `latest_sas_snapshot()` + skips verified/canceled transactions) — GitHub #33. - **v0.3.0**: bot-initiated device verification wizard (W1N-180/#32). -- Inbound SAS is gated to `allowed_users` (v0.1.3). +- Inbound SAS is gated to `allowed_users` (v0.1.3); **since v0.3.9 (W1N-156) + the gate is the separate `verification_peer_users` allowlist**, which is + unset on hass.windy.lan — only the bot's own account may drive SAS until + `@zhiqiang:chans.xyz` is added there. ### 2. One-sided fingerprint (added v0.1.3, hardened v0.1.4) diff --git a/hosts/gw.md b/hosts/gw.md index 30885cc..77744f4 100644 --- a/hosts/gw.md +++ b/hosts/gw.md @@ -124,3 +124,8 @@ from `192.168.55.254` reached the UniFi controller at `192.168.66.46` with 3/3 ICMP replies. This supports the AP Inform path to `192.168.66.46:9080`; the controller listener and an online LAN55 AP provide the corresponding application-level evidence. No firewall changes were made. + +IPv6 was re-verified by read-only SSH on 2026-08-20 during the UniFi AP/AC +check: the IPv6 routing table shows connected `/64`s on `eth0` (LAN66) and +`switch0` (LAN55) plus `::/0` via `pppoe0`; both UniFi APs obtained SLAAC +addresses from the router's RAs. No configuration changes were made. diff --git a/hosts/ubnt.md b/hosts/ubnt.md index d4c8527..402cdf9 100644 --- a/hosts/ubnt.md +++ b/hosts/ubnt.md @@ -53,6 +53,11 @@ of `8080`. During adoption or recovery, use the documented `:9080/inform` URL; an AP left on `:8080` can remain reachable by ping and SSH while showing offline in the controller. +IPv6 is enabled on the controller's `Default` network (`ipv6_enabled: true`, +client assignment SLAAC; RA is served by `gw`, so `ipv6_interface_type` is +`none`); both managed APs hold global SLAAC addresses — verified 2026-08-20. +See [docs/unifi-network.md](../docs/unifi-network.md). + ## Safe reconciliation and verification ```bash