Open Stack

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
-------------- 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/20190509/555c264a/attachment.sig>