[requirements][requests] security update for requests in stable branches
Recently it was reported to us that requests had a recent release that addressed a CVE (CVE-2018-18074). Requests has no stable branches so the only way to update openstack stable branches is to update to 2.20.1 in this case. I wanted to pass this by people as requests is generally a nasty library with nasty surprises. It's passed our cross and dvsm gating though (for rocky) so indications look good. What I'm asking you for is anything that could go wrong with updating (rocky in this case, but possibly back to newton, depending on co-installability). Please let me know any blockers to to update (in the review preferably).
https://review.openstack.org/637124
Thanks,
On 2019-02-15 01:27:49 -0600 (-0600), Matthew Thode wrote:
Recently it was reported to us that requests had a recent release that addressed a CVE (CVE-2018-18074). Requests has no stable branches so the only way to update openstack stable branches is to update to 2.20.1 in this case.
[...]
In the past we've assumed that folks consuming stable branches are doing so on distributions which are backporting security fixes for our dependencies anyway, so treating requirements for stable branches as a snapshot in time (even if that snapshot includes versions of dependencies with known vulnerabilities) is acceptable. If we need to start worrying about vulnerable dependencies on stable branches now, this implies quite a bit of extra work. I don't personally see any special need to make an exception for the requests library in this case. Will, e.g., CentOS or Ubuntu be replacing their LTS python-requests packages with 2.20.1 rather than just backporting a fix to the package versions they currently have?
On Fri, Feb 15, 2019 at 1:02 PM Jeremy Stanley fungi@yuggoth.org wrote:
On 2019-02-15 01:27:49 -0600 (-0600), Matthew Thode wrote:
Recently it was reported to us that requests had a recent release that addressed a CVE (CVE-2018-18074). Requests has no stable branches so the only way to update openstack stable branches is to update to 2.20.1 in this case.
[...]
In the past we've assumed that folks consuming stable branches are doing so on distributions which are backporting security fixes for our dependencies anyway, so treating requirements for stable branches as a snapshot in time (even if that snapshot includes versions of dependencies with known vulnerabilities) is acceptable.
Interesting, I didn't realize this.
I know openstack-ansible and kolla both (optionally?) deploy from source, so maybe it's time to start talking about it. Or should those projects handle security fixes themselves when deploying from source?
// jim
On 2019-02-15 13:06:21 -0500 (-0500), Jim Rollenhagen wrote: [...]
I know openstack-ansible and kolla both (optionally?) deploy from source, so maybe it's time to start talking about it. Or should those projects handle security fixes themselves when deploying from source?
If they're aggregating non-OpenStack software (that is, acting as a full software distribution) then they ought to be tracking and managing vulnerabilities in that software. I don't see that as being the job of the Requirements team to manage it for them. This is especially true in cases where the output is something like server or container images which include plenty of other software not even tracked by the requirements repository at all, any of which could have security vulnerabilities as well.
On Fri, Feb 15, 2019 at 1:18 PM Jeremy Stanley fungi@yuggoth.org wrote:
On 2019-02-15 13:06:21 -0500 (-0500), Jim Rollenhagen wrote: [...]
I know openstack-ansible and kolla both (optionally?) deploy from source, so maybe it's time to start talking about it. Or should those projects handle security fixes themselves when deploying from source?
If they're aggregating non-OpenStack software (that is, acting as a full software distribution) then they ought to be tracking and managing vulnerabilities in that software. I don't see that as being the job of the Requirements team to manage it for them. This is especially true in cases where the output is something like server or container images which include plenty of other software not even tracked by the requirements repository at all, any of which could have security vulnerabilities as well.
That's fair - I had to ask, given I believe they just take what the requirements.txt file gives them. Hopefully those projects are aware of this policy already. :)
// jim
On 19-02-15 13:32:34, Jim Rollenhagen wrote:
On Fri, Feb 15, 2019 at 1:18 PM Jeremy Stanley fungi@yuggoth.org wrote:
On 2019-02-15 13:06:21 -0500 (-0500), Jim Rollenhagen wrote: [...]
I know openstack-ansible and kolla both (optionally?) deploy from source, so maybe it's time to start talking about it. Or should those projects handle security fixes themselves when deploying from source?
If they're aggregating non-OpenStack software (that is, acting as a full software distribution) then they ought to be tracking and managing vulnerabilities in that software. I don't see that as being the job of the Requirements team to manage it for them. This is especially true in cases where the output is something like server or container images which include plenty of other software not even tracked by the requirements repository at all, any of which could have security vulnerabilities as well.
That's fair - I had to ask, given I believe they just take what the requirements.txt file gives them. Hopefully those projects are aware of this policy already. :)
I bugged OSA about it. What I'd like to do is to do updates on a best-effort basis (in this case a user reported the bug to us). You can't rely on requirements to monitor upper-constraints for security issues.
On 2/15/19, 6:20 PM, "Jeremy Stanley" fungi@yuggoth.org wrote:
On 2019-02-15 13:06:21 -0500 (-0500), Jim Rollenhagen wrote: [...] > I know openstack-ansible and kolla both (optionally?) deploy from source, > so maybe it's time to start talking about it. Or should those projects > handle security fixes themselves when deploying from source?
If I read the situation correctly, requests posted a CVE. Given that requests is a non-OpenStack python library , while it is part of our ecosystem, it is not directly curated by the OpenStack community.
From the OSA standpoint, as long as upper-constraints updates the version to include the fix, we inherit it. I think that packagers and us, along with ansible-helm and kolla, all rely on that mechanism - however, if the stance is that non-OpenStack libraries are not something managed through the requirements team then we (OSA) can work around it because we have our own override mechanisms... but those are meant to only be for temporary purposes. Any OSA community member should be proposing changes to the requirements repo if something like this comes up.
I would also hope that generally devstack tests would desire would be to test with the same thing that everyone is using to validate whether those new library versions might break things.
Personally, I think a 'best effort' approach is good enough. If CVE's are discovered in the community, then ideally we should cater to test with the updated libraries as far up the chain as possible. We should all be making the effort, however, to adhere to https://governance.openstack.org/tc/reference/principles.html#openstack-firs... - improving OpenStack for the greater good of the community.
On 2019-02-15 18:57:31 +0000 (+0000), Jesse Pretorius wrote: [...]
I would also hope that generally devstack tests would desire would be to test with the same thing that everyone is using to validate whether those new library versions might break things.
[...]
Continuing to test the frozen set of stable branch dependencies most closely approximates, typically, the state of frozen contemporary packaged versions on LTS distros which are backporting select security fixes to the versions they already ship. By testing our release under development (master branch) with latest versions of our dependencies, we attempt to ensure that we work with the versions most likely to be present in upcoming distro releases.
Updating dependencies on stable branches makes for a moving target, and further destabilizes testing on releases which have a hard time getting maintainers to keep their testing viable at all. We don't recommend running our stable branch source with the exact source code represented by the dependencies we froze at the time of release. It's expected they will be run within the scope of distributions which separately keep track of and patch security vulnerabilities in their contemporary forks of our dependencies as a small part of the overall running system.
Updating dependencies on stable branches makes for a moving target, and further destabilizes testing on releases which have a hard time getting maintainers to keep their testing viable at all. We don't recommend running our stable branch source with the exact source code represented by the dependencies we froze at the time of release. It's expected they will be run within the scope of distributions which separately keep track of and patch security vulnerabilities in their contemporary forks of our dependencies as a small part of the overall running system. -- Jeremy Stanley
It's sounding like we have two target audiences that have conflicting needs.
This makes a lot of sense for distros, and I think for the most part, our policies so far have been in keeping with the needs of distro maintainers. It's also less burden on upstream requirements management, which I think is very important.
The second group of folks are the deployment tools that are part of the community that attempt to use pure upstream source as much as possible to deploy stable versions of OpenStack services. My impressions is, due to lack of understanding (due to lack of communication (due to lack of knowing there was a need for communication)), most of these deployment projects expected the defined requirements and constraints to be maintained and accurate to get a decent installation of a given project.
I have no suggests for how to improve this, but I thought it worth pointing out the issue.
Sean
> Updating dependencies on stable branches makes for a moving target, > and further destabilizes testing on releases which have a hard time > getting maintainers to keep their testing viable at all.
FWIW, I've proposed a change to upper-constraints only: https://review.openstack.org/639340
If this is deemed something that should not be merged, then I'll submit a change to OSA which will achieve the same thing. However, I do believe that there is more value across the broader community to have this in upper-constraints where it can be consumed by everyone.
participants (5)
-
Jeremy Stanley
-
Jesse Pretorius
-
Jim Rollenhagen
-
Matthew Thode
-
Sean McGinnis