3 Commits

Include renames

Author	SHA1	Message	Date
enricobuehlerandClaude Opus 5	365caa23be	fix(plugins): plugin output reaches the console's log page, and /tmp is no longer hidden from the runner ... A user could not get the VirtualHere plugin to use their VirtualHere client and asked, reasonably, where the logs were. There was no good answer, and the reason they were stuck turned out to be ours. **The runner could not see /tmp.** `punktfunk-scripting.service` set PrivateTmp=yes, which hands the unit a private tmpfs. But integrating with things already running on the box is the entire job of a plugin, and on Linux those talk over /tmp: VirtualHere's client IPC is the FIFO pair /tmp/vhclient + /tmp/vhclient_response, X11 is /tmp/.X11-unix. So the plugin launched the vendor binary happily and could then never reach the daemon behind it — while the same command worked perfectly in the operator's own shell, because that shell has the real /tmp. No config change could fix it, which is exactly the loop the report described. PrivateTmp is now off, with /tmp added to ReadWritePaths (which ProtectSystem=strict would otherwise make read-only). **Plugin logs now land in the console.** Plugins are not host child processes — the runner is a separate bun process that import()s each plugin in-process — so nothing they print passed through the host's tracing, and the console's Logs page could not show a single plugin line. The fallback was journalctl on Linux; on Windows the runner's scheduled task writes no log file at all, so a failing plugin was diagnosable only by stopping the task and re-running the runner by hand. Both mean shell access on the host box, which is what the console exists to avoid — and it left the one question a stuck user asks with no answer. So the runner now tees its output to POST /api/v1/plugins/logs, and those lines join the host's own ring under one cursor, targeted plugin:<name>. The console grows a Host/Plugins switch beside the level filter; an empty Plugins view says the thing that is actually usually wrong (the runner isn't running) rather than "adjust the filter". The shipper keeps stdout authoritative — journald and foreground output are unchanged whatever the host is doing — and is built so that logging can never hurt the thing being logged: it never throws into a caller, holds a bounded queue that drops oldest and then says how many, backs off when the host is away (a restart is normal), and re-sends a batch the host failed to take. Lines logged while a POST is in flight are kept, which cost one round to get right: the first version held its recursion guard across the await and silently dropped exactly the lines a busy plugin produces. Runner lines that report a failure (a refused unit file, a crashed plugin, a give-up) now go out at warn/error instead of all arriving as INFO, so the console's level filter means something for them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-03 15:47:51 +02:00
enricobuehlerandClaude Fable 5	7b7231fdbe	feat(security): gate public-registry plugin installs + sandbox the runner unit ... Supply chain: resolvePackage() used to pass any punktfunk-plugin-* or foreign-scope name straight to bun add — a typo or a squatted look-alike on npmjs.org would install operator-privileged code. Only the @punktfunk scope (pinned to the Gitea registry by the bunfig scope map) resolves by default now; anything else throws with an explanation unless --allow-public-registry is passed, and even then installs print a loud warning. Removal never gates — uninstalling stays safe regardless of origin. systemd (user unit): free hardening for well-behaved plugins — NoNewPrivileges, PrivateTmp, ProtectSystem=strict with ReadWritePaths=%h (plugin state and download dirs under $HOME keep working), and RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6. Plugins writing outside $HOME, and distros that restrict unprivileged user namespaces for user units, are handled via a documented systemctl --user edit drop-in. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 00:45:27 +02:00
enricobuehlerandClaude Opus 4.8	e7a8cf2bba	feat(packaging): nix web console + plugin/script runner everywhere; fix tray zbus/tokio crash ... Ship the management web console and the plugin/script runner across the packaging matrix, and fix a Linux tray startup crash. - nix: add punktfunk-web (Nitro SSR on bun) and punktfunk-scripting (Effect runner), with services.punktfunk.{web,scripting} modules. Both bun node_modules come from fixed-output derivations pinned to real deps hashes; patchShebangs the web node_modules so orval/paraglide/vite run in the sandbox. Validated on x86_64-linux (nix build .#punktfunk-{web,scripting,tray,host} all green). - punktfunk-scripting now ships for deb/rpm/arch/nix/windows, mirroring the web-console mechanics (vendored bun on deb/rpm/arch, pkgs.bun on nix; one self-contained `bun build --target=bun` bundle). Opt-in: host Recommends it, but the systemd --user unit ships un-started (Windows registers its scheduled task disabled). - fix(tray): build punktfunk-tray in its OWN cargo invocation on nix/rpm/arch. Cargo unifies features across one `cargo build`, so co-building the tray with the host pulls the host's ashpd->zbus/tokio onto the tray's shared zbus and it panics at startup ("there is no reactor running, must be called from the context of a Tokio 1.x runtime"). Isolated, the tray's zbus stays on async-io. The .deb already did this; runtime-verified on nix. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 21:16:34 +02:00