Open Stack

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.
> 
> 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".

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

Simo.

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