Security
What these tools can, and cannot, do to your machine
These are front ends for programs that change a running system. That is worth being precise about rather than reassuring about. Here is every promise the family makes, what each one is worth, and the one that is still an open item.
The principles
Preview, then confirm
No tool changes anything without first showing the exact command line. A tool never assembles a shell string: it builds a command value, the confirm dialog displays that value, and the runner receives the same one. The preview cannot drift from what executes, because they are the same object. That is the whole trust boundary, and it is one small package in tui-kit rather than a rule each tool re-implements.
Read-only by default
Starting a tool only reads. Nothing is written, nothing is scheduled, and there is no first-run setup that changes your machine. If a read itself needs root, as ufw's status does, the tool says so instead of silently escalating.
Runs as you
Reads work unprivileged wherever the underlying tool allows it. Only an action escalates, through sudo -n, which never prompts: run sudo -v in another terminal first, or start the tool with sudo. The prefix is configurable, so doas works, and an empty prefix runs the command directly when you are already root.
No daemon, no state of its own
One static binary. Nothing keeps running after you quit, nothing is installed to run later, and no state is kept beside the system's own. The system is the source of truth; a tool re-reads it after every change, so what you see is what the machine reports rather than what the tool assumed.
No network
The tools open no network connection of their own. No telemetry, no update check, no crash reporting, no phone home. Upgrading means downloading a newer binary, on purpose.
--demo always works
Every tool runs against in-memory sample data with --demo. Every key works and every command is built and previewed for real; the fake runner records what it was asked to run and answers from a table, so nothing reaches your system. It exists so a reviewer can read the previews before ever pointing a tool at a real machine.
Every tool, answered
from each tool.json| Tool | Escalates | No daemon | No network | Static | Signed releases |
|---|---|---|---|---|---|
| tui-cert | actions only | ✓ | ✕ | ✓ | ✕ |
| tui-containers | actions only | ✓ | ✓ | ✓ | ✕ |
| tui-cron | actions only | ✓ | ✓ | ✓ | ✕ |
| tui-disk | actions only | ✓ | ✓ | ✓ | ✕ |
| tui-firewall | actions only | ✓ | ✓ | ✓ | ✕ |
| tui-logs | actions only | ✓ | ✓ | ✓ | ✕ |
| tui-network | actions only | ✓ | ✓ | ✓ | ✕ |
| tui-samba | actions only | ✓ | ✕ | ✓ | ✕ |
| tui-secure | actions only | ✓ | ✕ | ✓ | ✕ |
| tui-snapper | actions only | ✓ | ✓ | ✓ | ✕ |
| tui-ssh | actions only | ✓ | ✓ | ✓ | ✕ |
| tui-systemd | actions only | ✓ | ✓ | ✓ | ✕ |
| tui-update | actions only | ✓ | ✓ | ✓ | ✕ |
| tui-users | actions only | ✓ | ✓ | ✓ | ✕ |
| tui-template | actions only | ✓ | ✓ | ✓ | ✕ |
The last column is the open item. Releases carry SHA-256 checksums and nothing else, which is stated here rather than left for you to discover.
How sudo is used
A tool resolves the binary it drives — ufw,systemctl — to an absolute path, and prefixes it with the escalation prefix from its configuration. The default issudo -n: the -n means non-interactive, so it never prompts. If your sudo timestamp has expired, the command fails and the tool tells you, rather than a password box appearing inside a TUI where you cannot tell what is reading it.
The whole prefix is one configuration value. Set it todoas, or to the empty string when you are already root:
$ sudo -v$ sudo tui-firewall --sudo ''Verifying a download
$ curl -fsSLO https://github.com/tui-tools/tui-firewall/releases/latest/download/checksums.txt
sha256sum -c checksums.txt --ignore-missingEach tool's page lists the SHA-256 of every asset, parsed from that same file at build time, so you can compare without downloading anything first. --ignore-missing checks only what you have.
What a checksum proves
That the file arrived intact from the same place the checksum did. Both come from the GitHub release, so this catches corruption and a broken mirror, not a compromised release.
Signatures are what would close that gap, and they are not in place yet. Until they are, the strongest check available is building from source: the repositories are small, the dependencies are Bubble Tea, Bubbles, Lip Gloss and the kit, and make build is the whole story.
Reporting a vulnerability
Report privately, through GitHub's private vulnerability reporting on the affected repository's Security tab. Do not open a public issue. Expect a first reply within a week; this is a small project maintained in spare time, and there is no bounty.
In scope is anything that breaks the trust boundary: a command that executes without having been previewed and confirmed; a preview that does not match what is executed; an argument taken from a config file, a theme file or parsed command output that reaches a shell or changes the meaning of a command line; escalation beyond the configured prefix.
Not in scope is anything you can already do with the underlying tool at the same privilege level. These are terminal front ends, not a privilege boundary of their own. Needing root to change the system is the design, and locking yourself out of a machine with a rule that does so is something the tools warn about but do not second-guess.