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