Skip to content

Security: santhsecurity/keyhog

SECURITY.md

Security Policy

Reporting a Vulnerability

Please report security vulnerabilities privately through GitHub's built-in Private Vulnerability Reporting:

  1. Go to the repository's Security tab.
  2. Click Report a vulnerability and fill out the advisory form.

If private reporting is unavailable for some reason, email security@santh.dev with:

  • Affected version / commit SHA
  • Reproduction steps and proof-of-concept (where safe to share)
  • Impact assessment

You will receive an acknowledgement within 5 business days. Coordinated-disclosure timeline is up to 90 days from acknowledgement; we will notify you before the patch ships.

Supported Versions

Only the main branch (and the latest published crate / package release) receives security fixes. Vendored snapshots and forks are responsible for backporting.

Out of Scope

  • Findings against archived branches or deprecated tags.
  • Self-XSS or social-engineering attacks against maintainers.
  • Reports that depend on a compromised upstream package without a reproducible downstream impact.

Coordinated Disclosure

GHSA advisories are filed under the appropriate Santh GitHub organization. We coordinate CVE assignment via GitHub's CNA when a fix ships.

RustSec Advisory Assessment (v0.5.3)

A cargo audit of Cargo.lock surfaces seven advisories total (3 vulnerability, 4 informational across the workspace + vendored vyre). Each was reviewed against keyhog's actual usage of the affected crate and given an explicit accept-with-rationale decision or a fix path. The accepts are reflected in the [advisories] ignore list at the workspace-root audit.toml; cargo audit exits clean with that file in place.

Accepted (rationale-documented)

RUSTSEC-2023-0071 - rsa 0.9.7 Marvin attack

Risk: PKCS#1 v1.5 RSA decryption is timing-sidechannel-vulnerable (Marvin attack); an attacker with a decryption oracle can recover a key.

Why not applicable: crates/verifier/src/oob/client.rs uses ONLY rsa::Oaep for decryption (use rsa::{Oaep, RsaPrivateKey, RsaPublicKey}). PKCS#1 v1.5 decryption code paths are not invoked. Even if the rsa crate's PKCS#1 v1.5 implementation has timing leaks, keyhog never exercises them.

Threat-model gate: the OOB verifier is a client, not a server. We generate a keypair, share the public half with the InteractSh server, and decrypt server-pushed payloads locally. There is no remote decryption oracle exposed by keyhog.

RUSTSEC-2026-0002 - lru 0.12.5 IterMut Stacked Borrows violation

Risk: LruCache::iter_mut() invalidates an internal pointer (detectable by Miri's Stacked Borrows checker).

Why not applicable: crates/scanner/src/multiline/fragment_cache.rs uses lru::LruCache::get_or_insert_mut() and cluster.iter_mut() on its own Vec<SecretFragment>, not on LruCache::iter_mut(). The unsound API isn't called.

RUSTSEC-2026-0097 - rand 0.8.5 unsound with custom logger

Risk: rand::rng() interaction with custom tracing logger has a data race when the global rng is replaced.

Why not applicable: keyhog does not replace the global rng. rand is pulled transitively via num-bigint-digrsa; both use only the default OsRng seed path. Our tracing logger does not call into rand.

RUSTSEC-2024-0436 - paste 1.0.15 unmaintained

Risk: crate is unmaintained; future advisories will not get fixes.

Why not applicable now: paste is a proc-macro used at compile time; it produces no runtime code in keyhog binaries. An unmaintained proc-macro can't introduce runtime CVEs. We will migrate when a suitable replacement appears in our transitive dep tree.

RUSTSEC-2025-0141 - bincode 1.x unmaintained

Risk: bincode 1.x is unmaintained upstream; future advisories against it will not be patched.

Why not applicable now: keyhog itself does not depend on bincode directly. It is only pulled in transitively through the published Vyre GPU stack, which uses bincode for serializing compiled GPU pattern databases. The serialization surface is local disk caches keyed under $KEYHOG_CACHE_DIR; there is no untrusted network input deserialized through bincode. This advisory clears when Vyre cuts a release that drops bincode 1.x or migrates to bincode 2.x.

Resolved in v0.5.3

RUSTSEC-2025-0140 - gix-date 0.9.4 non-utf8 String construction

Risk: A malicious commit with a non-UTF-8 timestamp string could have triggered UB through TimeBuf::as_str.

Resolution: Bumped gix from =0.70.0 to 0.77.0 (which pulls gix-date 0.12.0+). The bump is API-clean - all five git-using sources tests pass without source changes. See commits under "security: bump gix".

RUSTSEC-2025-0021 - gix-features 0.40.0 SHA-1 collision attacks

Risk: gix-features 0.40.0 did not detect SHA-1 collisions in git objects (Severity 6.8 / medium).

Resolution: Same gix bump pulls gix-features 0.42.0+, which adds collision detection. No source changes needed in keyhog's git source layer.

The gix bump also coordinated with two transitive dep updates that its newer versions required: smallvec 1.14.0 → 1.15.1 (in vyre's vendored workspace pin) and memmap2 0.9.9 → 0.9.10 (workspace pin).

There aren't any published security advisories