<div dir="ltr"><div><div>I completely agree that this shall be upstream first. So the main effort will be on landing this python patch first. This has been up since 2010, so more effort in terms of code contribution and reviews is needed, I'm happy to collaborate in amending the patch as the reviews are requesting.<br></div><br>But the general idea is still there, and that's why a wrapper can make sense. Even if the final patch has a different signature, or a different functionality, the idea is the same: don't block md5 if that's not used for security.<br></div><br>Even if the python patch lands, this would be in 3.7 and this version adoption can take long in OpenStack. And enabling FIPS kernel is an important security feature that we shall cover, if we just wait for the patch to land it can take long time. The wrapper can be the short-term solution as Doug says, allowing us to enable this important feature.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 17, 2017 at 5:51 PM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Ian Cordasco's message of 2017-01-17 05:59:13 -0600:<br>
<span class="">> On Tue, Jan 17, 2017 at 4:11 AM, Yolanda Robla Mota <<a href="mailto:yroblamo@redhat.com">yroblamo@redhat.com</a>> wrote:<br>
> > Hi, in previous threads, there have been discussions about enabling FIPS,<br>
> > and the problems we are hitting with md5 inside OpenStack:<br>
> > <a href="http://lists.openstack.org/pipermail/openstack-dev/2016-November/107035.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/2016-<wbr>November/107035.html</a><br>
> ><br>
> > It is important from a security perspective to enable FIPS, however<br>
> > OpenStack cannot boot with that, because of the existence of md5 calls in<br>
> > several projects. These calls are not used for security, just for hash<br>
> > generation, but even with that, FIPS is blocking them.<br>
> ><br>
> > There is a patch proposed for newest versions of python, to avoid that<br>
> > problem. The idea is that when a hash method is called, users could specify<br>
> > if these are used for security or not. If the useforsecurity flag is set to<br>
> > False, FIPS won't block the call. See: <a href="http://bugs.python.org/issue9216" rel="noreferrer" target="_blank">http://bugs.python.org/<wbr>issue9216</a><br>
><br>
> This patch looks to have died off in 2013 prior to Robert's comment from today.<br>
><br>
> > This won't land until next versions of Python, however the patch is already<br>
> > on place for current RHEL and CentOS versions that are used in OpenStack<br>
> > deploys. Using that patch as a base, I have a proposal to allow FIPS<br>
> > enabling, at least in the distros that support it.<br>
> ><br>
> > The idea is to create a wrapper around md5, something like:<br>
> > md5_wrapper('string_to_hash', useforsecurity=False)<br>
><br>
> We should probably work harder on actually landing the patch in Python<br>
> first. I agree with Robert that the optional boolean parameter is<br>
> awkward. It'd be better to have a fips submodule.<br>
<br>
</span>Please see my comment on that patch about why that approach doesn't<br>
solve the problem.<br>
<div><div class="h5"><br>
> > This method will check the signature of hashlib.md5, and see if that's<br>
> > offering the useforsecurity parameter. If that's offered, it will pass the<br>
> > given parameter from the wrapper. If not, we will just call<br>
> > md5('string_to_hash') .<br>
> ><br>
> > This gives us the possibility to whitelist all the md5 calls, and enabling<br>
> > FIPS kernel booting without problems. It will start to work for distros<br>
> > supporting it, and it will be ready to use generally when the patch lands in<br>
> > python upstream and another distros adopt it. At some point, when all<br>
> > projects are using newest python versions, this wrapper could disappear and<br>
> > use md5 useforsecurity parameter natively.<br>
><br>
> I'd much rather have the upstream interface fixed in Python and then<br>
> to have a wrapper that does things the correct way. Otherwise, we're<br>
> encouraging other distros to use a patch that still requires a lot of<br>
> edits to address the review comments and might be defining an API that<br>
> will never end up in Python.<br>
><br>
> > The steps needed to achieve it are:<br>
> > - create a wrapper, place it on some existing project or create a new fips<br>
> > one<br>
> > - search and replace all md5 calls used in OpenStack core projects , to use<br>
> > that new wrapper. Note that all the md5 calls will be whitelisted by<br>
> > default. We have not noted any md5 call that is used for security, but if<br>
> > that exists, it shall be better to use another algorithms, in terms of<br>
> > security.<br>
> ><br>
> > What do people think about it?<br>
><br>
> I think people should work on the Python patches *first*. Once they're<br>
> merged, *then* we should potentially create a wrapper (if it's still<br>
> necessary at that point) to do this.<br>
><br>
<br>
</div></div>The idea is to use the wrapper as a short-term solution to give us the<br>
time to make that happen. The original patch did lose interest, but even<br>
if it landed today it wouldn't necessarily be the sort of thing that<br>
would qualify for a backport, so it might take quite a while to see a<br>
real release.<br>
<br>
As you point out, the final version of the upstream API may be<br>
different. With a wrapper in place, we ought to be able to modify the<br>
implementation of the wrapper to accommodate that to ensure backwards<br>
compatibility, during the deprecation period after the upstream fix is<br>
implemented.<br>
<span class="HOEnZb"><font color="#888888"><br>
Doug<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Yolanda Robla Mota<br></div><div>NFV Partner Engineer<br></div><a href="mailto:yroblamo@redhat.com" target="_blank">yroblamo@redhat.com</a><br>+34 605641639<br></div></div>
</div>