Open Stack

On Thu, May 16, 2019 at 6:14 AM Jeremy Stanley <fungi at yuggoth.org> wrote:
>
> On 2019-05-15 16:50:58 -0500 (-0500), Eric Fried wrote:
> > (NB: I'm explicitly rendering "no opinion" on several items below so you
> > know I didn't miss/ignore them.)
> [...]
>
> (NBNB: Kashyap asked to be Cc'd as a non-subscriber, so I have added
> him back but you may want to forward him a copy of your reply.)
>
> > >>> Does the Security Team has any strong opinions?
> >
> > Still hoping someone speaks up in this capacity...
> [...]
>
> I've added a link to this thread on the agenda for tomorrow's
> Security SIG meeting[*] in order to attempt to raise the visibility
> a bit with other members of the SIG.
>
> [*] http://eavesdrop.openstack.org/#Security_SIG_meeting
> --
> Jeremy Stanley

I'm actually on the side of adding all the traits (cpu flags) and
letting the operator make sure that their cloud is patched.

We don't want to make assumption on behalf of the user, if I am
$chip_manufacturer and I want to use OpenStack to do CI for regression
testing of these, then I don't have the ability to do it.  The
solution of introducing a flag that says "it's okay if it's
vulnerable" opens a whole can of worms on a) keeping up to date with
all thee different vulnerabilities and b) potentially causing a lot of
upgrade surprises when all of a sudden the flag you relied on is now
all of a sudden a "banned" one.

I think we should empower our operators and let them decide what to do
with their clouds.  These recent CPU vulnerabilities are very
'massive' in terms of "PR" so usually most people know about them.

-- 
Mohammed Naser — vexxhost
-----------------------------------------------------
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mnaser at vexxhost.com
W. http://vexxhost.com