aboutsummaryrefslogtreecommitdiff
path: root/SECURITY.md
blob: 3af71d18394669ccfb07da81b23462258c835ab0 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
# Security Policy

## Supported Versions

| Version | Supported          |
| ------- | ------------------ |
| master  | :white_check_mark: |
| 0.6.x   | :white_check_mark: |
| older   | :x:                |

## Reporting a Vulnerability

If you find a vulnerability, or evidence of one, use either of the following contacts:
- via email: [Kitsune Ral](mailto:Kitsune-Ral@users.sf.net); or
- via Matrix: [direct chat with @kitsune:matrix.org](https://matrix.to/#/@kitsune:matrix.org?action=chat).

In any of these two options, indicate that you have such information (do not share it yet), and we'll tell you the next steps.

By default, we will give credit to anyone who reports a vulnerability in a responsible way so that we can fix it before public disclosure.
If you want to remain anonymous or pseudonymous instead, please let us know; we will gladly respect your wishes.
If you provide a fix as a PR, you have no way to remain anonymous; you also thereby lay out the vulnerability itself
so this is NOT the right way for undisclosed vulnerabilities, whether or not you want to stay incognito.

## Timeline and commitments

Initial reaction to the message about a vulnerability (see above) will be
no more than 5 days. From the moment of the private report or public disclosure
(if it hasn't been reported earlier in private) of each vulnerability, we take
effort to fix it on priority before any other issues. In case of vulnerabilities
with [CVSS v2](https://nvd.nist.gov/cvss.cfm) score of 4.0 and higher
the commitment is to provide a workaround within 30 days and a full fix
within 60 days after the project has been made aware about the vulnerability
(in private or in public). For vulnerabilities with lower score there is
no commitment on the timeline, only prioritisation. The full fix doesn't imply
that all software functionality remains accessible (in the worst case
the vulnerable functionality may be disabled or removed to prevent the attack).