Maurice 3c507c2314 feat(plugins): re-consent gate when an update wants new permissions ...

Updating a plugin used to just reinstall and reactivate, which silently
granted whatever the new version declared — so a plugin could quietly
widen its own rights on the next release.

Route updates through a new server-side update() that diffs the new
version's declared permissions against what the admin already granted:
- nothing new -> the plugin is restarted transparently on the new code.
- new permissions or a new outbound host -> the new code is installed
  but the plugin is left OFF, and the delta is handed back so the admin
  has to approve it before it turns on.

Install runs first, so a failed download/signature check leaves the
running plugin untouched. The client shows the delta in a consent dialog
and only then activates. An update can never widen a plugin behind your back.

2026-07-04 19:11:23 +02:00

..

plugin-runtime.test.ts

feat(plugins): re-consent gate when an update wants new permissions

2026-07-04 19:11:23 +02:00

registry.test.ts

feat(plugins): sandbox hardening — OS permission model, egress choke point, bound acting user, author signatures

2026-07-04 19:11:23 +02:00

supervisor.test.ts

feat(plugins): isolated per-plugin runtime + capability RPC (M1)

2026-07-04 19:11:23 +02:00