Open Stack

On 8/4/15, 13:17, "Clark, Robert Graham" <robert.clark at 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.