Open Stack

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190515/535d3aea/attachment.sig>