[Documentation] [TitleIndex] [WordIndex] 

ROS 2 Security Working Group

This page exists to contain meeting notes for the ROS 2 Security Working Group, chaired by Canonical.

Effective December 2020, future working group meeting minutes have moved to the ROS 2 Security Working Group Community github repository.

Contents

2020-11-10

Meeting Recording Meeting Announcement

Agenda

Attendees Gianluca Caiazza, Iker Luengo Gil, Jacob Hassold, Jeremie Deray, Mikael Arguedas, Roger Strain, Ruffin White, Sid Faber, Ted Kern

1. Bug report

See Unable to run SROS with CycloneDDS on ROS 2 foxy · Issue #1051 · ros2/ros2 and Fix Fix OpenSSL Dependency. Issue is resolved waiting for merge, no further action required.

2. Vulnerability Remediation Procedure

Propose hosting it under our "Community" page. See Community PR#8. This is the follow-on to the Vulnerability disclosure policy, it discusses how internally to handle reports to security@openrobotics.org. See the original document.

Updates from the original document are based on experience working through NVD - CVE-2020-16124, https://github.com/ros/ros_comm/pull/2065. This vuln was for ROS 1, but it exercised essentially the same workflow.

3. ROS without a file system

Follow-up from a discussion at our last meeting. Although there's some agreement with creating a system-wide build flag, there's not a lot of enthusiasm. One volunteer from the Embedded WG to discuss. (see rcl issue 545 and discourse post.)

Next steps: schedule the meeting, give the meeting some visibility. Continue trying to work with the embedded WG.

4. Launch files

Ted gave an update on the current status of https://github.com/ros2/launch_ros/pull/180

5. Permissions file size

Continue to review uglifying the permissions files to save space, this seems like a simple thing to do. Only uglify the permissions files that get signed, **not** the XML files used to create them. The XML files stay as-is for readability.

Mikael to open an issue to be used for tracking.

6. G-turtle goals

Are there any larger goals we should try to hit for G-turtle?

Open action items

2020-10-13

Meeting Recording Meeting Announcement

Agenda

Attendees

Gianluca Caiazza, Ian Meinzen, Iker Luengo Gil, Jacob Hassold, Jaime Martin Losa, Jeremie Deray, Kyle Fazzari, Marco Gutierrez, Roger Strain, Ruffin White, Sid Faber, Ted Kern

1. rcl issue #545

Background

Some environments do not have file systems. Environment vars may also be out of bounds. RCL security implementation relies on the file system; however, environment vars are used elsewhere. If we were to remove both, that'd be required at compile time: specify the rmw implementation, then extract some file system bits.

The original request was simply to move security features out of RCL to avoid file system dependencies.

Options

There seem to be two primary ways forward:

Two are two different aspects of the issue:

Currently security traces a file path and passes it to dds-security through config attributes. Instead of a path it could be a PEM encoded device (data), and that could be passed as an argument. Although extracting security file stuff will solve this problem, it won't truly implement the intended design: RCL doesn't have a feature to say "don't use a file system".

Determining target device capabilities

Consider creating a system-wide build flag to identify embedded systems without a file system. Projects should opt-in, which would make this a wide-reaching change.

The proposed solution should be coordinated with the MicroROS working group. Schedule a joint ad-hoc meeting with the embedded wg to discuss doing security in embedded in more detail.

Enabling in sros2 Consider expanding the API so the security properties can be passed in as data rather than requiring them to be in a file system. This pushes work onto maintainers to decide whether they're able to build, and if so, what capabilities they support without a file system.

There are ~5 file paths currently, but they can be updated from file paths to a "data:" or "pkcs11:" uri. Not all implementations support this.

Open action items

Closed

2020-09-22

Meeting Recording Meeting Announcement

Agenda

Attendees Iker Luengo Gil, Jacob Hassold, Jaime Martin Losa, Jeremie Deray, Kyle Fazzari, Marco Gutierrez, Mikael Arguedas, Roger Strain, Ruffin White, Sid Faber, Ted Kern

