|
| 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