scripts/SECURITY.md

Security policy

Supported versions

The published scripts are not versioned artefacts: https://petrbalvin.org/scripts/ is updated on every push to main, and each script carries its own version string. A security fix goes to the newest published copy and to the development branch of the repository. Older copies that were downloaded earlier do not receive fixes; take the current file again.

SHA256SUMS is published beside the scripts and covers every one of them, so a downloaded copy can be checked before it runs:

curl -sSfO https://petrbalvin.org/scripts/server-setup.pl
curl -sSfO https://petrbalvin.org/scripts/SHA256SUMS
sha256sum -c --ignore-missing SHA256SUMS

Reporting a vulnerability

Do not open a public issue for a security problem. A public report tells everyone about the flaw before there is a fix. Report it privately to opensource@petrbalvin.org.

Include:

• the script and its version (--version), and the platform
• what the problem is, and what an attacker gains from it
• the smallest reproducer you have, ideally a single command
• a suggested fix, if you have one

What to expect

• A human reads the report, and you get an acknowledgement.
• You are kept informed while the fix is being made, and told when it ships.
• The fix is published before the details are, and the timing is agreed with you.
• You are credited in the commit message of the fix, by name or by handle, as you prefer.

What the scripts already do

These are the properties to check first, because a finding that contradicts one of them is a defect worth reporting:

• server-setup.pl writes the SSH rule into the permanent firewalld configuration and verifies it through the offline client before firewalld is enabled, so enabling the firewall cannot lock the operator out.
• sglang-deploy.pl protects the endpoint with an API key stored in a root-only EnvironmentFile (/etc/sysconfig/sglang, mode 0600), serves it over TLS only, and binds the engine to the loopback address.
• workstation-setup.pl verifies what it downloads: the Go tarball against the SHA-256 in go.dev's download API, the GoLand tarball against JetBrains' published checksum, and Brave's repository key against the fingerprints published on brave.com.
• Downloads are never piped into a shell: a fetched installer lands in a file first and is executed only after the transfer completed.

Out of scope

• Findings that require the attacker to already have root, or to already run code as the user who runs the script.
• Missing hardening with no demonstrated impact, such as a script not setting a stricter umask than the system's.
• Flaws in a third-party tool the scripts drive (dnf, podman, openssl, nginx and the rest): report those to that project, and here only when this repository's use of the tool makes the flaw reachable in a way the tool's own documentation does not anticipate.
• The published copies being fetched over HTTPS from a domain the operator does not control, which is the deployment model rather than a defect in the scripts.