1. CIS Update

Guide is in draft, scheduled for initial publication shortly. Continues to be available for comment. Kyle added a new recommendation to have the default install limited to localhost communications only.

2. Compressing permissions

OMG comments forwarded from Jaime:

Contents of the OMG JIRA issue: DDS Security 1.2 RTFDDSSEC12-88

Description:

The Permission File is an XML file. The signature is also encoded as text. For large systems with a lot of Topics the size can grow to be quite big. This is amplified by the fact that it is possible and convenient to combine the permissions of multiple participants into a single file. This size can exceed the 64KB max size of IP.

An additional problem is that the permissions file is sent during the authentication handshake. The authentication handshake uses a special "best efforts stateless" that does not support fragmentation of large packets. This is done on purpose to make the channel to be robust to sequence number attacks but it results on the inability to send these large permission files. This could be addressed by separating the permissions from the authentication handshake and there is already an issue filed for this, see DDSSEC12-13.

However there is a simple solution that can make the current approach more scalable. The proposed approach is to send the Permissions document compressed rather than in their current text form.

Users are already hitting this limit so this issue requests that capability to send the permissions compressed is added with high priority, even if later a more general solution is developed as requested in DDSSEC12-13.

Last comment from Gerardo: (Solution proposal, I think this will be voted)

Main changes required to support compressing the "large" files sent during authentication:

An alternative and perhaps simpler approach is to compress the entire Token. ... Instead of sending HandshakeRequestMessageToken and HandshakeReplyMessageToken we would send HandshakeRequestMessageTokenZ and HandshakeReplyMessageTokenZ is a compressed version of these Tokens.

The DataWriter/Reader used tor the Authentication protocol write/read data of type: sequence<Token>. So the actual data sent during Authentication is a sequence<Token> containing a single element which is the HandshakeRequestMessageToken, HandshakeReplyMessageToken and HandshakeFinalMessageToken.

The Tokens themselves have the type: 

@extensibility(APPENDABLE)
struct DataHolder {
    string             class_id;
    PropertySeq        properties;
    BinaryPropertySeq  binary_properties;
};

One way to do this is to extend struct DataHolder to be: 

@extensibility(APPENDABLE)
struct DataHolderZ : DataHolder {
    @optional sequence<octet> properties_z;
    @optional sequence<octet> binary_properties_z;
};

These optional members contain a compressed version of the namesake properties,

For backwards interoperability they would only be used if the peer participant announces support of DDS-Security version 1.2. This could be tied to the class_id in the IdentityToken class. Currently it is "DDS:Auth:PKI-DH:1.0" it could change to "DDS:Auth:PKI-DH:1.2" furthermore we could add a property: "dds.compression" with value that indicates the compression algorithm used. The presence of which indicates support for sending the HandshakeMessageToken tokens compressed using that algorithm.

The standard would define the compression algorithm to use. We would need to choose one that favors a high compression ratio over speed and can be implemented without adding too much code.

3. SROS2 API update

Curated the API, proposed only exposing a limited part of the API to the public. Looking for reviews to the API changes to enable secure launch.

Open action items

2020-09-08

Meeting Recording

Agenda

Attendees Jaime Martin (eProsima) Iker Luengo (eProsima) Sid Faber Jacob Hassold Gianluca Caiazza Kyle Fazzari Ted Kern Marco Gutierrez Jeremie Deray Roger Strain

1. system_tests overview

GitHub ros2 system tests

These are integration level tests. The tests spawn nodes in different processes, make sure messages are received when they should and are not when they should not. They also check proper configurations and failure of improperly configured security. test_configs sets up all the tests. Intent is to test all the messages in test_messages since that should give message coverage.

Intent is to implement with all client libraries and all middleware implementations. Currently only testing C++ nodes, not doing cross-vendor testing. Historically there were some cross-vendor issues; not sure if that's still the case.

