Security Policy

Copy Markdown View Source

sr25519 is cryptographic infrastructure intended for money-path signature verification. A vulnerability here is high-severity. Please treat it accordingly.

Reporting a vulnerability

Report privately to vfe@einsfeld.com, or via GitHub's private vulnerability reporting, with enough detail to reproduce. Please do not open a public issue for a suspected vulnerability. You will get an acknowledgement, and we will coordinate a fix and disclosure timeline with you.

Scope

This library verifies exact bytes and (in v0.1) handles no secret material. The most security-relevant areas:

  • The verification result contract (Sr25519.verify_raw/4 and the named Sr25519.Substrate variants) — a wrong result on the money path is the worst case.
  • The exact signing convention ("substrate" context; <Bytes>…</Bytes> wrapping) pinned in named, vector-backed functions. Constructing the exact signed bytes is a caller responsibility; a confused-deputy bug most often lives there.
  • The NIF boundary: no panic may cross it (panic = "unwind", #![forbid(unsafe_code)]).
  • The precompiled-NIF supply chain: checksums, build-provenance attestations, and the release-verify.yml gate (see the README section "Verifying release artifacts" for the full trust chain).

Pre-release review gate

Before the first published release, an independent human review is required (someone comfortable with Rust NIFs and crypto bindings), confirming at least:

  • no unsafe; no unwrap/expect/panic path reachable from untrusted input;
  • the release workflow cannot publish a mismatched artifact/checksum;
  • the vector generators are reproducible and the pinned convention matches real tooling;
  • the consuming integration constructs exactly the signed bytes.

This gate is not a substitute for a formal audit but is required for a money-path, AI-assisted codebase.

Dependency & version policy

  • schnorrkel is pinned to an exact version (built with default-features = false, so the verify-only NIF links no OS-RNG stack); Cargo.lock is committed and shipped. rustler does not pass --locked to cargo, so CI and the release workflow gate every build with a cargo metadata --locked integrity check instead — a stale or drifting lockfile fails before any artifact is built.
  • cargo audit and cargo deny cover the Rust tree in CI; mix hex.audit and mix deps.audit cover the Elixir tree; zizmor lints the workflows; GitHub Actions are pinned to commit SHAs.
  • Crypto-dependency bumps are never auto-merged. Any schnorrkel bump re-runs the full vector corpus and is treated as potentially breaking.

Supported versions

Until v1.0, only the latest 0.x release receives security fixes.