Test / test (push) Successful in 2m33s
Release / gates (push) Successful in 2m29s
Release / build (amd64, linux) (push) Successful in 1m18s
Release / build (arm64, linux) (push) Successful in 1m20s
Release / build (loong64, linux) (push) Successful in 1m17s
Release / build (riscv64, linux) (push) Successful in 1m26s
Release / release (push) Failing after 35s
1.3 KiB
1.3 KiB
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.35.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.