Jaime: OMG Security interoperability Tests: https://github.com/omg-dds/dds-security

The tests depend heavily on cmake logic. See the video for a walkthrough of the current cmake logic.

Open concern on where the tests should be located. Consider moving closer to sros2. Could also position the cross-vendor security tests elsewhere; they're related to security, but they're also related to other cross-vendor testing.

There are opportunities to continue improving the tests, this discussion should continue in matrix and / or an upcoming WG meeting.

Administrivia

CIS update and SROS2 public API update pushed to the next meeting.

Open action items

2020-08-25

Meeting Recording

Agenda

Attendees

Jacob Hassold, Jeremie Deray, Kyle Fazzari, Roger Strain, Ruffin White, Marco Gutiérrez

1. SROS2 Utilities

Marco (OpenRobotics) discussed his project on working with ROS fleet managers. He is looking to understand the current state of security in ROS and add security to the fleet manager. The current system is open source. Encryption is working but with some challenges. Security is at the security participant level, which is not node-specific, and the policy.xml is manually created.

Ruffin suggested reviewing the TurtleBot security demo. It takes a snapshot of the graph and generates a policy set for the graph; this does not cover dynamic behaviors but creates a starting point. The WG is also working on logging to capture ephemeral changes like creating a temporary action client.

Marco is willing to test nodl and security for his use case.

2. Global parameter_events

Background: the risk of adding more topics to the global namespace Historically parameters were a global key-value store managed by roscore, which made it difficult to secure and prevent unauthorized nodes form changing parameters. For ROS 2 each node hosted its own parameter interface. This is problematic because there's still a need for a global parameter (e.g., time, tf). Permissions have to be excessive in the current implementation to function properly.

Kyle and Ruffin to respond to the discourse discussion.

Administrivia

Topic Open general discussion on ROS Security pushed to next meeting.

Open action items:

2020-07-28

Meeting Recording | Announcement (Discourse)

Agenda (ruffin): Enclave permission size limitations with Secure DDS

Attendees

Iker Luengo Gil, Jacob Hassold, Jamie Martin Losa, Jeremie Deray, Joe McManus, Kyle Fazzari, Mikael Arguedas, Roger Strain, Ruffin White, Sid Faber

1. Permissions File Size Limitations

See Enclave permission size limitations with Secure DDS discussion on matrix. Also see github comments

(eProsima): Problem is not the UDP limit, but the RTPS Parameter size limit. Specification does not allow sending parameters larger than 64kB. eProsima Fast-DDS is not issuing an error with sizes larger than 64KB. Will be corrected.

Ruffin reviewed the background on how the issue was identified. Bottom line: large policy file requires fragmentation. This exceeds the RTPS maximum packet size of 64kb (not an issue with fragmentation necessarily). Possible options / ways to improve:

Some of the challenge is the combinatorial explosion of default nodes (e.g., parameter and lifecycle nodes). A better default should help.

2. The DDS Access Control Listener

Simple case: a node container wants to load a new node, and it concatenates it and updates it and re-signs it. Is that possible? Can that interface be used to change a participant's interface on-the-fly? eProsima will look into this further.

Review Ticket 272, Refactoring ExecuteProcess into Execute and Executable, see how it applies to this discussion.

Administrivia Mikael is looking for help to work on tickets on SROS2. Ticket 221. This includes the need to re-enable the cyclone test, see Issue 408

New action items:

Open action items:

Recently closed action items:

2020-07-14

Meeting Recording | Announcement (Discourse)

Agenda

Attendees Gianluca Caiazza Jeremie Deray Joe McManus Jono Spring Kyle Fazzari Roger Strain Ruffin White Sid Faber Ted Kern Jacob Haskell

1. CIS ROS Melodic Benchmark

Joe presented a background on CIS.

Sid introduced the Benchmark structure, profiles, and origin of the ROS benchmark.

