ledger holds records for people for whom exposure can be dangerous. Security here is not only about the software — it is about the safety of contributors. Please read the reporting rules below; one of them is unusual and important.
This is a pre-1.0 reference implementation. Security fixes land on main and the
latest tagged release. Pin a tag and watch releases for advisories.
| Version | Supported |
|---|---|
main / latest tag |
✅ |
| older tags | ❌ |
Use GitHub's private vulnerability reporting ("Report a vulnerability" under the
repository's Security tab). It opens a private advisory only maintainers can see.
If you cannot use it, email ckellyreif@gmail.com with ledger security in the
subject. Expect an acknowledgement within a few days; this is a volunteer project, so
please be patient and do not disclose publicly until a fix is available.
When you report a bug or a security issue, never paste a real sealed value, a real
contributor identity, or any record content that is not already public. If a flaw
exposes a sealed field, describe the shape of the leak — "field X with policy
sealed-until rendered to an anonymous viewer on route Y" — and reproduce it with the
synthetic fixtures in tests/fixtures/, which carry sentinel values designed exactly
for this. A report that helps us fix a leak must not itself become a leak. Issue
templates and the bug-capture path are built to never ask you for sealed content.
In addition to the usual (RCE, auth bypass, injection, secret exposure), the following are first-class security bugs in ledger, equal in severity to a memory unsafety bug elsewhere:
- Any path by which holding or operating an archive reveals who contributed a record to a viewer without an explicit identity-unseal grant — via a view, the JSON API, an export, a filename, a log line, a metric label, an error message, a timing difference, or inference from what is not shown.
- Any path by which a sealed record or field renders to a viewer whose grant does not permit it, including after a takedown or consent change.
- Any silent fixity outcome — corruption accepted as valid, or a
fixity-failureswallowed instead of quarantined. - Any consent or takedown that does not propagate to all replicas.
See docs/THREAT-MODEL.md for the full model (seizure, subpoena, doxxing, a
malicious steward) and the guarantees the code is required to meet.
- We fix no-outing and sealed-disclosure bugs with the highest priority.
- We credit reporters who want credit, and respect those who want anonymity.
- Releases are signed and dependencies are pinned and scanned (pip-audit, CodeQL,
gitleaks in CI); see
CONTRIBUTING.md.