Open Stack

On 9/17/14, 3:11 PM, "Mike Bayer" <mbayer at redhat.com> wrote:

>
>On Sep 17, 2014, at 3:42 PM, Ian Cordasco <ian.cordasco at rackspace.com>
>wrote:
>
>> 
>> Circling back to the issue of vendoring though: it’s a conscious
>>decision
>> to do this, and in the last two years there have been 2 CVEs reported
>>for
>> requests. There have been none for urllib3 and none for chardet.
>>(Frankly
>> I don’t think either urllib3 or chardet have had any CVEs reported
>>against
>> them, but let’s ignore that for now.) While security is typically the
>> chief concern with vendoring, none of the libraries we use have had
>> security issues rendering it a moot point in my opinion.
>
>That’s just amazing.  Requests actually deals with security features
>*directly*, certificates, TLS connections, everything; to take the
>attitude that “well there’ve been hardly any security issues in a *whole
>two years*, so I’m not so concerned” is really not one that is acceptable
>by serious development teams.

I said 2 years, because I wasn’t involved much before that, but looking at
the histories of the involved projects there aren’t mentions of CVEs
before then either.

>Wouldn’t it be a problem for *you* if Requests itself were vendored?
>You fix a major security hole, but your consuming projects don’t respond,
>their developers are on vacation, sorry, so that hole just keeps right on
>going. 

Isn’t the whole point of distributing a library to let people use it as
they see fit? If requests fixes it immediately and releases it, it’s not
our responsibility to search out every piece of software to fix it for
them. We took all of the appropriate measures to document the two CVEs
that were reported earlier this year. Software that vendored requests
including still vulnerable to those two exposures are responsible for
their own updates. Further, let’s consider this potential situation:

Project X pins a version of requests. Alice doesn’t know anything about
requests and does pip install X. Until Alice takes a more active role in
the development of Project X and looks into requests, she will never know
she’s installed software that has exposures in it. In all likelihood, any
person who just uses something that pins requests will never check for it.
If they just use pip and Project X never updates, it’s not our
responsibility for anything that happens to the user.

>People make sure to upgrade their Requests libraries locally, but for all
>those poor saps who have *no idea* they have widely used apps that are
>bundling it silently, they remain totally open to vulnerabilities and the
>black hats have disneyland at their disposal.

I think more applications bundle it than you realize. You’re likely using
one daily that does it.

>The blame keeps going right to you as well.  Is that really how things
>should be done?

And yeah, we’ll continue to take the blame for the mistake that was made
for those two exposures. As for “Is that how things should be done?”
that’s not for me to answer. More than enough projects do it and do it out
of necessity. The reality is that by vendoring its dependencies, requests
allows its users more flexibility than other projects. Even if we didn’t,
users would still likely find ways to vendor requests and its dependencies
for their own use and in doing so would have to modify requests to rewrite
the import statements to point at those vendored dependencies. The fact is
that vendoring is a real solution and it’s deployed more often than you
likely realize. It benefits our project and it benefits our users.