Skip to content

Commit b34e78d

Browse files
committed
Add SECURITY.md
1 parent 450856a commit b34e78d

1 file changed

Lines changed: 72 additions & 0 deletions

File tree

SECURITY.md

Lines changed: 72 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,72 @@
1+
# Security Policy
2+
3+
## Supported Versions
4+
5+
This project aims for strict [SemVer](https://semver.org/) compliance. This
6+
means that upgrading to a new minor or patch version should be trivial, but
7+
upgrading to a new major version may incur some significant costs on your side.
8+
9+
With that in mind, if we denote major.minor.patch the project's version
10+
number, the policy for security updates support is that...
11+
12+
- The latest major.minor.patch version published on crates.io is supported
13+
(obviously).
14+
- Each previously published major release remains supported, for users of the
15+
latest minor.patch version, during 6 months after the release of the next
16+
major release.
17+
18+
19+
## Reporting a Vulnerability
20+
21+
### Basics
22+
23+
Please do not report security vulnerabilities (any bug that has security
24+
implications if e.g. a setuid binary happens to use `triple-buffer`) using
25+
public channels such as...
26+
27+
- A project's issue tracker
28+
- Social media
29+
- A [CVE
30+
Report](https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures)
31+
32+
Doing so is the computer security equivalent of reporting a fire safety risk by
33+
starting a fire: you are informing attackers that software has a problem before
34+
a fix is available, and they will be able to exploit this information for the
35+
entire duration it will take us to come up with a fix, which is [Very
36+
Bad](https://en.wikipedia.org/wiki/Zero-day_(computing)).
37+
38+
Instead, you should privately report the vulnerability to the project, give it
39+
some time to come up with a fix, and only report the vulnerability publicly once
40+
a patch release is available for all supported major versions (except in
41+
worst-case scenarios discussed below).
42+
43+
### Reporting guidelines
44+
45+
Please privately submit us a security advisory using [this dedicated
46+
form](https://github.com/HadrienG2/triple-buffer/security/advisories/new). A
47+
good security advisory should...
48+
49+
- Describe the vulnerability
50+
- Assess its impact on downstream users of the library
51+
- Provides instructions on how to replicate the issue locally
52+
- Additionally provide a patch that addresses the issue, if you have one
53+
available (otherwise the project will take care of writing it)
54+
55+
### Worst-case scenarios
56+
57+
While private reporting and embargo until a bugfix is available is the preferred
58+
course of action on our side, we are well aware that if we spend too much time
59+
without fixing the vulnerability, or if you become aware that another attacker
60+
has found out about the vulnerability and started exploiting it, you may want to
61+
publicly report the vulnerability anyway.
62+
63+
Here's what you can expect from us in terms of response time :
64+
65+
- At the time of writing, the project only has one permanent maintainer,
66+
[**@HadrienG2**](https://github.com/HadrienG2). I will aim for fast replies
67+
(less than a week, ideally next-day), but I may be momentarily unavailable
68+
for various reasons: holidays, sickness... So please ping me a few times
69+
(e.g. after a week and a month) before concluding that I am unresponsive and
70+
must have abandoned the project.
71+
- Unless the vulnerability is extremely complex and requires a major library
72+
rewrite to fix, 90 days should be more than enough time for me to fix it.

0 commit comments

Comments
 (0)