Next step: Sign in to the CIS workbench. The ROS community is at https://workbench.cisecurity.org/communities/108.

2. Handling Vulns

Sid reviewed the doc, extended call for comments until July 28.

3. NoDL

Ted reviewed proposed updates to the NoDL .

In particular, an "executable" attribute was added to the NoDL file. Similar in some ways to [launch] Refactoring ExecuteProcess into Execute and Executable · Issue #272 · ros2/design

Administrivia

New action items:

Open action items:

2020-06-23

Meeting Recording | Announcement (Discourse)

Agenda

Attendees Jacob Haskell Jeremie Deray Joe McManus Jono Spring Kyle Fazzari Mikael Arguedas Pablo Inigo Blasco Ruffin White Sid Faber Víctor Mayoral Vilches

1. SROS2 Maintenance

2. The Robot Vulnerability Database

References:

Victor summarized the whitepaper for the group.

Victor also reviewed the github implementation that uses CI to automatically generate details using labels. Input is primarily from Alias, although the templates can be completed by the public.

A discussion covered vulnerability scoring: CVSS, RVSS, SSVC. RVD fetches from NVD; everything in RVD has a CVE ID.

Victor will facilitate followup discussions Matrix.

Administrivia

New Action Items:

Open Action Items:

Recently Completed Action Items:

2020-05-26

Meeting Recording | Announcement (Discourse)

Agenda

Attendees Mikael Arguedas Jeremie Deray Sid Faber Kyle Fazzari Joe McManus Roger Strain Víctor Mayoral Vilches Ruffin White

1. Level 2 compliance for sros2

sros2 package quality level: we should strive for level 2 compliance. This requires additional work and should be a community effort. Dependencies do not have a defined quality level which prevents us from claiming a quality level. As a core package, sros2 needs to meet both the core standard and quality 2 as an individual package.

Key missing items include documentation and test coverage; dependency trace is questionable.

A discussion followed on the details of improving documentation.

2. CPE

CPEs (Common Platform Enumeration) have been issued by NIST for ROS. CPEs support the security content automation protocol (SCAP), inventory, CVE mapping and so on.

3. VDP Action Items

Action item status

New:

Completed:

2020-05-26

Meeting Recording | Announcement (Discourse)

Agenda

Attendees Mikael Arguedas Jeremie Deray Sid Faber Kyle Fazzari Joe McManus Roger Strain Víctor Mayoral Vilches Ruffin White Florian Gramss Chris Lalancette

1. VDP Next Steps

See comments on REP-2006: ROS 2 Security VDP PR and past WG meeting minutes.

Challenge is that this represents a large community, and it may be difficult to access code related to the vulnerability while handling an embargoed report.

It generally works well to find the maintainer when handling ROS releases. If a maintainer cannot be identified OR has a way around.

Non-responsiveness may result in removing the package from REP-2005.

We could consider adding a security contact to the package as part of the standard for REP-2005.

When reporting the vulnerability, the reporter should also provide steps needed to reproduce the issue. For example, a docker image or a snap.

Code quality and security is more than just responding to the vulnerabilities: there are more secure coding issues that will need to be addressed beyond this.

Take recommendations on how to maintain list membership. It was strongly recommended that more people should be represented on the security mailing list. Particularly, Michael Arguedas, Ruffin White and Alias Robotics were supported by several in the call. However, to be on the list you have to contribute to the community.

2. WG interaction with the public

Follow-up from discussions about the VDP. Should someone want to interact with the WG (e.g., for robot security advice), where should they be directed? Today we have the following places:

Consensus was to use the github community page as our landing site.

3. SROS2 claiming a Quality Level

Should we claim a REP-2004 quality level for SROS2?

SROS2 is a part of ros core. Most of the core is aiming for level 2, so it makes sense.

Consensus is to target level 2, although first we need to evaluate whether we comply today.

Action items update

2020-05-12

Meeting Recording | Announcement (Discourse)

Agenda

