Merge pull request #897 from dhardy/policy
Policies: security and yanked crates
diff --git a/CHANGELOG.md b/CHANGELOG.md
index e2b0f13..102a3b1 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -16,6 +16,11 @@
- Unit tests for value stability of distributions added (#888)
## [0.7.1] - 2019-09-13
+### Yanked
+This release was yanked since it depends on `rand_core::OsRng` added in 0.5.1
+but specifies a dependency on version 0.5.0 (#890), causing a broken builds
+when updating from `rand 0.7.0` without also updating `rand_core`.
+
### Fixes
- Fix `no_std` behaviour, appropriately enable c2-chacha's `std` feature (#844)
- `alloc` feature in `no_std` is available since Rust 1.36 (#856)
diff --git a/README.md b/README.md
index 66100fc..c4bd676 100644
--- a/README.md
+++ b/README.md
@@ -67,6 +67,12 @@
When upgrading to the next minor series (especially 0.4 → 0.5), we recommend
reading the [Upgrade Guide](https://rust-random.github.io/book/update.html).
+### Yanked versions
+
+Some versions of Rand crates have been yanked ("unreleased"). Where this occurs,
+the crate's CHANGELOG *should* be updated with a rationale, and a search on the
+issue tracker with the keyword `yank` *should* uncover the motivation.
+
### Rust version requirements
Since version 0.7, Rand requires **Rustc version 1.32 or greater**.
diff --git a/SECURITY.md b/SECURITY.md
new file mode 100644
index 0000000..daedb78
--- /dev/null
+++ b/SECURITY.md
@@ -0,0 +1,69 @@
+# Security Policy
+
+## No guarantees
+
+Support is provided on a best-effort bases only.
+No binding guarantees can be provided.
+
+## Security premises
+
+Rand provides the trait `rand_core::CryptoRng` aka `rand::CryptoRng` as a marker
+trait. Generators implementating `RngCore` *and* `CryptoRng`, and given the
+additional constraints that:
+
+- Instances of seedable RNGs (those implementing `SeedableRng`) are
+ constructed with cryptographically secure seed values
+- The state (memory) of the RNG and its seed value are not be exposed
+
+are expected to provide the following:
+
+- An attacker can gain no advantage over chance (50% for each bit) in
+ predicting the RNG output, even with full knowledge of all prior outputs.
+
+For some RNGs, notably `OsRng`, `ThreadRng` and those wrapped by `ReseedingRng`,
+we provide limited mitigations against side-channel attacks:
+
+- After a process fork on Unix, there is an upper-bound on the number of bits
+ output by the RNG before the processes diverge, after which outputs from
+ each process's RNG are uncorrelated
+- After the state (memory) of an RNG is leaked, there is an upper-bound on the
+ number of bits of output by the RNG before prediction of output by an
+ observer again becomes computationally-infeasible
+
+Additionally, derivations from such an RNG (including the `Rng` trait,
+implementations of the `Distribution` trait, and `seq` algorithms) should not
+introduce signficant bias other than that expected from the operation in
+question (e.g. bias from a weighted distribution).
+
+## Supported Versions
+
+We will attempt to uphold these premises in the following crate versions,
+provided that only the latest patch version is used, and with potential
+exceptions for theoretical issues without a known exploit:
+
+| Crate | Versions | Exceptions |
+| ----- | -------- | ---------- |
+| `rand` | 0.7 | |
+| `rand` | 0.5, 0.6 | Jitter |
+| `rand` | 0.4 | Jitter, ISAAC |
+| `rand_core` | 0.2 - 0.5 | |
+| `rand_chacha` | 0.1 - 0.2 | |
+| `rand_hc` | 0.1 - 0.2 | |
+
+Explanation of exceptions:
+
+- Jitter: `JitterRng` is used as an entropy source when the primary source
+ fails; this source may not be secure against side-channel attacks, see #699.
+- ISAAC: the [ISAAC](https://burtleburtle.net/bob/rand/isaacafa.html) RNG used
+ to implement `thread_rng` is difficult to analyse and thus cannot provide
+ strong assertions of security.
+
+## Known issues
+
+In `rand` version 0.3 (0.3.18 and later), if `OsRng` fails, `thread_rng` is
+seeded from the system time in an insecure manner.
+
+## Reporting a Vulnerability
+
+To report a vulnerability, [open a new issue](https://github.com/rust-random/rand/issues/new).
+Once the issue is resolved, the vulnerability should be [reported to RustSec](https://github.com/RustSec/advisory-db/blob/master/CONTRIBUTING.md).
