dove-core is the crypto and transfer library behind dove: 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.

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.

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.

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 and 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).

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 are that binary's, not this crate's.