On Tue, Aug 13, 2013 at 5:54 PM, Simo Sorce <s...@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
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
