18 Commits

Include renames

Author	SHA1	Message	Date
UltradesuandClaude Opus 4.8	3e066f991f	CI: install libxdo-dev for the Linux tray link ... The x86_64 Linux tray failed at link with "unable to find library -lxdo": tray-icon pulls libxdo, whose .so was not present. Add libxdo-dev to the GUI build's apt install, alongside libgtk-3-dev and libayatana-appindicator3-dev. Everything else (aarch64 agent, macOS, Windows) already built. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-10-02 16:51:53 +01:00
UltradesuandClaude Opus 4.8	3752419075	CI: build the Linux tray natively with GTK; drop the aarch64 GUI ... The aarch64 GUI cross-build failed: tray-icon links GTK and libappindicator through pkg-config, which zig cross-compilation cannot satisfy without a target sysroot. Rather than set one up, the Linux tray is now built natively on the x86_64 runner with libgtk-3-dev and libayatana-appindicator3-dev installed, so pkg-config just works. The agent is still static musl for both arches. The aarch64 Linux GUI is dropped for now: that archive stays agent-only and no aarch64 tsunagi-gui package is produced. x86_64 gets the tray in its archive and the tsunagi-gui .deb/.pkg.tar.zst. macOS and Windows build the tray natively as before. Guarded on matrix.gnu_target (set only on x86_64 Linux). Note: the native build links the runner's glibc, so the Linux GUI binary needs a reasonably recent glibc; fine for current desktops. A lower baseline would need a GTK sysroot or an older runner image. YAML validated; the Linux GUI build is exercised only by a real CI run. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-10-02 16:38:58 +01:00
UltradesuandClaude Opus 4.8	f63343a6a0	CI: ship the tray GUI — in the archives and as tsunagi-gui deb/zst ... Adds the tray application to the release: - Every target's archive now also contains the tsunagi-tray binary. On Linux it is built against an old glibc baseline (via cargo-zigbuild) rather than static musl, because a GUI must dlopen libGL/X11/Wayland at runtime and a static musl binary cannot; the agent stays static musl. macOS and Windows build the tray natively. - New GUI package variants for Linux: `tsunagi-gui` .deb and .pkg.tar.zst, built by the existing scripts with an extra tray argument. They install the agent (service, polkit, user — same as the headless packages) plus the tray binary, a desktop launcher (dist/linux/tsunagi-tray.desktop) and an icon (dist/linux/tsunagi.svg), so the GUI appears in the applications menu. The GUI package conflicts/replaces/provides the headless tsunagi so the two do not coexist. - The tray finds the system service with no configuration: the library's default control-socket path now prefers /run/tsunagi/agent.sock when present (both the tray and CLI use this), falling back to the per-user path. No control-protocol change. Builds, fmt and clippy clean on macOS; the Linux GUI cross-build and the packages are exercised only by a real CI run. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-10-02 16:26:45 +01:00
UltradesuandClaude Opus 4.8	8c812e6874	Bump the GitHub workflow actions off deprecated Node 20 ... GitHub now forces actions/checkout@v4, actions/upload-artifact@v4 and actions/download-artifact@v4 (all Node 20) onto Node 24 with a deprecation warning. Move them to the current Node 24 majors — checkout@v5, upload-artifact@v7, download-artifact@v8 — which keep the same inputs and the per-artifact subdirectory layout (merge-multiple defaults to false), so the publish step is unchanged. Only the .github workflow is touched. The .gitea workflow stays on checkout@v4 and the @v3 artifact actions, because Gitea does not support the v4+ artifact backend and may not have Node 24 on its runner image; it also does not emit these deprecation warnings. mlugg/setup-zig has no Node 24 release yet (latest v2.2.1 is still Node 20), so that one warning remains until upstream updates — nothing to change on our side. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-10-02 14:01:33 +01:00
UltradesuandClaude Opus 4.8	63178574ce	Package as a dedicated tsunagi user; add Arch packages ... Reworks the Linux packaging so the service runs as an unprivileged, dedicated "tsunagi" user instead of root — the point of a native package is to set things up properly for that OS's users — and adds Arch Linux packages beside the deb. Both package families are built from the already-compiled static binary; nothing is recompiled. Service model (shared systemd unit, dist/linux/tsunagi.service): - User=tsunagi with AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE, so it creates the TUN and binds low ports without root. - StateDirectory/CacheDirectory/RuntimeDirectory give it /var/lib/tsunagi, /var/cache/tsunagi and /run/tsunagi, and the agent is pointed at them (and the socket at /run/tsunagi/agent.sock) through TSUNAGI_* env in the unit. - The polkit rule now grants the resolve1 actions to the "tsunagi" group; the service user is in it, and admins can add themselves. CLI: when no state dir is chosen, the control commands prefer the system service's socket at /run/tsunagi/agent.sock when it exists, so `sudo tsunagi status`/`join` reach the packaged daemon with no flags. A per-user agent (its socket absent from /run) still uses its own. Packaging: - deb (build-deb.sh): postinst now creates the tsunagi system user+group; unit installed to /lib/systemd/system, binary to /usr/bin. - Arch (new dist/arch/build-pkg.sh): a dependency-free .pkg.tar.zst assembled with bsdtar + zstd (no makepkg, no Arch host) — .PKGINFO, a .INSTALL scriptlet that creates the user and reloads systemd, and a gzipped .MTREE; unit to /usr/lib/systemd/system. - The polkit rule moved to dist/linux (shared by deb, Arch and the tarball), and the tarball install.sh now creates the user and installs the unit + rule. - Both release workflows build the deb and the Arch package on the two Linux matrix entries (deb_arch/pkg_arch), install libarchive-tools+zstd for it, and attach both to the release (Gitea API loop / gh). Not exercised in this session: the .deb and .pkg.tar.zst build and install only on Linux (no dpkg-deb/bsdtar+pacman locally); CLI build, clippy, fmt and tests pass, and all shell/YAML is syntax-checked. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-10-02 13:46:27 +01:00
UltradesuandClaude Opus 4.8	a3856eed3b	Build a dependency-free .deb and attach it to the release ... Adds a Debian package to the release for the x86_64 and aarch64 Linux builds, so `apt install ./tsunagi_*.deb` is a convenient path on the Ubuntu hosts. Because the binary is static musl, the package declares no Depends — it is built with plain dpkg-deb on the runner (no cargo-deb or nfpm), from dist/deb/build-deb.sh. The package installs: - the static binary at /usr/bin/tsunagi; - a systemd service at /lib/systemd/system/tsunagi.service that runs the agent as root (ExecStart rewritten to /usr/bin; the source unit targets /usr/local/bin for the tarball installer); - a polkit rule at /usr/share/polkit-1/rules.d granting the resolve1 actions to a "tsunagi" group, for running the agent as a non-root user instead of via the root service. postinst creates that system group and runs daemon-reload; prerm disables the service on removal. Both release workflows gain a "Build the Debian package" step on the two Linux matrix entries (deb/deb_arch), include the .deb in the uploaded run artifacts, and attach it to the release (Gitea via the API loop, GitHub via gh). macOS and Windows are unchanged. Service runs as root by default; the polkit rule/group is the documented opt-in for the non-root path — say if you'd rather the service itself run as the tsunagi user. YAML and shell syntax validated; the .deb build itself runs only on the Linux runner (no dpkg-deb locally) and has not been exercised in this session. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-10-02 13:34:33 +01:00
UltradesuandClaude Opus 4.8	eac54f8c79	Revert the GitHub workflow guard to server_url ... Misdiagnosed the earlier report: Gitea was correctly running its own .gitea/workflows copy, not this .github one, so the server_url guard was fine. The switch to a GITHUB_RELEASE repo variable then made the workflow skip on GitHub itself, since that variable is not set there. Put both job guards back to `github.server_url == 'https://github.com'`, which runs on GitHub with no manual setup and skips on Gitea (its .gitea copy is the one that runs). No repository variable is needed. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-10-02 12:53:26 +01:00
UltradesuandClaude Opus 4.8	a8dfd7017b	Gate the GitHub release workflow on a repo variable, not server_url ... The github.server_url guard did not keep this workflow from running on Gitea: Gitea reports github.server_url as https://github.com, so the condition was true there too and the jobs ran (and would fail on @v4/gh). Switch both job guards to `vars.GITHUB_RELEASE == 'true'`, a repository variable set only in the GitHub repo's settings. It is deterministic: absent on Gitea, so the jobs skip there and the .gitea workflow is the one that runs; present on GitHub once configured, so it runs there. The header documents how to set it (Settings → Secrets and variables → Actions → Variables → GITHUB_RELEASE=true). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-10-02 12:50:04 +01:00
UltradesuandClaude Opus 4.8	99f4cf0220	Add a GitHub release workflow alongside the Gitea one ... Gitea and GitHub need different release plumbing, so each gets its own file: the Gitea workflow stays in .gitea/workflows, and this GitHub one lives in .github/workflows. The build half is identical (static musl Linux via cargo-zigbuild, native macOS aarch64 and Windows x86_64); only publishing differs — GitHub uses the v4 artifact backend and `gh release create`/`upload`, which the Gitea file cannot use. Because Gitea reads both .gitea/workflows and .github/workflows, every job here is guarded with `if: github.server_url == 'https://github.com'`, so on Gitea this file's jobs are skipped (no v4/gh failures) and the .gitea file is the one that runs. GitHub never reads .gitea, so there it runs only this one. Publish is re-run safe: it creates the release on the first run and uploads with --clobber onto an existing release afterwards; a pre-release suffix on the tag marks it prerelease. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-10-02 12:47:19 +01:00
UltradesuandClaude Opus 4.8	69263b2dd9	Move the release workflow to .gitea/workflows ... The release pipeline is Gitea-specific (v3 artifacts, Gitea release API), so it must not run on github.com, where it would fail. GitHub only reads .github/workflows, while Gitea reads both, so moving the file to .gitea/workflows keeps it running on Gitea and invisible to GitHub. A separate GitHub-flavoured release workflow can be added under .github later. The portable .github/workflows/ci.yml (fmt/clippy/test) is left in place; it works on both and is not what this change is about. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-10-02 12:13:45 +01:00
UltradesuandClaude Opus 4.8	20444013c0	Split release into build artifacts + a publish job (Gitea) ... The direct-upload-from-each-build approach failed ("Upload the archive to the release" exit 1) and left no artifacts to inspect. Restructured into the familiar shape: build jobs now leave their archive as a run artifact, and a single publish job — gated on all targets succeeding — collects them and fills the release. - Build jobs use actions/upload-artifact@v3 (Gitea has no v4 backend; v3 is what shows under the run), so the archive is visible and handed on. - publish (needs: build) downloads everything with download-artifact@v3 and uploads each archive to the Gitea release with curl, once, with no matrix race. It prints the API base and the HTTP status/body of every call, so a failure (e.g. a read-only Actions token → 403, or a bad API URL) is now visible in the log instead of a bare exit 1. - Release API base prefers GITHUB_API_URL (Gitea sets it to its /api/v1 root) and falls back to GITHUB_SERVER_URL/api/v1. Asset uploads run in the main shell via process substitution so a failed upload fails the job. Build, package, musl/zig setup and the target matrix are unchanged. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-10-02 12:12:53 +01:00
UltradesuandClaude Opus 4.8	2196f6635b	Quiet the cosmetic zig linker_messages warning on the musl build ... The musl release build now links cleanly through cargo-zigbuild, but rustc's new linker_messages lint echoed zig's "ignoring deprecated linker optimization setting '1'" note — zig's linker declining the -O1 GNU-ld flag Rust passes. It is cosmetic and the binary is correct, so allow that one lint, scoped to the zig build step only. macOS and Windows keep full linker diagnostics, and a real link error still fails the build. No behaviour change to the produced binaries; takes effect on the next tag. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-10-02 12:06:04 +01:00
UltradesuandClaude Opus 4.8	6438982d45	Upload release assets via the Gitea API instead of artifacts + gh ... The release ran on Gitea Actions, where it failed at actions/upload-artifact@v4: the v4 artifact backend (and the GitHub REST API that `gh release create` uses) are not available on Gitea/GHES, so both the artifact handoff and the publish job were dead ends there. Reworked so each build job uploads its archive straight to the release through Gitea's native API (`/api/v1/repos/<repo>/releases`) with curl: create the release for the tag if absent (races between matrix jobs are resolved by reading the id back by tag), then POST the archive as an asset. The separate publish job, download-artifact and `gh` are gone. The id is parsed with grep, so the runner needs only curl and coreutils — no jq, no third-party release action. Uses the Gitea-injected GITHUB_TOKEN, GITHUB_SERVER_URL and GITHUB_REPOSITORY; a tag with a pre-release suffix (e.g. -rc.2) is marked prerelease. This targets Gitea by design; it no longer runs as-is on github.com (different API), which is fine — the GitHub build is being retired. Build and package steps, the musl/zig setup and the target matrix are unchanged. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-10-02 12:04:20 +01:00
UltradesuandClaude Opus 4.8	21b619388c	Pin Zig to a real release so the musl release build fetches reliably ... The release run failed at "Install zig": mlugg/setup-zig, left unpinned, resolved to the newest version it knew of — an unreleased 0.16.0 whose tarball 404s on ziglang.org — and the community mirrors returned 502/503 around it, so the step errored out before cargo-zigbuild ever ran. Pin the action to Zig 0.14.1, an archived release with a permanent official download URL. The official source then succeeds even when the mirrors are flaky, and the version stays compatible with cargo-zigbuild. Also moves the action to @v2. Only the Linux musl jobs use zig; macOS and Windows are unaffected. Not run on a real tag yet in this session. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-10-02 11:54:29 +01:00
UltradesuandClaude Opus 4.8	d1ab993dd2	Add a tagged-release CI workflow and Linux/Windows packaging ... Pushing a `v*` tag now builds the agent for every supported target and attaches the archives to a GitHub release. Modelled on the furumi release workflow (a build matrix, then a publish job that runs `gh release create`), adapted to this project's two differences: it needs system integration (capabilities/polkit on Linux, elevation+wintun on Windows, a root daemon on macOS), and its users run varied distros, not just Ubuntu. Linux is built as a fully **static musl** binary with cargo-zigbuild, so one artifact runs on Arch, Alpine, NixOS and old-glibc systems alike, and can be repackaged into whatever a distro prefers later. musl has no prebuilt aws-lc-sys bindings, so the Linux jobs install cmake + libclang (bindgen) and zig (the cross C compiler zigbuild drives). macOS (aarch64) and Windows (x86_64) build natively; Linux covers x86_64 and aarch64. Targets: x86_64/aarch64 linux-musl, aarch64 macOS, x86_64 Windows. Each archive carries the binary, the top-level README, and the platform's install notes plus integration files: - dist/linux/: a static-friendly README, a systemd unit (runs as root, so no capability grant or polkit rule is needed; a commented non-root variant is included), and an install.sh that drops the binary and the unit or prints the setcap/polkit alternative. - dist/windows/: install notes covering wintun.dll and Run-as-administrator. - dist/macos/: the existing LaunchDaemon plist and notes, now also shipped in the archive. Not exercised yet: the workflow only runs on a real tag push, and the aws-lc-sys-under-musl build has not been run locally in this session (no zig toolchain here). YAML and install.sh syntax are validated. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-10-02 11:48:19 +01:00
tsunagiandClaude Opus 5	21be7e9b44	Separate control and data logically, move WireGuard into userspace, add a CLI ... Corrects the architecture on two points raised in review, while the project is still small enough to change cheaply. 1. Control and data are separated *logically*, not physically. The old reading — "nothing but control may ride on iroh" — threw away iroh's whole value and would have forced the data plane to reimplement STUN, ICE and a relay. Now both planes ride on iroh with different ALPNs and different connections, so the data plane inherits hole punching and relay fallback, while proto/ still knows nothing about packets and dataplane/ knows nothing about the control protocol. New boundary: PacketTransport / PacketLink, an authenticated unreliable datagram channel per (network, peer, protocol). tsunagi/data/1 runs the same membership handshake, then DataOpen/DataOpenAck, then QUIC datagrams. Only the smaller endpoint id dials, so exactly one link exists per pair. A plugin is handed links and never learns reachability, so the WireGuard announcement shrank to a public key: there is no address left to lie about. 2. WireGuard now runs in userspace, on boringtun's protocol state machine. No kernel module, no wg tool, no ip shell-out, no loopback proxy: the wgtool, backend and bridge modules are gone. Only creating a TUN device needs privileges, and that sits behind TunFactory, so the entire data plane — handshake, encryption, routing, address ownership — is tested with none. Address ownership is enforced rather than believed: outbound packets go to the owner of the destination address, inbound packets are dropped unless their source is the address derived for the peer that sent them. 3. A `tsunagi` binary: secret, doctor, id, up. It owns the runtime, the logging subscriber and Ctrl-C, which the library still refuses to. Also fixes a reference cycle where IrohTransport held Arc<Inner>, which kept the databases open and the directory lock held after shutdown; two storage tests caught it once the cycle existed. 81 tests pass offline with no privileges, including real IPv6 packets crossing a real WireGuard tunnel over real iroh connections. Verified by hand: two CLI processes forming a mesh both on loopback and via n0 discovery using only an endpoint id. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-21 11:55:20 +01:00
tsunagiandClaude Opus 5	ea7aaa2b69	Implement the WireGuard data plane plugin ... The first IP plugin, built on the data plane boundary the core already had. Plugin: - one X25519 key per network in the plugin's own wireguard.sqlite, separate from the iroh identity and from the network secret; a damaged store is an error, never a silently regenerated identity - deterministic IPv6 ULA overlay: every member derives the same /64 from the network id and its own /128 from its WireGuard public key, so no coordinator allocates addresses - AllowedIPs are derived locally, never taken from a peer's announcement, so a member cannot claim another member's overlay address; a mismatched claim is rejected - bounded, versioned, validated announcement carried as the existing opaque capability payload, which the core still never parses - each agent builds its own full-mesh configuration (N-1 peers) and reconciles on every change and on a timer, repairing drift - WireguardBackend abstraction: RecordingBackend in memory, and WgToolBackend driving real wg/ip on Linux, split into a pure planner plus parsers and a thin executor so everything interesting is testable without root Core, three generic additions the plugin needed: - IpPlugin::on_network_activated, so per-network state is ready before peers - PluginContext for re-announcements and error reports from plugin tasks, with errors counted by the owning network runtime - IpPlugin::shutdown, awaited with a grace period, so system objects go away 94 tests pass offline with no privileges: 35 new WireGuard unit tests and 12 integration tests over real iroh connections. The real wg/ip backend needs root and is behind --ignored in tests/wireguard_system.rs; it was not run. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-21 11:07:31 +01:00
tsunagiandClaude Opus 5	7cea9afa37	Proof-of-concept mesh agent library over iroh ... Working library with real iroh connections, not an interface sketch: - persistent device identity in state.sqlite, stable across restarts - deterministic network space derived from name + secret via HKDF-SHA256, with frozen labels and unambiguous length-prefixed encoding - replaceable discovery returning unverified candidates only; static bootstrap, in-memory test backend and a composite - real iroh connections plus an explicit mutual membership proof: HMAC-SHA256 over a role-separated transcript bound to the TLS exporter, the network id and both endpoint identities - small versioned control protocol: handshake, announcement, ping/pong - multiple networks per agent with enforced isolation - automatic reconnect with bounded backoff and jitter - mandatory state vs disposable cache, with a real directory ownership lock - status snapshots, event stream and honest diagnostics 47 integration and unit tests cover the required scenarios offline on loopback. Snapshots, revocations and WireGuard are designed for and documented, not implemented. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-21 00:10:07 +01:00