|
| 1 | +# Security Process |
| 2 | + |
| 3 | +If you find a vulnerability in our software, please report it via |
| 4 | +GitHub "Private vulnerability reporting" feature at |
| 5 | +https://github.com/ngtcp2/nghttp3/security instead of submitting |
| 6 | +issues on github issue page. It is a standard practice not to |
| 7 | +disclose vulnerability information publicly until a fixed version is |
| 8 | +released, or mitigation is worked out. |
| 9 | + |
| 10 | +If we identify that the reported issue is really a vulnerability, we |
| 11 | +open a new security advisory draft using [GitHub security |
| 12 | +feature](https://github.com/ngtcp2/nghttp3/security) and discuss the |
| 13 | +mitigation and bug fixes there. The fixes are committed to the |
| 14 | +private repository. |
| 15 | + |
| 16 | +We write the security advisory and get CVE number from GitHub |
| 17 | +privately. We also discuss the disclosure date to the public. |
| 18 | + |
| 19 | +We make a new release with the fix at the same time when the |
| 20 | +vulnerability is disclosed to public. |
| 21 | + |
| 22 | +At least 7 days before the public disclosure date, we open a new issue |
| 23 | +on [nghttp3 issue tracker](https://github.com/ngtcp2/nghttp3/issues) |
| 24 | +which notifies that the upcoming release will have a security fix. |
| 25 | +The `SECURITY` label is attached to this kind of issue. The issue is |
| 26 | +not opened if a vulnerability is already disclosed, and it is publicly |
| 27 | +known that nghttp3 is affected by that. The issue might not be |
| 28 | +created if CVE only affects the latest version released very recently. |
| 29 | +In this case, we would like to release a fix without waiting a week to |
| 30 | +avoid widespread use of the version. |
| 31 | + |
| 32 | +Before few hours of new release, we merge the fixes to the master |
| 33 | +branch (and/or a release branch if necessary) and make a new release. |
| 34 | +Security advisory is disclosed on GitHub. |
0 commit comments