On 2019-05-15 12:01:36 +0200 (+0200), Thierry Carrez wrote: [...]
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 concur. There is a reason the model we follow for our own stable branches (fork from a point in time and only backport critical fixes) is basically identical to how distros operate, except they do it on a *much* larger scale. To do this "properly" we would not only need to stay on top of vulnerabilities announced for our entire transitive Python dependency tree, but also fork the source code for all of it and then backport fixes to those forks. This is precisely creating a new (perhaps derivative) distro, and it's a ton of work I doubt anyone is eager to sign up for.
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.
This isn't so much the problem at hand, it's that we have deployment projects who have decided that deploying from stable branch source with pip-installed python packages selected using the frozen stable upper-constraints.txt set is a model they're recommending to their users. Honestly I think the solution to *that* problem is to stop, or at least document clearly that it's a security-wise unsafe choice for anything besides a test/proof-of-concept environment. I get why they thought it could be a useful addition since it's basically how we test our stable branches, but it's really a frightening lapse in judgement which puts our users' systems at grave risk of compromise. -- Jeremy Stanley