Comments (9)
it appears that the security topic, as defined by the DDS Sec specs, is not a valid topic name in ROS2 realm since the 'colon' character is not valid
That's OK, because that topic lives in the DSS world. It is not a ROS 2 topic. ROS 2's topic name constraints are extra restrictions on top of the DDS topic name constraints, and only for topics created by ROS.
Is there a mistake in the DDS Security spec or were the naming constraints misinterpreted? (The colon character is invalid vs the topic constraints do not exist). Neither and I'm missing something?
The topic constraints do not exist for topics created by DDS and its facilities. They are only relevant to names used in ROS, and designed to ensure that the names that come from ROS can be mapped unambiguously to DDS topic names.
Assuming the topic DDS:Security:LogTopic is not a mistake, how could I get to subscribe to it from ROS2?
Probably you would have to use the DDS API of your DDS vendor directly. You can get access to the objects created by your DDS implementation underneath the rmw
layer and use those with the DDS API directly.
from design.
That's OK, because that topic lives in the DSS world. It is not a ROS 2 topic. ROS 2's topic name constraints are extra restrictions on top of the DDS topic name constraints, and only for topics created by ROS.
Not sure what you mean by created but the aforementioned topic is not created by ROS per se. I'm only trying to subscribe to it.
ROS 2's topic name constraints are extra restrictions on top of the DDS topic name constraints [...]
The topic constraints do not exist for topics created by DDS and its facilities.
That seems contradictory or am I reading it wrong?
In case the constraints do not exist for topics created by DDS then maybe the design doc needs to be fixed since it states:
In DDS, topic names are restricted by these restrictions:
From DDS 1.4 specification, or the RTI documentation:
TOPICNAME - A topic name is an identifier for a topic, and is defined as any series of characters 'a', ..., 'z', 'A', ..., 'Z', '0', ..., '9', '_' but may not start with a digit.
...
Probably you would have to use the DDS API of your DDS vendor directly. You can get access to the objects created by your DDS implementation underneath the
rmw
layer and use those with the DDS API directly.
While I could implement a plain DDS subscriber, I wish to benefit from ROS to be vendor agnostic. Furthermore, we (the Security WG) are working on enabling the DDS Security logging in ROS2, the fourth of five DDS security plugins defined in the DDS Security specs. As mentioned previously PRs were already merged in the vendor specific rmw
layer so that at the moment the logging can be enabled but not accessed from ROS. This logging will allow one to monitor the security events of a ROS2 graph (e.g. an unexpected subscription to your image (ros) topic). It would be unfortunate if this information cannot be accessible at the ROS2 level in any ways and monitored through e.g. rqt_console
and such.
Of course I'm not advocating for removing the topic naming constraints but rather for opening the discussion on how to access this particular topic (DDS:Security:LogTopic
) from ROS.
Friendly ping to @wjwwood as he wrote most of the design doc. I'd be interested in knowing your view on this matter.
from design.
One option could be to add an API in the rmw
layer.
from design.
@gbiggs not sure to understand what you mean. An API in the rmw
layer to (?) expand/disable the topic naming constraint?
from design.
An API that gives access to information about the underlying security information, such as logged events.
from design.
I think this is a bug in the DDS security spec or implementation, if they are knowingly using :
in their topic names. It is definitely not allowed (yet) in the DDS specification. The section we quoted from our design docs is still there in the DDS spec. At this moment the ROS 2 spec is a super set of what is technically allowed in the DDS spec, in that we also allow the /
character, in addition to alphanumerics and underscores.
If either the DDS spec is updated to allow :
or they just continue using :
in the name anyways, then you will not be able to subscribe to this topic with ROS 2. I don't think we'd add :
to our allowed names either.
So you'd either need to add a way to ROS 2 to skip checking the topic name for validity (the avoid_ros_namespace_convention
will not do this) or you'd need a function that subscribes to the security topic or otherwise exposes the information from it, as @gbiggs suggested.
Either way, our design document is still up-to-date right now, so I'll close this issue.
I recommend continuing the discussion with the ROS 2 security working group and/or asking someone in the DDS community and/or the OMG group about this issue.
from design.
Hi,
so, we (the Security WG) had a meeting today with members of the OMG group regarding various security-related topics. During the meeting we had the opportunity to ask about DDS topic naming constraints and got the confirmation that, as of today, there are no limitations on what characters can be used for a DDS topic name. The OMG group acknowledges that this can potentially be an issue and plans on defining such valid subset of characters. One may refer to the (open) issue DDS15-197 for further information. Here is an extract:
The DDS specification states a Topic name is a string but it does not state what the legal characters are. [...]
Because of this it is also possible for multiple vendors to put in place restrictions that could cause incompatibilities.
As pointed in my initial post, the constraint 'a', ..., 'z', 'A', ..., 'Z', '0', ..., '9', '_'
was mistakenly understood as applying to topic names when really it concerns syntax for queries and filters.
The OMG group plans on fixing this situation by the next revision and we received an oral confirmation that the colon character will be part of the valid set (thus the security logging topic will be valid as per the specs).
Now I don't know how this update will affect the ROS 2 topic naming constraints but would it be foolish of me to hope to see the colon character supported by ROS 2 as well ? 🙂 Or should I start working on a workaround ? 🙁
Edit: Could we see this issue re-opened? Thanks
from design.
I'd argue for a workaround that allows you to use any character you want under the hood, bypassing the ROS checks, rather than updating the ROS constraints to be more permissive.
from design.
Related Issues (20)
- Multirobot support HOT 9
- Middleware alternatives to DDS HOT 4
- fix login by using new GitHub methods HOT 1
- Changes between ROS 1 and ROS 2 design doc is out of date HOT 1
- Add support for fully qualified names in message defnitions
- Add design document on configuring QoS at startup time HOT 4
- Add support for preemption in actions HOT 39
- Update XML schema definition for launch files HOT 2
- Add [ros2 node kill <node_name>] and [ros2 node kill --all] (similar to [rosnode kill] from ros1) HOT 23
- Article numbering is not clear HOT 3
- Documentation linter HOT 5
- zero-copy: shared memory using external mapped buffer HOT 3
- is intra-process communication meta-message transfered via DDS? HOT 4
- Logging Design Document
- Update Launch XML Schema HOT 3
- can we add a "date written" to the design docs? HOT 2
- Map char[N] to str in Python
- Why must field names of messages and services be lowercase? HOT 4
- how you configured opentcs nena ros2 adapter to your agv? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from design.