neocache is in active development. Security fixes are made against the latest released 0.x minor version on crates.io and the main branch.

When a 1.0 is published, this policy will be revised to support the most recent stable major version.

Please do not report security vulnerabilities through public GitHub issues, discussions, or pull requests.

neocache uses unsafe Rust internally (via the hashbrown raw API and a vendored reader-writer lock). Bugs in this crate can therefore cause memory unsafety, data races, or undefined behaviour in downstream programs. We treat any such report as a security issue.

To report a vulnerability, use either of the following private channels:

1. GitHub private vulnerability reporting — preferred. Open https://github.com/Shopify/neocache/security/advisories/new and submit a draft advisory. Only repository maintainers can see it.
2. Email — send a description to security@shopify.com with neocache in the subject line. PGP is available on request.

Please include, where possible:

• The version (or commit SHA) of neocache affected.
• A minimal reproducer (a Rust test or short program is ideal).
• The platform, Rust toolchain version, and feature flags used.
• The observed impact (e.g. crash, data race detected by ThreadSanitizer, out-of-bounds access reported by Miri, panic on a code path that should be total).
• Whether the issue requires unsafe from the caller, or is reachable from safe Rust only.
• Any suggested mitigation, if you have one.

We aim for the following response targets:

We coordinate disclosure with the reporter and will credit you in the published advisory unless you ask otherwise.

The following are not considered security vulnerabilities for this project:

• Performance pathologies that do not cause memory unsafety. Tail-latency surprises (for example, an insert blocking on a long S3-FIFO eviction sweep) should be reported as regular GitHub issues.
• Behaviour that requires a malicious Hash, Eq, Clone, or Drop implementation on user-supplied K or V. The crate documents that it trusts these traits.
• Hash-flooding attacks against a NeoCache constructed with a non-randomized hasher (e.g. std::collections::hash_map::DefaultHasher with a fixed seed). The default ahash::RandomState is randomized; substituting a deterministic hasher is an opt-in trade-off.
• Issues in third-party dependencies. Please report those upstream; we will bump the dependency once a fix is available.

If you embed neocache in a service that handles untrusted input:

• Keep the default ahash::RandomState hasher unless you have a specific reason to substitute one.
• Set cache_capacity to a finite value sized to your memory budget; avoid new_unbounded() for caches keyed on attacker-controlled data.
• Do not hold Ref / RefMut guards across .await points or across calls that may re-enter the same shard. See docs/usage-guide.md.