Vulnerability Disclosure

If you think you have found a potential security vulnerability in requests,please email sigmavirus24 andLukasa directly. Do not file a public issue.

Our PGP Key fingerprints are:

  • 0161 BB7E B208 B5E0 4FDC 9F81 D9DA 0A04 9113 F853 (@sigmavirus24)
  • 90DC AE40 FEA7 4B14 9B70 662D F25F 2144 EEC1 373D (@lukasa)If English is not your first language, please try to describe the problem andits impact to the best of your ability. For greater detail, please use yournative 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 shortestamount of code necessary to reproduce it.

Please do not disclose this to anyone else. We will retrieve a CVE identifierif 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 arelease.

We will respect your privacy and will only publicize your involvement if yougrant us permission.

Process

This following information discusses the process the requests project followsin response to vulnerability disclosures. If you are disclosing avulnerability, this section of the documentation lets you know how we willrespond to your disclosure.

Timeline

When you report an issue, one of the project members will respond to you withintwo days at the outside. In most cases responses will be faster, usuallywithin 12 hours. This initial response will at the very least confirm receiptof the report.

If we were able to rapidly reproduce the issue, the initial response will alsocontain confirmation of the issue. If we are not, we will often ask for moreinformation about the reproduction scenario.

Our goal is to have a fix for any vulnerability released within two weeks ofthe initial disclosure. This may potentially involve shipping an interimrelease 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 soonas possible.

Throughout the fix process we will keep you up to speed with how the fix isprogressing. Once the fix is prepared, we will notify you that we believe wehave a fix. Often we will ask you to confirm the fix resolves the problem inyour environment, especially if we are not confident of our reproductionscenario.

At this point, we will prepare for the release. We will obtain a CVE numberif one is required, providing you with full credit for the discovery. We willalso decide on a planned release date, and let you know when it is. Thisrelease date will always be on a weekday.

At this point we will reach out to our major downstream packagers to notifythem of an impending security-related patch so they can make arrangements. Inaddition, these packagers will be provided with the intended patch ahead oftime, to ensure that they are able to promptly release their downstreampackages. Currently the list of people we actively contact ahead of a publicrelease is:

  • Jeremy Cline, Red Hat (@jeremycline)
  • Daniele Tricoli, Debian (@eriol)We will notify these individuals at least a week ahead of our planned releasedate to ensure that they have sufficient time to prepare. If you believe youshould be on this list, please let one of the maintainers know at one of theemail addresses at the top of this article.

On release day, we will push the patch to our public repository, along with anupdated changelog that describes the issue and credits you. We will then issuea PyPI release containing the patch.

At this point, we will publicise the release. This will involve mails tomailing lists, Tweets, and all other communication mechanisms available to thecore team.

We will also explicitly mention which commits contain the fix to make it easierfor other distributors and users to easily patch their own versions of requestsif upgrading is not an option.

Previous CVEs