# Security Policy
`dove-core` is the crypto and transfer library behind
[dove](https://dove.sh): it encrypts files client-side and drives access to
time- and count-limited links. Its security properties are the product, so we
take reports seriously and want to make them easy to file.
## Reporting a vulnerability
**Please do not open a public issue for a security vulnerability.**
Report it privately through **GitHub's private vulnerability reporting** on
this repository (the *Security* tab → *Report a vulnerability*). If you can't
use that, note it in a minimal, non-public way and we'll arrange a private
channel.
Please include, as best you can:
- what the issue is and the impact you think it has,
- steps or a proof-of-concept to reproduce it,
- the version / commit affected.
We aim to acknowledge a report within a few days, agree on a disclosure timeline
with you, and credit you when the fix ships (unless you'd rather stay anonymous).
Please give us a reasonable window to fix before any public disclosure.
If the issue you're reporting is really about the `dove` CLI or the access-gate
Lambda rather than this library, that's fine — report it here anyway and we'll
route it; the crypto and transfer code both consumers rely on lives in this repo.
## Supported versions
dove-core is pre-1.0 and moving fast. Security fixes land on the latest release
and `main`; older releases are not maintained. Once dove-core reaches 1.0 this
section will list a support window.
## Scope and the security model
dove-core's core guarantee: **the infrastructure that stores and gates access
to a file can never read it.** Files are chunked and encrypted with
AES-256-GCM client-side; the decryption key travels only in the URL
*fragment*, which is never sent to any server, so S3, CloudFront, and the
access-policy gate hold ciphertext and enforce *how many times / how long* —
never *what*. A PIN, when set, is folded into key derivation (PBKDF2) rather
than checked as a separate secret, and share/request ids are MAC'd
(`hex(nonce ‖ HMAC-SHA256(secret, nonce))`) so a forged or guessed id is
rejected before any storage lookup. See [docs/DESIGN.md](docs/DESIGN.md) and
[docs/REQUEST.md](docs/REQUEST.md) for the full model and threat analysis.
Things we consider **in scope** for a report:
- key material leaking to the server (e.g. the fragment reaching a request),
- weaknesses in the chunked AES-256-GCM container (nonce reuse, missing
authentication, truncation/reorder attacks, chunk-boundary tampering),
- weaknesses in PIN handling (PIN recoverable without brute-forcing the
derived key, missing/bypassable rate-limiting or lockout),
- forgeable or guessable share/request ids,
- the browser (WebCrypto) container diverging from this crate's byte format
in a way that breaks the security guarantees rather than just interop
(see `tests/browser_crypto_compat.rs` and `tests/parity.rs`),
- the access policy being bypassable (downloads or uploads consumed outside
the counted path, count/expiry not enforced),
- provisioned infrastructure that is more permissive than documented (public
read, over-broad IAM),
- the plugin-backend seam (`resolve`) executing or trusting an unsigned/wrong
binary.
Out of scope: issues in AWS/Cloudflare themselves, and misuse of a correctly
functioning feature (e.g. a caller choosing a very long expiry).
## Release integrity
dove-core ships as source through crates.io, not as a binary — pin an exact
version in your `Cargo.lock` rather than tracking a floating range. The
signed, checksummed release artifacts referenced by the `dove` CLI's
[SECURITY.md](https://github.com/boomctl/dove/blob/main/SECURITY.md) are that
binary's, not this crate's.