ordvec

The project follows Semantic Versioning and records changes in CHANGELOG.md, giving a clear upgrade path (cargo update); as a pre-1.0 project it maintains a single active release line on main. https://github.com/Project-Navi/ordvec/blob/main/CHANGELOG.md

GitHub Issues is the project's issue tracker. https://github.com/Project-Navi/ordvec/issues

No vulnerabilities have been reported or resolved in the last 12 months, so there are no reporters to credit.

SECURITY.md documents the process for responding to vulnerability reports: private reporting via GitHub Security Advisories, an acknowledgement commitment, and the supported-version policy for fixes. https://github.com/Project-Navi/ordvec/blob/main/SECURITY.md

Rust uses rustfmt (the standard style) plus Clippy; the Python bindings follow PEP 8. CONTRIBUTING documents the required style and CI enforces it. https://github.com/Project-Navi/ordvec/blob/main/CONTRIBUTING.md https://github.com/Project-Navi/ordvec/blob/main/.github/workflows/ci.yml

rustfmt and Clippy run automatically in CI on every push/PR (cargo fmt --all --check; cargo clippy --all-targets --all-features -- -D warnings), so style violations fail the build. https://github.com/Project-Navi/ordvec/blob/main/.github/workflows/ci.yml

The project is pure Rust built with Cargo and has no native C/C++ build, so compiler/linker variables such as CC/CFLAGS/LDFLAGS do not apply.

Builds use Cargo's standard profiles, which preserve debugging information per profile; the project does not strip symbols. https://github.com/Fieldnote-Echo/ordvec/blob/main/Cargo.toml

The project builds with Cargo, which is not a recursive make-style build system, so recursive subdirectory builds with cross-dependencies do not apply.

Builds are repeatable: dependencies are locked in Cargo.lock and the toolchain floor is pinned (MSRV 1.89), so a clean checkout reproduces the same result. https://github.com/Project-Navi/ordvec/blob/main/Cargo.lock

The crate installs via Cargo using a common convention (git dependency now, crates.io on first release); the Python bindings install via pip/maturin. The README documents installation. https://github.com/Project-Navi/ordvec/blob/main/README.md#quickstart

The project produces a Rust library consumed via Cargo (and a Python wheel via pip); it has no end-user system installer with location variables such as DESTDIR or prefix, so this does not apply.

Developers get everything needed to make changes and run the tests with git clone then cargo build / cargo test (and maturin develop + pytest for the bindings); CONTRIBUTING documents the full setup and gate. https://github.com/Project-Navi/ordvec/blob/main/CONTRIBUTING.md

External dependencies are listed in a computer-processable form in Cargo.toml and Cargo.lock (and a CycloneDX SBOM is generated in CI). https://github.com/Project-Navi/ordvec/blob/main/Cargo.toml

Dependencies are monitored automatically: Dependabot (7-day cooldown) opens update PRs, cargo-deny checks advisories in CI, and a weekly scheduled audit runs cargo-deny advisories. https://github.com/Project-Navi/ordvec/blob/main/.github/dependabot.yml https://github.com/Project-Navi/ordvec/blob/main/.github/workflows/audit.yml

Reused components are standard Cargo crates with versioned dependencies, trivial to identify and update via Cargo (Cargo.toml/Cargo.lock) and Dependabot. https://github.com/Project-Navi/ordvec/blob/main/Cargo.toml

