Open Stack

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)