70 lines
3.0 KiB
Markdown
70 lines
3.0 KiB
Markdown
# 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:
|
|
|
|
```sh
|
|
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`, `caddy` 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.
|