minisign-verify

Zero-dependency Rust crate for verifying Minisign Ed25519 signatures

Library
Cargo
v0.2.5
42stars
MIT License

Repository Health

Pre-computed score based on development activity, maintenance, community, maturity, and trend momentum.How we score it →
27/100Needs Attention
Development Activity16
Maintenance0
Community20
Maturity60
Momentum12

Technical Analysis

AI-assessed by reading the actual repository — architecture, code quality, innovation, and documentation.How we score it →
70/100Good
Architecture74
Code Quality72
Innovation65
Learning Curve70

minisign-verify is a small, dependency-free Rust crate for verifying signatures produced by Minisign, Frank Denis’s simple tool for signing files with Ed25519 keys. It implements the full verification path itself — Ed25519 signature checking, Blake2b/SHA-512 hashing, and base64 decoding are all vendored directly into the crate rather than pulled in from external cryptography crates, keeping the dependency tree at zero and the codebase auditable in one place.

The crate supports both standard (in-memory) and pre-hashed/streaming verification modes, the latter letting callers verify signatures on large files by feeding data through in chunks rather than loading the whole file into memory. It’s aimed squarely at software that needs to verify update packages, release artifacts, or other Minisign-signed files as part of a build, deployment, or auto-update flow, without needing a full general-purpose cryptography dependency.

What You Get

  • A PublicKey type loadable from base64 strings or .pub key files
  • A Signature type parsed from Minisign’s signature file format, including trusted/untrusted comment access
  • PublicKey::verify() for straightforward in-memory signature verification
  • A StreamVerifier (verify_stream/update/finalize) for verifying large files in chunks without loading them fully into memory
  • Self-contained, vendored Ed25519, Blake2b, and SHA-512 implementations with zero external dependencies
  • Structured Error variants for precise failure reporting (bad signature, key mismatch, I/O errors, etc.)

Common Use Cases

  • Verifying signed release artifacts or update packages before installing them in an auto-update mechanism
  • Checking Minisign signatures on downloaded files as part of a build or CI supply-chain integrity step
  • Verifying large file downloads (ISOs, archives) via streaming verification without buffering the entire file in memory
  • Adding lightweight signature verification to a tool without introducing a heavier general-purpose crypto dependency

Under The Hood

Architecture - The crate is organized around three public types in src/lib.rs: PublicKey (parsed from Minisign’s base64 key format), Signature (parsed from Minisign’s signature file format, including its trusted/untrusted comment lines), and StreamVerifier for incremental verification. Underneath, src/crypto/ contains self-contained implementations of the primitives Minisign needs: ed25519.rs for signature verification, curve25519.rs for the underlying elliptic-curve arithmetic, blake2b.rs and sha512.rs for the two hash functions Minisign signatures can be built on (selected based on the signature’s algorithm identifier), and cryptoutil.rs for shared byte-level helpers. src/base64.rs implements the crate’s own base64 decode/encode rather than depending on an external crate.

Tech Stack - Pure Rust (edition 2018) with genuinely zero runtime dependencies — every cryptographic primitive (Ed25519, Curve25519, Blake2b, SHA-512) and encoding routine (base64) is implemented directly in the crate rather than delegated to ed25519-dalek, base64, or similar. The release profile enables LTO, panic = "abort", and full optimization, consistent with a crate meant to be embedded in small tools and update-checking code paths where binary size and predictable behavior matter.

Code Quality - Inline #[test] modules in lib.rs cover the documented example flows (decoding a public key and signature, verifying against known-good test vectors), giving direct confidence that the crate correctly implements Minisign’s on-disk formats and verification logic. Because all cryptographic primitives are vendored rather than reused from audited upstream crates, correctness rests entirely on this project’s own implementation and tests — a deliberate trade-off explicitly framed in the README as favoring “simple, auditable code” over reusing a general-purpose crypto dependency.

API Design - The API mirrors Minisign’s own two-step verification flow closely: load a PublicKey (from a base64 string or .pub file), load a Signature (from a string or .sig file), then call verify() with the file content, or build a StreamVerifier and repeatedly update() it with chunks before calling finalize(). Errors are returned as a structured Error enum rather than panicking, and comment accessors (trusted_comment()/untrusted_comment()) expose Minisign’s comment metadata directly, so callers don’t need to hand-parse the signature file format themselves.

Join founders buildingwith open source

Opinionated takes, migration guides, cost-saving tips, and insights from the open source ecosystem.

Subscribe on Substack
Join 750+ subscribers

Search