Test / test (push) Successful in 2m11s
Release / gates (push) Successful in 2m11s
Release / build (amd64, linux) (push) Successful in 1m13s
Release / build (arm64, linux) (push) Successful in 1m10s
Release / build (loong64, linux) (push) Successful in 1m12s
Release / build (riscv64, linux) (push) Successful in 1m33s
Release / release (push) Successful in 58s
42 lines
1.3 KiB
Markdown
42 lines
1.3 KiB
Markdown
# Security policy
|
|
|
|
## Supported versions
|
|
|
|
Security fixes go to the newest release and to the `development` branch. Older
|
|
releases do not receive them.
|
|
|
|
| Version | Supported |
|
|
|---|---|
|
|
| 0.34.0 | yes |
|
|
| older releases | no |
|
|
|
|
## 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 fix ships without naming you: the project keeps no credits list, so the release
|
|
notes, the changelog and the commits name no reporter.
|
|
|
|
## 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.
|