0.7.0 (Coquette)
The key feature of this release is the support for the core of DDS Security 1.1: authentication, access control and encryption. The other significant change is the much improved behaviour for very large samples: an improved retransmit strategy reduces the number of unnecessary retransmits and eliminates the sometimes excessive latencies.
DDS Security defines a set of plug-in interfaces and protocol hooks that are part of the core DDS implementation and a set of "default" plug-ins that users may expect the DDS implementation to provide, but they can also provide their own plug-ins. The default plug-ins rely on standard cryptographical techniques (AES for symmetric encryption, Diffie-Hellman key exchange, etc.) and are typically sufficient for protecting a DDS system.
One can choose at build-time whether to include the interfaces and protocol hooks in the core of Cyclone DDS. Leaving it out significantly reduces the size of the code and brings a tiny performance improvement. If security supported is compiled out, the DDS_HAS_SECURITY macro will be undefined (otherwise it is defined to 1) and any attempt at creating a participant with security settings will be rejected with a "precondition not met" failure.
A lot of effort has gone into testing and checking that malformed or unexpected messages are handled correctly, that message authentication codes are checked and that no data never goes out unencrypted by accident. Still, it is significant amount of code and it is only prudent to assume the worst for a new implementation of such a complex specification.
The overall architecture is holding up just fine, but there remain many, mostly local, details that need reworking. The addition of DDS Security has unfortunately laid bare some more of these details.
Cleaning up these issues is an ongoing process, undertaken as a background activity while working towards covering all of the DDS specification famliy. The number of issues reported by people remains very low despite evidence of a growing user base, and this is also an indication that the fundamental architectural choices are sound.
There is currently no dependency of Cyclone DDS on any other project, and therefore no relationship to any of these resolved vulnerabilities. We don't currently provide binary releases and rely on users to follow best-practices of staying up to date with their dependencies, in our case, OpenSSL. (Open Robotics is providing binary packages using up-to-date dependencies.)
Given that Cyclone DDS now supports DDS Security, it is now "at risk" of having vulnerabilities. None are known at this point in time, but it must be assumed that some exist.
The documentation is very basic but appears to be good enough for those who are willing to invest a bit and make a few educated guesses, based on the evidence of increasing usage and the questions that have been asked on GitHub. Presentation of the documentation and providing easy access to it (e.g., via readthedocs.io), as well as a proper website is still missing, but there are some indications that help will come.
How many users there would have been by now had the documentation been better is anyone's guess. Thus, it is one of the main points needing attention.
As it is middleware the intended audience is very minimal and there is no user interface to speak of.
None.
OMG DDS:
- DCPS specification version 1.4 (with a more friendly API)
- DDSI specification version 2.3
- Security specification version 1.1
The use of and contributions to Cyclone DDS has grown notably since becoming a tier-1 middleware in "Foxy Fitzroy", released June 5. This is visible in several ways: more well-known companies putting their logo up on the "adopters" board (https://iot.eclipse.org/adopters/?#iot.cyclonedds), more issues and pull requests on Cyclone DDS itself, but more notably on the ROS 2 Middleware abstraction where various people have now joined in maintaining the abstraction layer. The number of downloads as reported by GitHub has gone up significantly as well.
There are also activities underway to combine Cyclone DDS and Eclipse Iceoryx to get the best of both in a single system, and to combine Cyclone DDS and Eclipse Zenoh to overcome some of the scalability limitations inherent in the DDS specification.