-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow external ownership of CHIPDeviceController operational key #18482
Allow external ownership of CHIPDeviceController operational key #18482
Conversation
- For controllers that make use of their own key management, such as OS-aided key management, it is currently impossible to pass-in the Operational Key pair to use for a given controller. This PR adds APIs to avoid FabricTable from trying to manage the lifecycle of the operational key, and allow the caller/initializer of CHIPDeviceControllerFactory to properly inject its own operational key that it manages, without attempts of storage or dynamic memory management. Issue project-chip#18444 Issue project-chip#7695 Testing done: - Unit tests still pass, cert tests as well - This was tested internally by us using the APIs to manage a key for Android. That change will be a follow-up
PR #18482: Size comparison from ed43d59 to b0b50df Increases above 0.2%:
Increases (37 builds for cc13x2_26x2, cyw30739, efr32, esp32, k32w, linux, mbed, nrfconnect, p6, telink)
Decreases (5 builds for cc13x2_26x2)
Full report (37 builds for cc13x2_26x2, cyw30739, efr32, esp32, k32w, linux, mbed, nrfconnect, p6, telink)
|
Co-authored-by: Boris Zbarsky <[email protected]>
PR #18482: Size comparison from ed43d59 to 585f422 Increases above 0.2%:
Increases (36 builds for cc13x2_26x2, cyw30739, efr32, esp32, k32w, linux, nrfconnect, p6, telink)
Decreases (5 builds for cc13x2_26x2)
Full report (37 builds for cc13x2_26x2, cyw30739, efr32, esp32, k32w, linux, mbed, nrfconnect, p6, telink)
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still need to fix GetOperationalKey
to not allocate mOperationalKey
if it's null and mHasExternallyOwnedOperationalKey
, right? Or are we OK with that just allocating a bogus key that will fail further down the line (which I think I am)?
PR #18482: Size comparison from ed43d59 to 3920bea Increases above 0.2%:
Increases (34 builds for cc13x2_26x2, cyw30739, efr32, k32w, linux, nrfconnect, p6, telink)
Decreases (7 builds for cc13x2_26x2, esp32)
Full report (37 builds for cc13x2_26x2, cyw30739, efr32, esp32, k32w, linux, mbed, nrfconnect, p6, telink)
|
Problem
such as OS-aided key management, it is currently impossible
to pass-in the Operational Key pair to use for a given controller.
Issue #18444
Issue #7695
Change overview
This PR adds APIs to avoid FabricTable from trying to manage
the lifecycle of the operational key, and allow the caller/initializer
of CHIPDeviceControllerFactory to properly inject its own operational
key that it manages, without attempts of storage or dynamic memory
management.
Testing
manage a key for Android. That change will be a follow-up