Attendees Mikael Arguedas, Jeremie Deray, Sid Faber, Kyle Fazzari, Ted Kern, Joe McManus, John-Paul Ore, Roger Strain, Victor Mayoral Vilches, Ruffin White

Administrivia The WG agreed to move meetings earlier in the day to accommodate Europe time zones. In the future meeting will be adjusted if needed to support Asia/Pacific members.

1. Move security outside rcl

See rcl issue 545

Goal is to be able to compile without security, particularly for resource constrained environments. Discussions included how environment variables are used/accessed, what rcl contributes to security and use cases.

The WG concluded that this is not a simple issue.

Request for WG members to review the PR above, discuss in matrix and make a recommendation on how to move forward.

2. Update on security landscape for Foxy

Mikael discussed again Foxy support and problems of current tests failing. Help is needed with testing on alternate operating systems, particularly in US time zones.

There is a vetted PR to address many of the issues, it just needs tested in an Americas time zone.

3. ROSCon outlook and planning

Víctor discussed last year's workshop at ROSCon. Since last year's event was well received, it could be repeated again this year. Request for assistance from the WG in helping to put together content for this year's event.

Consensus was that we need some diversity in content, we do not simply want to repeat last year's content. Open question on whether we have new items to present.

Víctor also proposed activities to raise security awareness within the ROS community, including a week of ROS bugs coordinated by the Security WG.

4. Vulnerability Disclosure Policy (VDP) update

Sid discussed the current state of the VDP. After discussing with OR, the VDP is now proposed as REP 2006. This largely accepts the WG's recommended document with two changes: some language was changed from a disclose.io format to follow kernel.org formatting, and the contact email was updated to security@openrobotics.org.

WG members can see past comments in the first (with Security WG) google docs draft

.

5. ros2 launch --secure demo

Ted gave a demo of ros2 launch --secure using demo_nodes_cpp talker_launch.py. See the video for details.

Launch secure depends on the nodl file; the one used for the demo is available in pastebin.

This is a minimum viable product; composable and lifecycle nodes may be a challenge.

6. Other topics

Ruffin clarified that some DDS implementations support chained CAs which allow for interesting security setups. Using this approach the robot computational graph could be further segmented and segregated.

2020-04-28

Meeting Recording | Announcement (Discourse)

Agenda

Attendees Jacob Hassel, Alexis, Roger Strain, Victor Mayoral Vilches, Ted Kern, Mikael Arguedas, Sid Faber

1. Foxy Status

Current status of items for Foxy, some concerns that sros2 will not be working in Foxy:

2. ros2 launch --secure

Ted is working on adding "secure" launch tag to use NoDL to generate the keystore, create certs and keys for nodes as they are launched. Eventually will also manage individual policies. Launch is complex due to remapping and substitutions; if anyone has experience, consider helping to work through the buildout.

A design doc will be posted to the forum shortly once there's a minimum viable product with an explanation of design decisions to open it for comment.

3. Other topics

Mikael asked for US-timezone help to get SROS2 foxy-ready. He volunteered to steer whoever took on this task but cycles from someone are required.

Request: Generate keystore materials ahead of time and set them up before the robot is actually deployed. The challenge is that the substitution system is only evaluated when the launch node action is visited by the launch service.

Use cases: Víctor requested to consider situations where CAs are not available while the robot is running. He argued that DDS did already allow for multi-CA configurations. One option is to use a Permissions CA and an Identity CA, another is to use different CAs for different parts of the robot.

Out of Víctor suggestion, It was jointly agreed to start putting together a series of reference use cases to steer the development of sros2. It may also be good to revisit CA management within sros2, since it was originally written assuming proper support for a robust keystore.

2020-04-14

Meeting Recording | Announcement (Discourse)

Agenda

Attendees Gianluca Caiazza, Jeremie Deray, Sid Faber, Kyle Fazzari, Jacob H, Ted Kern, Joe McManus, Victor Murray, Victor Mayoral Vilches, Roger Strain, Ruffin White

