Open Stack

Jeremy Stanley wrote:
> [...]
> It's still unclear to me why we're doing this at all. Our stable
> constraints lists are supposed to be a snapshot in time from when we
> released, modulo stable point release updates of the libraries we're
> maintaining. Agreeing to bump random dependencies on stable branches
> because of security vulnerabilities in them is a slippery slope
> toward our users expecting the project to be on top of vulnerability
> announcements for every one of the ~600 packages in our constraints
> list. 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).
> 
> 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. Trying to
> 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.</soapbox>

I agree it is a bit of a slippery slope... We historically did not do 
that (stable branches are a convenience, not a product), because it is a 
lot of work to track and test vulnerable dependencies across multiple 
stable branches in a comprehensive manner.

Why update requests 2.18.4 for CVE-2018-18074, and not Jinja2 2.10.0 for 
CVE-2019-8341 ?

I'm not sure doing it on a case-by-case basis is a good idea either, as 
it might set unreasonable expectations.

-- 
Thierry Carrez (ttx)