Skip to content

Security and architecture

This is a terminal that runs commands on production equipment, and a site where strangers publish those commands to each other. The uncomfortable facts are on this page with the reassuring ones.

On your machine

  • Credentials go in the operating system's vault. DPAPI on Windows, Keychain on macOS, libsecret on Linux. Not a config file, not a database, and not in any export you share.
  • Session logs and the audit log are local. They are files on your disk for you to read. Nothing is sent anywhere; there is no telemetry in the application.
  • The AI assistant cannot execute anything. It reads the session transcript and proposes a command. You press the key. There is no mode, setting or flag that lets it run one — including its Insert button, which puts text in the terminal and stops. Point it at Ollama on your own machine and the transcript never leaves the building at all.
  • Global variables are a file you own. Values live in global-variables.env next to the app's data, in plain text. Treat it the way you would treat any file with a jump host in it — and note that it is deliberately plain, so it is not the place for a password.

The button exchange

The threat model is simple: uploaded button sets are shell commands that strangers will run on production network equipment.

  • Nothing uploaded is ever executed, interpreted or passed to a shell. The site parses a file, checks it, and describes it. It is a file exchange, not a runtime.
  • The whole script is on the page before the download button. Every step of every button, with the exact text that will be sent, nested branches included. Read it the way you would read a script someone emailed you.
  • Destructive steps are flagged, not blocked. Reboots, config erases, factory resets and credential changes are matched and labelled, through nested branches and through called buttons. Engineers share reboot buttons for good reasons — the point is that one never arrives unannounced.
  • Nothing is ever called safe. An unflagged set is one that did not match a rule, which is not the same thing. The rules are heuristics over command text and can miss.
  • You get the exact bytes that were uploaded. Downloads are served from the stored original, so the SHA-256 printed on the page is what sha256sum will tell you.
  • A first upload is reviewed by a person, and so is anything carrying a high-severity flag, whoever sent it.

The builds themselves

The builds are not code-signed

Signing certificates cost money that is not being spent on this yet. SmartScreen will say so on Windows, and your antivirus may quarantine the first run of an unsigned installer. That is the honest state of it, not a bug to work around.

Until that changes, the SHA-256 published beside every download is the only integrity check available to you — so it is worth actually running. The commands are on the download page next to each file.

The site

  • Everything user-supplied is escaped on output, and the content security policy is script-src 'self' with no inline script — so a missed escape still has nothing to execute.
  • Passwords are hashed with bcrypt. Nobody can read them back, including whoever runs the site.
  • Downloading needs no account. Reading a set's full script needs no account.
  • There is no advertising, no third-party analytics and no tracking across other sites. Download counts are numbers, with nothing recorded about who downloaded — see the privacy notice.

Reporting something

If you find a security problem in the application or this site, email security@smartcomrevisited.com. If a published button set is dangerous or misrepresented, there is a report form on its page, and abuse@smartcomrevisited.com reaches the moderators without an account.

A fuller architecture write-up — how the upload pipeline is put together, what the parser will and will not accept, and where the boundaries are — is still to be written. Until then the documentation covers the parts that affect what you do day to day.