Open Stack

Eric Windisch wrote:
> [...]
> I presently have a patch that introduces RPC-ENVELOPE v3, although it is
> presently failing some tests:
>  https://review.openstack.org/#/c/21562/
> 
> This patch introduces much of what we need for trusted-messaging. It
> fixes the envelope and introduces a replay-prevention check that is a
> non-secure variant of what we'll do with trusted-messaging enabled.
>  This patch will solidify how/where we will do the signature
> verification, for instance. I believe there is a very strong chance we
> can get this patch in for Grizzly, but we do need to settle whatever
> concerns/questions there might be about v2 versus v3 envelope
> compatibility and how the API should look. I do believe we absolutely do
> need to resolve these questions before feature-freeze because we do not
> want to make breaking changes after, or worse, in Havana.

I don't really know the story behind v2 not addressing your need, but
from your description, it indeed sounds like a good idea to get that in
grizzly, i.e. merge it now.

> Once these changes land, doing the message signing and verification,
> especially if we use a high-level library such as pygpgme, is relatively
> straightforward. It is premature to say this can be ready for G3, the
> time is tight, but I don't think it is an impossible goal, either.  In
> doing so, we'll likely need to rev the RPC envelope again, but in a
> non-breaking fashion.
> 
> Finally, in regard to the implementation of crypto, through a bit of
> analysis, and even some trial-and-error, I've realized that crypto in
> Python is terribly immature.  The choice of OpenPGP over X.509 is
> largely to do with the availability of standardized keyserver options,
> also OpenPGP is *designed* for the decentralized pattern that we're
> using in OpenStack messaging.  These factors both considered, I've
> decided that the best chance to complete this work for Grizzly is to use
> pygpgme as an almost end-all, be-all solution. This depends on the LGPL
> C-library, GPGME. After some consideration and discussion, I *think*
> this license is compatible with the Apache license, as long as we are
> simply linking. Keysevers will be initially supported through HKP, for
> which plenty of keyserver options presently exist.  Finally, it seems
> reasonable that if there is a sufficient demand, a pure-python
> implementation can be complete for Havana.

Given the time left and the need for more discussion and checks around
this, I'm not sure trying to rush that in Grizzly (in the very last
week) is the right thing, compared to pushing it early in Havana after
design summit discussion.

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack