Open Stack

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

The main issue is that data that is signed together must, well, be signed together. What is signed must be a byte sequence.

I've spent a bit more work on this since my original posting. It may be that I overstated the need to make the change incompatible. For one, I had originally thought it would be necessary for the data to be readable/parsable. I don't know why I was thinking that, but it was wrong.  Instead, it is only necessary we can have all of that data in the same bytes sequence. Thus, my original concern about double-serializing does not apply, we can simply concat the values. We'll never have to actually understand the data, so it isn't necessary that it remains a valid JSON blob.

We *will* break the unit tests that are out there for rpc-envelope-v2 and much of my own effort today has been to improve backwards-compatibility and pass, improve, fix the unit tests.  Presently, the current patch set is largely or entirely compatible except that existing rpc_common code explicitly rejects older envelopes with an older version string. I left that check unchanged, since it seemed to be Russell's intention, but I can update that to provide backwards compatibility.

Getting more eyes on this patch would be appreciated, but I do think it is shaping up quickly.

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

My main goal of this blueprint for Grizzly is to push the envelope changes that will be needed that are not strictly related to message signing, but will be needed to make it secure. For instance, specifically, this patch lays the groundwork to reject replay attacks.  It turns out, this also relates to a need from the Kombu/RabbitMQ folks that are experiencing queue-server induced replays.

However, I think that this patch constitutes the majority of the work and risk. Tacking on message signing from there will be relatively simple. If this patch lands, the message signing patch itself will be significantly lower risk, assuming it were to be ready by Friday.

Regards,
Eric Windisch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130212/079b216b/attachment.html>