Remove the per-provider custom scripts feature #82

New issue

Open

opened 2026-08-20 00:48:12 -04:00 by mysticalsoap · 0 comments

mysticalsoap commented

2026-08-20 00:48:12 -04:00

Owner

Remove the per-provider custom-scripts feature: the Scripts tab, save_scripts/clear_scripts/update_scripts_enabled in the GUI, exe_custom_scripts and its six call sites in tunnel.py, and the {provider}_scripts config keys.

Why:

It is arbitrary root command execution configured from the GUI: script strings live in config.json (written via cfgupdate) and run inside the root service's tunnel threads. polkit gates the writer, but it's a wide, quiet root-exec channel kept alive for a feature with no known users — same reasoning that deleted the self-updater (#19).
The hooks get no context (no device, no role, no env), so they can't do anything a tunnel hook is actually for.
They're keyed per provider but fire per tunnel process, which is how #74's sibling bug #81 exists (pre/down firing for hop connects). This removal supersedes #81 — the buggy guards exist only to gate this feature; the removal PR should close both.

If demand ever shows up, the re-add should be the inverse shape: hooks run in the GUI process as the user, triggered by the status/state signals the GUI already receives (it now holds the typed tunnel state for context) — no root involvement. Same check-only-re-add pattern as #48.

Remove the per-provider custom-scripts feature: the Scripts tab, `save_scripts`/`clear_scripts`/`update_scripts_enabled` in the GUI, `exe_custom_scripts` and its six call sites in `tunnel.py`, and the `{provider}_scripts` config keys. Why: - It is arbitrary root command execution configured from the GUI: script strings live in config.json (written via `cfgupdate`) and run inside the root service's tunnel threads. polkit gates the writer, but it's a wide, quiet root-exec channel kept alive for a feature with no known users — same reasoning that deleted the self-updater (#19). - The hooks get no context (no device, no role, no env), so they can't do anything a tunnel hook is actually for. - They're keyed per provider but fire per tunnel process, which is how #74's sibling bug #81 exists (pre/down firing for hop connects). This removal supersedes #81 — the buggy guards exist only to gate this feature; the removal PR should close both. If demand ever shows up, the re-add should be the inverse shape: hooks run in the GUI process as the user, triggered by the status/state signals the GUI already receives (it now holds the typed tunnel state for context) — no root involvement. Same check-only-re-add pattern as #48.

mysticalsoap added the

cleanup

security

labels

2026-08-20 00:48:12 -04:00

mysticalsoap referenced this issue

2026-08-20 10:48:59 -04:00

Module decomposition (index) #83

mysticalsoap referenced this issue

2026-08-23 01:44:31 -04:00

Extract the Provider tab into gui/provider.py #129