Open Stack

Hi,

> dependencies, we can't rely on *them* to properly avoid depending on
> vulnerable second-level dependencies (and so on). And this solution does
> not cover non-Python dependencies. So saying "use this to be secure" is
> just misleading our users.

We typically don't use pip constraints for non-python dependencies, so
that is an
orthogonal problem. Yes, it doesn't tell you that you need to install
kernel updates
to be secure but since we're not documenting the kernel version that OpenStack
requires you to be having installed to begin with its not really part
of the problem scope..

> Nothing short of full distribution security work can actually deliver on
> a "use this to be secure" promise. And that is definitely not the kind
> of effort we should tackle as a community imho.

See my previous reply to Jeremy. I'm not asking for the community to suddenly
replace the paid work of distribution vendors. What I was aiming at is
that we could align our testing coverage with the situation that end users
might likely end up, which is something along the lines of "the
upper-constraints
version of the dependency + distro specific bugfixes + customer/user requested
bugfixes + security backports". Hopefully the vendor follows good practices
and upstreams those changes, which means a stable release of the version
that OpenStack depends on would pretty closely match end user situation,
which is good because we want to test that functionality in our CI.

> I would rather continue to use that mechanism to communicate about
> critical vulnerabilities in all our dependencies than implement a
> complex and costly process to only cover /some/ of our Python dependencies.

I think announcing such changes in our upper-constraints via OSSN
is an excellent idea, totally on board with that.


Greetings,
Dirk