# Security policy

## Reporting a vulnerability

Report privately, through GitHub's **Report a vulnerability** button on the
[Security tab](https://github.com/dahomey-technologies/rustis/security/advisories/new).
It opens a private advisory that only the maintainers can read.

Please do not open a public issue for a vulnerability. A public report is a
disclosure, and it happens before there is a version to upgrade to.

Useful in a report: the rustis version, the Redis version and topology
(standalone, cluster, sentinel), whether TLS is in use, and the shortest input or
sequence that reproduces it.

## Supported versions

The crate is pre-1.0. Fixes go to the latest published version; there are no
maintained release branches.

## What the crate treats as hostile input

Everything arriving over the connection. A reply is parsed before anything else
knows whether the server is the one you meant, so the RESP layer assumes an
attacker-controlled byte stream:

* `#![forbid(unsafe_code)]`, so a malformed or hostile reply cannot become a
  memory-safety bug.
* The explicit-panic lint family is denied crate-wide, and `indexing_slicing` in
  `resp/` and `network/` — the two zones where a panic ends the connection rather
  than one command.
* Frame size, nesting depth and collection length are bounded and configurable
  (`Config::limits`), so a crafted reply cannot drive an unbounded allocation or
  a stack overflow. The defaults are 128 levels of nesting, 512 MiB per bulk
  string and 128 M elements per collection.
* Four `cargo-fuzz` targets exercise the frame parser, both deserializers and the
  chunked decode path, weekly in CI.

A report showing any of these failing — a panic, an unbounded allocation, a
hang — on input a server can send is in scope, and so is anything that lets a
connection read or write on behalf of another.

Out of scope: what a Redis server you have chosen to trust does with the data you
send it, and configuration that disables the protections above.