On 2019-05-09 12:38:29 +0000 (+0000), Jesse Pretorius wrote: [...]
A lot of operators make use of u-c for source-based builds to ensure consistency in the builds and to ensure that they’re using the same packages as those which were tested upstream. It makes sense to collaborate on something this important as far upstream as possible. [...]
See, this is what frightens me. We should *strongly* discourage them from doing this, period. If your deployment relies on distribution packages of dependencies then your distro's package maintainers have almost certainly received advance notice of many of these vulnerabilities and have fixes ready for you to download the moment they're made public. They're in most cases selectively backporting the fixes to the versions they carry so as to make them otherwise backward compatible and avoid knock-on effects involving a need to upgrade other transitive dependencies which are not involved in the vulnerability.
If we think of this as a community effort similar to the extended maintenance policy - the development community doesn’t *have* to implement the infrastructure to actively monitor for the vulnerabilities and respond to them. It can be maintained on a best effort basis by those interested in doing so.
By the time we find out and work through the transitive dependency bumps implied by this sort of change (because many of these ~600 dependencies of ours don't backport fixes or maintain multiple stable series of their own and so our only option is to upgrade to the latest version, and this brings with it removal of old features or reliance on newer versions of other transitive dependencies), we're long past public disclosure and the vulnerability has likely been getting exploited in the wild for some time. If a deployer/operator can't rely on our constraints list for having a timely and complete picture of a secure dependency tree then they already need local workarounds which are probably superior regardless. There are also plenty of non-Python dependencies for our software which can have vulnerabilities of their own, and those aren't reflected at all in our constraints lists. How are said users updating those?
To limit the effort involved we could agree to limit the scope to only allow changes to the current ‘maintained’ releases. For all other branches we can encourage an upgrade to a ‘maintained’ release by adding a release note.
I still think even that is an abuse of the stable upper constraints lists and in direct conflict with their purpose as a *frozen* snapshot of external dependencies contemporary with the release which allow us to maintain the stability of our test environments for our stable branches. It can't be both that *and* updated with the latest versions of some dependencies because of random bug fixes, security-related or otherwise.
To manage the 'unreasonable expectations’, we should document a policy to this effect.
What we should document is that it's unreasonable to attempt to repurpose our stable constraints lists as a security update mechanism for external dependencies, and encourage users to look elsewhere when attempting to find solutions for securing the dependency trees of their deployments. -- Jeremy Stanley