Reporting a security problem
Please report privately first, and please don’t open a public issue for something exploitable. Each project has its own policy file; this page points to the right channel for each.
Where to send it
| Project | Channel | Policy |
|---|---|---|
| Peira | security@peiralabs.com | SECURITY.md |
| deadair | GitHub private vulnerability reporting | SECURITY.md |
| Revision Agreement | GitHub private vulnerability reporting, for errors with security consequences; ordinary errors go in a public issue | SECURITY.md |
| Field tools | GitHub private advisory or email | SECURITY.md |
| This site | security@peiralabs.com | this page |
What helps
- The project and version, or the page address.
- What you found, and the smallest input that reproduces it.
- What an attacker would need: network position, access, or a file you would have to open.
Reports are handled on a best-effort basis, not under a service-level agreement. The Peira and deadair policies say to expect an acknowledgment within about a week, and the field tools policy within a few days. Fixes go into the latest release; the field tools have no releases, so their fixes land on the main branch.
This site is static: no accounts, forms, cookies or server-side code. The machine-readable contact is at /.well-known/security.txt.