From 9e1e71d661c9c3df5eaa6b1ce5f0704e470fe96f Mon Sep 17 00:00:00 2001 From: Luke Hoersten Date: Mon, 26 Oct 2026 19:57:11 -0500 Subject: openhop/repeater: resolve the 1.1.4 identity-validation review TODO Checked the actual upstream diffs, not just PR titles: #359/#370's identity-validation changes only add collision checks between multiple identities configured on one node (repeater/companion/room-server sharing a one-byte prefix namespace), unrelated to the single-identity load path. config.py's _load_or_create_identity_key is unchanged in 1.1.4 and still silently generates a fresh identity on any read failure instead of failing loudly, same mechanism as the 2026-08-10 stale-UID incident. Not introduced or fixed by this bump, so nothing blocks it, but the underlying fragility remains latent upstream. --- openhop/repeater/defaults/main.yaml | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) (limited to 'openhop') diff --git a/openhop/repeater/defaults/main.yaml b/openhop/repeater/defaults/main.yaml index cf37609..a67f7e1 100644 --- a/openhop/repeater/defaults/main.yaml +++ b/openhop/repeater/defaults/main.yaml @@ -1,10 +1,13 @@ --- # version-check: https://github.com/openhop-dev/openhop_repeater/tags -### TODO: before deploying this 1.1.4 bump to the live mesh node (lp1.chi.gdn), -### review upstream PRs 1.1.2-1.1.4 titled "refactor identity validation" / -### "relaxed identity guard" against the stale-UID identity bug fixed there -### on 2026-08-10. +# Reviewed the 1.1.2-1.1.4 "identity validation"/"identity guard" PRs against +# the stale-UID identity bug fixed on lp1.chi.gdn 2026-08-10: unrelated, they +# only cover collision checks between multiple identities configured on one +# node. The actual function (config.py's _load_or_create_identity_key) is +# unchanged; a read failure on the identity file still just logs a warning +# and silently generates a fresh identity instead of failing loudly. Not +# introduced or fixed by this bump, still latent upstream. repeater_version: "1.1.4" # openhop_repeater is NOT on PyPI, so it installs from this git tag. # Its dependency openhop_core[hardware] resolves from PyPI automatically. -- cgit v1.2.3