1. Environment variables update

Details are available in Github sros issue 199.

Variables which used to specify security_root_directory, etc., were path files to the root of the keystore or a folder with the artifacts. This has been changed with the migration of security to enclaves. Also looking to eventually use the security location for more than just a keystore--there may be other runtime security configs that should be in the directory (which is why enclaves are in a subdirectory).

Also the variabel security_override doesn't need the prefix, just the name to be forced for the root or debug enclave, etc. Inspead pass the fully qualified path name.

2. CIS Benchmarks

Canonical will begin working on a ROS security benchmark shortly. The benchmark begins with the Ubuntu 18.04 benchmark and will be relaxed/updated to suite ROS 1. After ROS 1, intend to work on a benchmark for ROS 2. Once the initial template is laid out, this will be shared for community feedback.

The CIS security benchmarks are community accepted best practice standards. Membership is required in order to use the workbench for editing.

See https://www.cisecurity.org/ and https://www.cisecurity.org/benchmark/ubuntu_linux/.

3. MVP for RMW

Pull request 404, security logging plugin for rmw_connext is up for review. This implements a minimum viable project for enabling logging. It allows enabling experimental logging for Foxy (work will continue with the design for next release).

The DDS standard does not give much definition for the primitives necessary used for security logging. This pull request does not define / change logging either, it does not add new functionality but it simply pulls the events out of the existing log and puts them into the security log.

4. Public API for SROS 2

Work is in progress to move the SROS 2 API that was public by default and moving parts of it private in order to curating the public API. Please add comments to the review document to define what should be public and what should not be considered public.

In addition work is in progress on a ros launch extension to automatically generate keys, keystores and securely launch nodes.

2020-03-31

Meeting Recording | Announcement (Discourse)

Agenda

Attendees Joe McManus, Mikael Arguedas, Jeremie Deray, Sid Faber, Kyle Fazzari, Victor Murray, Jacob, Roger Strain, Victor Mayoral Vilches

1. rcl

RCL issue 545 requests that security features be moved out of rcl and into rcutils. Primary motivation was to enable ros2 on systems (e.g., embedded) that don't have a file system or environment variables.

This can be done by moving security features elsewhere, or by better use of the -DENABLE_SECURITY compile option.

2. Logging Plugin

Jeremie reviewed the logging plugin design document for FastRTPS.

The goal is to provide an ability to react to security events; the first step is to get DDS logs to syslog. This implements a new (not required) DDS plugin. There are three main streams of work:

Discussion covered:

Administrative

Victor discussed Alias Robotics work in finding bugs in the widely used UR robot; bugs are not necessarily limited to ROS. This is part of an ongoing campaign to raise awareness of robotics vendors to security.

2020-03-10

Meeting Recording | Announcement (Discourse)

Agenda

Attendees Mikael Arguedas, Michael C, Jeremie Deray, Sid Faber, Kyle Fazzari, Ted Kern, Joe McManus, Victor Mayoral Vilches, Ruffin White

1. Participant Mapping

Discussion on implementation details of context security. Highlights of the pending changes:

Administrative

2020-02-25

Meeting Recording | Announcement (Discourse)

Agenda

Attendees Mikael Arguedas, Jeremie Deray, Sid Faber, Kyle Fazzari, Joe McManus, Ricardo Gonzalez Moreno, Victor Mayoral Vilches, Ruffin White

1. REP-2004

See https://github.com/ros-infrastructure/rep/pull/218. The REP is important to the WG because it ties in to vulnerability response that’s in the draft VDP which provides a deadline to fix vulnerabilities. There's also a good way to view current quality status

General discussion covered how this might change behaviors, whether the proposed categories are too coarse, and whether this drives response times for remediating vulnerabilities.

Continue discussions offline. Make comments over the next few days in the google doc.

2. "security-wg" team

