Open Stack

On 19-05-09 13:48:09, Jeremy Stanley wrote:
> 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.
> 

To extend on this, I thought that OSA had the ability to override
certian constraints (meaning they could run the check and maintain the
overrides on their end).

> > 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?
> 

There's also the problem for knock on dependencies.  Update foo, which
pulls in a new version of bar as required.  Either of which can break
the world (and on down the dep tree)

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