On 8/4/15, 13:17, "Clark, Robert Graham" <robert.cl...@hp.com> wrote:
>Hi Elena, > >This is interesting work, thanks for posting it (and for posting it here >on openstack-dev, we are trying to wind down the security > ML) though maybe use the [Security] tag in the subject line next time. > >I think this is a very interesting project, though it’s unclear to me who >might be the targeted users for this? It seems like it > would make the most sense for this to be in the gate. Now this could be >the standard build gates (Jenkins etc) but I’m not sure how much sense >that makes on its own, after all most production consumers (those who >care about CVEs) of OpenStack are probably > not consuming it vanilla from source but are more likely to be consuming >it from a vendor who’s already packaged it up. > >In the latter case, I’m sure vendors would find this tool very useful, we >do something similar at HP today but I’m sure a tool like > this would add value and it’s probably something we could contribute to. > >As I write this I’ve realised that there would be an interesting >possibility in the former case (putting this in the upstream OpenStack > gates). It would be interesting to see something running that regularly >checks for CVE’s in the libraries that _could_ be included in OpenStack, >(library requirements within OpenStack often include more than one >version) and bumps the version to the > next safest and submits a change request for manual verification etc. > >-Rob Since requests was already brought up in the discussion below and we're discussing potential uses for this in the gate, let me throw in my two cents as a requests core developer. The mere presence of a CVE id for a release does not in anyway imply an effect on OpenStack. In the CVEs in question (which Elena referred to) we have three separate issues: 1. Authentication credentials being sent on redirect to the wrong domain, e.g., attempt to authenticate to example.com which redirects to example.org and we would faithfully continue to attempt to authenticate. 2. See 1 but for proxies 3. Cookies sent with a redirect to a different domain were set for the domain we were redirected to instead of the domain we were redirected from. When I tried bumping the version for the first two, we had a discussion about the impact to OpenStack and it was decided that there wasn't a necessity to bump the version. There was no need to have a discussion about 3 because (as far as I'm aware) there isn't any service that uses cookies so that also doesn't have any effect. Being aware of these CVEs is one thing and would be nice. If we can determine that a CVE affects us, we most certainly should bump the minimum required version of that library in OpenStack. That said, part of the argument against increasing the lower bound on requests (at the time) was due to packagers not wanting to or being able to (I forget which) package the newer version (and no the review was not sent to a stable/* branch). So if we're going to be conflicting with downstream re-distributors, then this might be harder than we think. I have to agree that this is something that some Vendors will find useful. I suspect stackforge/os-ansible-deployment and stackforge/kolla will both find this useful as they both build OpenStack from source (although for the latter it is an option rather than a requirement). For Vendors depending distro packaged OpenStack (MOS if I remember correctly uses Debian's OpenStack packages), this will be of no interest and may be a waste of time. For example, Debian and Ubuntu should both be packaging python-requests-2.2.1 (this in fact is a reason why we had gate failures when urllib3 1.11 was released) but it should absolutely be patched for all three CVEs (making it not exactly 2.2.1 but that's besides the point). Those vendors should be trusting their curated packages to be properly patched for them. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev