mirror of
https://github.com/kennethreitz/requests.git
synced 2026-06-05 14:50:16 +00:00
Seth Michael Larson
94 lines
4.1 KiB
Markdown
94 lines
4.1 KiB
Markdown
# Vulnerability Disclosure
|
|
|
|
If you think you have found a potential security vulnerability in
|
|
requests, please email [Nate](mailto:nate.prewitt@gmail.com)
|
|
and [Seth](mailto:sethmichaellarson@gmail.com) directly.
|
|
**Do not file a public issue.**
|
|
|
|
Our PGP Key fingerprints are:
|
|
|
|
- 8722 7E29 AD9C FF5C FAC3 EA6A 44D3 FF97 B80D C864 ([@nateprewitt](https://keybase.io/nateprewitt))
|
|
|
|
- EDD5 6765 A9D8 4653 CBC8 A134 51B0 6736 1740 F5FC ([@sethmlarson](https://keybase.io/sethmlarson))
|
|
|
|
You can also contact us on [Keybase](https://keybase.io) with the
|
|
profiles above if desired.
|
|
|
|
If English is not your first language, please try to describe the
|
|
problem and its impact to the best of your ability. For greater detail,
|
|
please use your native language and we will try our best to translate it
|
|
using online services.
|
|
|
|
Please also include the code you used to find the problem and the
|
|
shortest amount of code necessary to reproduce it.
|
|
|
|
Please do not disclose this to anyone else. We will retrieve a CVE
|
|
identifier if necessary and give you full credit under whatever name or
|
|
alias you provide. We will only request an identifier when we have a fix
|
|
and can publish it in a release.
|
|
|
|
We will respect your privacy and will only publicize your involvement if
|
|
you grant us permission.
|
|
|
|
## Process
|
|
|
|
This following information discusses the process the requests project
|
|
follows in response to vulnerability disclosures. If you are disclosing
|
|
a vulnerability, this section of the documentation lets you know how we
|
|
will respond to your disclosure.
|
|
|
|
### Timeline
|
|
|
|
When you report an issue, one of the project members will respond to you
|
|
within two days *at the outside*. In most cases responses will be
|
|
faster, usually within 12 hours. This initial response will at the very
|
|
least confirm receipt of the report.
|
|
|
|
If we were able to rapidly reproduce the issue, the initial response
|
|
will also contain confirmation of the issue. If we are not, we will
|
|
often ask for more information about the reproduction scenario.
|
|
|
|
Our goal is to have a fix for any vulnerability released within two
|
|
weeks of the initial disclosure. This may potentially involve shipping
|
|
an interim release that simply disables function while a more mature fix
|
|
can be prepared, but will in the vast majority of cases mean shipping a
|
|
complete release as soon as possible.
|
|
|
|
Throughout the fix process we will keep you up to speed with how the fix
|
|
is progressing. Once the fix is prepared, we will notify you that we
|
|
believe we have a fix. Often we will ask you to confirm the fix resolves
|
|
the problem in your environment, especially if we are not confident of
|
|
our reproduction scenario.
|
|
|
|
At this point, we will prepare for the release. We will obtain a CVE
|
|
number if one is required, providing you with full credit for the
|
|
discovery. We will also decide on a planned release date, and let you
|
|
know when it is. This release date will *always* be on a weekday.
|
|
|
|
At this point we will reach out to our major downstream packagers to
|
|
notify them of an impending security-related patch so they can make
|
|
arrangements. In addition, these packagers will be provided with the
|
|
intended patch ahead of time, to ensure that they are able to promptly
|
|
release their downstream packages. Currently the list of people we
|
|
actively contact *ahead of a public release* is:
|
|
|
|
- Jeremy Cline, Red Hat (@jeremycline)
|
|
- Daniele Tricoli, Debian (@eriol)
|
|
|
|
We will notify these individuals at least a week ahead of our planned
|
|
release date to ensure that they have sufficient time to prepare. If you
|
|
believe you should be on this list, please let one of the maintainers
|
|
know at one of the email addresses at the top of this article.
|
|
|
|
On release day, we will push the patch to our public repository, along
|
|
with an updated changelog that describes the issue and credits you. We
|
|
will then issue a PyPI release containing the patch.
|
|
|
|
At this point, we will publicise the release. This will involve mails to
|
|
mailing lists, Tweets, and all other communication mechanisms available
|
|
to the core team.
|
|
|
|
We will also explicitly mention which commits contain the fix to make it
|
|
easier for other distributors and users to easily patch their own
|
|
versions of requests if upgrading is not an option.
|