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 updates. 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 'somewhat-tested-secureconstraints.txt' 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