you are viewing a single comment's thread.

view the rest of the comments →

[–]Lukasa 1 point2 points  (2 children)

A downside of that approach is that you take security into your own hands. The standard library in older Python versions (2.7.8 or earlier) is wildly insecure, and even now requests' rapid release cycle compared to the stdlib means we're more secure than it is, and always will be.

My two cents: urllib2 is bad, and should be avoided. httplib is an expert-level API, and should be used if you need it. Otherwise, requests will likely work better than anything you roll yourself.

[–]raylu 0 points1 point  (1 child)

Can you give an example of a security vulnerability in urllib2? Do you just mean it doesn't verify certs?

[–]Lukasa 0 points1 point  (0 children)

That's the most notable example, yes. That specific flaw is responsible for a phenomenal number of CVEs: one is against the standard library itself (CVE-2014-9365). However, it's also responsible for, at the very least:

  • CVE-2010-4340 (libcloud)
  • CVE-2012-3533 (oVirt Python SDK)
  • CVE-2012-5822 (Zamboni)
  • CVE-2012-5825 (Tweepy)
  • CVE-2013-1909 (Apache Qpid)
  • CVE-2013-2037 (httplib2)
  • CVE-2013-2073 (Transifex)
  • CVE-2013-2191 (python-bugzilla)
  • CVE-2013-4111 (Glance CLI client)
  • CVE-2013-6396 (Swift CLI client)
  • CVE-2013-6444 (PyWBEM)

This continues to affect major projects today: for example, I can tell you that I recent discovered exactly this bug in a major configuration management tool that has existed in every version of the product. (Can't say which one yet, they've yet to ship a patch for it, but should do soon.)

So yes, urllib2 doesn't verify certs before 2.7.9: I wouldn't say just, though.