Use Contexts #177

ruffsl · 2020-03-15T22:57:11Z

TODO:

Update policy schema with contexts
Update policy transforms for DDS
Update keystore layout with pubic, private, contexts sub folders
Update existing tests and downstream packages

Bonus items

Update auto generation
- would require context aware telemetry from rosgraph API
- disable otherwise if rosgraph API doesn't expose context info
Update documentation
Support for metadata and <profiles> type attribute
- e.g. associating profiles to domains, validity times, singing CA
- may need more thought, could look back at keymint for config patterns

ruffsl · 2020-03-16T04:01:56Z

Ok, I think the basics are working at least:

$ ros2 security generate_artifacts -k keystore -p ~/ws/ros2/src/ros2/sros2/sros2/test/policies/talker_listener.policy.xml 
keystore is not a valid keystore, creating new keystore
creating keystore: keystore
creating new CA key/cert pair
creating governance file: keystore/contexts/governance.xml
creating signed governance file: keystore/contexts/governance.p7s
all done! enjoy your keystore in keystore
cheers!
creating key for identity: '/talker_listener/talker'
creating cert and key
creating permission file for identity: '/talker_listener/talker'
creating key for identity: '/talker_listener/listener'
creating cert and key
creating permission file for identity: '/talker_listener/listener'

$ tree keystore/
keystore/
├── contexts
│   ├── governance.p7s
│   ├── governance.xml
│   └── talker_listener
│       ├── listener
│       │   ├── cert.pem
│       │   ├── governance.p7s -> ../../governance.p7s
│       │   ├── identity_ca.cert.pem -> ../../../public/identity_ca.cert.pem
│       │   ├── key.pem
│       │   ├── permissions.p7s
│       │   ├── permissions.xml
│       │   └── permissions_ca.cert.pem -> ../../../public/permissions_ca.cert.pem
│       └── talker
│           ├── cert.pem
│           ├── governance.p7s -> ../../governance.p7s
│           ├── identity_ca.cert.pem -> ../../../public/identity_ca.cert.pem
│           ├── key.pem
│           ├── permissions.p7s
│           ├── permissions.xml
│           └── permissions_ca.cert.pem -> ../../../public/permissions_ca.cert.pem
├── private
│   ├── ca.key.pem
│   ├── identity_ca.key.pem -> ca.key.pem
│   └── permissions_ca.key.pem -> ca.key.pem
└── public
    ├── ca.cert.pem
    ├── identity_ca.cert.pem -> ca.cert.pem
    └── permissions_ca.cert.pem -> ca.cert.pem

6 directories, 22 files

ping @mikaelarguedas @kyrofa @ivanpauno

ivanpauno

I've left some minimal comments and questions.
I will give this a try and comment again.

Thanks @ruffsl for working on this!

sros2/sros2/api/__init__.py

sros2/sros2/policy/defaults/policy.xml

sros2/test/policies/add_two_ints.policy.xml

ivanpauno

Some of the verbs arguments or arguments' help should be updated.
e.g.:

sros2/sros2/sros2/verb/generate_artifacts.py

Line 37 in 44479cd

'-n', '--node-names', nargs='*', default=[],

or

sros2/sros2/sros2/verb/create_permission.py

Line 36 in 44479cd

parser.add_argument('NAME', help='key name, aka ROS node name')

mikaelarguedas

Great, thanks @ruffsl !

not a full review, didnt test the code just some fly-by comments

sros2/sros2/api/__init__.py

sros2/sros2/policy/defaults/policy.xml

sros2/test/policies/permissions/single_context/permissions.xml

sros2/sros2/policy/schemas/policy.xsd

ivanpauno · 2020-03-16T20:07:03Z

@ruffsl To allow publishing/subscribing to ros_discovery_info topic, I pushed a branch with two commits:

