Requests security release policy

In the wake of CVE-2015-2296 we should take another look at our policy for patching, releasing and publicising security vulnerabilities like this one.

Although we did a great job of responding quickly and pushing out a new release, we can definitely improve. I've received feedback from a couple of places that wanted to point out ways we could improve, and I'd like to solicit public feedback from anyone who has an interest to ensure that we're doing the best we possibly can with this sort of thing.

The goal here is for me to write up a document that explains, step-by-step, our policy with security issues. This will be posted publicly and we'll use it as a reference for any future events.

Below is the list of points people have raised:
- We probably shouldn't announce these vulnerabilities on weekends. Several people have products and projects that require them to evaluate vulnerabilities as soon as they become aware of them, and forcing those people to work on weekends does not engender positive feelings towards us.
- We released and announced before we had a CVE number. This might not have been the best thing for us to do, particularly as it will have made it a bit more difficult for people to keep track of what was going on.

If you have any other suggestions, please post them below.

I'm going to ping some specific interested parties to ensure they see this: @sigmavirus24 @dstufft @eriol @ralphbean


https://alexgaynor.net/2013/oct/19/security-process-open-source-projects/


Some lead time on the changes in 3bd8afbff would have been nice, yes.  @alex's recommendations look quite good to me as a 'maximal effort'.  If even portions of those suggestions could be adopted, it would be an improvement.  Thanks for the effort on this!


I agree with @ralphbean and I too would like to thank your effort on this!


I'm entirely happy to adopt almost all of @alex's suggestions. I'll take a look at writing up a procedure at some point shortly and pass it around for consideration.


FWIW, if you need those in a more prose version, you're welcome to any text
from http://cryptography.readthedocs.org/en/latest/security/

On Mon, Mar 16, 2015 at 4:12 PM, Cory Benfield notifications@github.com
wrote:

> I'm entirely happy to adopt almost all of @alex https://github.com/alex's
> suggestions. I'll take a look at writing up a procedure at some point
> shortly and pass it around for consideration.
> 
> —
> Reply to this email directly or view it on GitHub
> https://github.com/kennethreitz/requests/issues/2497#issuecomment-81910438
> .

## 

"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084


Alright, thanks for your feedback all! Can you please take a look at the diff attached to this issue and confirm that it's to your liking, and that you're happy with this commitment? All feedback valued! 

One particular note: I'm not sure about having a public list of who we notify downstream, but at the same time I worry about losing track of it if we don't record it somewhere. Thoughts there? @sigmavirus24?


It looks good.  Here's one thing to consider:
- Can you privately disclose the patches to your downstream re-distributors before you make it public?  That way we can have the time to ensure that the patch applies to X, Y, and Z older releases before hand.  This requires agreement and trust that we won't prematurely reveal the patch by pushing it to a public build system or anything like that.


@ralphbean Ah, yes, that was something I intended but clearly failed to make explicit in the document. I'll extend it to include it.


Alright, I've made that update. =)


:+1: 


If there are no objections, I'm going to merge this tonight or tomorrow.


I'm not sure it belongs in the docs (or maybe it does, who knows), but we should probably create a template for our announcements as well as a template for requesting CVEs. (Making it easy for any of us to handle this.)


Agreed. Probably best to put it in our docs (it's the open source way).


So more food for thought surrounding vendoring:
1. When requests itself has a vulnerability found, we should definitely **not** upgrade urllib3 before cutting a release. The release would, ideally, be very minimal.
2. Given the fact that we vendor urllib3 and chardet and the fact that either could potentially produce a vulnerability as well, we need a way to announce a release that updates the vendored copy and identifies which versions of requests are affected.