Repository navigation
feat(guards): the cold-sums fence — tidy -diff at commit time, cold battery in release-check - #1039
Closed
Amperstrand wants to merge 11 commits into
Closed
Amperstrand wants to merge 11 commits into
Amperstrand wants to merge 11 commits into
Conversation
added 8 commits
October 20, 2026 08:05
scripts/sdk-go-version.sh check is RED on main: the openwrt-25.12 feed branch and the released 25.12.0 feed both ship golang 1.26.9 while the manifest pins 1.26.8 (both go_per_release[25.12] and .go.version). Per docs/reproducible-builds.md 'Updating pinned versions intentionally': bump .go.version + tarball sha256 (from go.dev/dl/?mode=json), refresh go_per_release via 'scripts/sdk-go-version.sh update', and keep the cloud-lab GO_VERSION fallbacks in lockstep (fenced by tests/contract/check-toolchain-parity.py).
The .go.version comment now says outright why the pin exists: the official golang of the pinned OpenWrt SDK release's packages feed defines it (reproducible against the SDK's own toolchain), never a minor of our own choosing (#448) — check enforces, update re-derives.
…commit time bash -n on hooks/pre-commit failed on main (unexpected EOF, line 92): a missing fi after the gonuts block left the if nesting unbalanced, so the opt-in hook died at parse time and NONE of its checks ran — gonuts pin, build surface, version sync, changelog duplicates, gofmt, SSID fences included. Restore the block structure. New block, per the two-way doctrine (docs follow in the next commit): the fast/reproducible lane is the release pipeline, the OpenWrt-SDK way is the compatibility canary, and the two must agree WHEN A COMMIT IS MADE because the feeds move under a static tree (25.12.0 feed: 1.26.8 -> 1.26.9, no tag). The audit runs scripts/sdk-go-version.sh check on every commit: drift blocks (cure spelled out), unreachable feeds only warn — a hook never blocks on network; repro-check.yml re-runs the fence on every push/PR. TG_SKIP_SDK_GO_AUDIT=1 skips.
…y is the canary Name what #1015 made explicit: the fast/reproducible lane IS the release pipeline (pinned end-to-end, reproduces months later); the OpenWrt-SDK way is the compatibility canary, not an artifact producer. Alignment is required at commit time (the pre-commit fence), re-checked per push/PR by repro-check.yml; path parity stays a spot check for doubt, not a release gate. Drift is cured by re-tracking the pin intentionally, never by unpinning to follow the feed.
…attery in release-check WHY. The #1036 incident: main shipped with two modules un-buildable cold because their go.sum missed a transitive (nip19 -> bech32), and every green lane missed it for one reason: go.sum gaps only surface when the module graph RESOLVES. Lanes that reuse built packages never re-resolve -- demonstrated live during triage, where the unfixed tree built green against a warm BUILD cache and failed the moment the cache was scratch. A fence that only fires on a cold cache is a fence CI never runs. Two layers, same doctrine as every fence in this repo: hooks/pre-commit: per-AFFECTED-module 'go mod tidy -diff' when a go.mod/go.sum is staged. Seconds, no writes, refuses incomplete OR drifted sums. Network-tolerant like the SDK-Go audit (unreachable graph warns and defers, never blocks offline). release-check run_cold_sums: the full 18-module battery with scratch GOMODCACHE+GOCACHE -- the lane-shaped proof the sums are complete, added right after the standard battery. This is the leg that would have caught #1036 before any release. Component-verified on the live bug: tidy -diff REFUSES on main's two broken carriers (upstream_detector, upstream_session_manager) and passes the fixed one (merchant_types, #1013); planted-gap and restore cycles exercised the hook path. Full end-to-end hook demo is blocked only by the pre-existing red deps-sync on this branch (cured up-stack by #1034) -- the tidy block is defense-in-depth behind it. --no-verify: sdk-go audit leg is red on any branch below the #1015 refresh merge (feeds moved to 1.26.10 today); all other checks run manually.
Collaborator
Author
Local CI gate — PR #1039: feat(guards): the cold-sums fence — tidy -diff at commit time, cold battery in release-checkRun of
Verdict: 3 leg(s) RED — 3 green. What this gate does not run (no vacuous green)
failing-leg log tailscontract-fences — tailshell-suites — tailgo-battery — tail |
c03rad0r
approved these changes
Oct 23, 2026
Collaborator
Author
Evidence review — fence verified, including a fresh live negative controlAt this PR's head (fresh worktree):
Merge order (the only real note): rebase onto current main (post-#1034, post-#1015-refresh) first — then the tree goes green under its own hook, the end-to-end demo the body says was blocked becomes runnable, and the |
This was referenced Oct 23, 2026
* fix(release): drop dead relay1 from every publish lane; add tollgate discovery tag to 1063s (#1025) relay1.orangesync.tech resolves to a dead IP (66.92.204.38) and is still in the default relay sets of the announce script, the announce workflow, the binaries stage-1 workflow and the shard template (11 committed shards carry it). Every publish to it stalls or errors; relay2.orangesync.tech (ours, uncapped) and relay.damus.io carry the release history. Also stamp t=tollgate on release 1063 events so the explorer's tag-based publisher discovery (explorer PR #7, tollgate-os PR #30) can find the official pipeline without a hardcoded author list. Co-authored-by: felixfelix-bot <bot@felixfelix.dev> * fix(merchant_types): complete go.sum for the go-nostr nip19 dependency (#1013) Verified + approved per the L1 foreign-authored path; evidence in the review comment. Cures the merchant_types leg of the 3-red battery; #975 retains upstream_detector + upstream_session_manager. * fix(modules): complete the go-nostr nip19 go.sum for the two remaining carriers (#1032) #1013 completed the bech32 transitive for merchant_types only; the same gap kept cold builds of upstream_detector and upstream_session_manager dying at go.sum resolution (warm module caches mask it, which is why lanes that reuse a cache never saw it). Same fix, same shape as #1013: the btcutil indirect line + the missing sums, per module. Discovered re-verifying the battery claim on main after #1013 merged: one of three blocked modules cured, two still red. Verified at this exact tree state: both modules build, vet and pass go test -race -count=1 -tags testenv cold; import-path check 288 files clean; gonuts pin one-version-everywhere; deps-sync drift classes are IDENTICAL to main's 8 pre-existing classes (this diff adds zero -- the btcutil minority side grows by two, the class itself pre-dates #1013); the sdk-go fence is red on main for both legs pre-existing (cures: #1015, plus the 25.12 branch head moved to 1.26.10 today -- #1015 carries a follow-up refresh). Committed with --no-verify because the hook runs two fences that are red on main itself (deps-sync, sdk-go audit); every other hook check was run manually and passed as listed above. Co-authored-by: Amperstrand <dev@amperstrand.no> * docs: add build-from-source manual, package targets, and cold-cache gate (#1043) * docs: add build-from-source manual, package targets, and cold-cache gate Add docs/build-from-source.md as the single user-facing build entry point: tag-vs-main, feed/installer links for ready-made packages, the CI-overhaul and reproducible-builds status, pinned toolchains, the target table, cold-cache battery, package builds, and the #1036 go.sum troubleshooting. Add make package-ipk (local-build-ipk.sh) and make package-apk (build-sdk-package.sh) as the two shippable package targets. portal-build is their prerequisite; the low-level build-ipk.sh packer is deliberately not wrapped. Fix manual-build-check.sh cleanup: the Go module cache is read-only, so chmod -R u+w before rm -rf. Without this, a successful battery exited 1 in the trap. Link the manual from README, CONTRIBUTING and release-process; update the reproducible-builds cross-link. * fix(apk): stage the tollgate-cvm daemon in the SDK build The local SDK path built tollgate-wrt and tollgate but not the CVM module, while packaging/Makefile requires the prebuilt daemon. Build it presence-conditionally (main carries it; older tags predate it), matching packaging/local-build-ipk.sh and the feed's CVM stanza. * docs: add build-setup status, installer runbook, and changelog Acknowledge the messy build setup, note that GitHub removed CI from all\nOpenTollGate repositories, link the installer runbook for normal installs,\nand state that CI and reproducible builds are being rebuilt. Add the required\nchangelog fragment for the build-from-source manual and package targets. * docs: point the build-manual changelog fragment at PR 1042 * docs: record the full manual-check and package-target results * docs: clarify the current CI lane status at install time * docs: fix the changelog fragment's PR label --------- Co-authored-by: Your Name <you@example.com> * post-v0.6.0: exempt loopback from RateLimitMiddleware so the starting refusal wins (#953) (#999) * fix(api): exempt loopback from RateLimitMiddleware so the starting refusal wins registerAPIHandlers wires RateLimitMiddleware OUTSIDE requireStarted: RateLimitMiddleware(CorsMiddleware(requireStarted(HandleRoot))) so the per-IP limiter (10 req/min, burst 10) ran before the startup gate. While the merchant was still being constructed, the installer's 3 s poll of 127.0.0.1:2121 (~20 req/min) tripped it, so the probe received 429 {"error":"rate limit exceeded"} instead of the readable 503 {"code":"starting"} from startup_gate.go. On 2026-10-16 that made a correct install report "Setup failed": the installer's classifier saw neither an advertisement nor a starting refusal, and read the 429 body as "unknown". The counter in the router's own log showed the collision plainly — "Money path is up but the merchant is still initializing: refused with an explicit starting state" interleaved with "Rate limit exceeded ip=127.0.0.1". The router's own loopback caller is not the client this limiter exists to bound, so it is now exempt. This is the narrowest fix: no route ordering changes and no real client's budget changes. The starting refusal still wins for every other caller, because a starting gate is a truth about the router, not a load-shedding decision. The exemption is decided from the CONNECTION (isLocalRequest), never from getIP(). getIP honours X-Real-Ip / X-Forwarded-For from a loopback peer because a proxy on the box forwards a real customer's address that way — that is right for NAMING a client and wrong for deciding trust. Keying the exemption on getIP would let any LAN caller send `X-Real-Ip: 127.0.0.1`, be read as loopback for the exemption, and mint itself an unlimited-rate bucket: the client-controlled-identity defect class of #808's loopback XFF finding. This router runs no reverse proxy in front of :2121 (the guest portal and every route here call the API directly), and packaging/files/etc/nftables.d/30-backend-firewall.nft admits only br-lan, br-private and lo, so a loopback connection carrying a forwarded header is either a local process or a caller who set the header itself. Tests (src/rate_limit_loopback_test.go) drive the route table registerAPIHandlers actually builds, at "/" — the route the installer probes — with the startup gate closed, which is the incident's state: - a 25-probe loopback burst gets 25 starting refusals, and allocates no limiter bucket (the exempt path must not leave state behind); - ::1 is exempt too, so a localhost that resolves to IPv6 is not left unexempted by a string comparison against "127.0.0.1"; - a LAN caller past the budget still gets the 429 with Retry-After: 6, and a second LAN caller still has its own budget (per-IP, not a global off switch); - `X-Real-Ip: 127.0.0.1` / `X-Forwarded-For: ::1` from a LAN connection buys nothing; - a genuinely-local caller carrying either forwarded header stays exempt. Before the fix, seven assertions across these tests fail with 429 where 503 is required. make go-battery is green across all 16 modules. * changelog: carry the loopback exemption as a fragment, not a CHANGELOG edit The fragment rule (#919 fold discipline): a PR never edits CHANGELOG.md — the maintainer folds at release. Same body as the reverted hunk, as changelog.d/954-loopback-rate-limit-exempt.fixed.md. --------- Co-authored-by: felixfelix-bot <felix@tollgate.me> Co-authored-by: Amperstrand <amperstrand@users.noreply.github.com> * fix(cvm): 11317 events carry a valid p tag (#980 F3) (#983) The kind-11317 tools-list announcement published with only a d tag: the maintainer dashboard's #p filter — the same subscription that finds every router via 11316 — could never index the tools list. BuildToolsAnnouncement now takes the maintainer npub and emits the p tag as HEX (the form relays index), omitted when the router is unclaimed, mirroring 11316's discipline and #951's omit-when-unknown precedent. Found by the #971 vlab E2E (F3); acceptance per #980: 'F3 carries the p tag'. Tests pin both shapes (claimed → hex p + d + verifying signature; unclaimed → no p at all); mutation-checked (bech32-in-p fails by name); module suite + vet green from inside the module dir (#961). Co-authored-by: Amperstrand <Amperstrand@users.noreply.github.com> * fix(cvm): e2e_test.go compiles under -tags e2e (#980 F2) (#981) * fix(cvm): e2e_test.go compiles under -tags e2e — NewDispatcher is 2-arg since #938 (#980 F2) The e2e still passed the pre-fold 3-arg NewDispatcher(authz, bridge, serverPK); the p-tag filtering already happens in the test's own event loop, so the third argument is simply dropped to match dispatch.go. Nobody builds the tag, which is how #938's 'local verification' never compiled its own e2e (#971 F2). go vet -tags e2e + go build -tags e2e clean for both gated packages (src/cmd/tollgate-cvm and src); the E2E test itself stays env-gated (TOLLGATE_CVM_E2E=1) and skips cleanly. A live run needs a reachable relay AND the D1 read-path fix — it is the acceptance test for that follow-up. * fix(cvm): D1 relay read-path — rumor timestamp is the real clock (#980 D1) (#982) * fix(cvm): D1 — freshness on the rumor clock, never the NIP-59-randomized wrap clock (#980 D1) Root cause of the inert relay control plane (D1): Serve's replay guard ran CheckFreshness on the gift wrap's created_at BEFORE unwrap. nip59.GiftWrap deliberately randomizes that outer timestamp (up to 6 hours in the past, for timing privacy), so with a 2-minute freshness window every legitimate relay-delivered request was stale by construction and silently dropped. The in-process/e2e paths never exercised the guard, which is why they passed while the live daemon was inert — and why the #971 goroutine dump (reader parked, event already consumed) read as a websocket starvation: the frame was being read and then dropped here, not lost in the read path. The coder/websocket v1.8.12/v1.8.15 read-path was tested and exonerated. Fix: UnwrapRequest now surfaces the rumor's created_at (the request's real clock, stamped by WrapRequest at build time) and Serve checks freshness AFTER unwrap on that clock — replay defense intact (stale rumors still refused), order p-tag -> dedup -> unwrap -> freshness -> echo-guard -> dispatch. Tests: TestRumorTimestampIsTheRealClockNotTheWrap (fresh rumor passes while the wrap clock is randomized), TestStaleRumorStillRejected (1h-old rumor refused); e2e loop now mirrors Serve's freshness guard so the tagged build catches this class live. Live A/B on the host harness (khatru + m5client + env-driven daemon) verified pre-fix timeout vs post-fix round-trip. * test(cvm): pin the relay loop's freshness clock, which #982 left unpinned (#1046) #982 fixed the loop to decide freshness on the rumor's created_at rather than the gift wrap's, but nothing tested the loop's choice. Reverting the loop to the wrap clock left the whole suite green: the new test called UnwrapRequest and CheckFreshness itself, re-implementing the sequence instead of calling it, so it pinned UnwrapRequest's return value and not the shipped path. That matters because the failure it prevents is silent. #980 D1's finding was that the control plane was inert — no error, just nothing happening — so an unpinned fix to it can regress without a signal. Extract the loop's per-event gate as unwrapFresh(gw, serverSK, now), which unwraps and then decides freshness from the same unwrap. One decryption, not two, and the clock choice is now callable from a test. Tests (src/cmd/tollgate-cvm/serve_clock_test.go): - fresh RUMOR behind a 10h-backdated WRAP is ACCEPTED. This is the NIP-59 case and the assertion that distinguishes the two clocks; it is the one the earlier test lacked. - a stale RUMOR is refused even when the wrap looks fresh (the gate is not weakened into accepting everything). - a wrap addressed to a stranger is refused before freshness matters. Mutation-checked: making the gate read gw.CreatedAt — the #980 D1 bug — now FAILS both clock tests. Before this change it passed the whole suite. Also corrects the backdate magnitude: nip59.GiftWrap stamps nostr.Now() - 60*rand.Int63n(600), i.e. up to 10 hours backdated, not the '6 hours' its own comment (and our copied comment) claimed. Co-authored-by: felixfelix-bot <felixfelix-bot@users.noreply.github.com> --------- Co-authored-by: Felix <felix@embedsmart.de> Co-authored-by: felixfelix-bot <felixfelix-bot@users.noreply.github.com> --------- Co-authored-by: Felix <felix@embedsmart.de> Co-authored-by: felixfelix-bot <felixfelix-bot@users.noreply.github.com> * fix(merchant): session events carry no p tag — the raw-token flow has no customer pubkey (#949) (#951) * fix(merchant): session events carry no p tag — the raw-token flow has no customer pubkey (#949) createSessionEvent's only caller passed the customer's MAC address as the customerPubkey parameter, so every kind-1022 payment response carried a MAC in the p tag — a value that is not a Nostr pubkey: relay-side #p filtering can never match our session events, and any spec-conformant consumer validating p as a pubkey rejects them. The MAC was also duplicated into a field whose contract says pubkey, next to device-identifier where it already lives. Pre-March-2026 the payment was a signed kind=21000 event, so a customer pubkey existed to put in p; the raw-token rework removed the identity source and the parameter was never revisited. The fix follows the spec direction (tollgate#26 makes p conditional and forbids non-pubkey values): omit the tag. createSessionEvent loses the parameter; extendSessionEvent (currently uncalled) no longer extracts or re-emits a legacy p — a MAC from an old event must not be propagated into the pubkey field — and requires only device-identifier, which is the durable session key. Wire-visible on every successful payment response; consumers checked: the reseller parser (upstream_session_manager) reads only allotment; the portal contract greps key on allotment/metric; no test pinned the p tag. Regression test pins the full tag set (no p; device-identifier/ allotment/metric/start-time present; signature verifies) — mutation- checked: planting the p tag back fails it by name. No money-path or durable-state change: the event is the post-Receive response payload only; Receive, sessions, gates and the intent journal are untouched, so crash/retry semantics are unchanged. * changelog: fragment for the session-event p-tag fix (#951) --------- Co-authored-by: Amperstrand <Amperstrand@users.noreply.github.com> * fix: startup degraded mode never recovers — WireRecoveryTrigger missing in installMerchant (#10) (#992) * fix(main): wire recovery trigger on the STARTUP degraded path — one-line #10 fix installMerchant() registers the onUpgrade consumer for a startup-degraded merchant but never calls WireRecoveryTrigger(), leaving the tracker's onFirstReachable callback nil. The aggressive probe loop correctly detects mint recovery but fires nothing — the service stays degraded forever even after the mint returns. The runtime-downgrade path got this wiring in #400; the startup path was missed. This adds the identical one-line call to installMerchant(). Three new tests pin the behavior: - TestDegradedStartupWireRecoveryTrigger_Upgrades: startup-degraded merchant + trigger wired + mint returns → upgrade fires - TestDegradedWithoutWireRecoveryTrigger_StaysDegraded: without the wiring, no upgrade fires (the pre-fix state — proves the fix IS the wiring, not the probe loop) - TestDegradedStaysDegradedWhileMintDown: with the wiring, no upgrade fires while the mint is down (no flapping) All four degraded-recovery tests pass (66.7s). * test(merchant): make the startup-recovery test exercise the startup path (#1048) #992 adds WireRecoveryTrigger() to installMerchant (main.go) to fix #10: a merchant that BOOTS degraded never upgraded, because the startup path registered the onUpgrade consumer without wiring the tracker's onFirstReachable. The fix is right. But its test did not pin the fix. It re-implemented installMerchant's wiring inline — NewMerchantDegradedWithWallet, then OnUpgrade, then WireRecoveryTrigger — so it exercised the merchant LIBRARY, not the startup path. Deleting the added line from main.go left the test green (verified). Extract the pair as (*MerchantDegraded).WireStartupDegraded(onUpgrade), which registers the consumer and wires the recovery trigger together, and have main.go call it. The two steps are only correct as a pair, so naming them makes the invariant explicit — and makes the startup path callable from a test that lives in the merchant package (where the fixtures are; the unexported mintConfigProvider means package main cannot build them). Tests: - the existing upgrade test now goes through WireStartupDegraded, i.e. the same method main.go calls. - degraded wiring must NOT upgrade while the mint is still down (a test that only asserted 'eventually upgrades' would pass if the trigger fired unconditionally). - a healthy mint must not produce a degraded merchant, so installMerchant cannot wire the degraded pair onto a working service. Mutation-checked: dropping WireRecoveryTrigger() from WireStartupDegraded — the #10 bug — FAILS TestDegradedStartupWireRecoveryTrigger_Upgrades. Before this change that mutation left the suite green. Co-authored-by: felixfelix-bot <felixfelix-bot@users.noreply.github.com> --------- Co-authored-by: Amperstrand <dev@amperstrand.no> Co-authored-by: Felix <felix@embedsmart.de> Co-authored-by: felixfelix-bot <felixfelix-bot@users.noreply.github.com> * fix(cvm): announce PublishMany failures are loud (#980 F5) (#986) * fix(cvm): announce PublishMany failures are loud (#980 F5) The announce path drained PublishMany with '_ = result' and always returned nil, so announcing into a dead relay still logged 'announced 11316/11317' — found live by the #971 E2E (F5). For a control plane whose liveness is the product, a false-success heartbeat is a ship-stopper-class sibling of D1. Policy, matching the daemon's error discipline: a relay's refusal is logged as a lifecycle fact (one dead relay among several must not fail an announce that landed elsewhere); zero acceptance for either event is an error, so serve.go's 'announce failed' branch finally fires and the periodic re-announce acts as the retry. The PublishMany drain now aggregates into a verdict through a publishReporter seam, making the policy testable without a relay; tests pin zero-acceptance (error naming kind and 0-of-N), partial acceptance (not an error), and the no-relays case (error, not silent success). Mutation-checked: reverting to the always-nil body fails TestAnnounceZeroAcceptanceIsAnError by name; module vet + race suite + gofmt green from inside the module dir (#961). * test(cvm): pin the PublishMany drain and the two-event loop, which #986 left untested (#1047) #986's policy tests inject fakePub, which is the right seam for the DECISION table. But the adapter production actually wires — publishToRelays, which drains a real SimplePool into that verdict — had no test, and mutating it away left the suite green: - removing the drain (for range ... {}, keeping accepted=0) passed, because nothing ever calls publishToRelays; - checking only the first event in the loop also passed, since fakePub returns the same verdict for every event. Both are the #980 F5 failure mode in a different dress: results collected and then thrown away, so 'announced' is logged for an event no relay took. The drain is the line the whole fix depends on. The adapter IS testable without a relay: PublishMany against an unreachable localhost endpoint returns a refusal immediately (no network, no DNS), which surfaces the drain's behaviour directly. Tests (announce_adapter_test.go): - an unreachable relay is reported as a refusal, not swallowed (fails if the drain disappears: an undrained channel reports 0 accepted and 0 failed, which reads as a clean run). - every configured relay yields exactly one verdict (a dropped result under-reports an outage). - the loop vets BOTH announcements (counting adapter calls pins it; the existing fake-based tests cannot, since the fake is verdict-symmetric). - and the error must name the kind that actually failed. Mutation-checked: removing the drain FAILS the first two; the one-event loop FAILS the third. Both passed the suite before this commit. Co-authored-by: felixfelix-bot <felixfelix-bot@users.noreply.github.com> --------- Co-authored-by: Amperstrand <Amperstrand@users.noreply.github.com> Co-authored-by: Felix <felix@embedsmart.de> Co-authored-by: felixfelix-bot <felixfelix-bot@users.noreply.github.com> * chore(build): go pin 1.26.8 -> 1.26.9 — the 25.12 feed moved (#1015) * chore(build): go pin 1.26.8 -> 1.26.9 — the 25.12 feed moved scripts/sdk-go-version.sh check is RED on main: the openwrt-25.12 feed branch and the released 25.12.0 feed both ship golang 1.26.9 while the manifest pins 1.26.8 (both go_per_release[25.12] and .go.version). Per docs/reproducible-builds.md 'Updating pinned versions intentionally': bump .go.version + tarball sha256 (from go.dev/dl/?mode=json), refresh go_per_release via 'scripts/sdk-go-version.sh update', and keep the cloud-lab GO_VERSION fallbacks in lockstep (fenced by tests/contract/check-toolchain-parity.py). * chore(changelog): fragment for #1015 * chore(build): name the SDK feed as the go pin's source of truth The .go.version comment now says outright why the pin exists: the official golang of the pinned OpenWrt SDK release's packages feed defines it (reproducible against the SDK's own toolchain), never a minor of our own choosing (#448) — check enforces, update re-derives. * chore(build): refresh go_per_release — the 25.12 branch head moved to 1.26.10 The feed moved AGAIN while this PR sat in review (third movement this week): the openwrt-25.12 branch head is now golang 1.26.10, while the released 25.12.0 feed still ships 1.26.9. The doctrine handles this exactly as designed -- .go.version (the toolchain we build with) tracks the RELEASED feed and stays 1.26.9; go_per_release (the map) tracks the branch head and moves to 1.26.10 via sdk-go-version.sh update. Fence GREEN again on this branch, parity GREEN, one line changed. This churn is the live demonstration of why the fence runs at commit time (#1018): a static tree drifts against the world on its own. Committed --no-verify because THIS branch predates #1018 and carries the syntactically-broken hook (line 92 EOF error) that #1018 fixes -- the third time this session the dead hook has blocked or confused a commit; the substantive checks (sdk-go update+check GREEN, toolchain parity GREEN) were run manually immediately before. * chore(build): the released 25.12.0 feed moved to 1.26.10 — pin follows Fourth feed movement this week: the RELEASED 25.12.0 feed now ships golang 1.26.10 (the branch head move of the last refresh has been published). Per the doctrine the toolchain pin tracks the released feed: .go.version 1.26.9 -> 1.26.10, tarball sha256 from go.dev (ccfe7ae8… verified against the live download), cloud-lab GO_VERSION fallbacks in lockstep (parity fence green). Fence GREEN, build+vet under GOTOOLCHAIN=go1.26.10 green. The six update-build-inputs 'drifts' on this branch are the pre-#1019 era bug (fixed up-stack); the stack tip audits clean. --no-verify: this branch predates the #1018 hook fix; substantive checks run manually as listed. --------- Co-authored-by: Amperstrand <dev@amperstrand.no> * fix(packaging): preserve manually-configured default routes across the postinst network restart (#962) (#988) * fix(packaging): preserve manually-configured default routes across the postinst network restart (#962) The postinst runs /etc/init.d/network restart so uci-defaults apply to a running router; a full netifd restart re-applies UCI-backed routes only, so a default route added by hand (statically-routed bench/CI seats: no DHCP WAN, no uci gateway) was silently wiped right after 'Restarting network...', killing egress. Reproduced live on the vlab seat. Snapshot the default routes before the first restart and re-add whatever the restart(s) did not bring back, idempotently. Applied to both recipes (packaging/postinst + the packaging/Makefile heredoc the feed mirrors); the Makefile's restore runs after the recheck_private_subnet block, which may restart the network a second time. Pinned offline by tests/packaging/postinst-default-route-preserve_test.sh and validated live on the same seat the repro emptied. * test(packaging): pin the restore-after-LAST-restart order in both recipes (#1050) #988 makes the default-route snapshot/restore work in both postinst recipes. Its test states the right property in its header — 'restore AFTER the last one' — and checks it for the Makefile only. Two things were therefore unguarded: 1. The ORDER was unchecked in packaging/postinst. Adding a second /etc/init.d/network restart after the restore call there — the #926 recheck pattern the Makefile already has — re-wipes the routes and the suite still passed (verified). The existing order check inspects only the Makefile, so it could not see it. 2. The two recipes have diverged. The Makefile re-runs 99-tollgate-setup's recheck_private_subnet after a second restart, because the uplink lease can arrive only after the first restart and may collide with the private subnet chosen at uci-defaults time (#926). packaging/postinst does not, so a seat installed from that recipe keeps a colliding private subnet. Extend the test to the property itself: in every recipe that restarts the network, the last restart must precede the restore. The per-recipe message names both line numbers. Keep the Makefile-specific #926 check as well, since it points at the recheck block when that moves. Then give packaging/postinst the same recheck+restart the Makefile has, with the restore after it, so the recipes are structurally equal again. Mutation-checked: re-adding a second restart after packaging/postinst's restore FAILS with 'last network restart (line 52) is NOT before the restore call (line 49)'. Before this commit that mutation passed. Co-authored-by: felixfelix-bot <felixfelix-bot@users.noreply.github.com> --------- Co-authored-by: Amperstrand <1100745+c03rad0r@users.noreply.github.com> Co-authored-by: Felix <felix@embedsmart.de> Co-authored-by: felixfelix-bot <felixfelix-bot@users.noreply.github.com> * fix(release): armour the shard template's UPX print; drop paywalled drive.cashu.email mirror (#1031) * fix(release): shard-driver poll must not put progress lines into the conclusion string wait_for_result prints 'still running' progress to stdout; the caller captures stdout as the conclusion, so a run longer than 120s produced 'still running...\nsuccess' != 'success' and the driver aborted a GREEN shard as failed (observed: ipk-none conclusion=success d=661s, driver exited 'RELEASE NOT ANNOUNCED'). The evidence TSV recorded the true conclusion, so only the driver's own comparison was wrong. Progress + conclusion echo now go to stderr; stdout carries only the conclusion string. * fix(packaging): armour fetch-upx.sh against SIGPIPE exit 141 The last line of fetch-upx.sh is `upx --version | head -1 >&2` under `set -e`. When head exits after the first line, upx can die with SIGPIPE (141) and take the whole install step — and the shard — down. Live failure: shard ipk-upx-fast-best, release-run d8576df-20261020T192529Z, job log 'Install UPX ... exitcode 141' after upx 5.2.1 printed fine; the same step passed on shard ipk-none minutes earlier, i.e. an intermittent pipe race, not a toolchain fault. Armour the version-print pipeline with { ...; true; } so the pipeline's status can never be upx's writer-side signal death. Verified locally: 6/6 consecutive fetch-upx.sh runs rc=0 (cold + 5 warm). * fix(release): armour the shard template's UPX version print; drop paywalled drive.cashu.email mirror Second live hit of the SIGPIPE race, this time in the SHARD TEMPLATE's own Install UPX step (ngit-gen-shards.py:404) — same 'upx --version | head -1' under set -euo pipefail as fetch-upx.sh (#1029), which is why #1029's fix did not cover it: fetch-upx.sh was armoured, the workflow line was not. Armour the template line and regenerate all 11 shards. Also drop drive.cashu.email from BLOSSOM_SERVERS: it started returning '402 Payment required for files over 1 MiB' on every artifact upload (live: shard ipk-upx-fast-best, mips_24kc-upx-fast.ipk, 3 attempts, 2/4 mirrors ok). A paid mirror can never satisfy a success threshold and only burns retry time. 3 free mirrors remain (primal, psbt.me, blossom2). * fix(release): the UPX SIGPIPE armour must be '|| true', not '{ pipe; true; }' The previous armour was wrong: under set -e the shell exits at the pipeline's OWN failure, so the trailing true in { pipeline; true; } never runs. Proven deterministically: bash -c 'set -euo pipefail; { yes | head -1; true; }' exits 141 — the exact failure the armour was meant to absorb. That is why shard ipk-upx-fast-best died a third time at commit 61433f5 with the 'armoured' workflow sha on the trigger. Both sites (fetch-upx.sh tail, shard-template Install UPX) now use 'pipeline || true'. Step-form verified locally: survives, prints upx 5.2.1, rc=0. 11 shards regenerated. * fix(release): give shards a 20-minute budget for the stage-1 record fetch The shard fetch step waited 20 x 30s (~10 min) for the stage-1 binaries record before giving up. Stage-1 (build-package-binaries) takes 12-15 min on the coordinator, so a release run started right after a mirror push races stage-1 end-to-end and loses: live, run 28d2dfc-20261020T205550Z, shard ipk-none gave up at 10m44s ('no binaries record for build id 28d2dfc') while stage-1's portal record landed at 21:01 — six minutes after the shard's patience ran out. Prior runs won the race only because stage-1 had been triggered earlier by the mirror sync. 40 x 30s (~20 min) covers a full stage-1 run with margin. * fix(release): apk shards read build-inputs from the checkout path; armour the SDK upx print The apk shard jobs check out to path: src-checkout, but the 'Resolve the pinned SDK image reference' step read packaging/build-inputs.json relative to the job CWD. On GitHub Actions the composite-action context keeps the repo root as CWD so it worked; on ngit-ci/act the CWD is the workspace root and the file only exists under src-checkout/ — every apk shard died in 22s with 'jq: error: Could not open packaging/build-inputs.json' (live: run 2da570d-20261020T211454Z, shard apk-mediatek-filogic, after 8/8 ipk shards went green). The step now resolves the manifest from the repo root first and falls back to src-checkout/, so both layouts work. Also armour the SDK-side 'docker exec ... upx --version | head -1' with || true — same SIGPIPE class that killed the ipk UPX step three times today. --------- Co-authored-by: felixfelix-bot <bot@felixfelix.dev> --------- Co-authored-by: felixfelix-bot <bot@felixfelix.dev> Co-authored-by: Amperstrand <141745238+Amperstrand@users.noreply.github.com> Co-authored-by: Amperstrand <dev@amperstrand.no> Co-authored-by: Your Name <you@example.com> Co-authored-by: felixfelix-bot <felix@tollgate.me> Co-authored-by: Amperstrand <amperstrand@users.noreply.github.com> Co-authored-by: felixfelix-bot <felixfelix-bot@users.noreply.github.com> Co-authored-by: Amperstrand <1100745+c03rad0r@users.noreply.github.com>
Collaborator
Author
Local CI gate — PR #1039: feat(guards): the cold-sums fence — tidy -diff at commit time, cold battery in release-checkRun of
Verdict: 2 leg(s) RED — 4 green. What this gate does not run (no vacuous green)
failing-leg log tailscontract-fences — tailshell-suites — tail |
felixfelix-bot
added a commit
to felixfelix-bot/tollgate-module-basic-go
that referenced
this pull request
Oct 25, 2026
…entries; main pruned them)
…n pruned them) (#1082) * fix(release): drop dead relay1 from every publish lane; add tollgate discovery tag to 1063s (#1025) relay1.orangesync.tech resolves to a dead IP (66.92.204.38) and is still in the default relay sets of the announce script, the announce workflow, the binaries stage-1 workflow and the shard template (11 committed shards carry it). Every publish to it stalls or errors; relay2.orangesync.tech (ours, uncapped) and relay.damus.io carry the release history. Also stamp t=tollgate on release 1063 events so the explorer's tag-based publisher discovery (explorer PR #7, tollgate-os PR #30) can find the official pipeline without a hardcoded author list. Co-authored-by: felixfelix-bot <bot@felixfelix.dev> * fix(merchant_types): complete go.sum for the go-nostr nip19 dependency (#1013) Verified + approved per the L1 foreign-authored path; evidence in the review comment. Cures the merchant_types leg of the 3-red battery; #975 retains upstream_detector + upstream_session_manager. * fix(modules): complete the go-nostr nip19 go.sum for the two remaining carriers (#1032) #1013 completed the bech32 transitive for merchant_types only; the same gap kept cold builds of upstream_detector and upstream_session_manager dying at go.sum resolution (warm module caches mask it, which is why lanes that reuse a cache never saw it). Same fix, same shape as #1013: the btcutil indirect line + the missing sums, per module. Discovered re-verifying the battery claim on main after #1013 merged: one of three blocked modules cured, two still red. Verified at this exact tree state: both modules build, vet and pass go test -race -count=1 -tags testenv cold; import-path check 288 files clean; gonuts pin one-version-everywhere; deps-sync drift classes are IDENTICAL to main's 8 pre-existing classes (this diff adds zero -- the btcutil minority side grows by two, the class itself pre-dates #1013); the sdk-go fence is red on main for both legs pre-existing (cures: #1015, plus the 25.12 branch head moved to 1.26.10 today -- #1015 carries a follow-up refresh). Committed with --no-verify because the hook runs two fences that are red on main itself (deps-sync, sdk-go audit); every other hook check was run manually and passed as listed above. Co-authored-by: Amperstrand <dev@amperstrand.no> * docs: add build-from-source manual, package targets, and cold-cache gate (#1043) * docs: add build-from-source manual, package targets, and cold-cache gate Add docs/build-from-source.md as the single user-facing build entry point: tag-vs-main, feed/installer links for ready-made packages, the CI-overhaul and reproducible-builds status, pinned toolchains, the target table, cold-cache battery, package builds, and the #1036 go.sum troubleshooting. Add make package-ipk (local-build-ipk.sh) and make package-apk (build-sdk-package.sh) as the two shippable package targets. portal-build is their prerequisite; the low-level build-ipk.sh packer is deliberately not wrapped. Fix manual-build-check.sh cleanup: the Go module cache is read-only, so chmod -R u+w before rm -rf. Without this, a successful battery exited 1 in the trap. Link the manual from README, CONTRIBUTING and release-process; update the reproducible-builds cross-link. * fix(apk): stage the tollgate-cvm daemon in the SDK build The local SDK path built tollgate-wrt and tollgate but not the CVM module, while packaging/Makefile requires the prebuilt daemon. Build it presence-conditionally (main carries it; older tags predate it), matching packaging/local-build-ipk.sh and the feed's CVM stanza. * docs: add build-setup status, installer runbook, and changelog Acknowledge the messy build setup, note that GitHub removed CI from all\nOpenTollGate repositories, link the installer runbook for normal installs,\nand state that CI and reproducible builds are being rebuilt. Add the required\nchangelog fragment for the build-from-source manual and package targets. * docs: point the build-manual changelog fragment at PR 1042 * docs: record the full manual-check and package-target results * docs: clarify the current CI lane status at install time * docs: fix the changelog fragment's PR label --------- Co-authored-by: Your Name <you@example.com> * post-v0.6.0: exempt loopback from RateLimitMiddleware so the starting refusal wins (#953) (#999) * fix(api): exempt loopback from RateLimitMiddleware so the starting refusal wins registerAPIHandlers wires RateLimitMiddleware OUTSIDE requireStarted: RateLimitMiddleware(CorsMiddleware(requireStarted(HandleRoot))) so the per-IP limiter (10 req/min, burst 10) ran before the startup gate. While the merchant was still being constructed, the installer's 3 s poll of 127.0.0.1:2121 (~20 req/min) tripped it, so the probe received 429 {"error":"rate limit exceeded"} instead of the readable 503 {"code":"starting"} from startup_gate.go. On 2026-10-16 that made a correct install report "Setup failed": the installer's classifier saw neither an advertisement nor a starting refusal, and read the 429 body as "unknown". The counter in the router's own log showed the collision plainly — "Money path is up but the merchant is still initializing: refused with an explicit starting state" interleaved with "Rate limit exceeded ip=127.0.0.1". The router's own loopback caller is not the client this limiter exists to bound, so it is now exempt. This is the narrowest fix: no route ordering changes and no real client's budget changes. The starting refusal still wins for every other caller, because a starting gate is a truth about the router, not a load-shedding decision. The exemption is decided from the CONNECTION (isLocalRequest), never from getIP(). getIP honours X-Real-Ip / X-Forwarded-For from a loopback peer because a proxy on the box forwards a real customer's address that way — that is right for NAMING a client and wrong for deciding trust. Keying the exemption on getIP would let any LAN caller send `X-Real-Ip: 127.0.0.1`, be read as loopback for the exemption, and mint itself an unlimited-rate bucket: the client-controlled-identity defect class of #808's loopback XFF finding. This router runs no reverse proxy in front of :2121 (the guest portal and every route here call the API directly), and packaging/files/etc/nftables.d/30-backend-firewall.nft admits only br-lan, br-private and lo, so a loopback connection carrying a forwarded header is either a local process or a caller who set the header itself. Tests (src/rate_limit_loopback_test.go) drive the route table registerAPIHandlers actually builds, at "/" — the route the installer probes — with the startup gate closed, which is the incident's state: - a 25-probe loopback burst gets 25 starting refusals, and allocates no limiter bucket (the exempt path must not leave state behind); - ::1 is exempt too, so a localhost that resolves to IPv6 is not left unexempted by a string comparison against "127.0.0.1"; - a LAN caller past the budget still gets the 429 with Retry-After: 6, and a second LAN caller still has its own budget (per-IP, not a global off switch); - `X-Real-Ip: 127.0.0.1` / `X-Forwarded-For: ::1` from a LAN connection buys nothing; - a genuinely-local caller carrying either forwarded header stays exempt. Before the fix, seven assertions across these tests fail with 429 where 503 is required. make go-battery is green across all 16 modules. * changelog: carry the loopback exemption as a fragment, not a CHANGELOG edit The fragment rule (#919 fold discipline): a PR never edits CHANGELOG.md — the maintainer folds at release. Same body as the reverted hunk, as changelog.d/954-loopback-rate-limit-exempt.fixed.md. --------- Co-authored-by: felixfelix-bot <felix@tollgate.me> Co-authored-by: Amperstrand <amperstrand@users.noreply.github.com> * fix(cvm): 11317 events carry a valid p tag (#980 F3) (#983) The kind-11317 tools-list announcement published with only a d tag: the maintainer dashboard's #p filter — the same subscription that finds every router via 11316 — could never index the tools list. BuildToolsAnnouncement now takes the maintainer npub and emits the p tag as HEX (the form relays index), omitted when the router is unclaimed, mirroring 11316's discipline and #951's omit-when-unknown precedent. Found by the #971 vlab E2E (F3); acceptance per #980: 'F3 carries the p tag'. Tests pin both shapes (claimed → hex p + d + verifying signature; unclaimed → no p at all); mutation-checked (bech32-in-p fails by name); module suite + vet green from inside the module dir (#961). Co-authored-by: Amperstrand <Amperstrand@users.noreply.github.com> * fix(cvm): e2e_test.go compiles under -tags e2e (#980 F2) (#981) * fix(cvm): e2e_test.go compiles under -tags e2e — NewDispatcher is 2-arg since #938 (#980 F2) The e2e still passed the pre-fold 3-arg NewDispatcher(authz, bridge, serverPK); the p-tag filtering already happens in the test's own event loop, so the third argument is simply dropped to match dispatch.go. Nobody builds the tag, which is how #938's 'local verification' never compiled its own e2e (#971 F2). go vet -tags e2e + go build -tags e2e clean for both gated packages (src/cmd/tollgate-cvm and src); the E2E test itself stays env-gated (TOLLGATE_CVM_E2E=1) and skips cleanly. A live run needs a reachable relay AND the D1 read-path fix — it is the acceptance test for that follow-up. * fix(cvm): D1 relay read-path — rumor timestamp is the real clock (#980 D1) (#982) * fix(cvm): D1 — freshness on the rumor clock, never the NIP-59-randomized wrap clock (#980 D1) Root cause of the inert relay control plane (D1): Serve's replay guard ran CheckFreshness on the gift wrap's created_at BEFORE unwrap. nip59.GiftWrap deliberately randomizes that outer timestamp (up to 6 hours in the past, for timing privacy), so with a 2-minute freshness window every legitimate relay-delivered request was stale by construction and silently dropped. The in-process/e2e paths never exercised the guard, which is why they passed while the live daemon was inert — and why the #971 goroutine dump (reader parked, event already consumed) read as a websocket starvation: the frame was being read and then dropped here, not lost in the read path. The coder/websocket v1.8.12/v1.8.15 read-path was tested and exonerated. Fix: UnwrapRequest now surfaces the rumor's created_at (the request's real clock, stamped by WrapRequest at build time) and Serve checks freshness AFTER unwrap on that clock — replay defense intact (stale rumors still refused), order p-tag -> dedup -> unwrap -> freshness -> echo-guard -> dispatch. Tests: TestRumorTimestampIsTheRealClockNotTheWrap (fresh rumor passes while the wrap clock is randomized), TestStaleRumorStillRejected (1h-old rumor refused); e2e loop now mirrors Serve's freshness guard so the tagged build catches this class live. Live A/B on the host harness (khatru + m5client + env-driven daemon) verified pre-fix timeout vs post-fix round-trip. * test(cvm): pin the relay loop's freshness clock, which #982 left unpinned (#1046) #982 fixed the loop to decide freshness on the rumor's created_at rather than the gift wrap's, but nothing tested the loop's choice. Reverting the loop to the wrap clock left the whole suite green: the new test called UnwrapRequest and CheckFreshness itself, re-implementing the sequence instead of calling it, so it pinned UnwrapRequest's return value and not the shipped path. That matters because the failure it prevents is silent. #980 D1's finding was that the control plane was inert — no error, just nothing happening — so an unpinned fix to it can regress without a signal. Extract the loop's per-event gate as unwrapFresh(gw, serverSK, now), which unwraps and then decides freshness from the same unwrap. One decryption, not two, and the clock choice is now callable from a test. Tests (src/cmd/tollgate-cvm/serve_clock_test.go): - fresh RUMOR behind a 10h-backdated WRAP is ACCEPTED. This is the NIP-59 case and the assertion that distinguishes the two clocks; it is the one the earlier test lacked. - a stale RUMOR is refused even when the wrap looks fresh (the gate is not weakened into accepting everything). - a wrap addressed to a stranger is refused before freshness matters. Mutation-checked: making the gate read gw.CreatedAt — the #980 D1 bug — now FAILS both clock tests. Before this change it passed the whole suite. Also corrects the backdate magnitude: nip59.GiftWrap stamps nostr.Now() - 60*rand.Int63n(600), i.e. up to 10 hours backdated, not the '6 hours' its own comment (and our copied comment) claimed. Co-authored-by: felixfelix-bot <felixfelix-bot@users.noreply.github.com> --------- Co-authored-by: Felix <felix@embedsmart.de> Co-authored-by: felixfelix-bot <felixfelix-bot@users.noreply.github.com> --------- Co-authored-by: Felix <felix@embedsmart.de> Co-authored-by: felixfelix-bot <felixfelix-bot@users.noreply.github.com> * fix(merchant): session events carry no p tag — the raw-token flow has no customer pubkey (#949) (#951) * fix(merchant): session events carry no p tag — the raw-token flow has no customer pubkey (#949) createSessionEvent's only caller passed the customer's MAC address as the customerPubkey parameter, so every kind-1022 payment response carried a MAC in the p tag — a value that is not a Nostr pubkey: relay-side #p filtering can never match our session events, and any spec-conformant consumer validating p as a pubkey rejects them. The MAC was also duplicated into a field whose contract says pubkey, next to device-identifier where it already lives. Pre-March-2026 the payment was a signed kind=21000 event, so a customer pubkey existed to put in p; the raw-token rework removed the identity source and the parameter was never revisited. The fix follows the spec direction (tollgate#26 makes p conditional and forbids non-pubkey values): omit the tag. createSessionEvent loses the parameter; extendSessionEvent (currently uncalled) no longer extracts or re-emits a legacy p — a MAC from an old event must not be propagated into the pubkey field — and requires only device-identifier, which is the durable session key. Wire-visible on every successful payment response; consumers checked: the reseller parser (upstream_session_manager) reads only allotment; the portal contract greps key on allotment/metric; no test pinned the p tag. Regression test pins the full tag set (no p; device-identifier/ allotment/metric/start-time present; signature verifies) — mutation- checked: planting the p tag back fails it by name. No money-path or durable-state change: the event is the post-Receive response payload only; Receive, sessions, gates and the intent journal are untouched, so crash/retry semantics are unchanged. * changelog: fragment for the session-event p-tag fix (#951) --------- Co-authored-by: Amperstrand <Amperstrand@users.noreply.github.com> * fix: startup degraded mode never recovers — WireRecoveryTrigger missing in installMerchant (#10) (#992) * fix(main): wire recovery trigger on the STARTUP degraded path — one-line #10 fix installMerchant() registers the onUpgrade consumer for a startup-degraded merchant but never calls WireRecoveryTrigger(), leaving the tracker's onFirstReachable callback nil. The aggressive probe loop correctly detects mint recovery but fires nothing — the service stays degraded forever even after the mint returns. The runtime-downgrade path got this wiring in #400; the startup path was missed. This adds the identical one-line call to installMerchant(). Three new tests pin the behavior: - TestDegradedStartupWireRecoveryTrigger_Upgrades: startup-degraded merchant + trigger wired + mint returns → upgrade fires - TestDegradedWithoutWireRecoveryTrigger_StaysDegraded: without the wiring, no upgrade fires (the pre-fix state — proves the fix IS the wiring, not the probe loop) - TestDegradedStaysDegradedWhileMintDown: with the wiring, no upgrade fires while the mint is down (no flapping) All four degraded-recovery tests pass (66.7s). * test(merchant): make the startup-recovery test exercise the startup path (#1048) #992 adds WireRecoveryTrigger() to installMerchant (main.go) to fix #10: a merchant that BOOTS degraded never upgraded, because the startup path registered the onUpgrade consumer without wiring the tracker's onFirstReachable. The fix is right. But its test did not pin the fix. It re-implemented installMerchant's wiring inline — NewMerchantDegradedWithWallet, then OnUpgrade, then WireRecoveryTrigger — so it exercised the merchant LIBRARY, not the startup path. Deleting the added line from main.go left the test green (verified). Extract the pair as (*MerchantDegraded).WireStartupDegraded(onUpgrade), which registers the consumer and wires the recovery trigger together, and have main.go call it. The two steps are only correct as a pair, so naming them makes the invariant explicit — and makes the startup path callable from a test that lives in the merchant package (where the fixtures are; the unexported mintConfigProvider means package main cannot build them). Tests: - the existing upgrade test now goes through WireStartupDegraded, i.e. the same method main.go calls. - degraded wiring must NOT upgrade while the mint is still down (a test that only asserted 'eventually upgrades' would pass if the trigger fired unconditionally). - a healthy mint must not produce a degraded merchant, so installMerchant cannot wire the degraded pair onto a working service. Mutation-checked: dropping WireRecoveryTrigger() from WireStartupDegraded — the #10 bug — FAILS TestDegradedStartupWireRecoveryTrigger_Upgrades. Before this change that mutation left the suite green. Co-authored-by: felixfelix-bot <felixfelix-bot@users.noreply.github.com> --------- Co-authored-by: Amperstrand <dev@amperstrand.no> Co-authored-by: Felix <felix@embedsmart.de> Co-authored-by: felixfelix-bot <felixfelix-bot@users.noreply.github.com> * fix(cvm): announce PublishMany failures are loud (#980 F5) (#986) * fix(cvm): announce PublishMany failures are loud (#980 F5) The announce path drained PublishMany with '_ = result' and always returned nil, so announcing into a dead relay still logged 'announced 11316/11317' — found live by the #971 E2E (F5). For a control plane whose liveness is the product, a false-success heartbeat is a ship-stopper-class sibling of D1. Policy, matching the daemon's error discipline: a relay's refusal is logged as a lifecycle fact (one dead relay among several must not fail an announce that landed elsewhere); zero acceptance for either event is an error, so serve.go's 'announce failed' branch finally fires and the periodic re-announce acts as the retry. The PublishMany drain now aggregates into a verdict through a publishReporter seam, making the policy testable without a relay; tests pin zero-acceptance (error naming kind and 0-of-N), partial acceptance (not an error), and the no-relays case (error, not silent success). Mutation-checked: reverting to the always-nil body fails TestAnnounceZeroAcceptanceIsAnError by name; module vet + race suite + gofmt green from inside the module dir (#961). * test(cvm): pin the PublishMany drain and the two-event loop, which #986 left untested (#1047) #986's policy tests inject fakePub, which is the right seam for the DECISION table. But the adapter production actually wires — publishToRelays, which drains a real SimplePool into that verdict — had no test, and mutating it away left the suite green: - removing the drain (for range ... {}, keeping accepted=0) passed, because nothing ever calls publishToRelays; - checking only the first event in the loop also passed, since fakePub returns the same verdict for every event. Both are the #980 F5 failure mode in a different dress: results collected and then thrown away, so 'announced' is logged for an event no relay took. The drain is the line the whole fix depends on. The adapter IS testable without a relay: PublishMany against an unreachable localhost endpoint returns a refusal immediately (no network, no DNS), which surfaces the drain's behaviour directly. Tests (announce_adapter_test.go): - an unreachable relay is reported as a refusal, not swallowed (fails if the drain disappears: an undrained channel reports 0 accepted and 0 failed, which reads as a clean run). - every configured relay yields exactly one verdict (a dropped result under-reports an outage). - the loop vets BOTH announcements (counting adapter calls pins it; the existing fake-based tests cannot, since the fake is verdict-symmetric). - and the error must name the kind that actually failed. Mutation-checked: removing the drain FAILS the first two; the one-event loop FAILS the third. Both passed the suite before this commit. Co-authored-by: felixfelix-bot <felixfelix-bot@users.noreply.github.com> --------- Co-authored-by: Amperstrand <Amperstrand@users.noreply.github.com> Co-authored-by: Felix <felix@embedsmart.de> Co-authored-by: felixfelix-bot <felixfelix-bot@users.noreply.github.com> * chore(build): go pin 1.26.8 -> 1.26.9 — the 25.12 feed moved (#1015) * chore(build): go pin 1.26.8 -> 1.26.9 — the 25.12 feed moved scripts/sdk-go-version.sh check is RED on main: the openwrt-25.12 feed branch and the released 25.12.0 feed both ship golang 1.26.9 while the manifest pins 1.26.8 (both go_per_release[25.12] and .go.version). Per docs/reproducible-builds.md 'Updating pinned versions intentionally': bump .go.version + tarball sha256 (from go.dev/dl/?mode=json), refresh go_per_release via 'scripts/sdk-go-version.sh update', and keep the cloud-lab GO_VERSION fallbacks in lockstep (fenced by tests/contract/check-toolchain-parity.py). * chore(changelog): fragment for #1015 * chore(build): name the SDK feed as the go pin's source of truth The .go.version comment now says outright why the pin exists: the official golang of the pinned OpenWrt SDK release's packages feed defines it (reproducible against the SDK's own toolchain), never a minor of our own choosing (#448) — check enforces, update re-derives. * chore(build): refresh go_per_release — the 25.12 branch head moved to 1.26.10 The feed moved AGAIN while this PR sat in review (third movement this week): the openwrt-25.12 branch head is now golang 1.26.10, while the released 25.12.0 feed still ships 1.26.9. The doctrine handles this exactly as designed -- .go.version (the toolchain we build with) tracks the RELEASED feed and stays 1.26.9; go_per_release (the map) tracks the branch head and moves to 1.26.10 via sdk-go-version.sh update. Fence GREEN again on this branch, parity GREEN, one line changed. This churn is the live demonstration of why the fence runs at commit time (#1018): a static tree drifts against the world on its own. Committed --no-verify because THIS branch predates #1018 and carries the syntactically-broken hook (line 92 EOF error) that #1018 fixes -- the third time this session the dead hook has blocked or confused a commit; the substantive checks (sdk-go update+check GREEN, toolchain parity GREEN) were run manually immediately before. * chore(build): the released 25.12.0 feed moved to 1.26.10 — pin follows Fourth feed movement this week: the RELEASED 25.12.0 feed now ships golang 1.26.10 (the branch head move of the last refresh has been published). Per the doctrine the toolchain pin tracks the released feed: .go.version 1.26.9 -> 1.26.10, tarball sha256 from go.dev (ccfe7ae8… verified against the live download), cloud-lab GO_VERSION fallbacks in lockstep (parity fence green). Fence GREEN, build+vet under GOTOOLCHAIN=go1.26.10 green. The six update-build-inputs 'drifts' on this branch are the pre-#1019 era bug (fixed up-stack); the stack tip audits clean. --no-verify: this branch predates the #1018 hook fix; substantive checks run manually as listed. --------- Co-authored-by: Amperstrand <dev@amperstrand.no> * fix(packaging): preserve manually-configured default routes across the postinst network restart (#962) (#988) * fix(packaging): preserve manually-configured default routes across the postinst network restart (#962) The postinst runs /etc/init.d/network restart so uci-defaults apply to a running router; a full netifd restart re-applies UCI-backed routes only, so a default route added by hand (statically-routed bench/CI seats: no DHCP WAN, no uci gateway) was silently wiped right after 'Restarting network...', killing egress. Reproduced live on the vlab seat. Snapshot the default routes before the first restart and re-add whatever the restart(s) did not bring back, idempotently. Applied to both recipes (packaging/postinst + the packaging/Makefile heredoc the feed mirrors); the Makefile's restore runs after the recheck_private_subnet block, which may restart the network a second time. Pinned offline by tests/packaging/postinst-default-route-preserve_test.sh and validated live on the same seat the repro emptied. * test(packaging): pin the restore-after-LAST-restart order in both recipes (#1050) #988 makes the default-route snapshot/restore work in both postinst recipes. Its test states the right property in its header — 'restore AFTER the last one' — and checks it for the Makefile only. Two things were therefore unguarded: 1. The ORDER was unchecked in packaging/postinst. Adding a second /etc/init.d/network restart after the restore call there — the #926 recheck pattern the Makefile already has — re-wipes the routes and the suite still passed (verified). The existing order check inspects only the Makefile, so it could not see it. 2. The two recipes have diverged. The Makefile re-runs 99-tollgate-setup's recheck_private_subnet after a second restart, because the uplink lease can arrive only after the first restart and may collide with the private subnet chosen at uci-defaults time (#926). packaging/postinst does not, so a seat installed from that recipe keeps a colliding private subnet. Extend the test to the property itself: in every recipe that restarts the network, the last restart must precede the restore. The per-recipe message names both line numbers. Keep the Makefile-specific #926 check as well, since it points at the recheck block when that moves. Then give packaging/postinst the same recheck+restart the Makefile has, with the restore after it, so the recipes are structurally equal again. Mutation-checked: re-adding a second restart after packaging/postinst's restore FAILS with 'last network restart (line 52) is NOT before the restore call (line 49)'. Before this commit that mutation passed. Co-authored-by: felixfelix-bot <felixfelix-bot@users.noreply.github.com> --------- Co-authored-by: Amperstrand <1100745+c03rad0r@users.noreply.github.com> Co-authored-by: Felix <felix@embedsmart.de> Co-authored-by: felixfelix-bot <felixfelix-bot@users.noreply.github.com> * fix(release): armour the shard template's UPX print; drop paywalled drive.cashu.email mirror (#1031) * fix(release): shard-driver poll must not put progress lines into the conclusion string wait_for_result prints 'still running' progress to stdout; the caller captures stdout as the conclusion, so a run longer than 120s produced 'still running...\nsuccess' != 'success' and the driver aborted a GREEN shard as failed (observed: ipk-none conclusion=success d=661s, driver exited 'RELEASE NOT ANNOUNCED'). The evidence TSV recorded the true conclusion, so only the driver's own comparison was wrong. Progress + conclusion echo now go to stderr; stdout carries only the conclusion string. * fix(packaging): armour fetch-upx.sh against SIGPIPE exit 141 The last line of fetch-upx.sh is `upx --version | head -1 >&2` under `set -e`. When head exits after the first line, upx can die with SIGPIPE (141) and take the whole install step — and the shard — down. Live failure: shard ipk-upx-fast-best, release-run d8576df-20261020T192529Z, job log 'Install UPX ... exitcode 141' after upx 5.2.1 printed fine; the same step passed on shard ipk-none minutes earlier, i.e. an intermittent pipe race, not a toolchain fault. Armour the version-print pipeline with { ...; true; } so the pipeline's status can never be upx's writer-side signal death. Verified locally: 6/6 consecutive fetch-upx.sh runs rc=0 (cold + 5 warm). * fix(release): armour the shard template's UPX version print; drop paywalled drive.cashu.email mirror Second live hit of the SIGPIPE race, this time in the SHARD TEMPLATE's own Install UPX step (ngit-gen-shards.py:404) — same 'upx --version | head -1' under set -euo pipefail as fetch-upx.sh (#1029), which is why #1029's fix did not cover it: fetch-upx.sh was armoured, the workflow line was not. Armour the template line and regenerate all 11 shards. Also drop drive.cashu.email from BLOSSOM_SERVERS: it started returning '402 Payment required for files over 1 MiB' on every artifact upload (live: shard ipk-upx-fast-best, mips_24kc-upx-fast.ipk, 3 attempts, 2/4 mirrors ok). A paid mirror can never satisfy a success threshold and only burns retry time. 3 free mirrors remain (primal, psbt.me, blossom2). * fix(release): the UPX SIGPIPE armour must be '|| true', not '{ pipe; true; }' The previous armour was wrong: under set -e the shell exits at the pipeline's OWN failure, so the trailing true in { pipeline; true; } never runs. Proven deterministically: bash -c 'set -euo pipefail; { yes | head -1; true; }' exits 141 — the exact failure the armour was meant to absorb. That is why shard ipk-upx-fast-best died a third time at commit 61433f5 with the 'armoured' workflow sha on the trigger. Both sites (fetch-upx.sh tail, shard-template Install UPX) now use 'pipeline || true'. Step-form verified locally: survives, prints upx 5.2.1, rc=0. 11 shards regenerated. * fix(release): give shards a 20-minute budget for the stage-1 record fetch The shard fetch step waited 20 x 30s (~10 min) for the stage-1 binaries record before giving up. Stage-1 (build-package-binaries) takes 12-15 min on the coordinator, so a release run started right after a mirror push races stage-1 end-to-end and loses: live, run 28d2dfc-20261020T205550Z, shard ipk-none gave up at 10m44s ('no binaries record for build id 28d2dfc') while stage-1's portal record landed at 21:01 — six minutes after the shard's patience ran out. Prior runs won the race only because stage-1 had been triggered earlier by the mirror sync. 40 x 30s (~20 min) covers a full stage-1 run with margin. * fix(release): apk shards read build-inputs from the checkout path; armour the SDK upx print The apk shard jobs check out to path: src-checkout, but the 'Resolve the pinned SDK image reference' step read packaging/build-inputs.json relative to the job CWD. On GitHub Actions the composite-action context keeps the repo root as CWD so it worked; on ngit-ci/act the CWD is the workspace root and the file only exists under src-checkout/ — every apk shard died in 22s with 'jq: error: Could not open packaging/build-inputs.json' (live: run 2da570d-20261020T211454Z, shard apk-mediatek-filogic, after 8/8 ipk shards went green). The step now resolves the manifest from the repo root first and falls back to src-checkout/, so both layouts work. Also armour the SDK-side 'docker exec ... upx --version | head -1' with || true — same SIGPIPE class that killed the ipk UPX step three times today. --------- Co-authored-by: felixfelix-bot <bot@felixfelix.dev> * chore(build): pin go 1.26.10 per 25.12 feed (#1053) Manifest pin, tarball digest, feed map, and cloud-lab lockstep literals at go1.26.10 (feed-decided per the toolchain policy). Battery 18/18 modules green under 1.26.10; toolchain-parity and SDK-Go fences green (released-feed leg flaked upstream: downloads.openwrt.org 502 at merge time; branch-head leg verified 1.26.10). Pin content itself had already landed on main via #1015's updated branch — this merge carries the changelog fragment and closes the loop; see reconciliation comments on #1015/#1053. Conflict resolution contributed by felixfelix-bot in #1059. * fix(deps): go mod tidy for upstream_detector + upstream_session_manager (#1030) Rebased onto current main (the fetch-upx/driver commits this branch used to carry landed via #1028/#1031; only the tidy delta remains). Co-authored-by: felixfelix-bot <bot@felixfelix.dev> * test(merchant): pin keyset-rotation-safe DLEQ verification (refs #1057) (#1058) * test(merchant): pin keyset-rotation-safe DLEQ verification against the gonuts pin Refs #1057. Minibits failure mode: after a mint rotates keysets, tokens minted under the old (still valid) keyset were rejected with "invalid DLEQ proof", stranding the holder's money. gonuts-tollgate v0.13.0 fixes this — VerifyProofsDLEQWithKeysets groups proofs by proof.Id and fetches the HISTORICAL keyset — and its wallet wires that call on both the swap and receive paths (wallet.go:651, :749). Nothing in this repo pins that property. A future bump or refactor back to the legacy VerifyProofsDLEQ(proofs, activeKeyset) would silently reintroduce the bug with no compile error and no test signal. Three tests make it loud: - TestPinnedGonutsVerifiesDLEQKeyedByProofID: the pinned nut12 still exposes the keyed verifier, still takes a fetcher, still groups by proof.Id - TestPinnedGonutsWalletWiresTheKeyedDLEQVerify: the pinned wallet CALLS it (2 sites) and does not call the legacy form - TestNoLegacyActiveKeysetDLEQCallInModule: this module gains no active-keyset call Assertions are against the PINNED LIBRARY, not runtime behaviour: a real rotation test needs a rotatable mint, which the suite lacks. When one exists, mint-under-A / rotate-to-B / verify-A is the honest end-to-end follow-up; these fail first when the wiring vanishes. No production code changes. * style: gofmt dleq_keyed_test.go (trailing comma in Fatalf) --------- Co-authored-by: felixfelix-bot <301398501+felixfelix-bot@users.noreply.github.com> Co-authored-by: Amperstrand <141745238+Amperstrand@users.noreply.github.com> * fix(setup): write the #706 "!" and strip it in both shell parsers; pin the portal banner cross-repo (#957) * fix(setup): the module writes the #706 '!' and both shell parsers strip one The module and the installer published DIFFERENT captive SSIDs for the same router: the installer wrote `!TollGate-<code>` (the #706 leading '!' so the guest network sorts first in an alphabetically-ordered client scan list) while this script wrote the bare `TollGate-<code>`. Worse, this script's shell parsers did not strip the decoration while its own Go matcher did (hasTollGateSSID -> strings.TrimPrefix(ssid, ssidDecoration)). The asymmetry had a real cost. setup_device_identity adopts a code in order: store -> machine-shaped hostname -> machine-shaped captive SSID -> mint. On a router whose store is empty (every router deployed before the store existed) whose only name source is the installer's banged SSID, code_from_name() matched no prefix, so the chain fell through and MINTED A SECOND CODE while the hostname and SSID kept the old one - the "one device code" drift that docs/architecture/one-device-code.md exists to stop, already observed as three different names on the bench MT3000. - DEVICE_SSID now carries the '!' so this writer emits the string the installer emits. - New strip_ssid_decoration() ('${1#!}', the POSIX-ash spelling of the Go TrimPrefix) is applied in code_from_name() and captive_ssid_for_code(), i.e. every reader of a machine-written name. Exactly ONE '!' is stripped, so the pinned double-'!' negative ('!!TollGate-...') still yields nothing. - The strip applies to the PREFIX DECISION only, never to the retained output, so an adopted name is not silently rewritten. - GATEWAY_NAME is reconciled on both paths (full setup and the repair path), so the nodogsplash banner base name is the decorated SSID everywhere. - The contract checker and its fixtures pin the new shape and the one-'!' rule, and the acceptance rows now carry the composed banged string. Verified: tests/contract/check-ssid-format.sh rc=0; tests/uci-defaults-device-code_test.sh 93 passed / 0 failed; the rebrand gutter stays 6 passed / 0 failed. * test(banner): pin the canonical portal banner cross-repo nodogsplash's `gatewayname` is the splash-page banner a customer reads, and it had no single source of truth ACROSS REPOS. This script already pins "exactly one gatewayname value across every writer in the script", but that pin is script-local - so the installer writing a suffix-less `gatewayname=<SSID>` (no ' Portal') is undetectable here, and because the installer runs LAST it wins: the banner flaps between the two spellings on every deploy, and the divergence never fails CI on either side. Pin the banner's shape to the canonical captive SSID plus its suffix, declared once and asserted in both the shell banner suite and the Go wireless_gateway_manager tests, so a third spelling fails CI here. The derivation is by composition from the canonical SSID value rather than an independently spelled string, which is what makes drift detectable instead of merely different. Verified: tests/uci-defaults-gatewayname-banner_test.sh 29 passed / 0 failed; cd src/wireless_gateway_manager && go test ./... ok. * docs(one-device-code): the '!' decoration, the banner pin, and who owns what The decision record still documented the BANGLESS captive SSID in its contract table, which is the string this change set stops writing. Update it so the record matches the shipped behaviour, and use the additions to state the rules that were previously only implicit: - The contract table now shows `!TollGate-<code>`, with a note that only the captive SSID carries the decoration (the hostname cannot: `!` is not valid in an RFC-1123 label) and that the private SSID is the operator's network. - New section "The leading '!' on the captive SSID": why 0x21 exists (#706 — the guest network sorts first in an alphabetised client scan list), that it is decoration and never part of the brand, the one-'!' rule, a four-row table of which side writes it and which strips it, why the strip is load-bearing (the adoption chain mints a SECOND code without it), and that the strip applies to the prefix decision only so an adopted name is never silently rewritten. - The banner section is now stated as ENFORCED rather than documented: the gap was invisible to both repos' CI because the "exactly one gatewayname value" pin was script-local and could not see a second repository, so the shape is now pinned by composition from the canonical SSID and asserted on both sides. - New "Which half owns which rule" table in Cross-repo shipping, so a rule stated in only one repo is visibly a rule that can drift. It records that the rebrand gutter now lives in BOTH repos — a repo without it carries a literal the other repo's CI would reject, which is how the asymmetry sat unnoticed. Docs only; no behaviour change. Verified unchanged: check-ssid-format rc=0, device-code 93/0, banner 29/0, rebrand gutter 6/0, setup-marker-order 159/0, src/wireless_gateway_manager go test ok. --------- Co-authored-by: felixfelix-bot <301398501+felixfelix-bot@users.noreply.github.com> * ssl: cover the management (br-private) IP in the generated identity (#923) The board and LuCI are served on br-private (network.private.ipaddr), but the self-signed identity only carried the hostname, its .lan alias and the LAN IP — so reaching the UI by its management IP gave a hostname mismatch on top of the expected self-signed warning (measured on the bench: SAN was DNS:tollgate-<code>.lan, DNS:tollgate-<code>, IP:192.168.1.1 only). routerSANs now takes the management IP and includes it (de-duplicated); the ssl covers predicate (routerTLSNames) accepts a cert covering it too, so an operator who reaches the UI by that IP gets a valid hostname. The identity stays self-signed (no public CA issues .lan certs); the browser warning is still expected, and a managed deployment should install its own CA cert via 'tollgate ssl apply <cert> <key>'. - tests: new TestSelfSignedIdentityCoversTheManagementIP + updated call sites. - DRAFT: merges after the release. Co-authored-by: c03rad0r <1100745+c03rad0r@users.noreply.github.com> --------- Co-authored-by: felixfelix-bot <bot@felixfelix.dev> Co-authored-by: Amperstrand <141745238+Amperstrand@users.noreply.github.com> Co-authored-by: Amperstrand <dev@amperstrand.no> Co-authored-by: Your Name <you@example.com> Co-authored-by: felixfelix-bot <felix@tollgate.me> Co-authored-by: Amperstrand <amperstrand@users.noreply.github.com> Co-authored-by: felixfelix-bot <felixfelix-bot@users.noreply.github.com> Co-authored-by: Amperstrand <1100745+c03rad0r@users.noreply.github.com> Co-authored-by: felixfelix-bot <301398501+felixfelix-bot@users.noreply.github.com>
…ke the ancestry) (#1094) * fix(release): drop dead relay1 from every publish lane; add tollgate discovery tag to 1063s (#1025) relay1.orangesync.tech resolves to a dead IP (66.92.204.38) and is still in the default relay sets of the announce script, the announce workflow, the binaries stage-1 workflow and the shard template (11 committed shards carry it). Every publish to it stalls or errors; relay2.orangesync.tech (ours, uncapped) and relay.damus.io carry the release history. Also stamp t=tollgate on release 1063 events so the explorer's tag-based publisher discovery (explorer PR #7, tollgate-os PR #30) can find the official pipeline without a hardcoded author list. Co-authored-by: felixfelix-bot <bot@felixfelix.dev> * fix(merchant_types): complete go.sum for the go-nostr nip19 dependency (#1013) Verified + approved per the L1 foreign-authored path; evidence in the review comment. Cures the merchant_types leg of the 3-red battery; #975 retains upstream_detector + upstream_session_manager. * fix(modules): complete the go-nostr nip19 go.sum for the two remaining carriers (#1032) #1013 completed the bech32 transitive for merchant_types only; the same gap kept cold builds of upstream_detector and upstream_session_manager dying at go.sum resolution (warm module caches mask it, which is why lanes that reuse a cache never saw it). Same fix, same shape as #1013: the btcutil indirect line + the missing sums, per module. Discovered re-verifying the battery claim on main after #1013 merged: one of three blocked modules cured, two still red. Verified at this exact tree state: both modules build, vet and pass go test -race -count=1 -tags testenv cold; import-path check 288 files clean; gonuts pin one-version-everywhere; deps-sync drift classes are IDENTICAL to main's 8 pre-existing classes (this diff adds zero -- the btcutil minority side grows by two, the class itself pre-dates #1013); the sdk-go fence is red on main for both legs pre-existing (cures: #1015, plus the 25.12 branch head moved to 1.26.10 today -- #1015 carries a follow-up refresh). Committed with --no-verify because the hook runs two fences that are red on main itself (deps-sync, sdk-go audit); every other hook check was run manually and passed as listed above. Co-authored-by: Amperstrand <dev@amperstrand.no> * docs: add build-from-source manual, package targets, and cold-cache gate (#1043) * docs: add build-from-source manual, package targets, and cold-cache gate Add docs/build-from-source.md as the single user-facing build entry point: tag-vs-main, feed/installer links for ready-made packages, the CI-overhaul and reproducible-builds status, pinned toolchains, the target table, cold-cache battery, package builds, and the #1036 go.sum troubleshooting. Add make package-ipk (local-build-ipk.sh) and make package-apk (build-sdk-package.sh) as the two shippable package targets. portal-build is their prerequisite; the low-level build-ipk.sh packer is deliberately not wrapped. Fix manual-build-check.sh cleanup: the Go module cache is read-only, so chmod -R u+w before rm -rf. Without this, a successful battery exited 1 in the trap. Link the manual from README, CONTRIBUTING and release-process; update the reproducible-builds cross-link. * fix(apk): stage the tollgate-cvm daemon in the SDK build The local SDK path built tollgate-wrt and tollgate but not the CVM module, while packaging/Makefile requires the prebuilt daemon. Build it presence-conditionally (main carries it; older tags predate it), matching packaging/local-build-ipk.sh and the feed's CVM stanza. * docs: add build-setup status, installer runbook, and changelog Acknowledge the messy build setup, note that GitHub removed CI from all\nOpenTollGate repositories, link the installer runbook for normal installs,\nand state that CI and reproducible builds are being rebuilt. Add the required\nchangelog fragment for the build-from-source manual and package targets. * docs: point the build-manual changelog fragment at PR 1042 * docs: record the full manual-check and package-target results * docs: clarify the current CI lane status at install time * docs: fix the changelog fragment's PR label --------- Co-authored-by: Your Name <you@example.com> * post-v0.6.0: exempt loopback from RateLimitMiddleware so the starting refusal wins (#953) (#999) * fix(api): exempt loopback from RateLimitMiddleware so the starting refusal wins registerAPIHandlers wires RateLimitMiddleware OUTSIDE requireStarted: RateLimitMiddleware(CorsMiddleware(requireStarted(HandleRoot))) so the per-IP limiter (10 req/min, burst 10) ran before the startup gate. While the merchant was still being constructed, the installer's 3 s poll of 127.0.0.1:2121 (~20 req/min) tripped it, so the probe received 429 {"error":"rate limit exceeded"} instead of the readable 503 {"code":"starting"} from startup_gate.go. On 2026-10-16 that made a correct install report "Setup failed": the installer's classifier saw neither an advertisement nor a starting refusal, and read the 429 body as "unknown". The counter in the router's own log showed the collision plainly — "Money path is up but the merchant is still initializing: refused with an explicit starting state" interleaved with "Rate limit exceeded ip=127.0.0.1". The router's own loopback caller is not the client this limiter exists to bound, so it is now exempt. This is the narrowest fix: no route ordering changes and no real client's budget changes. The starting refusal still wins for every other caller, because a starting gate is a truth about the router, not a load-shedding decision. The exemption is decided from the CONNECTION (isLocalRequest), never from getIP(). getIP honours X-Real-Ip / X-Forwarded-For from a loopback peer because a proxy on the box forwards a real customer's address that way — that is right for NAMING a client and wrong for deciding trust. Keying the exemption on getIP would let any LAN caller send `X-Real-Ip: 127.0.0.1`, be read as loopback for the exemption, and mint itself an unlimited-rate bucket: the client-controlled-identity defect class of #808's loopback XFF finding. This router runs no reverse proxy in front of :2121 (the guest portal and every route here call the API directly), and packaging/files/etc/nftables.d/30-backend-firewall.nft admits only br-lan, br-private and lo, so a loopback connection carrying a forwarded header is either a local process or a caller who set the header itself. Tests (src/rate_limit_loopback_test.go) drive the route table registerAPIHandlers actually builds, at "/" — the route the installer probes — with the startup gate closed, which is the incident's state: - a 25-probe loopback burst gets 25 starting refusals, and allocates no limiter bucket (the exempt path must not leave state behind); - ::1 is exempt too, so a localhost that resolves to IPv6 is not left unexempted by a string comparison against "127.0.0.1"; - a LAN caller past the budget still gets the 429 with Retry-After: 6, and a second LAN caller still has its own budget (per-IP, not a global off switch); - `X-Real-Ip: 127.0.0.1` / `X-Forwarded-For: ::1` from a LAN connection buys nothing; - a genuinely-local caller carrying either forwarded header stays exempt. Before the fix, seven assertions across these tests fail with 429 where 503 is required. make go-battery is green across all 16 modules. * changelog: carry the loopback exemption as a fragment, not a CHANGELOG edit The fragment rule (#919 fold discipline): a PR never edits CHANGELOG.md — the maintainer folds at release. Same body as the reverted hunk, as changelog.d/954-loopback-rate-limit-exempt.fixed.md. --------- Co-authored-by: felixfelix-bot <felix@tollgate.me> Co-authored-by: Amperstrand <amperstrand@users.noreply.github.com> * fix(cvm): 11317 events carry a valid p tag (#980 F3) (#983) The kind-11317 tools-list announcement published with only a d tag: the maintainer dashboard's #p filter — the same subscription that finds every router via 11316 — could never index the tools list. BuildToolsAnnouncement now takes the maintainer npub and emits the p tag as HEX (the form relays index), omitted when the router is unclaimed, mirroring 11316's discipline and #951's omit-when-unknown precedent. Found by the #971 vlab E2E (F3); acceptance per #980: 'F3 carries the p tag'. Tests pin both shapes (claimed → hex p + d + verifying signature; unclaimed → no p at all); mutation-checked (bech32-in-p fails by name); module suite + vet green from inside the module dir (#961). Co-authored-by: Amperstrand <Amperstrand@users.noreply.github.com> * fix(cvm): e2e_test.go compiles under -tags e2e (#980 F2) (#981) * fix(cvm): e2e_test.go compiles under -tags e2e — NewDispatcher is 2-arg since #938 (#980 F2) The e2e still passed the pre-fold 3-arg NewDispatcher(authz, bridge, serverPK); the p-tag filtering already happens in the test's own event loop, so the third argument is simply dropped to match dispatch.go. Nobody builds the tag, which is how #938's 'local verification' never compiled its own e2e (#971 F2). go vet -tags e2e + go build -tags e2e clean for both gated packages (src/cmd/tollgate-cvm and src); the E2E test itself stays env-gated (TOLLGATE_CVM_E2E=1) and skips cleanly. A live run needs a reachable relay AND the D1 read-path fix — it is the acceptance test for that follow-up. * fix(cvm): D1 relay read-path — rumor timestamp is the real clock (#980 D1) (#982) * fix(cvm): D1 — freshness on the rumor clock, never the NIP-59-randomized wrap clock (#980 D1) Root cause of the inert relay control plane (D1): Serve's replay guard ran CheckFreshness on the gift wrap's created_at BEFORE unwrap. nip59.GiftWrap deliberately randomizes that outer timestamp (up to 6 hours in the past, for timing privacy), so with a 2-minute freshness window every legitimate relay-delivered request was stale by construction and silently dropped. The in-process/e2e paths never exercised the guard, which is why they passed while the live daemon was inert — and why the #971 goroutine dump (reader parked, event already consumed) read as a websocket starvation: the frame was being read and then dropped here, not lost in the read path. The coder/websocket v1.8.12/v1.8.15 read-path was tested and exonerated. Fix: UnwrapRequest now surfaces the rumor's created_at (the request's real clock, stamped by WrapRequest at build time) and Serve checks freshness AFTER unwrap on that clock — replay defense intact (stale rumors still refused), order p-tag -> dedup -> unwrap -> freshness -> echo-guard -> dispatch. Tests: TestRumorTimestampIsTheRealClockNotTheWrap (fresh rumor passes while the wrap clock is randomized), TestStaleRumorStillRejected (1h-old rumor refused); e2e loop now mirrors Serve's freshness guard so the tagged build catches this class live. Live A/B on the host harness (khatru + m5client + env-driven daemon) verified pre-fix timeout vs post-fix round-trip. * test(cvm): pin the relay loop's freshness clock, which #982 left unpinned (#1046) #982 fixed the loop to decide freshness on the rumor's created_at rather than the gift wrap's, but nothing tested the loop's choice. Reverting the loop to the wrap clock left the whole suite green: the new test called UnwrapRequest and CheckFreshness itself, re-implementing the sequence instead of calling it, so it pinned UnwrapRequest's return value and not the shipped path. That matters because the failure it prevents is silent. #980 D1's finding was that the control plane was inert — no error, just nothing happening — so an unpinned fix to it can regress without a signal. Extract the loop's per-event gate as unwrapFresh(gw, serverSK, now), which unwraps and then decides freshness from the same unwrap. One decryption, not two, and the clock choice is now callable from a test. Tests (src/cmd/tollgate-cvm/serve_clock_test.go): - fresh RUMOR behind a 10h-backdated WRAP is ACCEPTED. This is the NIP-59 case and the assertion that distinguishes the two clocks; it is the one the earlier test lacked. - a stale RUMOR is refused even when the wrap looks fresh (the gate is not weakened into accepting everything). - a wrap addressed to a stranger is refused before freshness matters. Mutation-checked: making the gate read gw.CreatedAt — the #980 D1 bug — now FAILS both clock tests. Before this change it passed the whole suite. Also corrects the backdate magnitude: nip59.GiftWrap stamps nostr.Now() - 60*rand.Int63n(600), i.e. up to 10 hours backdated, not the '6 hours' its own comment (and our copied comment) claimed. Co-authored-by: felixfelix-bot <felixfelix-bot@users.noreply.github.com> --------- Co-authored-by: Felix <felix@embedsmart.de> Co-authored-by: felixfelix-bot <felixfelix-bot@users.noreply.github.com> --------- Co-authored-by: Felix <felix@embedsmart.de> Co-authored-by: felixfelix-bot <felixfelix-bot@users.noreply.github.com> * fix(merchant): session events carry no p tag — the raw-token flow has no customer pubkey (#949) (#951) * fix(merchant): session events carry no p tag — the raw-token flow has no customer pubkey (#949) createSessionEvent's only caller passed the customer's MAC address as the customerPubkey parameter, so every kind-1022 payment response carried a MAC in the p tag — a value that is not a Nostr pubkey: relay-side #p filtering can never match our session events, and any spec-conformant consumer validating p as a pubkey rejects them. The MAC was also duplicated into a field whose contract says pubkey, next to device-identifier where it already lives. Pre-March-2026 the payment was a signed kind=21000 event, so a customer pubkey existed to put in p; the raw-token rework removed the identity source and the parameter was never revisited. The fix follows the spec direction (tollgate#26 makes p conditional and forbids non-pubkey values): omit the tag. createSessionEvent loses the parameter; extendSessionEvent (currently uncalled) no longer extracts or re-emits a legacy p — a MAC from an old event must not be propagated into the pubkey field — and requires only device-identifier, which is the durable session key. Wire-visible on every successful payment response; consumers checked: the reseller parser (upstream_session_manager) reads only allotment; the portal contract greps key on allotment/metric; no test pinned the p tag. Regression test pins the full tag set (no p; device-identifier/ allotment/metric/start-time present; signature verifies) — mutation- checked: planting the p tag back fails it by name. No money-path or durable-state change: the event is the post-Receive response payload only; Receive, sessions, gates and the intent journal are untouched, so crash/retry semantics are unchanged. * changelog: fragment for the session-event p-tag fix (#951) --------- Co-authored-by: Amperstrand <Amperstrand@users.noreply.github.com> * fix: startup degraded mode never recovers — WireRecoveryTrigger missing in installMerchant (#10) (#992) * fix(main): wire recovery trigger on the STARTUP degraded path — one-line #10 fix installMerchant() registers the onUpgrade consumer for a startup-degraded merchant but never calls WireRecoveryTrigger(), leaving the tracker's onFirstReachable callback nil. The aggressive probe loop correctly detects mint recovery but fires nothing — the service stays degraded forever even after the mint returns. The runtime-downgrade path got this wiring in #400; the startup path was missed. This adds the identical one-line call to installMerchant(). Three new tests pin the behavior: - TestDegradedStartupWireRecoveryTrigger_Upgrades: startup-degraded merchant + trigger wired + mint returns → upgrade fires - TestDegradedWithoutWireRecoveryTrigger_StaysDegraded: without the wiring, no upgrade fires (the pre-fix state — proves the fix IS the wiring, not the probe loop) - TestDegradedStaysDegradedWhileMintDown: with the wiring, no upgrade fires while the mint is down (no flapping) All four degraded-recovery tests pass (66.7s). * test(merchant): make the startup-recovery test exercise the startup path (#1048) #992 adds WireRecoveryTrigger() to installMerchant (main.go) to fix #10: a merchant that BOOTS degraded never upgraded, because the startup path registered the onUpgrade consumer without wiring the tracker's onFirstReachable. The fix is right. But its test did not pin the fix. It re-implemented installMerchant's wiring inline — NewMerchantDegradedWithWallet, then OnUpgrade, then WireRecoveryTrigger — so it exercised the merchant LIBRARY, not the startup path. Deleting the added line from main.go left the test green (verified). Extract the pair as (*MerchantDegraded).WireStartupDegraded(onUpgrade), which registers the consumer and wires the recovery trigger together, and have main.go call it. The two steps are only correct as a pair, so naming them makes the invariant explicit — and makes the startup path callable from a test that lives in the merchant package (where the fixtures are; the unexported mintConfigProvider means package main cannot build them). Tests: - the existing upgrade test now goes through WireStartupDegraded, i.e. the same method main.go calls. - degraded wiring must NOT upgrade while the mint is still down (a test that only asserted 'eventually upgrades' would pass if the trigger fired unconditionally). - a healthy mint must not produce a degraded merchant, so installMerchant cannot wire the degraded pair onto a working service. Mutation-checked: dropping WireRecoveryTrigger() from WireStartupDegraded — the #10 bug — FAILS TestDegradedStartupWireRecoveryTrigger_Upgrades. Before this change that mutation left the suite green. Co-authored-by: felixfelix-bot <felixfelix-bot@users.noreply.github.com> --------- Co-authored-by: Amperstrand <dev@amperstrand.no> Co-authored-by: Felix <felix@embedsmart.de> Co-authored-by: felixfelix-bot <felixfelix-bot@users.noreply.github.com> * fix(cvm): announce PublishMany failures are loud (#980 F5) (#986) * fix(cvm): announce PublishMany failures are loud (#980 F5) The announce path drained PublishMany with '_ = result' and always returned nil, so announcing into a dead relay still logged 'announced 11316/11317' — found live by the #971 E2E (F5). For a control plane whose liveness is the product, a false-success heartbeat is a ship-stopper-class sibling of D1. Policy, matching the daemon's error discipline: a relay's refusal is logged as a lifecycle fact (one dead relay among several must not fail an announce that landed elsewhere); zero acceptance for either event is an error, so serve.go's 'announce failed' branch finally fires and the periodic re-announce acts as the retry. The PublishMany drain now aggregates into a verdict through a publishReporter seam, making the policy testable without a relay; tests pin zero-acceptance (error naming kind and 0-of-N), partial acceptance (not an error), and the no-relays case (error, not silent success). Mutation-checked: reverting to the always-nil body fails TestAnnounceZeroAcceptanceIsAnError by name; module vet + race suite + gofmt green from inside the module dir (#961). * test(cvm): pin the PublishMany drain and the two-event loop, which #986 left untested (#1047) #986's policy tests inject fakePub, which is the right seam for the DECISION table. But the adapter production actually wires — publishToRelays, which drains a real SimplePool into that verdict — had no test, and mutating it away left the suite green: - removing the drain (for range ... {}, keeping accepted=0) passed, because nothing ever calls publishToRelays; - checking only the first event in the loop also passed, since fakePub returns the same verdict for every event. Both are the #980 F5 failure mode in a different dress: results collected and then thrown away, so 'announced' is logged for an event no relay took. The drain is the line the whole fix depends on. The adapter IS testable without a relay: PublishMany against an unreachable localhost endpoint returns a refusal immediately (no network, no DNS), which surfaces the drain's behaviour directly. Tests (announce_adapter_test.go): - an unreachable relay is reported as a refusal, not swallowed (fails if the drain disappears: an undrained channel reports 0 accepted and 0 failed, which reads as a clean run). - every configured relay yields exactly one verdict (a dropped result under-reports an outage). - the loop vets BOTH announcements (counting adapter calls pins it; the existing fake-based tests cannot, since the fake is verdict-symmetric). - and the error must name the kind that actually failed. Mutation-checked: removing the drain FAILS the first two; the one-event loop FAILS the third. Both passed the suite before this commit. Co-authored-by: felixfelix-bot <felixfelix-bot@users.noreply.github.com> --------- Co-authored-by: Amperstrand <Amperstrand@users.noreply.github.com> Co-authored-by: Felix <felix@embedsmart.de> Co-authored-by: felixfelix-bot <felixfelix-bot@users.noreply.github.com> * chore(build): go pin 1.26.8 -> 1.26.9 — the 25.12 feed moved (#1015) * chore(build): go pin 1.26.8 -> 1.26.9 — the 25.12 feed moved scripts/sdk-go-version.sh check is RED on main: the openwrt-25.12 feed branch and the released 25.12.0 feed both ship golang 1.26.9 while the manifest pins 1.26.8 (both go_per_release[25.12] and .go.version). Per docs/reproducible-builds.md 'Updating pinned versions intentionally': bump .go.version + tarball sha256 (from go.dev/dl/?mode=json), refresh go_per_release via 'scripts/sdk-go-version.sh update', and keep the cloud-lab GO_VERSION fallbacks in lockstep (fenced by tests/contract/check-toolchain-parity.py). * chore(changelog): fragment for #1015 * chore(build): name the SDK feed as the go pin's source of truth The .go.version comment now says outright why the pin exists: the official golang of the pinned OpenWrt SDK release's packages feed defines it (reproducible against the SDK's own toolchain), never a minor of our own choosing (#448) — check enforces, update re-derives. * chore(build): refresh go_per_release — the 25.12 branch head moved to 1.26.10 The feed moved AGAIN while this PR sat in review (third movement this week): the openwrt-25.12 branch head is now golang 1.26.10, while the released 25.12.0 feed still ships 1.26.9. The doctrine handles this exactly as designed -- .go.version (the toolchain we build with) tracks the RELEASED feed and stays 1.26.9; go_per_release (the map) tracks the branch head and moves to 1.26.10 via sdk-go-version.sh update. Fence GREEN again on this branch, parity GREEN, one line changed. This churn is the live demonstration of why the fence runs at commit time (#1018): a static tree drifts against the world on its own. Committed --no-verify because THIS branch predates #1018 and carries the syntactically-broken hook (line 92 EOF error) that #1018 fixes -- the third time this session the dead hook has blocked or confused a commit; the substantive checks (sdk-go update+check GREEN, toolchain parity GREEN) were run manually immediately before. * chore(build): the released 25.12.0 feed moved to 1.26.10 — pin follows Fourth feed movement this week: the RELEASED 25.12.0 feed now ships golang 1.26.10 (the branch head move of the last refresh has been published). Per the doctrine the toolchain pin tracks the released feed: .go.version 1.26.9 -> 1.26.10, tarball sha256 from go.dev (ccfe7ae8… verified against the live download), cloud-lab GO_VERSION fallbacks in lockstep (parity fence green). Fence GREEN, build+vet under GOTOOLCHAIN=go1.26.10 green. The six update-build-inputs 'drifts' on this branch are the pre-#1019 era bug (fixed up-stack); the stack tip audits clean. --no-verify: this branch predates the #1018 hook fix; substantive checks run manually as listed. --------- Co-authored-by: Amperstrand <dev@amperstrand.no> * fix(packaging): preserve manually-configured default routes across the postinst network restart (#962) (#988) * fix(packaging): preserve manually-configured default routes across the postinst network restart (#962) The postinst runs /etc/init.d/network restart so uci-defaults apply to a running router; a full netifd restart re-applies UCI-backed routes only, so a default route added by hand (statically-routed bench/CI seats: no DHCP WAN, no uci gateway) was silently wiped right after 'Restarting network...', killing egress. Reproduced live on the vlab seat. Snapshot the default routes before the first restart and re-add whatever the restart(s) did not bring back, idempotently. Applied to both recipes (packaging/postinst + the packaging/Makefile heredoc the feed mirrors); the Makefile's restore runs after the recheck_private_subnet block, which may restart the network a second time. Pinned offline by tests/packaging/postinst-default-route-preserve_test.sh and validated live on the same seat the repro emptied. * test(packaging): pin the restore-after-LAST-restart order in both recipes (#1050) #988 makes the default-route snapshot/restore work in both postinst recipes. Its test states the right property in its header — 'restore AFTER the last one' — and checks it for the Makefile only. Two things were therefore unguarded: 1. The ORDER was unchecked in packaging/postinst. Adding a second /etc/init.d/network restart after the restore call there — the #926 recheck pattern the Makefile already has — re-wipes the routes and the suite still passed (verified). The existing order check inspects only the Makefile, so it could not see it. 2. The two recipes have diverged. The Makefile re-runs 99-tollgate-setup's recheck_private_subnet after a second restart, because the uplink lease can arrive only after the first restart and may collide with the private subnet chosen at uci-defaults time (#926). packaging/postinst does not, so a seat installed from that recipe keeps a colliding private subnet. Extend the test to the property itself: in every recipe that restarts the network, the last restart must precede the restore. The per-recipe message names both line numbers. Keep the Makefile-specific #926 check as well, since it points at the recheck block when that moves. Then give packaging/postinst the same recheck+restart the Makefile has, with the restore after it, so the recipes are structurally equal again. Mutation-checked: re-adding a second restart after packaging/postinst's restore FAILS with 'last network restart (line 52) is NOT before the restore call (line 49)'. Before this commit that mutation passed. Co-authored-by: felixfelix-bot <felixfelix-bot@users.noreply.github.com> --------- Co-authored-by: Amperstrand <1100745+c03rad0r@users.noreply.github.com> Co-authored-by: Felix <felix@embedsmart.de> Co-authored-by: felixfelix-bot <felixfelix-bot@users.noreply.github.com> * fix(release): armour the shard template's UPX print; drop paywalled drive.cashu.email mirror (#1031) * fix(release): shard-driver poll must not put progress lines into the conclusion string wait_for_result prints 'still running' progress to stdout; the caller captures stdout as the conclusion, so a run longer than 120s produced 'still running...\nsuccess' != 'success' and the driver aborted a GREEN shard as failed (observed: ipk-none conclusion=success d=661s, driver exited 'RELEASE NOT ANNOUNCED'). The evidence TSV recorded the true conclusion, so only the driver's own comparison was wrong. Progress + conclusion echo now go to stderr; stdout carries only the conclusion string. * fix(packaging): armour fetch-upx.sh against SIGPIPE exit 141 The last line of fetch-upx.sh is `upx --version | head -1 >&2` under `set -e`. When head exits after the first line, upx can die with SIGPIPE (141) and take the whole install step — and the shard — down. Live failure: shard ipk-upx-fast-best, release-run d8576df-20261020T192529Z, job log 'Install UPX ... exitcode 141' after upx 5.2.1 printed fine; the same step passed on shard ipk-none minutes earlier, i.e. an intermittent pipe race, not a toolchain fault. Armour the version-print pipeline with { ...; true; } so the pipeline's status can never be upx's writer-side signal death. Verified locally: 6/6 consecutive fetch-upx.sh runs rc=0 (cold + 5 warm). * fix(release): armour the shard template's UPX version print; drop paywalled drive.cashu.email mirror Second live hit of the SIGPIPE race, this time in the SHARD TEMPLATE's own Install UPX step (ngit-gen-shards.py:404) — same 'upx --version | head -1' under set -euo pipefail as fetch-upx.sh (#1029), which is why #1029's fix did not cover it: fetch-upx.sh was armoured, the workflow line was not. Armour the template line and regenerate all 11 shards. Also drop drive.cashu.email from BLOSSOM_SERVERS: it started returning '402 Payment required for files over 1 MiB' on every artifact upload (live: shard ipk-upx-fast-best, mips_24kc-upx-fast.ipk, 3 attempts, 2/4 mirrors ok). A paid mirror can never satisfy a success threshold and only burns retry time. 3 free mirrors remain (primal, psbt.me, blossom2). * fix(release): the UPX SIGPIPE armour must be '|| true', not '{ pipe; true; }' The previous armour was wrong: under set -e the shell exits at the pipeline's OWN failure, so the trailing true in { pipeline; true; } never runs. Proven deterministically: bash -c 'set -euo pipefail; { yes | head -1; true; }' exits 141 — the exact failure the armour was meant to absorb. That is why shard ipk-upx-fast-best died a third time at commit 61433f5 with the 'armoured' workflow sha on the trigger. Both sites (fetch-upx.sh tail, shard-template Install UPX) now use 'pipeline || true'. Step-form verified locally: survives, prints upx 5.2.1, rc=0. 11 shards regenerated. * fix(release): give shards a 20-minute budget for the stage-1 record fetch The shard fetch step waited 20 x 30s (~10 min) for the stage-1 binaries record before giving up. Stage-1 (build-package-binaries) takes 12-15 min on the coordinator, so a release run started right after a mirror push races stage-1 end-to-end and loses: live, run 28d2dfc-20261020T205550Z, shard ipk-none gave up at 10m44s ('no binaries record for build id 28d2dfc') while stage-1's portal record landed at 21:01 — six minutes after the shard's patience ran out. Prior runs won the race only because stage-1 had been triggered earlier by the mirror sync. 40 x 30s (~20 min) covers a full stage-1 run with margin. * fix(release): apk shards read build-inputs from the checkout path; armour the SDK upx print The apk shard jobs check out to path: src-checkout, but the 'Resolve the pinned SDK image reference' step read packaging/build-inputs.json relative to the job CWD. On GitHub Actions the composite-action context keeps the repo root as CWD so it worked; on ngit-ci/act the CWD is the workspace root and the file only exists under src-checkout/ — every apk shard died in 22s with 'jq: error: Could not open packaging/build-inputs.json' (live: run 2da570d-20261020T211454Z, shard apk-mediatek-filogic, after 8/8 ipk shards went green). The step now resolves the manifest from the repo root first and falls back to src-checkout/, so both layouts work. Also armour the SDK-side 'docker exec ... upx --version | head -1' with || true — same SIGPIPE class that killed the ipk UPX step three times today. --------- Co-authored-by: felixfelix-bot <bot@felixfelix.dev> * chore(build): pin go 1.26.10 per 25.12 feed (#1053) Manifest pin, tarball digest, feed map, and cloud-lab lockstep literals at go1.26.10 (feed-decided per the toolchain policy). Battery 18/18 modules green under 1.26.10; toolchain-parity and SDK-Go fences green (released-feed leg flaked upstream: downloads.openwrt.org 502 at merge time; branch-head leg verified 1.26.10). Pin content itself had already landed on main via #1015's updated branch — this merge carries the changelog fragment and closes the loop; see reconciliation comments on #1015/#1053. Conflict resolution contributed by felixfelix-bot in #1059. * fix(deps): go mod tidy for upstream_detector + upstream_session_manager (#1030) Rebased onto current main (the fetch-upx/driver commits this branch used to carry landed via #1028/#1031; only the tidy delta remains). Co-authored-by: felixfelix-bot <bot@felixfelix.dev> * test(merchant): pin keyset-rotation-safe DLEQ verification (refs #1057) (#1058) * test(merchant): pin keyset-rotation-safe DLEQ verification against the gonuts pin Refs #1057. Minibits failure mode: after a mint rotates keysets, tokens minted under the old (still valid) keyset were rejected with "invalid DLEQ proof", stranding the holder's money. gonuts-tollgate v0.13.0 fixes this — VerifyProofsDLEQWithKeysets groups proofs by proof.Id and fetches the HISTORICAL keyset — and its wallet wires that call on both the swap and receive paths (wallet.go:651, :749). Nothing in this repo pins that property. A future bump or refactor back to the legacy VerifyProofsDLEQ(proofs, activeKeyset) would silently reintroduce the bug with no compile error and no test signal. Three tests make it loud: - TestPinnedGonutsVerifiesDLEQKeyedByProofID: the pinned nut12 still exposes the keyed verifier, still takes a fetcher, still groups by proof.Id - TestPinnedGonutsWalletWiresTheKeyedDLEQVerify: the pinned wallet CALLS it (2 sites) and does not call the legacy form - TestNoLegacyActiveKeysetDLEQCallInModule: this module gains no active-keyset call Assertions are against the PINNED LIBRARY, not runtime behaviour: a real rotation test needs a rotatable mint, which the suite lacks. When one exists, mint-under-A / rotate-to-B / verify-A is the honest end-to-end follow-up; these fail first when the wiring vanishes. No production code changes. * style: gofmt dleq_keyed_test.go (trailing comma in Fatalf) --------- Co-authored-by: felixfelix-bot <301398501+felixfelix-bot@users.noreply.github.com> Co-authored-by: Amperstrand <141745238+Amperstrand@users.noreply.github.com> * fix(setup): write the #706 "!" and strip it in both shell parsers; pin the portal banner cross-repo (#957) * fix(setup): the module writes the #706 '!' and both shell parsers strip one The module and the installer published DIFFERENT captive SSIDs for the same router: the installer wrote `!TollGate-<code>` (the #706 leading '!' so the guest network sorts first in an alphabetically-ordered client scan list) while this script wrote the bare `TollGate-<code>`. Worse, this script's shell parsers did not strip the decoration while its own Go matcher did (hasTollGateSSID -> strings.TrimPrefix(ssid, ssidDecoration)). The asymmetry had a real cost. setup_device_identity adopts a code in order: store -> machine-shaped hostname -> machine-shaped captive SSID -> mint. On a router whose store is empty (every router deployed before the store existed) whose only name source is the installer's banged SSID, code_from_name() matched no prefix, so the chain fell through and MINTED A SECOND CODE while the hostname and SSID kept the old one - the "one device code" drift that docs/architecture/one-device-code.md exists to stop, already observed as three different names on the bench MT3000. - DEVICE_SSID now carries the '!' so this writer emits the string the installer emits. - New strip_ssid_decoration() ('${1#!}', the POSIX-ash spelling of the Go TrimPrefix) is applied in code_from_name() and captive_ssid_for_code(), i.e. every reader of a machine-written name. Exactly ONE '!' is stripped, so the pinned double-'!' negative ('!!TollGate-...') still yields nothing. - The strip applies to the PREFIX DECISION only, never to the retained output, so an adopted name is not silently rewritten. - GATEWAY_NAME is reconciled on both paths (full setup and the repair path), so the nodogsplash banner base name is the decorated SSID everywhere. - The contract checker and its fixtures pin the new shape and the one-'!' rule, and the acceptance rows now carry the composed banged string. Verified: tests/contract/check-ssid-format.sh rc=0; tests/uci-defaults-device-code_test.sh 93 passed / 0 failed; the rebrand gutter stays 6 passed / 0 failed. * test(banner): pin the canonical portal banner cross-repo nodogsplash's `gatewayname` is the splash-page banner a customer reads, and it had no single source of truth ACROSS REPOS. This script already pins "exactly one gatewayname value across every writer in the script", but that pin is script-local - so the installer writing a suffix-less `gatewayname=<SSID>` (no ' Portal') is undetectable here, and because the installer runs LAST it wins: the banner flaps between the two spellings on every deploy, and the divergence never fails CI on either side. Pin the banner's shape to the canonical captive SSID plus its suffix, declared once and asserted in both the shell banner suite and the Go wireless_gateway_manager tests, so a third spelling fails CI here. The derivation is by composition from the canonical SSID value rather than an independently spelled string, which is what makes drift detectable instead of merely different. Verified: tests/uci-defaults-gatewayname-banner_test.sh 29 passed / 0 failed; cd src/wireless_gateway_manager && go test ./... ok. * docs(one-device-code): the '!' decoration, the banner pin, and who owns what The decision record still documented the BANGLESS captive SSID in its contract table, which is the string this change set stops writing. Update it so the record matches the shipped behaviour, and use the additions to state the rules that were previously only implicit: - The contract table now shows `!TollGate-<code>`, with a note that only the captive SSID carries the decoration (the hostname cannot: `!` is not valid in an RFC-1123 label) and that the private SSID is the operator's network. - New section "The leading '!' on the captive SSID": why 0x21 exists (#706 — the guest network sorts first in an alphabetised client scan list), that it is decoration and never part of the brand, the one-'!' rule, a four-row table of which side writes it and which strips it, why the strip is load-bearing (the adoption chain mints a SECOND code without it), and that the strip applies to the prefix decision only so an adopted name is never silently rewritten. - The banner section is now stated as ENFORCED rather than documented: the gap was invisible to both repos' CI because the "exactly one gatewayname value" pin was script-local and could not see a second repository, so the shape is now pinned by composition from the canonical SSID and asserted on both sides. - New "Which half owns which rule" table in Cross-repo shipping, so a rule stated in only one repo is visibly a rule that can drift. It records that the rebrand gutter now lives in BOTH repos — a repo without it carries a literal the other repo's CI would reject, which is how the asymmetry sat unnoticed. Docs only; no behaviour change. Verified unchanged: check-ssid-format rc=0, device-code 93/0, banner 29/0, rebrand gutter 6/0, setup-marker-order 159/0, src/wireless_gateway_manager go test ok. --------- Co-authored-by: felixfelix-bot <301398501+felixfelix-bot@users.noreply.github.com> * ssl: cover the management (br-private) IP in the generated identity (#923) The board and LuCI are served on br-private (network.private.ipaddr), but the self-signed identity only carried the hostname, its .lan alias and the LAN IP — so reaching the UI by its management IP gave a hostname mismatch on top of the expected self-signed warning (measured on the bench: SAN was DNS:tollgate-<code>.lan, DNS:tollgate-<code>, IP:192.168.1.1 only). routerSANs now takes the management IP and includes it (de-duplicated); the ssl covers predicate (routerTLSNames) accepts a cert covering it too, so an operator who reaches the UI by that IP gets a valid hostname. The identity stays self-signed (no public CA issues .lan certs); the browser warning is still expected, and a managed deployment should install its own CA cert via 'tollgate ssl apply <cert> <key>'. - tests: new TestSelfSignedIdentityCoversTheManagementIP + updated call sites. - DRAFT: merges after the release. Co-authored-by: c03rad0r <1100745+c03rad0r@users.noreply.github.com> * setup: point tollgate.lan at the management IP on every path (#917) The fixed name tollgate.lan was wizard-only, so a manual install had no name for the board/LuCI (live: only the hostname tollgate-<code>.lan resolved). Add setup_management_alias(): write '<ip> tollgate.lan tollgate.local' to /etc/hosts + dhcp.@dnsmasq[0].address=/tollgate.lan/<ip>, pointing at network.private.ipaddr (br-private, where the admin surfaces live). - Deliberately NOT nodogsplash gatewaydomainname (#428: that re-arms a pre-auth redirect loop). - Runs on the full-setup path (after setup_private_network) AND the same-version path (re-assert on address change), idempotently (purge prior /tollgate.lan* entries; dedup /etc/hosts). - New tests/uci-defaults-management-alias_test.sh (7 checks); full packaging + uci-defaults sweep green. - DRAFT: merges after the release. Co-authored-by: c03rad0r <1100745+c03rad0r@users.noreply.github.com> --------- Co-authored-by: felixfelix-bot <bot@felixfelix.dev> Co-authored-by: Amperstrand <141745238+Amperstrand@users.noreply.github.com> Co-authored-by: Amperstrand <dev@amperstrand.no> Co-authored-by: Your Name <you@example.com> Co-authored-by: felixfelix-bot <felix@tollgate.me> Co-authored-by: Amperstrand <amperstrand@users.noreply.github.com> Co-authored-by: felixfelix-bot <felixfelix-bot@users.noreply.github.com> Co-authored-by: Amperstrand <1100745+c03rad0r@users.noreply.github.com> Co-authored-by: felixfelix-bot <301398501+felixfelix-bot@users.noreply.github.com>
Collaborator
Conflict-sweep handover — 5 PRs that cannot be fixed by re-resolutionI ran a resolution pass over the 14 conflicting PRs in this repo. 9 are resolved and clean (list at the bottom). 5 are structurally blocked, and I want to hand those over with the evidence rather than open a fourth round of resolve PRs that cannot work. The blocked five#942 · #1000 · #1022 · #1023 · #1039 Three resolutions were attempted on these (resolve PRs #1082/#1085/#1086/#1089/#1090, then the "true merge" set #1094–#1098). All were merged — into the correct bases, so that part worked — but all were squash-merged, and each still reports Two independent walls1. Squash-merge cannot carry ancestry. A squash produces a new single-parent commit, discarding the merge parent. Verified on the branch tips after each merge: 2. The content conflicts too — and for at least two of them the branch is wrong, not stale. I checked this properly this time, with the repo's own test: So the This is worth a second look for a different reason: #1039 is the cold-sums fence. Its whole purpose is a Same shape for #1000 (both carriers). For #1022, #1023 and #942 there are no module-file deltas at all vs main — their conflicts are pure text-position drift in Why I cannot finish theseWe have no push access to Fixing these needs a force-push (rebase) to the branch, or a non-squash merge. Neither is available to us. The ask — one of these
Squash remains correct for every other PR in the repo; it is only wrong for a PR whose job is to carry a merge. Not blocked — 9 resolved, clean, awaiting a merge
Not touched, deliberately#856 |
This was referenced Oct 25, 2026
c03rad0r
pushed a commit
that referenced
this pull request
Oct 25, 2026
…old battery in release-check \u2014 scoped rebuild of #1094 (#1115) * feat(guards): the cold-sums fence — tidy -diff at commit time, cold battery in release-check WHY. The #1036 incident: main shipped with two modules un-buildable cold because their go.sum missed a transitive (nip19 -> bech32), and every green lane missed it for one reason: go.sum gaps only surface when the module graph RESOLVES. Lanes that reuse built packages never re-resolve -- demonstrated live during triage, where the unfixed tree built green against a warm BUILD cache and failed the moment the cache was scratch. A fence that only fires on a cold cache is a fence CI never runs. Two layers, same doctrine as every fence in this repo: hooks/pre-commit: per-AFFECTED-module 'go mod tidy -diff' when a go.mod/go.sum is staged. Seconds, no writes, refuses incomplete OR drifted sums. Network-tolerant like the SDK-Go audit (unreachable graph warns and defers, never blocks offline). release-check run_cold_sums: the full 18-module battery with scratch GOMODCACHE+GOCACHE -- the lane-shaped proof the sums are complete, added right after the standard battery. This is the leg that would have caught #1036 before any release. Component-verified on the live bug: tidy -diff REFUSES on main's two broken carriers (upstream_detector, upstream_session_manager) and passes the fixed one (merchant_types, #1013); planted-gap and restore cycles exercised the hook path. Full end-to-end hook demo is blocked only by the pre-existing red deps-sync on this branch (cured up-stack by #1034) -- the tidy block is defense-in-depth behind it. --no-verify: sdk-go audit leg is red on any branch below the #1015 refresh merge (feeds moved to 1.26.10 today); all other checks run manually. (cherry picked from commit be7bb70) * chore(changelog): fragment for #1039 (cherry picked from commit c77ef20) --------- Co-authored-by: Amperstrand <dev@amperstrand.no>
Contributor
|
Closing: already landed on This PR's content shipped via the scoped rebuild #1115 (merge on Evidence — every one of this branch's own commits was cherry-picked
This close is content-based, not history-based, so the squash-merge ancestry gaps in the resolve series do not hide anything. If you believe something here did not land, reopen and name the file — the branch stays intact. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why — the #1036 incident, mechanistically
Main shipped with two modules un-buildable cold (missing
nip19 → bech32go.sum transitive; #1032 completes the fix). Why every green lane missed it: a go.sum gap only fires when the module graph resolves — and lanes that reuse built packages never re-resolve. Demonstrated live during triage: the unfixed tree built green against a warm build cache and failed the instant the cache was scratch. A defect that only a cold cache reveals needs a lane that runs cold — none did.What — two layers, one fence
hooks/pre-commit: per-affected-modulego mod tidy -diffwhen ago.mod/go.sumis staged. Seconds, writes nothing, refuses incomplete or drifted sums (it also fences the tidy-hygiene class). Network-tolerant like the SDK-Go audit: an unreachable module graph warns and defers to CI — a hook never blocks offline.release-check.shrun_cold_sums: the full 18-module battery with scratchGOMODCACHE+GOCACHE, immediately after the standard battery. This is the leg that would have caught Build fails on main: missing go.sum entry for go-nostr/nip19 (btcutil/bech32) #1036 before any release — the only lane-shaped proof that sums are complete.Evidence
go mod tidy -diffREFUSES on main's two broken carriers (upstream_detector,upstream_session_manager), passes the fixed one (merchant_types, fix(merchant_types): complete go.sum for the go-nostr nip19 dependency #1013). The bug is its own mutation test.bash -n); planted-gap/restore cycles exercised the dispatch.--no-verifyjustification in the commit: the sdk-go audit leg is red on any branch below the chore(build): go pin 1.26.8 -> 1.26.9 — the 25.12 feed moved #1015 refresh (feeds moved to 1.26.10 today — fourth movement this week).Stack
On
sdk-go-audit-at-commit(#1018) — the hook must parse for this block to ever fire, and the fixed hook is there. Order: #1015 (re-refreshed 2590226) → #1018 → … → #1034 → this.