|
1 | 1 | Vulnerability Disclosure |
2 | 2 | ======================== |
3 | 3 |
|
4 | | -If you think you have found a potential security vulnerability in requests, |
5 | | -please email `Nate <mailto:nate.prewitt@gmail.com>`_ and `Seth <mailto:@sethmichaellarson@gmail.com>`_ directly. **Do not file a public issue.** |
6 | | - |
7 | | -Our PGP Key fingerprints are: |
8 | | - |
9 | | -- 8722 7E29 AD9C FF5C FAC3 EA6A 44D3 FF97 B80D C864 (`@nateprewitt <https://keybase.io/nateprewitt>`_) |
10 | | - |
11 | | -- EDD5 6765 A9D8 4653 CBC8 A134 51B0 6736 1740 F5FC (`@sethmlarson <https://keybase.io/sethmlarson>`_) |
12 | | - |
13 | | -You can also contact us on `Keybase <https://keybase.io/>`_ with the |
14 | | -profiles above if desired. |
15 | | - |
16 | | -If English is not your first language, please try to describe the problem and |
17 | | -its impact to the best of your ability. For greater detail, please use your |
18 | | -native language and we will try our best to translate it using online services. |
19 | | - |
20 | | -Please also include the code you used to find the problem and the shortest |
21 | | -amount of code necessary to reproduce it. |
22 | | - |
23 | | -Please do not disclose this to anyone else. We will retrieve a CVE identifier |
24 | | -if necessary and give you full credit under whatever name or alias you provide. |
25 | | -We will only request an identifier when we have a fix and can publish it in a |
26 | | -release. |
27 | | - |
28 | | -We will respect your privacy and will only publicize your involvement if you |
29 | | -grant us permission. |
30 | | - |
31 | | -Process |
32 | | -------- |
33 | | - |
34 | | -This following information discusses the process the requests project follows |
35 | | -in response to vulnerability disclosures. If you are disclosing a |
36 | | -vulnerability, this section of the documentation lets you know how we will |
37 | | -respond to your disclosure. |
38 | | - |
39 | | -Timeline |
40 | | -~~~~~~~~ |
41 | | - |
42 | | -When you report an issue, one of the project members will respond to you within |
43 | | -two days *at the outside*. In most cases responses will be faster, usually |
44 | | -within 12 hours. This initial response will at the very least confirm receipt |
45 | | -of the report. |
46 | | - |
47 | | -If we were able to rapidly reproduce the issue, the initial response will also |
48 | | -contain confirmation of the issue. If we are not, we will often ask for more |
49 | | -information about the reproduction scenario. |
50 | | - |
51 | | -Our goal is to have a fix for any vulnerability released within two weeks of |
52 | | -the initial disclosure. This may potentially involve shipping an interim |
53 | | -release that simply disables function while a more mature fix can be prepared, |
54 | | -but will in the vast majority of cases mean shipping a complete release as soon |
55 | | -as possible. |
56 | | - |
57 | | -Throughout the fix process we will keep you up to speed with how the fix is |
58 | | -progressing. Once the fix is prepared, we will notify you that we believe we |
59 | | -have a fix. Often we will ask you to confirm the fix resolves the problem in |
60 | | -your environment, especially if we are not confident of our reproduction |
61 | | -scenario. |
62 | | - |
63 | | -At this point, we will prepare for the release. We will obtain a CVE number |
64 | | -if one is required, providing you with full credit for the discovery. We will |
65 | | -also decide on a planned release date, and let you know when it is. This |
66 | | -release date will *always* be on a weekday. |
67 | | - |
68 | | -At this point we will reach out to our major downstream packagers to notify |
69 | | -them of an impending security-related patch so they can make arrangements. In |
70 | | -addition, these packagers will be provided with the intended patch ahead of |
71 | | -time, to ensure that they are able to promptly release their downstream |
72 | | -packages. Currently the list of people we actively contact *ahead of a public |
73 | | -release* is: |
74 | | - |
75 | | -- Python Maintenance Team, Red Hat (python-maint@redhat.com) |
76 | | -- Daniele Tricoli, Debian (@eriol) |
77 | | - |
78 | | -We will notify these individuals at least a week ahead of our planned release |
79 | | -date to ensure that they have sufficient time to prepare. If you believe you |
80 | | -should be on this list, please let one of the maintainers know at one of the |
81 | | -email addresses at the top of this article. |
82 | | - |
83 | | -On release day, we will push the patch to our public repository, along with an |
84 | | -updated changelog that describes the issue and credits you. We will then issue |
85 | | -a PyPI release containing the patch. |
86 | | - |
87 | | -At this point, we will publicise the release. This will involve mails to |
88 | | -mailing lists, Tweets, and all other communication mechanisms available to the |
89 | | -core team. |
90 | | - |
91 | | -We will also explicitly mention which commits contain the fix to make it easier |
92 | | -for other distributors and users to easily patch their own versions of requests |
93 | | -if upgrading is not an option. |
94 | | - |
95 | | -Previous CVEs |
96 | | -------------- |
97 | | - |
98 | | -- Fixed in 2.20.0 |
99 | | - - `CVE 2018-18074 <https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-18074>`_ |
100 | | - |
101 | | -- Fixed in 2.6.0 |
102 | | - |
103 | | - - `CVE 2015-2296 <https://cve.mitre.org/cgi-bin/cvename.cgi?name=2015-2296>`_, |
104 | | - reported by Matthew Daley of `BugFuzz <https://bugfuzz.com/>`_. |
105 | | - |
106 | | -- Fixed in 2.3.0 |
107 | | - |
108 | | - - `CVE 2014-1829 <https://cve.mitre.org/cgi-bin/cvename.cgi?name=2014-1829>`_ |
109 | | - |
110 | | - - `CVE 2014-1830 <https://cve.mitre.org/cgi-bin/cvename.cgi?name=2014-1830>`_ |
| 4 | +The latest vulnerability disclosure information can be found on GitHub in our |
| 5 | +`Security Policy <https://github.com/psf/requests/blob/main/.github/SECURITY.md>`_. |
0 commit comments