<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Tue, Aug 13, 2013 at 5:54 PM, Simo Sorce <span dir="ltr"><<a href="mailto:simo@redhat.com" target="_blank">simo@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tue, 2013-08-13 at 17:20 -0500, Dolph Mathews wrote:<br>
> With regard<br>
> to: <a href="https://blueprints.launchpad.net/keystone/+spec/key-distribution-server" target="_blank">https://blueprints.launchpad.net/keystone/+spec/key-distribution-server</a><br>
><br>
</div>Well I am of course biased so take my comments with a grain of salt,<br>
that said...<br>
<div class="im">><br>
> During today's project status meeting [1], the state of KDS was<br>
> discussed [2]. To quote ttx directly: "we've been bitten in the past<br>
> with late security-sensitive stuff" and "I'm a bit worried to ship<br>
> late code with such security implications as a KDS."<br>
<br>
</div>Is ttx going to review any "security implications" ? The code does not<br>
mature just because is sit there untouched for more or less time.<br>
<div class="im"><br>
>  I share the same concern, especially considering the API only<br>
> recently went up for formal review [3],<br>
<br>
</div>While the API may be important it has little to no bearing over the<br>
security properties of the underlying code and mechanism.<br>
The document to review to understand and/or criticize the "security<br>
implications" is this: <a href="https://wiki.openstack.org/wiki/MessageSecurity" target="_blank">https://wiki.openstack.org/wiki/MessageSecurity</a><br>
and it has been available for quite a few months.<br>
<div class="im"><br>
>  and the WIP implementation is still failing smokestack [4].<br>
<br>
</div>This is a red herring, unfortunately Smokestack doesn't say why it is<br>
failing but we suppose it is due to something python 2.6 doesn't like<br>
(only the centos machine fails). I have been developing on 2.7 and was<br>
planning to do a final test on a machine with 2.6 once I had reviews<br>
agreeing no more fundamental changes were needed.<br></blockquote><div><br></div><div>My mistake - glancing through the patchset history I thought it was SmokeStack that was regularly failing, but it appears to be mostly Jenkins failures with SmokeStack failing most recently.</div>
<div><br></div><div>Either way, I try to avoid reviewing code that is still failing automated tests, so I have yet to review the KDS implementation at all.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">><br>
> I'm happy to see the reviews in question continue to receive their<br>
> fair share of attention over the next few weeks, but can (and should?)<br>
> merging be delayed until icehouse while more security-focused eyes<br>
> have time to review the code?<br>
<br>
</div>I would agree to this only if you can name individuals that are going to<br>
do a "security review", otherwise I see no real reason to delay, as it<br>
will cost time to keep patches up to date, and I'd rather not do that if<br>
no one is lining up to do a "security review".<br></blockquote><div><br></div><div>keystone-core, at least... that's part of our responsibility. The commit message also lacks a SecurityImpact tag.</div><div>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
FWIW I did circulate the design for the security mechanism internally in<br>
Red Hat to some people with some expertise in crypto matters.<br></blockquote><div><br></div><div>I'd love to see their feedback provided publicly.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<span class="HOEnZb"><font color="#888888"><br>
Simo.<br>
<br>
--<br>
Simo Sorce * Red Hat, Inc * New York<br>
<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><br></div>-Dolph
</div></div>