Proposal is to create a ros2/security-wg github team to use as a tag so all relevant security features may be tagged and monitored. Problem is that github does not properly support mentioning teams in the situations we'd like. See @mentioning other teams issue. If we do create a team, it may be that only admins can tag the team.

The WG agreed that this is an improvement over what we have today and recommend creating the team.

3. Participant mapping

Brief discussion covered current status of changes in progress:

4. CS4R

"Cyber Security For Robotics"

Preparing cyber security for robotics workshop next week in Spain. Looking for collaborators, although short notice. Will try to record.

Remainder of the agenda was queued for our next meeting.

2020-02-11

Meeting Recording | Announcement (Discourse)

Agenda

Attendees Mikael Arguedas, Jeremie Deray, Tomoya Fujita, Joe McManus, Kyle Fazzari, Ruffin White. Michael Carroll

1. Switch to one DDS participant per context

https://github.com/ros2/rcl/pull/515 We need to review latest commits Status update on our side [action] Ruffin, Kyle and Mikael will chat offline

2. Default SROS 2 policies

Concept: Enable easy use of debugging tools when security is enabled by using an agreed-upon context name. Might also be a path toward encryption by default.

[action] explore solutions all

3. Package quality and security

How do we integrate security into package quality categories: https://github.com/ros-infrastructure/rep/pull/218

[action] Continue to discuss (on matrix) and aggregate feedback on this document - add CI to security policy, maybe time to patch, this package supports working policy setup, etc

Administrivia

2020-01-28

Meeting Recording | Announcement (Discourse)

Agenda

Attendees Kyle Fazzari (moderator), Mikael Arguedas, Michael Carroll, Jeremie Deray, Sid Faber, Ted Kern, Victor Mayoral, Dragan Stancevic, Ruffin White

1. Vulnerability Disclosure Policy

This discussion consumed the entire meeting. The following decisions were agreed upon:

Sid has an action item to update the policy and continue taking input.

The VDP discussion raised a few unanswered issues, including:

2. Meetings

The last two items on the agenda were not discussed.

Given the current activity and number of items to discuss, the working group agreed to increase meetings to twice monthly, and increase to an hour.

2019-12-11

Meeting Recording | Announcement (Discourse)

Agenda

Attendees Joe McManus, Kyle Fazzari , Dragan Stancevic, Lander Usategui, Jeremy Deray, Mikael Arguedas, Ruffin White

1. Logging plugins

2. Repo Management

As the security emphasis grows with tooling and examples, we should create a repo with security subprojects.

3. NoDL proposal

2019-11-12

Meeting Recording | Announcement (Discourse) | Calendar | Google Group

Agenda

Announcements

Action Items

1. Security Tooling

2. Vulnerability Disclosure Method

2019-09-17

Meeting Recording | Announcement (Discourse) | Chime Link | Calendar | Google Group

Agenda

Announcements

1. roslaunch2 sandboxing

https://github.com/aws-robotics/launch-ros-sandbox/tree/master/examples

[^] Bloom release is planned, release through PIP should be possible but is not scheduled yet.

2. Discussion DDS participants

https://github.com/ros2/design/pull/250 https://discourse.ros.org/t/reconsidering-1-to-1-mapping-of-ros-nodes-to-dds-participants/10062 iRobot Performance analysis:

2019-08-21

Meeting Recording | Announcement (Discourse) | Chime Link | Calendar | Google Group

1. ROS 2 Access Control Policies

ruffsl: PR for access control policies

Feedback

2. ROS 2 Node Sandboxing

Zach (AWS):

The objective is to extend roslaunch with a syntax allowing nodes to be sandboxed using various methods. We are looking at implementing a policy relying on Docker containers as an extension to ROS Launch.

Feedback

2019-08-01

Meeting Recording | Announcement (Discourse) | Chime Link | Calendar | Google Group

1. Generic Node Interface Description

kyrofa: ROS 2 node interface description

Feedback:

DDS-XML spec Example of use for a talker listener

2024-12-28 13:07