4 Commits

Include renames

Author	SHA1	Message	Date
enricobuehlerandClaude Opus 5	78926be4ac	fix(store): a plugin install lands in the plugins dir, not the nearest package.json above it ... Installing any plugin from the console failed on a user's Fedora 44 host with plugin store job failed: @punktfunk/plugin-virtualhere is not present after install while the same version installed fine on every box we tried. The difference turned out to be a file in his home directory. `bun add` does not install into its working directory. It walks UP to the nearest ancestor `package.json` and installs into that tree. A fresh plugins dir has no `package.json` — the store and the runner only write `bunfig.toml` — so any stray one above it captures the install: the packages land in `~/node_modules`, the dependency is written to `~/package.json`, bun prints "installed …" and exits 0, and the plugins dir stays empty. The plugins-dir `bunfig.toml` is not read in that case either, so the outcome splits on whether `@punktfunk` resolves in the hijacked tree: with no scope mapping there it 404s against npmjs and exits 1 ("the plugin runner exited with status 1"); with one, it succeeds into the wrong tree and the job dies on the presence check instead. Only the second shape looks like a broken store, which is why this took a reproduction to find. Seed the plugins dir with a `package.json` so it owns bun's install root. Three call sites rather than one: the store job, the `plugins add` CLI, and the SDK's `ensurePluginsDir`. The runner ships as its own package and can predate the host binary, so the host cannot delegate this — the same reason `ensure_bunfig_scope` writes the registry mapping on this side rather than passing a runner flag. Seeding only ever touches a tree with no `node_modules`. A dir with packages and no `package.json` is the hand-assembled/older layout that `installed_packages` deliberately falls back to the naming convention for, and dropping an empty `dependencies` on it reports every plugin the operator runs as uninstalled — already pinned by `an_emptied_dependency_list_means_nothing_is_installed`. The residual failure stops dead-ending: if the presence check fails anyway, the error names the capturing ancestor and what to do about it. Reproduced and fixed on glass (Nobara 44 VM, host + runner 0.22.3): with a stray ~/package.json the store reproduces the field report byte for byte — same 150 ms, same phase sequence, same message — and with the plugins dir seeded the same install lands correctly with nothing leaking into the home dir. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 12:48:25 +02:00
enricobuehlerandClaude Fable 5	45c3b96907	feat(store): plugin store host module — signed catalogs, tiered trust, install jobs ... The index is the verification gate: a catalog entry pins one exact version plus that version's tarball integrity hash, so 'verified on every release' is a property of the data rather than a promise about process. Nothing can express 'track latest' for a catalogued plugin. - store/index.rs signed index parse + ed25519 verify (ring), validate-and-drop per entry, semver minHost/advisory ranges - store/sources.rs built-in unom source (compiled-in URL + two key slots for rotation) + operator sources in plugin-sources.json - store/catalog.rs https fetch with size/timeout/redirect caps, signature before parse, last-good disk cache (stale-but-usable when offline) - store/jobs.rs single-flight install/uninstall: registry-integrity preflight against the pin, spawn the runner CLI with live log capture, post-install version check with rollback, provenance record, runner restart (discovery is startup-only) - store/manifest.rs install provenance; absence means CLI-installed - mgmt/store.rs 12 routes under /api/v1/store, denied to the plugin token (a plugin that can install plugins is an escalation primitive) Also generalizes runner discovery and listInstalled from @punktfunk/plugin-* to ANY scope's plugin-*: catalog entries must be scoped so the scope can map to that entry's registry, so a third-party plugin necessarily arrives under its own scope and would otherwise install but never run. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 20:48:02 +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 Fable 5	f0c511c8fa	feat(plugins): punktfunk-host plugins CLI — add/remove/list/enable/disable/status ... One-liner plugin management replacing the manual scripting-dir + bunfig + bun-add ritual: package ops forward to the bun runner (new sdk plugins module + runner-cli subcommands, 11 tests green), enable/disable/status drive the systemd unit on Linux and the PunktfunkScripting scheduled task on Windows (installer support in the ISS). Docs page rewritten as .mdx with per-platform Tabs (registered in mdx.tsx). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-19 16:34:43 +02:00