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
E-question Participation: opinions wanted X-security Security 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)).

@tarcieri
Copy link

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

@dhardy dhardy closed this as completed in 26897a5 Sep 27, 2019
@dhardy dhardy added E-question Participation: opinions wanted X-security Security discussion labels Jul 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E-question Participation: opinions wanted X-security Security discussion
Projects
None yet
Development

No branches or pull requests

3 participants