Files
volumen/SECURITY.md
T
petrbalvin f8ed33df83
Test / test (push) Successful in 7m5s
Release / gates (push) Successful in 7m28s
Release / build (amd64, freebsd) (push) Successful in 2m52s
Release / build (amd64, linux) (push) Successful in 2m46s
Release / build (arm64, freebsd) (push) Successful in 2m22s
Release / build (arm64, linux) (push) Successful in 2m38s
Release / build (loong64, linux) (push) Successful in 2m7s
Release / build (riscv64, linux) (push) Successful in 2m17s
Release / release (push) Successful in 1m0s
Initial commit
Assisted-by: GLM 5.3
2026-09-29 10:03:32 +02:00

1.2 KiB

Security policy

Supported versions

Security fixes go to the newest release and to the development branch. Older releases do not receive them.

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 version or commit you tested, and the platform
  • what the problem is, and what an attacker gains from it
  • the smallest reproducer you have, ideally a test or 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 released before the details are published, and the timing is agreed with you.
  • The reporter is credited in the release notes only if they ask to be.

Out of scope

  • Findings that require the attacker to already run code as the user, or to have local access.
  • Missing hardening with no demonstrated impact.
  • Flaws in a third-party dependency: report them to that project, and to this one only when this project's use of it makes them reachable.