aboutsummaryrefslogtreecommitdiff
path: root/SECURITY.md
blob: 086258bd8f6ea9e16cc8e518c527a02ed256cd4c (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
# Security Policy

## Supported Versions

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

## Reporting a Vulnerability

If you find a significant vulnerability, or evidence of one, use either of the following contacts:
- send an email to [Kitsune Ral](mailto:Kitsune-Ral@users.sf.net); or
- reach out in Matrix to [@kitsune:matrix.org](https://matrix.to/#/@kitsune:matrix.org) (if you can, switch encryption on).

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 specific information on the vulnerability has been
reported to the project by any means (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).