Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a security policy #882

Closed
vks opened this issue Sep 4, 2019 · 6 comments
Closed

Add a security policy #882

vks opened this issue Sep 4, 2019 · 6 comments
Labels
X-discussion Type: discussion

Comments

@vks
Copy link
Collaborator

vks commented Sep 4, 2019

We could use GitHub's security tab with the following SECURITY.md:

# Security Policy

## Supported Versions

The following versions of Rand are currently being supported with security updates:

| Version | Supported          |
| ------- | ------------------ |
| 0.7.x   | :white_check_mark: |
| < 0.7.0 | :x:                |

## Reporting a Vulnerability

To report a vulnerability, just [open an 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).
@dhardy
Copy link
Member

dhardy commented Sep 4, 2019

But is it useful?

@vks
Copy link
Collaborator Author

vks commented Sep 4, 2019

Well, we might want to have an advisory for the undefined behavior that was fixed with Rand 0.7.0.

@dhardy
Copy link
Member

dhardy commented Sep 4, 2019

True. We did backport (#853) so users should be recommended to upgrade to rand_core 0.4.2 or 0.5.0.

@vks
Copy link
Collaborator Author

vks commented Sep 4, 2019

I opened rustsec/advisory-db#149.

@dhardy
Copy link
Member

dhardy commented Sep 14, 2019

@tarcieri perhaps you have an opinion on whether this is useful enough to justify yet-another-piece-of-documentation?

The only explicit information it adds is a list of which versions will receive security updates — yet (a) this doesn't rule out backports (e.g. #853) and (b) this doesn't even attempt to answer the question of when a potential security issue is worth addressing (e.g. #699 prompted us to avoid use of JitterRng going forward, but not to patch old releases — something that may have been disruptive since #804 highlights a bug in our old OsRng code (in a case where JitterRng presumably also failed)).

@dhardy dhardy added the X-discussion Type: discussion label Sep 14, 2019
@tarcieri
Copy link

I think it's useful, particularly documenting the "bar" for a CryptoRng. FWIW, we rejected rustsec/advisory-db#149 as unexploitable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
X-discussion Type: discussion
Projects
None yet
Development

No branches or pull requests

3 participants