On Thu, May 16, 2019 at 6:14 AM Jeremy Stanley <fungi@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@vexxhost.com W. http://vexxhost.com