summaryrefslogtreecommitdiffstats
path: root/openstack/common/plugin
diff options
context:
space:
mode:
authorRussell Bryant <rbryant@redhat.com>2013-02-20 17:02:20 -0500
committerRussell Bryant <rbryant@redhat.com>2013-02-20 17:39:20 -0500
commit3b848ae38bd087cef263b9072d5da559d4508c73 (patch)
treeadbc5b5f4b4cbbfea8bd2ae62219e2728395a718 /openstack/common/plugin
parent7e6513dedc58577c187d69d576659bc7f2ed7a87 (diff)
downloadoslo-3b848ae38bd087cef263b9072d5da559d4508c73.tar.gz
oslo-3b848ae38bd087cef263b9072d5da559d4508c73.tar.xz
oslo-3b848ae38bd087cef263b9072d5da559d4508c73.zip
Revert "Fast serialization of RPC envelopes for Kombu"
This reverts commit 22c497097b0d0bd461be40a7a03290aa0b4179f2. I'm not convinced that this isn't just a micro-optimization when compared to the rest of the work that a given OpenStack service performs as the result of these messages. The implementation is also problematic. It depends on using a '\0' byte as a separator and assumes that '\0' will not exist anywhere else in the message. This seems to be asking for trouble. If future data could ever have a '\0' in it, this will be broken. Further, if a user could get a '\0' in a message directly with user-supplied input, this could result in a security vulnerability. Lastly, this has a significant impact on consumers of notifications that are outside of OpenStack code, which have been the primary use case of notifications (Ceilometer is changing that to a degree). I don't think consumers of notifications should have to implement this deserialization method. Change-Id: Ib3163ca98f568bf9f789d4b64bcc6d72e0fcb459
Diffstat (limited to 'openstack/common/plugin')
0 files changed, 0 insertions, 0 deletions