Matthew Thode wrote:
[...] I don't like the idea of conflating the stability promise of upper-constraints.txt with the not quite fully tested-ness of adding security updates after the fact (while we do some cross testing, we do not and should not have 100% coverage, boiling the ocean).
Me neither.
The only way I can see this working is to have a separate file for security updates.
The idea I had (and don't like too much) is to do the following. 1. Keep upper-constraints.txt as is a. rename to tox-constraints possibly 2. add a new file, let's call it 'security-updates.txt' a. in this file goes security updates and all the knock on updates that it causes (foo pulls in a new bersion of bar and baz). b. the file needs to maintain co-installability of openstack. It is laid over the upper-constraints file and tested the same way upper-constraints is. This testing is NOT perfect. The generated file could be called something like 'somewhat-tested-secureconstraints.txt' 3. global-requirements.txt remains the same (minimum not updated for security issues)
This would increase test sprawl quite a bit (tests need to be run on any constraints change on this larger set). This also sets up incrased work and scope for the requirements team. Perhaps this could be a sub team type of item or something?
I'm a bit worried that a security-updates.txt would promise more than we can deliver. While we may be able to track vulnerabilities in our direct 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. 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. I understand the need to signal critical vulnerabilities in our dependencies to our users and distributions. Historically we have used the OSSN (OpenStack Security Notices) to draw attention to select, key vulnerabilities in our dependency chain: OSSN-0082 - Heap and Stack based buffer overflows in dnsmasq<2.78 OSSN-0044 - Older versions of noVNC allow session theft OSSN-0043 - glibc 'Ghost' vulnerability can allow remote code execution ... 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. -- Thierry Carrez (ttx)