Skip to content

Security: ledvar/ledvar-rs

SECURITY.md

Security policy

Reporting a vulnerability

Do not open a public issue.

Report privately through GitHub: Security → Report a vulnerability. If that is unavailable to you, email maykon.lma@gmail.com — encrypted with the project signing key if you prefer (fingerprint 750F 73CA 0EC5 9FB3 D945 CA12 911C CB7A 80D3 49FB).

Please include the crate and version, the input that triggers it, and what you expected instead. A failing test is the most useful thing you can send.

You will get an acknowledgement within 7 days. There is no bounty; there is credit, if you want it.

What counts as a vulnerability

This crate hashes and compares state that often comes from untrusted input — a snapshot collected from a machine you do not control, a file someone sent you. Treat as security issues:

  • A wrong hash. Any input that hashes differently here than the protocol's canonical form requires. This is the worst kind of bug in this codebase: the hash is the product. A silent divergence means two systems disagree about reality while both report success.
  • Malformed input that gets hashed instead of refused. Validation runs before hashing, by design (SPEC.md §9). Anything that slips past it is a hole.
  • A panic, hang, or unbounded allocation on untrusted input. The CLI is meant to be safe to point at a hostile file. It must fail with an error, not die.
  • A dependency with a known advisory. CI runs cargo audit on every change and gates releases on it, but tell us if you spot one it misses.

Ordinary bugs — a confusing message, a missing flag, a slow path — are not security issues. Open them publicly; they are welcome.

Supported versions

Only the latest published version of each crate. The three crates (ledvar-core, ledvar-diff, ledvar) are versioned in lock-step.

Pre-1.0, a fix ships as a new MINOR or PATCH — there are no backports to older lines.

Verifying what you downloaded

Every release artifact is signed with a GPG key that never touches CI, and a published release is immutable. See Verifying a release.

The unsafe surface

The default build has no unsafe and no C: ledvar-core depends only on serde and sha2.

The one exception is opt-in: the yaml feature pulls serde_yaml_ng, which brings in unsafe-libyaml (C). That is precisely why it is not on by default. If your threat model does not allow it, do not enable it — the release binaries are built without it.

There aren't any published security advisories