# Security policy

## Supported versions

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

| Version | Supported |
|---|---|
| 1.0.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.
- You are credited in the `Security` section of `CHANGELOG.md` if you want 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. This module has none; the standard
  library is the only import, and standard library issues belong with the Go
  project.