| OLD | NEW |
|---|
| (Empty) |
| 1 Vulnerability Disclosure | |
| 2 ======================== | |
| 3 | |
| 4 If you think you have found a potential security vulnerability in requests, | |
| 5 please email `sigmavirus24 <mailto:graffatcolmingov@gmail.com>`_ and | |
| 6 `Lukasa <mailto:cory@lukasa.co.uk>`_ directly. **Do not file a public issue.** | |
| 7 | |
| 8 Our PGP Key fingerprints are: | |
| 9 | |
| 10 - 0161 BB7E B208 B5E0 4FDC 9F81 D9DA 0A04 9113 F853 (@sigmavirus24) | |
| 11 | |
| 12 - 90DC AE40 FEA7 4B14 9B70 662D F25F 2144 EEC1 373D (@lukasa) | |
| 13 | |
| 14 If English is not your first language, please try to describe the problem and | |
| 15 its impact to the best of your ability. For greater detail, please use your | |
| 16 native language and we will try our best to translate it using online services. | |
| 17 | |
| 18 Please also include the code you used to find the problem and the shortest | |
| 19 amount of code necessary to reproduce it. | |
| 20 | |
| 21 Please do not disclose this to anyone else. We will retrieve a CVE identifier | |
| 22 if necessary and give you full credit under whatever name or alias you provide. | |
| 23 We will only request an identifier when we have a fix and can publish it in a | |
| 24 release. | |
| 25 | |
| 26 We will respect your privacy and will only publicize your involvement if you | |
| 27 grant us permission. | |
| 28 | |
| 29 Process | |
| 30 ------- | |
| 31 | |
| 32 This following information discusses the process the requests project follows | |
| 33 in response to vulnerability disclosures. If you are disclosing a | |
| 34 vulnerability, this section of the documentation lets you know how we will | |
| 35 respond to your disclosure. | |
| 36 | |
| 37 Timeline | |
| 38 ~~~~~~~~ | |
| 39 | |
| 40 When you report an issue, one of the project members will respond to you within | |
| 41 two days *at the outside*. In most cases responses will be faster, usually | |
| 42 within 12 hours. This initial response will at the very least confirm receipt | |
| 43 of the report. | |
| 44 | |
| 45 If we were able to rapidly reproduce the issue, the initial response will also | |
| 46 contain confirmation of the issue. If we are not, we will often ask for more | |
| 47 information about the reproduction scenario. | |
| 48 | |
| 49 Our goal is to have a fix for any vulnerability released within two weeks of | |
| 50 the initial disclosure. This may potentially involve shipping an interim | |
| 51 release that simply disables function while a more mature fix can be prepared, | |
| 52 but will in the vast majority of cases mean shipping a complete release as soon | |
| 53 as possible. | |
| 54 | |
| 55 Throughout the fix process we will keep you up to speed with how the fix is | |
| 56 progressing. Once the fix is prepared, we will notify you that we believe we | |
| 57 have a fix. Often we will ask you to confirm the fix resolves the problem in | |
| 58 your environment, especially if we are not confident of our reproduction | |
| 59 scenario. | |
| 60 | |
| 61 At this point, we will prepare for the release. We will obtain a CVE number | |
| 62 if one is required, providing you with full credit for the discovery. We will | |
| 63 also decide on a planned release date, and let you know when it is. This | |
| 64 release date will *always* be on a weekday. | |
| 65 | |
| 66 At this point we will reach out to our major downstream packagers to notify | |
| 67 them of an impending security-related patch so they can make arrangements. In | |
| 68 addition, these packagers will be provided with the intended patch ahead of | |
| 69 time, to ensure that they are able to promptly release their downstream | |
| 70 packages. Currently the list of people we actively contact *ahead of a public | |
| 71 release* is: | |
| 72 | |
| 73 - Ralph Bean, Red Hat (@ralphbean) | |
| 74 - Daniele Tricoli, Debian (@eriol) | |
| 75 | |
| 76 We will notify these individuals at least a week ahead of our planned release | |
| 77 date to ensure that they have sufficient time to prepare. If you believe you | |
| 78 should be on this list, please let one of the maintainers know at one of the | |
| 79 email addresses at the top of this article. | |
| 80 | |
| 81 On release day, we will push the patch to our public repository, along with an | |
| 82 updated changelog that describes the issue and credits you. We will then issue | |
| 83 a PyPI release containing the patch. | |
| 84 | |
| 85 At this point, we will publicise the release. This will involve mails to | |
| 86 mailing lists, Tweets, and all other communication mechanisms available to the | |
| 87 core team. | |
| 88 | |
| 89 We will also explicitly mention which commits contain the fix to make it easier | |
| 90 for other distributors and users to easily patch their own versions of requests | |
| 91 if upgrading is not an option. | |
| 92 | |
| 93 Previous CVEs | |
| 94 ------------- | |
| 95 | |
| 96 - Fixed in 2.6.0 | |
| 97 | |
| 98 - `CVE 2015-2296 <http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2015-2296>
`_, | |
| 99 reported by Matthew Daley of `BugFuzz <https://bugfuzz.com/>`_. | |
| 100 | |
| 101 - Fixed in 2.3.0 | |
| 102 | |
| 103 - `CVE 2014-1829 <http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2014-1829>
`_ | |
| 104 | |
| 105 - `CVE 2014-1830 <http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2014-1830>
`_ | |
| OLD | NEW |
|---|
Chromium Code Reviews
Issue 2164713003:
Vendor requests. (Closed)
Base URL: https://chromium.googlesource.com/external/github.com/luci/recipes-py@master