Open Stack

On Tue, Aug 13, 2013 at 5:54 PM, Simo Sorce <simo at redhat.com> wrote:

> On Tue, 2013-08-13 at 17:20 -0500, Dolph Mathews wrote:
> > With regard
> > to:
> https://blueprints.launchpad.net/keystone/+spec/key-distribution-server
> >
> Well I am of course biased so take my comments with a grain of salt,
> that said...
> >
> > During today's project status meeting [1], the state of KDS was
> > discussed [2]. To quote ttx directly: "we've been bitten in the past
> > with late security-sensitive stuff" and "I'm a bit worried to ship
> > late code with such security implications as a KDS."
>
> Is ttx going to review any "security implications" ? The code does not
> mature just because is sit there untouched for more or less time.
>
> >  I share the same concern, especially considering the API only
> > recently went up for formal review [3],
>
> While the API may be important it has little to no bearing over the
> security properties of the underlying code and mechanism.
> The document to review to understand and/or criticize the "security
> implications" is this: https://wiki.openstack.org/wiki/MessageSecurity
> and it has been available for quite a few months.
>
> >  and the WIP implementation is still failing smokestack [4].
>
> This is a red herring, unfortunately Smokestack doesn't say why it is
> failing but we suppose it is due to something python 2.6 doesn't like
> (only the centos machine fails). I have been developing on 2.7 and was
> planning to do a final test on a machine with 2.6 once I had reviews
> agreeing no more fundamental changes were needed.
>

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.

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.


> >
> > I'm happy to see the reviews in question continue to receive their
> > fair share of attention over the next few weeks, but can (and should?)
> > merging be delayed until icehouse while more security-focused eyes
> > have time to review the code?
>
> I would agree to this only if you can name individuals that are going to
> do a "security review", otherwise I see no real reason to delay, as it
> will cost time to keep patches up to date, and I'd rather not do that if
> no one is lining up to do a "security review".
>

keystone-core, at least... that's part of our responsibility. The commit
message also lacks a SecurityImpact tag.


>
> FWIW I did circulate the design for the security mechanism internally in
> Red Hat to some people with some expertise in crypto matters.
>

I'd love to see their feedback provided publicly.


>
> Simo.
>
> --
> Simo Sorce * Red Hat, Inc * New York
>
>


-- 

-Dolph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130814/cc57dfcc/attachment.html>