|
| 1 | +# Security Policy |
| 2 | + |
| 3 | +## Supported Versions |
| 4 | + |
| 5 | +| Version | Supported | |
| 6 | +| ------- | ------------------ | |
| 7 | +| 1.4.x | :white_check_mark: | |
| 8 | +| < 1.4.0 | :x: | |
| 9 | + |
| 10 | +# Vulnerability Disclosure |
| 11 | + |
| 12 | +If you think you have found a potential security vulnerability in |
| 13 | +mailjet-rest, please open a [draft Security Advisory](https://github.com/mailjet/mailjet-apiv3-python/security/advisories/new) |
| 14 | +via GitHub. We will coordinate verification and next steps through |
| 15 | +that secure medium. |
| 16 | + |
| 17 | +If English is not your first language, please try to describe the |
| 18 | +problem and its impact to the best of your ability. For greater detail, |
| 19 | +please use your native language and we will try our best to translate it |
| 20 | +using online services. |
| 21 | + |
| 22 | +Please also include the code you used to find the problem and the |
| 23 | +shortest amount of code necessary to reproduce it. |
| 24 | + |
| 25 | +Please do not disclose this to anyone else. We will retrieve a CVE |
| 26 | +identifier if necessary and give you full credit under whatever name or |
| 27 | +alias you provide. We will only request an identifier when we have a fix |
| 28 | +and can publish it in a release. |
| 29 | + |
| 30 | +We will respect your privacy and will only publicize your involvement if |
| 31 | +you grant us permission. |
| 32 | + |
| 33 | +## Process |
| 34 | + |
| 35 | +This following information discusses the process the project |
| 36 | +follows in response to vulnerability disclosures. If you are disclosing |
| 37 | +a vulnerability, this section of the documentation lets you know how we |
| 38 | +will respond to your disclosure. |
| 39 | + |
| 40 | +### Timeline |
| 41 | + |
| 42 | +When you report an issue, one of the project members will respond to you |
| 43 | +within five days *at the outside*. In most cases responses will be |
| 44 | +faster, usually within 72 hours. This initial response will at the very |
| 45 | +least confirm receipt of the report. |
| 46 | + |
| 47 | +If we were able to rapidly reproduce the issue, the initial response |
| 48 | +will also contain confirmation of the issue. If we are not, we will |
| 49 | +often ask for more information about the reproduction scenario. |
| 50 | + |
| 51 | +Our goal is to have a fix for any vulnerability released within two |
| 52 | +weeks of the initial disclosure. This may potentially involve shipping |
| 53 | +an interim release that simply disables function while a more mature fix |
| 54 | +can be prepared, but will in the vast majority of cases mean shipping a |
| 55 | +complete release as soon as possible. |
| 56 | + |
| 57 | +Throughout the fix process we will keep you up to speed with how the fix |
| 58 | +is progressing. Once the fix is prepared, we will notify you that we |
| 59 | +believe we have a fix. Often we will ask you to confirm the fix resolves |
| 60 | +the problem in your environment, especially if we are not confident of |
| 61 | +our reproduction scenario. |
| 62 | + |
| 63 | +At this point, we will prepare for the release. We will obtain a CVE |
| 64 | +number if one is required, providing you with full credit for the |
| 65 | +discovery. We will also decide on a planned release date, and let you |
| 66 | +know when it is. This release date will *always* be on a weekday. |
| 67 | + |
| 68 | +At this point we will reach out to our major downstream packagers to |
| 69 | +notify them of an impending security-related patch so they can make |
| 70 | +arrangements. In addition, these packagers will be provided with the |
| 71 | +intended patch ahead of time, to ensure that they are able to promptly |
| 72 | +release their downstream packages. |
| 73 | + |
| 74 | +On release day, we will push the patch to our public repository, along |
| 75 | +with an updated changelog that describes the issue and credits you. We |
| 76 | +will then issue a PyPI release containing the patch. |
| 77 | + |
| 78 | +At this point, we will publicise the release. |
| 79 | + |
| 80 | +We will also explicitly mention which commits contain the fix to make it |
| 81 | +easier for other distributors and users to easily patch their own |
| 82 | +versions of mailjet-rest if upgrading is not an option. |
0 commit comments