[all][requirements][stable] requests version bump on stable brances {pike|queens} for CVE-2018-18074

Matthew Thode mthode at mthode.org
Tue May 14 14:39:35 UTC 2019

On 19-05-14 12:31:55, Jeremy Stanley wrote:
> On 2019-05-13 23:31:41 +0200 (+0200), Dirk Müller wrote:
> [...]
> > I think this is combining two different viewpoints in one:
> > "snapshot in time" and "user expects it to be updated asap on
> > security vulnerabilities".
> I agree, that is the point I was trying to make... or moreso that
> the "snapshot in time" is the purpose upper-constraints.txt was
> intended to serve for stable branches so we can keep them... stable.
> On the other hand "user expects it to be updated asap on security
> vulnerabilities" sounds like a misconception we need to better
> document isn't the reason we have that mechanism.
> > We are already updating upper-constraints on bugfixes for projects
> > that openstack maintains, and we do so similarly for security
> > fixes for packages that are part of openstack.
> Yes, in those cases we have selectively backported those fixes by
> themselves into the affected projects so as to minimize disruption
> to any other projects depending on them, and we update the
> constraints list so that they are tested with other projects'
> contemporary branches. Many (I expect most?) of our external Python
> dependencies do not follow a similar pattern, and those which do may
> not have the same opinions as to what constitutes a
> backward-incompatible change or may maintain different lifetimes for
> their various stable backport branches.
> > Also, distribution vendor provided (non-pip installed bindeps) are
> > maintained and updated by security fixes.
> Yes, and those vendors (at least for the versions of their distros
> we claim to test against) generally maintain a snapshot-in-time fork
> of those packages and selectively backport fixes to them, which is
> *why* we can depend on them being a generally stable test bed for
> us.
> > > Deployment projects already should not depend on our
> > > requirements team tracking security vulnerabilities, so need to have
> > > a mechanism to override constraints entries anyway if they're making
> > > such guarantees to their users (and I would also caution against
> > > doing that too).
> > 
> > for traditional openstack deployment projects that might be well
> > the case. However several virtualenv / container / dockerbuild
> > based projects are using upperconstraints to generate a stable,
> > coherent and tested container. Without adjustments those will not
> > be including security fixes though.
> Right, again we seem to agree on the risk, just not the source of
> the problem. I continue to argue that the underlying issue is the
> choice to reuse the existing upper-constraints.txt (which was
> invented for a different, conflicting purpose) rather than creating
> a solid solution to their problem. It's not a good idea to make the
> current constraints list less effective at solving its intended
> problem just so that it can be used to solve an unrelated one,
> regardless of how important solving that other problem might be.
> > > Distributions are far better equipped than our project to handle
> > > such tracking, as they generally get advance notice of
> > > vulnerabilities and selectively backport fixes for them.
> > 
> > Agreed, still OpenStack chose to use pip for managing its
> > dependencies, so I think it is preferable to find a solution
> > within that ecosystem. Not every dependency with security issues
> > is so offensive as "requests" is which does not maintain any
> > stable branch but asks you to update to the latest version
> > instead. Most others do have backports available on micro versions
> > as pip installable project.
> OpenStack chose to use pip to *test* its Python dependency chain so
> that we can evaluate newer versions of those dependencies than the
> distros in question are carrying. It sticks with the same model on
> stable branches to avoid having to maintain two fundamentally
> different mechanisms for installing Python dependencies for tests.
> This doesn't mean we necessarily think its a good model for
> production deployments of stable branches of our software (for
> exactly the security-related reasons being discussed in this
> thread). The stable branches are meant as a place for distro package
> maintainers to collaborate on selective backports of patches for
> their packaged versions of our software, and suddenly starting to
> have them depend on newer versions of external dependencies which
> don't follow the same branching model and cadence creates new
> challenges for verifying that critical and security fixes for *our*
> software continues to remain compatible with deps contemporary to
> when we initially created those branches.
> > > accomplish the same with a mix of old and new dependency
> > > versions in our increasingly aging stable and extended
> > > maintenance branches seems like a disaster waiting to happen.
> > 
> > I agree it is a difficult exercise and we need to document a clear
> > policy. For me documenting that it upper-constraints is maintained
> > with security fix version updates as a best effort/risk bases is
> > good enough, fwiw.
> And I think we're better off picking a different solution for
> coordinating security updates to external dependencies of our stable
> branches, rather than trying to turn upper-constraints.txt into that
> while destabilizing its intended use.

I don't like the idea of conflating the stability promise of
upper-constraints.txt with the not quite fully tested-ness of adding
security updates after the fact (while we do some cross testing, we do
not and should not have 100% coverage, boiling the ocean).  The only
way I can see this working is to have a separate file for security

The idea I had (and don't like too much) is to do the following.
1. Keep upper-constraints.txt as is
  a. rename to tox-constraints possibly
2. add a new file, let's call it 'security-updates.txt'
  a. in this file goes security updates and all the knock on updates
     that it causes (foo pulls in a new bersion of bar and baz).
  b. the file needs to maintain co-installability of openstack.  It is
     laid over the upper-constraints file and tested the same way
     upper-constraints is.  This testing is NOT perfect.  The generated
     file could be called something like
3. global-requirements.txt remains the same (minimum not updated for
   security issues)

This would increase test sprawl quite a bit (tests need to be run on any
constraints change on this larger set).
This also sets up incrased work and scope for the requirements team.
Perhaps this could be a sub team type of item or something?

Anything we do should be within our documentation before we do it,
policy wise.

Matthew Thode
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190514/f421f000/attachment-0001.sig>

More information about the openstack-discuss mailing list