The first commit adds a global parameter in the permissions dds template, to add or not that ALLOW rule.
The second commit, sets the parameter to true if the detected rmw implementation is fastrtps based. It uses rclpy get_rmw_implementation_identifier function if available, if not checks the RMW_IMPLEMENTATION environment variable (which can be set in environments without ROS2 installed).

I didn't open a PR to avoid adding extra noise and just in case you want to implement this differently. The first commit can probably be taken as-is. The second one, you maybe want to add something more explicit to the verbs arguments.

Update existing tests and downstream packages

I have already updated system_tests/test_security based on changes here and in rcl.

would require context aware telemetry from rosgraph API

I have already added this to fastrtps, and connext rmw implementations. I have to add something similar in cyclonedds (though they don't support security yet, just for completion), and implement the function in rcl, rclpy. It would be great to complete this in a follow-up though, to limit a bit the size of the changes.

ivanpauno · 2020-03-18T14:53:22Z

@ruffsl Friendly ping. It would be great to wrap up this for the beginning of next week (e.g. Wednesday), considering that Foxy deadline is close.

I can help with some of the remaining tasks if you don't have time to handle them (e.g.: updating the tests). Let me know if I can help with anything.

sros2/sros2/api/__init__.py

ruffsl · 2020-03-18T18:07:58Z

sros2/sros2/policy/templates/dds/permissions.xsl

+                    </topics>
+                  </subscribe>
+                </allow_rule>
+              </xsl:if>


Lets hope we don't have to keep this fully connected data flow rule forever.

Yes. I think that in a near future (two/three months), all the rmw implementation will be migrated.

I believe what @ruffsl mean is that hopefully this will be done out of band and not require a fully connected rule on this topic.

Oh, I see. I think it's definitely possible.
It would be great to finish discussing this alternative in the design document, before the other migrations are done.
Of course, we can first migrate all to use the ros_discovery_info topic, and then change them again to use Participant userData.

ruffsl · 2020-03-18T18:15:44Z

Hey @ivanpauno @mikaelarguedas , I had a moment to push some commits to address things.

The first commit can probably be taken as-is. The second one, you maybe want to add something more explicit to the verbs arguments.

I've cherry picked them into the PR. You're suggesting adding a verb to control this? If its already reading from the env, we may not need to clutter the CLI with a subsumption layer of settings.

It would be great to complete this in a follow-up though, to limit a bit the size of the changes.

Sounds fine.

I can help with some of the remaining tasks if you don't have time to handle them (e.g.: updating the tests). Let me know if I can help with anything.

Thanks! Could you wrap up this PR with the tests and any hanging review comments. I can't immediately think of a pythonic pattern to do the file/dir/symlink checks for the keystore, and I've got another deadline for my lab this week.

ivanpauno · 2020-03-18T21:15:15Z

sros2/sros2/verb/create_key.py

@@ -26,10 +26,15 @@ class CreateKeyVerb(VerbExtension):
    """Create key."""

    def add_arguments(self, parser, cli_name):
-        arg = parser.add_argument('ROOT', help='root path of keystore')
+        arg = parser.add_argument(
+            '-k', '--keystore-root-path',


To avoid a hard API break, 'ROOT' can be maintained too.
It could be also detected if it was used and print a deprecation warning if later is going to be removed.

P.S.: People will have to read about changes in sros2 for Foxy, so maybe it's not too bad to break this too.

People will have to read about changes in sros2 for Foxy, so maybe it's not too bad to break this too.

Yeah, I wanted to use this as an opportunity to make the CLI more consistent. The mix use of positional and keyed command arguments was really annoying in terms if UI.

👍 I was considering doing this before Foxy as well, currently only newly introduced verbs like generate_artifacts have keyed arguments. For clarity it would be better to have them in a separate PR. If we keep it in this one, can we make this in an independent commit (similar to file renaming commits) ?

I will consolidate things in different commits before merging.

sros2/sros2/verb/create_key.py

sros2/sros2/verb/generate_artifacts.py

ivanpauno · 2020-03-18T21:28:37Z

Thanks! Could you wrap up this PR with the tests and any hanging review comments. I can't immediately think of a pythonic pattern to do the file/dir/symlink checks for the keystore, and I've got another deadline for my lab this week.

Yes, I will follow up with this tomorrow. Thanks for your prompt answer!!

mikaelarguedas

thanks @ruffsl for the iteration!
added a couple inline questions to be able to review the following developments

sros2/sros2/policy/schemas/policy.xsd

mikaelarguedas · 2020-03-19T09:58:25Z

sros2/sros2/api/__init__.py

@@ -198,17 +242,21 @@ def is_key_name_valid(name):
    try:
        return (validate_namespace(node_ns) and validate_node_name(node_name))


is this still relevant ?
Seems like key names will now be de correlated from the concept of node name or node namespace

I've created a function in rcl: rcl_validate_security_context_name.
It does pretty much the same that rmw_validate_namespace.

I will use the later, until I propagate the rcl function to rclpy.

mikaelarguedas · 2020-03-19T10:01:22Z

sros2/sros2/api/__init__.py

    dest_governance_path = os.path.join(key_dir, 'governance.p7s')
-    shutil.copyfile(keystore_governance_path, dest_governance_path)
+    relativepath = os.path.relpath(keystore_governance_path, key_dir)
+    os.symlink(src=relativepath, dst=dest_governance_path)


What happens in the destination file already exists?

If the file already exists, it will raise a FileExistsError.
Should the old file be deleted and overridden?

We could use a logic similar to the above one above:

if it exists and is the same, do nothing

if it exists and is different -> delete + override it (this part is not above but I believe would be nicer behavior)

Addressed in f5080e8.

Instead of delete + override, I'm raising an error in that last case.
I'm afraid to delete something a distracted user didn't want.

They can cleanup manually and rerun if they really wanted to delete the file.

Maybe it's my workflow but I find it convenient to change a couple rules in a policy file and just rerun generate_artifacts on my entire policy file and trust the tool to override the changed permission files accordingly. It looks like with this more conservative approach I would need to go prune by hand all the directories that may have a permission change.

I'd prefer not changing the previous behavior, but either way it would be good to provide an option to opt-in (or out) of overwriting existing files

In my prior work with keymint, I treated auto generated security files as build artifacts, and thus subsequent build file could be modified at will by the build tool, where the user would recognize the temporal nature of these files if they instructed the build tool to rebuild changed source files. So I'd say let the tool overwrite it the generated files by default.

In keymint, I also separated the pipeline into a src. build, and install folder structure, so we may want to explore using similar workflows that could separate the policy source files, from the generated intermediate representations built, to the final signed security artifacts installed. Keymint had a --dry-run flag that the CLI could check to see if it should warn about detected file diffs and not write to disk.

Done in d523332.

sros2/sros2/policy/templates/dds/permissions.xsl

ivanpauno · 2020-03-19T21:19:33Z

I've addressed comments and made tests pass.
Though I will do some more updates tomorrow, this is ready to be reviewed again.

ruffsl · 2020-03-19T22:21:51Z

sros2/sros2/api/__init__.py

+        raise FileNotFoundError(errno.ENOENT, os.strerror(errno.ENOENT), keystore_path)
+    if not os.path.exists(contexts_path):
+        return True
+    for name in os.listdir(contexts_path):


Context paths can be nested. Is listdir recursive?
I.e. will it walk over contexts that aren't just flat in the root of the context sub folder?

👍 to that.

To be fair it was already the case before this change so doesn't have to be addressed here. Should be ticketed though if not addressed

To be fair it was already the case before this change so doesn't have to be addressed here. Should be ticketed though if not addressed

Agreed.
What should be the output of:

-> contexts -> context1 -> security artifacts ... -> nested1 -> security artifacts ... ->context2 ->nested2 ->security artifacts...

?

IMO, it should be:

/context1 /context1/nested1 /context2/nested2

If the contexts folder have valid security artifacts, / should be showed too.

Sounds good to me

mikaelarguedas

thanks @ivanpauno for the follow-up. I did another pass below

mikaelarguedas · 2020-03-20T09:08:31Z

sros2/sros2/api/__init__.py

    dest_governance_path = os.path.join(key_dir, 'governance.p7s')
-    shutil.copyfile(keystore_governance_path, dest_governance_path)
+    relativepath = os.path.relpath(keystore_governance_path, key_dir)
+    os.symlink(src=relativepath, dst=dest_governance_path)


We could use a logic similar to the above one above:

if it exists and is the same, do nothing

if it exists and is different -> delete + override it (this part is not above but I believe would be nicer behavior)

sros2/sros2/api/__init__.py

sros2/sros2/policy/templates/dds/permissions.xsl

sros2/sros2/verb/create_key.py

sros2/sros2/verb/create_permission.py

sros2/sros2/verb/generate_artifacts.py

sros2/sros2/verb/create_permission.py

ros-discourse · 2020-03-20T20:41:00Z

This pull request has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/ros-2-tsc-meeting-minutes-2020-03-18/13313/1

ivanpauno · 2020-03-24T18:36:59Z

@ruffsl @mikaelarguedas
I'm planning to do the following items in a follow-up:

Update auto generation
Update documentation
Use Contexts #177 (comment)

Something else missing to get this approved?

ruffsl · 2020-03-24T21:30:31Z

I was only wondering about that last unresolved comment you linked. If you'd like to follow up that with a septate PR, that's fine. This repo is set so authors of PR can't approve the same PR, but this all LGTM!

kyrofa

Couple high-level comments from me. This mostly looks good, although @mikaelarguedas is clearly more up-to-date on the design than I am. In the future, I'd prefer to see unrelated changes like the CLI bits in another PR. This one was big.

kyrofa · 2020-03-25T16:43:44Z

sros2/setup.py

@@ -66,7 +66,9 @@ def package_files(directory):
            ':CreatePermissionVerb',
            'distribute_key = sros2.verb.distribute_key:DistributeKeyVerb',
            'generate_artifacts = sros2.verb.generate_artifacts:GenerateArtifactsVerb',
-            'generate_policy = sros2.verb.generate_policy:GeneratePolicyVerb',
+            # TODO(ivanpauno): Reactivate this after having a way to instronspect
+            # security context names in rclpy


Do we have an issue in rclpy that we can use for tracking this?

+1, TODOs in code usually don't get revisited if there isn't an associated ticket (same for other TODOs below)

Spelling: instronspect -> introspect

See #182, ros2/rclpy#528, ros2/rclpy#529, #183.

Can we add a reference to ros2/rclpy#529 in this comment, please?

sros2/sros2/api/__init__.py

kyrofa · 2020-03-31T18:52:31Z

sros2/test/sros2/commands/security/verbs/test_create_key.py

+def security_context_keys_dir(tmpdir_factory):
+    keystore_dir = Path(str(tmpdir_factory.mktemp('keystore')))


Has pytest been updated enough we can use tmp_path_factory here now? Would save you a little work. See #145 for reference.

Sure, but I think we can left that for a follow-up, because I'm not sure which pytest version we're using in the different platforms.

sros2_cmake/package.xml

kyrofa · 2020-03-31T19:36:58Z

Alright this looks good to me now. What are we going to do about the failing tests, though? Can we ignore Focal for now in order to get this in before the freeze? @ivanpauno let us know what you learn about Windows.

ivanpauno · 2020-03-31T20:52:30Z

Alright this looks good to me now. What are we going to do about the failing tests, though? Can we ignore Focal for now in order to get this in before the freeze? @ivanpauno let us know what you learn about Windows.

Yes, I think it's safe to ignore the tests that are failing in the nightlies.
Of course, there's a chance that I'm introducing a regression without realizing, but the chances are small if it's working ok in the other platforms.

ruffsl · 2020-03-31T21:56:06Z

#177 (comment)

@ivanpauno if you revert/re-sign my commits here, could you move those reverted CLI commits to a new PR? I'd really prefer to remove any positional arguments in SROS from foxy before the API freeze. I think the PR only looks big because of the static xml files generated to test/track the xsd templates.

mikaelarguedas · 2020-04-01T09:16:23Z

I think the PR only looks big because of the static xml files generated to test/track the xsd templates.

The motivation for reverting it was not because of the size but the change but their nature. There were doubts on the relevance of making all these non-positional (discussion on matrix). Especially as as-is they were made optional. Currently generate_artifacts is using keyed optional args because they truly are all optional. While the ones like create_keystore do need mandatory arguments and making them keyed doesn't serve much purpose while lengthening user invocation.

So in the end a more complete discussion need to be had and evaluate what UX we are trying to accomplish here. Discussion can happen on such PR though.

mikaelarguedas · 2020-04-01T12:33:42Z

Most of them are happening in master too, to be clearer:

Thanks @ivanpauno for the summary.
Figuring out the windows ones would be good indeed: there seem to be some fastrtps failures as well https://ci.ros2.org/job/ci_windows/9674/testReport/junit/(root)/projectroot/test_security_nodes_c__rmw_fastrtps_cpp_2/

Is there a way for maintainers here want to be notified for sros2/test_security failing jobs? I see some of those have been failing for a long time but we weren't aware of it.

ivanpauno · 2020-04-01T12:42:02Z

Alright this looks good to me now. What are we going to do about the failing tests, though? Can we ignore Focal for now in order to get this in before the freeze?

I will ignore all existing failures on nightlies. Unfortunately, there's a minimal chance I introduce a regression by doing this.

@ivanpauno if you revert/re-sign my commits here, could you move those reverted CLI commits to a new PR? I'd really prefer to remove any positional arguments in SROS from foxy before the API freeze. I think the PR only looks big because of the static xml files generated to test/track the xsd templates.

https://github.com/ros2/sros2/tree/contexts-backup has the original commits of the PR.

@ivanpauno let us know what you learn about Windows.

That's the last failure I see in my jobs I that's not on the nightlies.
If I'm lucky, I will find the reason today.

Is there a way for maintainers here want to be notified for sros2/test_security failing jobs? I see some of those have been failing for a long time but we weren't aware of it.

IDK. @ros2/team for feedback.

jacobperron · 2020-04-01T16:38:07Z

Is there a way for maintainers here want to be notified for sros2/test_security failing jobs? I see some of those have been failing for a long time but we weren't aware of it.

I think at least the ROS 2 buildfarmer should open issues for failures (e.g. on sros2) and consider tagging @ros-security-wg if the issue is in a different repository.

ivanpauno · 2020-04-01T19:42:21Z

Figuring out the windows ones would be good indeed: there seem to be some fastrtps failures as well https://ci.ros2.org/job/ci_windows/9674/testReport/junit/(root)/projectroot/test_security_nodes_c__rmw_fastrtps_cpp_2/

The windows failures of security tests were those, and the same test was failing with connext. Fixed them in ros2/system_tests@1d93d97.

I will re-run CI today by end of day. If everything looks good tomorrow, I will merge.

mikaelarguedas

lgtm, a bionic CI on aarch64 would be good to confirm this doesnt break anything on that platform

ivanpauno · 2020-04-02T13:48:06Z

lgtm, a bionic CI on aarch64 would be good to confirm this doesn't break anything on that platform

Done. We're not supporting bionic for Foxy, but running it will add extra confidence in that sros2 wasn't broken.

These are the last jobs I ran ros2/rmw_fastrtps#312 (comment) (only with unrelated failures), and I have to wait to these two before merging ros2/rmw_fastrtps#312 (comment).

Hopefully, I will be merging today.

hidmic

Not much to add, LGTM too.

sros2/sros2/api/__init__.py

hidmic · 2020-04-02T13:55:24Z

sros2/test/policies/permissions/add_two_ints/permissions.xml

+      <subject_name>CN=/add_two_ints/add_two_ints_server</subject_name>
+      <validity>
+        <not_before>2013-10-26T00:00:00</not_before>
+        <not_after>2023-10-26T22:45:30</not_after>


@ruffsl @ivanpauno meta: is this supposed to span the foreseeable lifetime of Foxy? Won't this bite us in 3 years time? Same elsewhere.

this is something I'm planning to address separately as unrelated to this PR.

This should be using the time of generation as the start date similarly to how it's done for the certificates. I'll open an issue to make sure it doesnt slip off.
Hackier way to address this is to just change the hardcoded value to start in 2020 which will give us a lot of time to implement it more properly ^^

Edit: opened ticket at #186

I'd rather address #186 instead of pushing the expiration date (and then forgetting about it). Thanks for the explanation @mikaelarguedas!

Me too. Happy to review any PR addressing #186, timing before feature freeze is pretty tight so if it falls on my plate I'll most likely just push the date back

Signed-off-by: Ivan Santiago Paunovic <[email protected]>

codecov-io · 2020-04-02T14:30:50Z

Codecov Report

❗ No coverage uploaded for pull request base (master@547e2c2). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #177   +/-   ##
=========================================
  Coverage          ?   61.57%           
=========================================
  Files             ?       18           
  Lines             ?      838           
  Branches          ?       64           
=========================================
  Hits              ?      516           
  Misses            ?      308           
  Partials          ?       14

Flag	Coverage Δ
#unittests	`61.57% <0.00%> (?)`

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 547e2c2...61fb895. Read the comment docs.

ruffsl force-pushed the contexts branch 2 times, most recently from 63b6fcb to 0b873ad Compare March 16, 2020 03:56

ivanpauno reviewed Mar 16, 2020

View reviewed changes

mikaelarguedas reviewed Mar 16, 2020

View reviewed changes

ruffsl force-pushed the contexts branch 2 times, most recently from 6720468 to a2397e6 Compare March 18, 2020 17:51

ruffsl commented Mar 18, 2020

View reviewed changes

sros2/sros2/api/__init__.py Show resolved Hide resolved

ruffsl commented Mar 18, 2020

View reviewed changes

ivanpauno reviewed Mar 18, 2020

View reviewed changes

mikaelarguedas reviewed Mar 19, 2020

View reviewed changes

ivanpauno requested review from kyrofa, mikaelarguedas and hidmic March 19, 2020 21:19

ivanpauno self-assigned this Mar 19, 2020

ivanpauno mentioned this pull request Mar 19, 2020

Switch to one Participant per Context ros2/rmw_fastrtps#312

Merged

ruffsl commented Mar 19, 2020

View reviewed changes

mikaelarguedas requested changes Mar 20, 2020

View reviewed changes

mikaelarguedas reviewed Mar 20, 2020

View reviewed changes

sros2/sros2/verb/create_permission.py Outdated Show resolved Hide resolved

ivanpauno marked this pull request as ready for review March 23, 2020 13:34

kyrofa reviewed Mar 25, 2020

View reviewed changes

kyrofa reviewed Mar 31, 2020

View reviewed changes

sros2_cmake/package.xml Outdated Show resolved Hide resolved

ivanpauno force-pushed the contexts branch from c0a1c46 to 468d316 Compare March 31, 2020 19:29

mikaelarguedas previously approved these changes Apr 2, 2020

View reviewed changes

hidmic previously approved these changes Apr 2, 2020

View reviewed changes

ivanpauno added 2 commits April 2, 2020 11:14

Use security contexts

3073744

Signed-off-by: Ivan Santiago Paunovic <[email protected]>

Update sros2_cmake to use security contexts

61fb895

Signed-off-by: Ivan Santiago Paunovic <[email protected]>

ivanpauno dismissed stale reviews from hidmic and mikaelarguedas via 61fb895 April 2, 2020 14:15

ivanpauno force-pushed the contexts branch from 468d316 to 61fb895 Compare April 2, 2020 14:15

ivanpauno requested review from mikaelarguedas and hidmic April 2, 2020 14:17

hidmic approved these changes Apr 2, 2020

View reviewed changes

kyrofa approved these changes Apr 2, 2020

View reviewed changes

ivanpauno merged commit 521b0cb into master Apr 3, 2020

delete-merged-branch bot deleted the contexts branch April 3, 2020 13:15

artivis mentioned this pull request Apr 3, 2020

Update documentation #187

Closed

ruffsl mentioned this pull request May 1, 2020

Update generate_policy verb for enclaves #203

Merged

mikaelarguedas mentioned this pull request May 2, 2020

reenable test_generate_policy_no_policy_file #206

Merged

mikaelarguedas mentioned this pull request Jun 5, 2020

Eloquent backports #222

Merged

		@@ -198,17 +242,21 @@ def is_key_name_valid(name):
		try:
		return (validate_namespace(node_ns) and validate_node_name(node_name))

		def security_context_keys_dir(tmpdir_factory):
		keystore_dir = Path(str(tmpdir_factory.mktemp('keystore')))

Use Contexts #177

Use Contexts #177

Conversation

ruffsl commented Mar 15, 2020 • edited by ivanpauno Loading

TODO:

Bonus items

ruffsl commented Mar 16, 2020

ivanpauno left a comment

Choose a reason for hiding this comment

ivanpauno left a comment

Choose a reason for hiding this comment

mikaelarguedas left a comment • edited Loading

Choose a reason for hiding this comment

ivanpauno commented Mar 16, 2020

ivanpauno commented Mar 18, 2020 • edited Loading

Choose a reason for hiding this comment

ivanpauno Mar 18, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ruffsl commented Mar 18, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ivanpauno commented Mar 18, 2020

mikaelarguedas left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ivanpauno Mar 19, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ivanpauno Mar 20, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ivanpauno commented Mar 19, 2020

ruffsl Mar 19, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mikaelarguedas left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ros-discourse commented Mar 20, 2020

ivanpauno commented Mar 24, 2020

ruffsl commented Mar 24, 2020 • edited Loading

kyrofa left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kyrofa Mar 31, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kyrofa commented Mar 31, 2020 • edited Loading

ivanpauno commented Mar 31, 2020

ruffsl commented Mar 31, 2020

mikaelarguedas commented Apr 1, 2020

mikaelarguedas commented Apr 1, 2020

ivanpauno commented Apr 1, 2020

jacobperron commented Apr 1, 2020

ivanpauno commented Apr 1, 2020

mikaelarguedas left a comment

Choose a reason for hiding this comment

ivanpauno commented Apr 2, 2020

hidmic left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mikaelarguedas Apr 2, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

codecov-io commented Apr 2, 2020

Codecov Report

ruffsl commented Mar 15, 2020 •

edited by ivanpauno

Loading

mikaelarguedas left a comment •

edited

Loading

ivanpauno commented Mar 18, 2020 •

edited

Loading

ivanpauno Mar 18, 2020 •

edited

Loading

ivanpauno Mar 19, 2020 •

edited

Loading

ivanpauno Mar 20, 2020 •

edited

Loading

ruffsl Mar 19, 2020 •

edited

Loading

ruffsl commented Mar 24, 2020 •

edited

Loading

kyrofa left a comment •

edited

Loading

kyrofa Mar 31, 2020 •

edited

Loading

kyrofa commented Mar 31, 2020 •

edited

Loading

mikaelarguedas Apr 2, 2020 •

edited

Loading