The project avoids deprecated/obsolete APIs: it builds under -D warnings, so any use of a deprecated function (including the crate's own deprecated aliases) fails CI, and Clippy flags obsolete patterns. https://github.com/Project-Navi/ordvec/blob/main/.github/workflows/ci.yml

An automated test suite runs on every check-in via GitHub Actions: cargo test across the default/experimental/no-default-features surfaces on Linux/macOS/Windows, plus the Python pytest suite, each reporting pass/fail. https://github.com/Project-Navi/ordvec/blob/main/.github/workflows/ci.yml

Bug fixes are shipped with regression tests added to the automated suite (e.g., the red-team test files under tests/ and audit-remediation regression tests added alongside their fixes). https://github.com/Project-Navi/ordvec/tree/main/tests

The automated test suite achieves over 80% statement coverage as measured by cargo-llvm-cov (a FLOSS tool), run on every push/PR in .github/workflows/coverage.yml and reported to Codecov; the most recent hosted-CI figure is ~82%. The enforced regression floor is set to 78% only to tolerate the AVX-512-free hosted runner, which cannot execute the AVX-512 kernels (those are additionally exercised under Intel SDE). https://github.com/Project-Navi/ordvec/blob/main/.github/workflows/coverage.yml

CONTRIBUTING.md states a formal written policy: "Tests are required for new functionality. As major new functionality is added, tests covering it MUST be added to the automated test suite" (cargo test, plus pytest for the Python bindings). https://github.com/Project-Navi/ordvec/blob/main/CONTRIBUTING.md

CONTRIBUTING.md documents the contribution gate, which requires the test suite to pass. https://github.com/Project-Navi/ordvec/blob/main/CONTRIBUTING.md

Maximally strict: all compiler warnings denied and clippy -D warnings across all targets/features.

Secure design is implemented where applicable for a numeric library: all external inputs (serialized index files, query buffers) are validated; size computations use checked_mul; the public API exposes no caller-facing unsafe, and the internal SIMD unsafe is SAFETY-documented and fuzzed. https://github.com/Project-Navi/ordvec/tree/main/fuzz

ordvec implements no cryptography.

The software ships no cryptography (the only RNG, ChaCha8, is used solely in tests/benchmarks), so cryptographic algorithm agility does not apply.

The software stores no authentication credentials or private cryptographic keys, so this does not apply.

The software performs no network communication, so secure-protocol requirements do not apply.

The software does not use TLS, so this does not apply.

The software does not use TLS, so certificate verification does not apply.

The software does not use TLS, so this does not apply.

Met. ordvec’s public releases are signed and/or attested: the v0.4.0 release ships signed Git tag provenance plus GitHub/Sigstore/SLSA attestations for the crates.io .crate artifacts and PyPI wheel/sdist artifacts, with PEP 740 attestations served by PyPI. Verification is documented in RELEASING.md; users verify downloaded artifacts with gh attestation verify <file> -R Project-Navi/ordvec and PyPI Integrity API provenance. The project uses OIDC/Sigstore keyless signing and trusted publishing, so no long-lived private signing key or registry token is stored on crates.io, PyPI, or the public distribution sites.

Met. Important public release tags are cryptographically signed and verifiable. The current public release tag v0.4.0 is a signed annotated Git tag; GitHub reports the tag signature as verified, and local verification succeeds with git tag -v v0.4.0. The documented release process requires signed tags via git tag -s vX.Y.Z -m "vX.Y.Z" before publishing.

All inputs from untrusted sources are validated and invalid inputs rejected: the index-file loaders perform semantic validation (magic, dimensions, lengths, trailing-byte rejection) and return errors rather than panicking; sizing uses checked_mul; the FFI layer enforces finiteness/contiguity. Deserialization paths are continuously fuzzed. https://github.com/Project-Navi/ordvec/tree/main/fuzz

Hardening appropriate to a Rust library: memory-safe by construction, arithmetic-overflow guards on size computations, no caller-facing unsafe, SAFETY-audited internal SIMD, fuzzed parsers, and cargo-deny gating advisories/licenses/bans. https://github.com/Project-Navi/ordvec/blob/main/.github/workflows/ci.yml

THREAT_MODEL.md is the project's assurance case: it gives a threat model, identifies trust boundaries (the section 1 component-map / trust-boundary table), argues secure-design principles are applied (untrusted-input parsing, fail-loud validation, checked arithmetic, type-level write/load round-trip), and argues common implementation weaknesses are countered (layered deserialization hardening + cargo-fuzz, a #![deny(unsafe_op_in_unsafe_fn)] lint over the AVX-512 kernel, Python FFI guards, and SHA-pinned/OIDC/SLSA supply-chain controls). https://github.com/Project-Navi/ordvec/blob/main/THREAT_MODEL.md

CodeQL security queries plus cargo-deny (RUSTSEC advisory DB) check for common vulnerability classes.

Fuzz targets exercise the parsing paths; the SIMD unsafe kernels are exercised under CI incl. Intel SDE with documented SAFETY invariants (ASAN coverage tracked as a follow-up).