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

Jeremy Stanley fungi at yuggoth.org
Tue May 14 12:31:55 UTC 2019


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.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190514/899621c2/attachment.sig>


More information about the openstack-discuss mailing list