Closed Arnatious closed 3 years ago
Thanks @Arnatious, nice to have a use-case driving our API. As we have discussed in the API proposal, I think it's time to move away from the "key" terminology, toward either "enclaves" or "identities". I favor the latter, but I'm not sure how far this terminology change should leak. @mikaelarguedas should we still be using the "keystore" term if we want to change create_key
, for example?
As we have discussed in the API proposal, I think it's time to move away from the "key" terminology, toward either "enclaves" or "identities".
To keep user-facing terminology narrow I'm leaning towards enclaves
that is used in the CLI and RCL. Side note: The renaming should likely be applied consistently to all verbs regardless of which API is made public
should we still be using the "keystore"
As we renamed the env variables from ROS_SECURITY_ROOT_DIRECTORY
to ROS_SECURITY_KEYSTORE
I think we converged towards that term even if it contains more than keys. So keeping it as is sounds fine.
@mikaelarguedas alright, I've updated the API proposal, take a pass when you can.
I've updated the API proposal, take a pass when you can.
Sorry I didnt get around reviewing this yet. It'll be another couple of days before I can look at it
It's alright, #241 is up and ready as well if that's easier.
Feature request
Feature description
The current sros2 api is entirely private.
Currently, the following functions are used in the implementation of secure launch
sros2.api._keystore
create_keystore()
is_valid_keystore()
sros2.api._key
create_key()
Exposing a public api for these would be appreciated.