On 9/17/14, 3:11 PM, "Mike Bayer" <mba...@redhat.com> wrote:
> >On Sep 17, 2014, at 3:42 PM, Ian Cordasco <ian.corda...@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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev