<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 18, 2016 at 4:14 PM, Dean Troyer <span dir="ltr"><<a href="mailto:dtroyer@gmail.com" target="_blank">dtroyer@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">> -----Original Message-----<br>
> From: Luke Hinds <<a href="mailto:lhinds@redhat.com">lhinds@redhat.com</a>><br>
</span><span class="gmail-">[...]<br>
>> for non security related functions, but when it comes to government<br>
>> compliance and running OpenStack on public clouds (and even private for the<br>
>> Telcos / NFV), not meeting FIPS will in some cases block production getting<br>
>> a green light, or at least make it a big challenge to push through.<br>
<br>
</span>Are there any know cases of this happening?  If so, can those be<br>
publicly documented to quantify how much this issue is hurting<br>
deployments?<br>
<span class="gmail-"><br>
<br></span></blockquote><div> </div><div>I don't have any that I could share publicly at the moment, but I will dig around.</div><div><br></div><div>I expect the FIPS 140-2 requirement will be more frequently requested for the telecommunications based NFV deployments, which as we all see, are undergoing a groundswell in OpenStack, with many networks expected to go into production over the next five years. Security compliance tends to be more strictly enforced in Telco as the networks are seen as a critical infrastructure. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
<br>
On Fri, Nov 18, 2016 at 9:57 AM, Ian Cordasco <<a href="mailto:sigmavirus24@gmail.com">sigmavirus24@gmail.com</a>> wrote:<br>
> Also, instead of creating bugs, I would suggest instead that we try to make this into a community goal. We would work with the TC and for P or Q, make it a goal to start migrating off of MD5 and have a goal for a cycle or two later to completely remove reliance on MD5.<br>
><br>
> Doing this piecemeal via bugs will not be efficient and we'll need community buy-in.<br>
<br></span></blockquote><div><br></div><div>If that is the more pragmatic approach and there is TC buy in, then let's go ahead. Whatever means is most effective in getting it done.</div><div><br></div><div>At some point, I think we will need a tag to return a set of bugs to gauge progress, but I agree the consensus needs to be in place, more then a bug list.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
</span>We would also need to get a reasonable scoping of the issue (which<br>
projects, how many instances, etc) to help decide if this is an<br>
achievable goal (in the sense of the 'community goals').<br>
<br>
As you noted, this will not be easy for Swift or Glance (others?), but<br>
if the impact to deployers can be quantified it makes it easier to<br>
spend energy here.<br>
<span class="gmail-HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>I can collate figures on how many instances there are, on which projects etc.</div><div><br></div><div>The part where I am green is how this would be taken forward to gain community consensus or TC approval.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-HOEnZb"><font color="#888888">
dt<br>
<br>
--<br>
<br>
Dean Troyer<br>
<a href="mailto:dtroyer@gmail.com">dtroyer@gmail.com</a><br>
</font></span></blockquote></div><div><br></div>
</div></div>