Migrate device provisioning client #640
Conversation
WalkthroughThe changes involve updates to the Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant GitHub Actions
participant Docker
participant Device Provisioning Service
User->>GitHub Actions: Trigger workflow
GitHub Actions->>Docker: Build image
Docker-->>GitHub Actions: Image built
GitHub Actions->>Device Provisioning Service: Run tests
Device Provisioning Service-->>GitHub Actions: Test results
GitHub Actions-->>User: Workflow completed
Possibly related PRs
Suggested labels
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
|
🎉 Thank you for your code contribution! To guarantee the change/addition is conformant to the OCF Specification, we would like to ask you to execute OCF Conformance Testing of your change ☝️ when your work is ready to be reviewed. ℹ️ To verify your latest change (2b4f284), label this PR with |
Danielius1922
force-pushed
the
adam/feature/dps
branch
from
2b4f284
to
360d6a3
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (4)
- .github/workflows/android.yml (1 hunks)
- .github/workflows/build.yml (1 hunks)
- .github/workflows/plgd-device-tests.yml (1 hunks)
- .github/workflows/plgd-hub-tests.yml (1 hunks)
Files skipped from review due to trivial changes (3)
- .github/workflows/android.yml
- .github/workflows/build.yml
- .github/workflows/plgd-hub-tests.yml
Additional comments not posted (1)
.github/workflows/plgd-device-tests.yml (1)
14-17: Confirmed: Disabled automatic workflow triggers.The
pushandpull_requesttriggers for themasterbranch are correctly commented out, aligning with the PR objective to disable automatic execution.The code changes are approved.
There was a problem hiding this comment.
Actionable comments posted: 0
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (6)
- .github/workflows/android.yml (1 hunks)
- .github/workflows/build.yml (1 hunks)
- .github/workflows/docker-build-publish.yml (1 hunks)
- .github/workflows/plgd-device-tests.yml (1 hunks)
- .github/workflows/plgd-hub-tests.yml (1 hunks)
- .github/workflows/sonar-cloud-analysis.yml (1 hunks)
Files skipped from review due to trivial changes (2)
- .github/workflows/docker-build-publish.yml
- .github/workflows/sonar-cloud-analysis.yml
Files skipped from review as they are similar to previous changes (4)
- .github/workflows/android.yml
- .github/workflows/build.yml
- .github/workflows/plgd-device-tests.yml
- .github/workflows/plgd-hub-tests.yml
There was a problem hiding this comment.
Actionable comments posted: 2
Outside diff range, codebase verification and nitpick comments (11)
api/plgd/device-provisioning-client/plgd_dps_log.c (1)
51-72: LGTM, but consider using a larger buffer for the timestamp.The
dps_log_default_fnfunction properly formats and prints the log message to stdout. However, the fixed-size buffer used to store the timestamp may not be sufficient in some cases.Consider using a larger buffer or dynamically allocating the buffer for the timestamp to avoid potential buffer overflow issues.
api/plgd/device-provisioning-client/plgd_dps_endpoint_internal.h (1)
1-115: LGTM! The code follows best practices.The code is well-structured, follows a consistent naming convention, and is well-documented. The header file doesn't contain any implementation details, which is a good practice.
Consider the following minor improvements:
- The header file can be split into smaller, more focused headers if it grows too large.
- The
dps_endpoint_log_stringfunction can be marked asOC_NO_DISCARD_RETURNto encourage callers to check the return value.- The
dps_endpoint_add_peerfunction can be marked asOC_NO_DISCARD_RETURNto encourage callers to check the return value.api/plgd/device-provisioning-client/plgd_dps_tag.c (1)
26-30: Simplify thedps_has_tagfunction.The function can be simplified by directly comparing the strings instead of comparing the lengths first.
Apply this diff to simplify the function:
-return oc_string_len(value) == taglen && (strcmp(oc_string(value), tag) == 0); +return strcmp(oc_string(value), tag) == 0;api/plgd/device-provisioning-client/plgd_dps_pki_internal.h (2)
34-34: Add a comment explaining the purpose of thePLGD_DPS_CREDS_URImacro.Consider adding a brief comment to explain what this URI is used for.
+/// @brief URI for retrieving device provisioning credentials from the DPS service. #define PLGD_DPS_CREDS_URI "/api/v1/provisioning/credentials"
59-63: Consider adding a comment to explain the purpose of thedps_pki_configuration_tstruct.A brief comment explaining what this struct is used for would improve the code's readability.
+/// @brief Configuration for PKI certificate management. typedef struct dps_pki_configuration_t { uint16_t expiring_limit; ///< interval in seconds within which a certificate ///< is considered as expiring } dps_pki_configuration_t;.github/workflows/cmake-linux.yml (1)
66-66: Impact of DisablingPLGD_DEV_TIME_ENABLEDDisabling the
PLGD_DEV_TIME_ENABLEDflag will exclude certain compile-time features and source files related to theplgdfeature from the build. Additionally, ensure thatPLGD_DEV_DEVICE_PROVISIONING_ENABLEDis not set whenPLGD_DEV_TIME_ENABLEDis disabled, as this will trigger a fatal error and potentially break the build process.
- CMakeLists.txt: Ensure
PLGD_DEV_DEVICE_PROVISIONING_ENABLEDis not set withoutPLGD_DEV_TIME_ENABLED.Analysis chain
LGTM!
The code changes are approved.
Please verify the impact of disabling the development time feature (
-DPLGD_DEV_TIME_ENABLED=OFF) on the build process and the system. Ensure that disabling this feature does not introduce any unintended consequences or break any functionality.Run the following script to verify the impact:
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the impact of disabling the development time feature. # Test: Search for the usage of the PLGD_DEV_TIME_ENABLED flag. Expect: Relevant code segments. rg --type cmake -A 5 $'PLGD_DEV_TIME_ENABLED' # Test: Search for the usage of the development time feature in the codebase. Expect: Relevant code segments. ast-grep --lang c++ --pattern $'if ($$$) { $$$ plgd_dev_time_$$$ $$$ }'Length of output: 1705
api/plgd/device-provisioning-client/plgd_dps_manager.c (2)
98-132: Consider refactoring the function to improve readability.The function is quite long and can be refactored to improve readability. Consider breaking it down into smaller functions that handle specific tasks.
134-187: Consider refactoring the function to improve readability.The function is quite long and can be refactored to improve readability. Consider breaking it down into smaller functions that handle specific tasks.
api/plgd/device-provisioning-client/plgd_dps.c (2)
63-124: Consider improving thedps_handle_endpoint_eventfunction.The function handles endpoint events effectively, but there are a couple of areas that could be enhanced:
- The function is quite lengthy. Consider extracting some of the logic into separate functions to improve readability and maintainability.
- The
#if DPS_DBG_IS_ENABLEDblock at lines 68-75 seems unnecessary since theep_strvariable is only used within that block. Consider removing it.
169-186: Consider enhancing error handling inplgd_dps_init.The function initializes the DPS contexts for each device correctly. However, there are a couple of areas where error handling could be improved:
- When memory allocation fails for any context, the function returns -1. Consider using a more specific error code or logging additional details about the failure to aid in debugging.
- If loading DPS data from storage fails for a context, the function silently continues. It would be helpful to log a warning or error message in such cases to indicate the failure.
api/plgd/device-provisioning-client/plgd_dps_resource.c (1)
93-151: Function looks good, but consider using a switch statement.The function correctly handles all the possible status codes and returns the corresponding string.
Consider simplifying the function by using a switch statement instead of multiple if statements. For example:
const char * dps_status_to_str(uint32_t status) { switch (status) { case PLGD_DPS_FAILURE: return kPlgdDpsStatusFailure; case PLGD_DPS_TRANSIENT_FAILURE: return kPlgdDpsStatusTransientFailure; case 0: return kPlgdDpsStatusUninitialized; case PLGD_DPS_INITIALIZED: return kPlgdDpsStatusInitialized; case PLGD_DPS_INITIALIZED | PLGD_DPS_GET_TIME: return kPlgdDpsStatusGetTime; // ... handle other cases ... default: return NULL; } }
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (45)
- .github/workflows/cmake-linux.yml (1 hunks)
- CMakeLists.txt (7 hunks)
- api/plgd/device-provisioning-client/plgd_dps.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_apis.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_apis_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_cloud.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_cloud_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_context.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_context_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_dhcp.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_dhcp_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_endpoint.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_endpoint_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_endpoints.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_endpoints_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_log.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_log_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_manager.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_manager_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_pki.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_pki_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision_cloud.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision_cloud_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision_owner.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision_owner_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_resource.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_resource_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_retry.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_retry_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_security.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_security_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_store.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_store_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_tag.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_tag_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_time.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_time_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_verify_certificate.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_verify_certificate_internal.h (1 hunks)
- api/plgd/plgd.cmake (1 hunks)
- include/plgd/plgd_dps.h (1 hunks)
- tools/utils.cmake (1 hunks)
Files skipped from review due to trivial changes (1)
- api/plgd/plgd.cmake
Additional comments not posted (229)
api/plgd/device-provisioning-client/plgd_dps_provision_owner_internal.h (7)
1-17: LGTM!The Apache 2.0 license header looks good.
19-20: LGTM!The header guards are correctly defined.
Also applies to: 59-59
22-25: LGTM!The included headers are relevant and necessary.
Also applies to: 27-27
33-33: LGTM!The macro definition is appropriate.
35-45: LGTM!The function declaration looks good with appropriate argument and return types, non-null annotation, and useful documentation.
47-53: LGTM!The debug function declaration looks good with appropriate argument type and useful documentation. It is correctly guarded by the debug macro.
29-31: LGTM!The
extern "C"block is correctly used to ensure C linkage.Also applies to: 55-57
api/plgd/device-provisioning-client/plgd_dps_time_internal.h (6)
1-17: LGTM!The Apache License, Version 2.0 is correctly provided at the beginning of the file.
19-20: LGTM!The header guards and includes are correctly provided.
Also applies to: 22-27, 78-78
41-41: LGTM!The macro
PLGD_DPS_TIME_URIis correctly defined.
49-49: LGTM!The function
dps_has_plgd_timeis correctly declared.
61-61: LGTM!The function
dps_get_plgd_timeis correctly declared.
72-72: LGTM!The function
dps_timeis correctly declared.api/plgd/device-provisioning-client/plgd_dps_tag_internal.h (1)
1-84: LGTM!The code changes are approved.
The new header file follows standard practices and conventions:
- The license header is present and correctly formatted.
- The include guards are correctly defined.
- The
extern "C"block is correctly used.- The macros are correctly defined.
- The function declarations follow the C naming convention and use appropriate parameter types.
- The code is well-formatted and follows a consistent style.
api/plgd/device-provisioning-client/plgd_dps_manager_internal.h (1)
1-76: LGTM!The new header file follows best practices and is well-structured. The code changes are approved.
api/plgd/device-provisioning-client/plgd_dps_resource_internal.h (1)
1-89: LGTM!The code changes in this new header file are approved for the following reasons:
- The header file is well-structured and follows best practices for C header files.
- The code is properly guarded with include guards to prevent multiple inclusions.
- The code uses appropriate data types and modifiers for function parameters and struct members.
- The code provides a clear separation between the public API and internal implementation details using preprocessor macros.
- The code includes necessary header files and forward declarations to ensure proper compilation.
- The code is well-documented, making it easier for other developers to understand and maintain.
tools/utils.cmake (2)
17-48: LGTM!The
oc_add_compile_optionsfunction is well-structured and follows best practices:
- It uses
cmake_parse_argumentsto parse the arguments, which is a standard CMake function.- It checks each flag using
check_c_compiler_flagandcheck_cxx_compiler_flag, which are standard CMake functions.- It sets a variable
C_COMPILER_SUPPORTS_${flag_name}orCXX_COMPILER_SUPPORTS_${flag_name}based on the result, which can be used by the caller.- It adds the flag as a global compile option using
add_compile_optionsif theGLOBALoption is provided.
50-71: LGTM!The
oc_set_maximum_log_levelfunction is well-structured and follows best practices:
- It uses a series of
ifstatements to map the level string to an integer value, which is a common pattern in CMake.- It sets the output variable
outlevelto the integer value usingsetwithPARENT_SCOPE, which allows the caller to access the value.- It uses
message(FATAL_ERROR)to handle invalid input, which is a standard CMake function.api/plgd/device-provisioning-client/plgd_dps_retry_internal.h (6)
1-17: License header looks good.The file includes the standard Apache License 2.0 header.
19-28: Header guard and includes look good.
- The header guard
PLGD_DPS_RETRY_INTERNAL_Hfollows the naming convention.- The includes are minimal and relevant.
- The
extern "C"usage is correct to ensure C linkage when used from C++.Also applies to: 79-81
30-32: Macros look good.
- The macros are used to define constants.
- The names are in uppercase, following the convention for macros.
- The
NOLINTNEXTLINEcomment is used to suppress linter warnings for the macro, which is a good practice.
34-41:schedule_action_tstruct looks good.
- The struct is used to store the configuration for scheduling an action.
- The fields are well-named and have appropriate types.
- The comments explain the purpose of each field.
49-55:plgd_dps_retry_tstruct looks good.
- The struct is used to store the retry configuration and current value.
- The fields are well-named and have appropriate types.
- The comments explain the purpose of the struct and its fields.
58-58: Function declarations look good.
- The functions are used to manipulate and query the retry configuration and current value.
- The function names are clear and follow a consistent naming convention.
- The comments explain the purpose of each function.
- The function parameters and return types are appropriate.
Also applies to: 61-61, 68-68, 71-71, 74-74, 77-77
api/plgd/device-provisioning-client/plgd_dps_endpoints_internal.h (6)
1-17: License header looks good!The Apache 2.0 license header is correctly added.
19-20: Header guards are correctly defined.The header guards match the file name and are correctly placed.
Also applies to: 84-84
22-22: Includes look good.All the necessary headers are included and there are no unused or missing includes.
Also applies to: 24-25, 27-28
50-51:dps_set_endpointfunction declaration looks good.
- The function signature and documentation are clear and complete.
- Good use of
OC_NONNULL()annotation to prevent passing NULL pointers.
62-65:dps_set_endpointsfunction declaration looks good.
- The function signature and documentation are clear and complete.
- Good use of
OC_NONNULL(1, 2)annotation to prevent passing NULL pointers for the first two arguments.
75-78:dps_endpoints_initfunction declaration looks good.
- The function signature and documentation are clear and complete.
- Good use of
OC_NONNULL(1)annotation to prevent passing NULL pointer for the first argument.api/plgd/device-provisioning-client/plgd_dps_verify_certificate_internal.h (8)
1-17: License header looks good!The Apache License, Version 2.0 is correctly specified.
19-24: Header guards and extern "C" block look good!
- The header guards are correctly defined using the file name.
- The extern "C" block is correctly used for C++ compatibility.
Also applies to: 92-96
26-34: Included headers look good!The included headers are relevant and necessary for the functionality provided by this file.
42-46:dps_verify_certificate_data_tstruct looks good!
- The struct is well-defined and serves a clear purpose.
- It stores the original verification function with data and a flag indicating if fingerprint verification is done.
56-57:dps_verify_certificate_data_newfunction looks good!
- The function has a clear contract and is well-documented.
- It is used to allocate and initialize custom user data for
dps_verify_certificate.
66-66:dps_verify_certificate_data_freefunction looks good!
- The function has a clear contract and is well-documented.
- It is used to free previously allocated
dps_verify_certificate_data_t.- It matches the
oc_pki_user_data_t::freesignature.
80-81:dps_verify_certificatefunction looks good!
- The function has a clear contract and is well-documented.
- It is used for certificate verification.
- It invokes the original verification function stored in the peers user data.
- If the original verification fails, it runs fingerprint verification if enabled.
86-88:dps_print_fingerprintfunction looks good!
- The function has a clear contract and is well-documented.
- It is used to print fingerprint for debugging purposes.
- It is correctly wrapped in a debug macro to exclude it from release builds.
api/plgd/device-provisioning-client/plgd_dps_store_internal.h (1)
1-107: The code looks good and follows best practices.
- The file is well-structured and follows a consistent naming convention.
- The code is properly documented with Doxygen-style comments.
- The header file has appropriate include guards.
- The code uses
extern "C"for C++ compatibility.- The code uses
OC_NONNULLandOC_NO_DISCARD_RETURNattributes for null pointer checks and return value checks.Overall, the code is clean, readable, and maintainable.
api/plgd/device-provisioning-client/plgd_dps_log.c (4)
1-29: LGTM!The license header and includes are properly added.
31-40: LGTM!The global
g_dps_loggerstruct is properly defined and initialized with default values. The struct members are annotated with comments describing their purpose.
42-49: LGTM!The
dps_log_get_component_labelfunction properly returns the label for a given log component and handles the default component case.
74-113: LGTM!The remaining functions are properly implemented and provide getters and setters for the logging configuration. The functions use atomic operations to access the global
g_dps_loggerstruct, ensuring thread safety. Theplgd_dps_set_log_fnandplgd_dps_get_log_fnfunctions allow setting and getting a custom logging function, while the other functions allow setting and getting the log level and enabled log components.api/plgd/device-provisioning-client/plgd_dps_dhcp_internal.h (3)
1-17: LGTM!The Apache License, Version 2.0 with the plgd.dev copyright notice looks good.
19-20: LGTM!The header guard looks good.
Also applies to: 87-87
33-38: LGTM!The function declarations look good. The
OC_NONNULLattribute is a good practice to prevent NULL pointer dereferences.Also applies to: 64-81
api/plgd/device-provisioning-client/plgd_dps_security_internal.h (1)
1-101: LGTM!The new header file follows good practices and the code changes are approved.
api/plgd/device-provisioning-client/plgd_dps_provision_cloud_internal.h (1)
1-107: The code looks clean and well-structured.Observations:
- The file is a C header file containing function declarations and a struct definition.
- The file is well-documented with Doxygen-style comments.
- The code follows a consistent naming convention and style.
- The header file is properly guarded with
#ifndefand#definedirectives.- The code is properly licensed under the Apache License 2.0.
The code is approved.
api/plgd/device-provisioning-client/plgd_dps_apis_internal.h (1)
1-97: Overall, the new header file looks good!The file follows the project's coding style and conventions. The functions have clear names and are well documented. There are no obvious correctness, security, or performance issues.
api/plgd/device-provisioning-client/plgd_dps_provision_internal.h (1)
1-104: LGTM!The header file follows a standard structure and the function declarations adhere to the coding style. The code changes are approved.
api/plgd/device-provisioning-client/plgd_dps_tag.c (4)
32-44: LGTM!The code changes are approved.
46-58: LGTM!The code changes are approved.
60-73: LGTM!The code changes are approved.
75-88: LGTM!The code changes are approved.
api/plgd/device-provisioning-client/plgd_dps_internal.h (1)
1-107: LGTM!The new header file
plgd_dps_internal.hfollows best practices and is well-structured:
- The file has a clear license header.
- Header guards are used to prevent multiple inclusions.
- Includes are properly listed.
- Macros are used for constants and flags.
- An
extern "C"block is used for C++ compatibility.- Function declarations have clear names and are documented.
- Conditional compilation directives are used effectively.
The code is clean, well-organized, and properly formatted. I did not find any issues or areas that require improvements.
Great job!
api/plgd/device-provisioning-client/plgd_dps_cloud_internal.h (1)
1-150: LGTM!The new header file looks good:
- It is well-documented with comments explaining the purpose of each function and struct.
- It includes necessary header files and defines some macros.
- It follows a consistent naming convention and coding style.
- It uses standard C types and doesn't have any obvious bugs or issues.
The code is approved.
api/plgd/device-provisioning-client/plgd_dps_endpoints.c (14)
1-17: The file includes the Apache License 2.0 header.The code is properly licensed under the Apache License 2.0.
19-29: The necessary header files are included.The code includes the necessary header files for the implementation.
31-32: The endpoint address memory pool is defined.The code defines a memory pool for the endpoint addresses using the
OC_MEMBmacro.
34-61: Thedps_set_endpointfunction implementation looks good.The function sets the DPS service endpoint and handles the case when the endpoint is already set. It disconnects the previous endpoint, reinitializes the endpoint addresses, and notifies observers if necessary. The function returns an appropriate status code.
63-80: Thedps_set_endpointsfunction implementation looks good.The function sets multiple DPS service endpoints and handles the case when the selected endpoint changes. It updates the endpoint addresses in the store and disconnects the previous endpoint if necessary.
82-86: Theplgd_dps_set_endpointfunction implementation looks good.The function is a wrapper around
dps_set_endpointthat sets the DPS service endpoint and notifies observers.
88-109: Theplgd_dps_get_endpointfunction implementation looks good.The function retrieves the selected DPS service endpoint and copies it to the provided buffer. It checks for NULL pointers and buffer size to prevent errors.
111-116: Theplgd_dps_endpoint_is_emptyfunction implementation looks good.The function checks if no DPS service endpoint is selected.
118-128: Thedps_endpoints_initfunction implementation looks good.The function initializes the DPS service endpoints using
oc_endpoint_addresses_init.
130-138: Theplgd_dps_add_endpoint_addressfunction implementation looks good.The function adds a DPS service endpoint address using
oc_endpoint_addresses_add.
140-145: Theplgd_dps_remove_endpoint_addressfunction implementation looks good.The function removes a DPS service endpoint address using
oc_endpoint_addresses_remove.
147-154: Theplgd_dps_iterate_server_addressesfunction implementation looks good.The function iterates over the DPS service endpoint addresses using
oc_endpoint_addresses_iterate.
156-161: Theplgd_dps_select_endpoint_addressfunction implementation looks good.The function selects a DPS service endpoint address using
oc_endpoint_addresses_select.
163-167: Theplgd_dps_selected_endpoint_addressfunction implementation looks good.The function retrieves the selected DPS service endpoint address using
oc_endpoint_addresses_selected.api/plgd/device-provisioning-client/plgd_dps_log_internal.h (1)
1-142: LGTM!The code changes are approved. The new header file is well-structured, follows best practices, and provides a consistent logging mechanism for the device provisioning client.
api/plgd/device-provisioning-client/plgd_dps_context_internal.h (4)
1-17: License information looks good.The license information follows the standard practice of including it at the beginning of the file and specifies the Apache License, Version 2.0.
19-33: Header guards and includes are properly defined.
- The header guards are correctly defined using the file name to prevent multiple inclusions.
- The included headers seem relevant and necessary for the functionality provided by this file.
38-94: Type definitions are well-structured and documented.
- The structures are well-defined and contain relevant fields for their respective purposes.
- The comments provide clear explanations of the fields and their usage.
- The naming conventions follow the project's style.
96-158: Function declarations provide a clear interface.
- The function declarations provide a clear interface for managing the plgd device provisioning context.
- The use of
OC_NONNULLannotation helps catch potential NULL pointer issues at compile-time.- The comments provide brief descriptions of the functions' purposes.
api/plgd/device-provisioning-client/plgd_dps_endpoint.c (7)
36-51: LGTM!The code changes are approved.
55-77: LGTM!The code changes are approved.
80-123: LGTM!The code changes are approved.
125-133: LGTM!The code changes are approved.
135-145: LGTM!The code changes are approved.
154-185: LGTM!The code changes are approved.
187-198: LGTM!The code changes are approved.
api/plgd/device-provisioning-client/plgd_dps_apis.c (8)
35-43: LGTM!The code changes are approved.
45-51: LGTM!The code changes are approved.
53-61: LGTM!The code changes are approved.
63-73: LGTM!The code changes are approved.
75-90: LGTM!The code changes are approved.
92-99: LGTM!The code changes are approved.
132-182: LGTM!The code changes are approved.
184-201: LGTM!The code changes are approved.
api/plgd/device-provisioning-client/plgd_dps_provision_owner.c (5)
1-41: License header and includes look good.The Apache License 2.0 header is properly formatted and all the necessary header files are included.
42-73: Thedps_handle_get_owner_responsefunction looks good.
- It correctly parses the response payload to extract the owner UUID.
- It properly converts the owner UUID string to a UUID structure using
oc_str_to_uuid.- It sets the owner UUID in the device provisioning context using
dps_set_owner.- The error handling and logging are appropriate.
75-143: Thedps_get_owner_handlerfunction looks good.
- It properly checks the status of the device provisioning context and handles errors.
- It calls
dps_handle_get_owner_responseto parse the response payload.- It updates the status and error flags in the context based on the result.
- The logic for updating the status and error flags is correct.
- It schedules the next step in the provisioning process if successful using
dps_provisioning_schedule_next_step.- The error handling and logging are appropriate.
145-175: Thedps_get_ownerfunction looks good.
- It properly checks the provisioning status before sending the request.
- It sets up the TLS connection using
dps_setup_tls.- It dispatches the GET request using
oc_do_get_with_timeoutwith the correct URI, timeout, and handler.- It updates the status and error flags in the context appropriately.
- The error handling and logging are adequate.
177-208: Thedps_print_ownerfunction looks good.
- It is properly wrapped in the
DPS_DBG_IS_ENABLEDmacro to ensure it's only compiled when debugging is enabled.- It retrieves the owner-related UUIDs from the appropriate security structures (doxm, pstat, creds, acls).
- It converts the UUIDs to strings using
oc_uuid_to_strand logs them usingDPS_DBG.- The code is properly excluded from coverage analysis using
GCOVR_EXCL_STARTandGCOVR_EXCL_STOPcomments.api/plgd/device-provisioning-client/plgd_dps_verify_certificate.c (5)
30-43: LGTM!The code changes are approved.
45-58: LGTM!The code changes are approved.
62-100: LGTM!The code changes are approved.
104-135: LGTM!The code changes are approved.
137-218: LGTM!The code changes are approved.
api/plgd/device-provisioning-client/plgd_dps_time.c (5)
48-52: LGTM!The code changes are approved.
54-60: LGTM!The code changes are approved.
62-71: LGTM!The code changes are approved.
73-97: LGTM!The code changes are approved.
99-172: LGTM!The code changes are approved.
api/plgd/device-provisioning-client/plgd_dps_context.c (1)
1-296: LGTM!The code in this file follows a modular structure, uses appropriate naming conventions, and has clear responsibilities for each function. The code is well-documented, uses assert statements for error checking, and follows the Apache License 2.0.
Some key observations:
- The file includes various header files related to device provisioning, ensuring proper dependencies are included.
- The file defines global variables and pools for managing device provisioning contexts, allowing for efficient memory management.
- The functions for allocating, freeing, and managing device provisioning contexts are implemented correctly.
- The functions for initializing, deinitializing, and resetting device provisioning contexts handle the necessary cleanup and reinitialization steps.
- The functions for managing device provisioning callbacks, configuration, and status provide a clean interface for interacting with the device provisioning system.
Overall, the code is well-structured, follows best practices, and is ready for integration.
api/plgd/device-provisioning-client/plgd_dps_retry.c (7)
34-44: LGTM!The debug function looks good. It is correctly wrapped in a
DPS_DBG_IS_ENABLEDmacro and is excluded from code coverage.
46-58: LGTM!The function correctly initializes the retry configuration with default values and prints the configuration if debug is enabled.
60-83: LGTM!The function correctly validates the provided configuration before setting it.
85-107: LGTM!The function correctly checks the buffer size before copying the configuration.
109-119: LGTM!The function correctly determines the size of the retry configuration.
121-133: LGTM!The function correctly calculates the delay based on the timeout value and adds a random delay to prevent synchronization issues.
135-148: LGTM!The function correctly schedules the default retry action based on the retry count and selects the next DPS endpoint if the retry count has exceeded the maximum retry attempts.
api/plgd/device-provisioning-client/plgd_dps_manager.c (5)
44-53: LGTM!The code changes are approved.
55-75: LGTM!The code changes are approved.
77-96: LGTM!The code changes are approved.
189-194: LGTM!The code changes are approved.
196-205: LGTM!The code changes are approved.
api/plgd/device-provisioning-client/plgd_dps_dhcp.c (11)
1-17: The Apache 2.0 license header looks good.The file includes a properly formatted license header with:
- The correct Apache 2.0 license text.
- An appropriate copyright notice mentioning plgd.dev, s.r.o. and the years 2022-2024.
19-28: The include statements look good.Observations:
- The necessary project-specific and standard C headers are included.
- The project header names follow a consistent naming convention.
- The headers included with double quotes are placed before the standard headers included with angle brackets, following the recommended order.
31-35: The enum declaration for DHCP option codes looks good.
- Using an enum to define the option codes enhances code readability and maintainability.
- The enum constant names are descriptive and follow a consistent naming convention with the
DHCP_OPTION_CODE_prefix.
37-38: TheMAX_DHCP_VENDOR_ENCAPSULATED_OPTION_BYTE_SIZEmacro definition looks good.
- The macro is used to define the maximum size of the DHCP vendor encapsulated option in bytes.
- The value 255 is reasonable as it is the maximum value that can be represented in a byte.
- The
NOLINTNEXTLINEcomment is appropriately used to suppress linter warnings related to the use of a macro.
40-49: Theplgd_dps_dhcp_initfunction looks good.
- The function initializes the
plgd_dps_dhcp_tstruct with default values for the option codes.- The use of
assertis good for catching programming errors early.- The function follows a clear and concise implementation.
51-57: Theplgd_dps_dhcp_set_vendor_encapsulated_option_code_dps_endpointfunction looks good.
- The function allows setting a custom option code for the DPS endpoint.
- The use of
assertis good for catching programming errors early.- The function follows a clear and concise implementation.
59-65: Theplgd_dps_dhcp_get_vendor_encapsulated_option_code_dps_endpointfunction looks good.
- The function allows retrieving the custom option code for the DPS endpoint.
- The use of
assertis good for catching programming errors early.- The function follows a clear and concise implementation.
67-73: Theplgd_dps_dhcp_set_vendor_encapsulated_option_code_dps_certificate_fingerprintfunction looks good.
- The function allows setting a custom option code for the DPS certificate fingerprint.
- The use of
assertis good for catching programming errors early.- The function follows a clear and concise implementation.
75-81: Theplgd_dps_dhcp_get_vendor_encapsulated_option_code_dps_certificate_fingerprintfunction looks good.
- The function allows retrieving the custom option code for the DPS certificate fingerprint.
- The use of
assertis good for catching programming errors early.- The function follows a clear and concise implementation.
83-96: Thehexchar_to_decimalfunction looks good.
- The function converts a hexadecimal digit to its decimal equivalent.
- The if-else statements cover all possible cases for valid hexadecimal digits (0-9, A-F, a-f).
- Returning -1 for invalid input is a good way to indicate an error.
- The use of magic numbers (e.g., 10) is justified in this context.
98-131: Thehex_to_valuefunction looks good.
- The function converts a hexadecimal string to a byte value.
- The use of
assertis good for catching programming errors early.- The loop iterates over the characters in the data and handles the end of the hexadecimal value correctly.
- The function returns the number
api/plgd/device-provisioning-client/plgd_dps_store.c (18)
1-17: LGTM!The Apache License 2.0 header is correctly formatted and contains the necessary information.
19-32: LGTM!The include statements are correctly formatted and seem to be including all the necessary header files.
38-40: LGTM!The error handling for the missing OC_STORAGE definition is correctly implemented and the error message is clear and informative.
58-66: LGTM!The function
dps_store_dump_handleris correctly implemented and handles the error case properly.
68-73: LGTM!The function
dps_store_dump_asyncis correctly implemented.
75-83: LGTM!The function
dps_store_initis correctly implemented and is calling the necessary functions.
85-91: LGTM!The function
dps_store_deinitis correctly implemented and is calling the necessary functions.
93-143: LGTM!The function
dps_store_set_endpointsis correctly implemented and is handling the error cases properly. It is also logging the added endpoints for debugging purposes.
145-221: LGTM!The function
dps_store_decodeis correctly implemented and is handling all the properties of the dps store. It is also logging the decoded values for debugging purposes.
223-230: LGTM!The function
dps_store_gen_tagis correctly implemented and is ensuring that the tag is null-terminated.
232-238: LGTM!The function
dps_store_get_storageis correctly implemented and is calling the necessary functions.
240-250: LGTM!The function
dps_store_rep_set_text_stringis correctly implemented and is handling the case when the value is NULL.
252-258: LGTM!The function
dps_store_rep_set_boolis correctly implemented.
260-280: LGTM!The function
dps_store_encode_with_mapis correctly implemented and is encoding all the properties of the dps store.
282-313: LGTM!The function
dps_store_loadis correctly implemented and is handling the error cases properly. It is also freeing the allocated memory.
315-322: LGTM!The function
dps_store_encodeis correctly implemented and is calling the necessary functions.
324-365: LGTM!The function
dps_store_dump_internalis correctly implemented and is handling the error cases properly. It is also freeing the allocated memory.
367-374: LGTM!The function
dps_store_dumpis correctly implemented and is calling the necessary functions.api/plgd/device-provisioning-client/plgd_dps_pki.c (5)
1-17: License header looks good.The file includes the standard Apache License 2.0 header.
19-40:#includedirectives look good.The included headers seem to be properly organized and necessary for the functionality implemented in this file.
50-57:dps_pki_initfunction looks good.
- The function performs a simple initialization of the
dps_pki_configuration_tstruct.- The use of constants for the default expiring limit improves readability.
- The
assertcheck forNULLpointer is a good defensive programming practice.
59-105:dps_pki_send_csrfunction looks good.
- The function follows a logical flow for generating and sending a CSR to the DPS service.
- Error handling is present, with appropriate error messages logged and early returns on failure.
- The use of
assertchecks forNULLpointers is a good defensive programming practice.- The function uses
oc_do_post_with_timeoutto send the POST request with a timeout, which is a good practice to prevent hanging on network issues.
129-152:dps_pki_validate_certificatefunction looks good.
- The function performs a thorough validation of the certificate's validity period.
- It handles the case when the current time cannot be obtained, returning an error.
- The use of
uint64_tfor representing time in seconds is a good practice to avoid overflow issues.- The function returns an appropriate
dps_certificate_state_tenum value based on the validation result.api/plgd/device-provisioning-client/plgd_dps_provision_cloud.c (11)
1-17: License header looks good.The file includes a properly formatted license header specifying the Apache License 2.0 and the copyright holder.
19-38: Include statements look good.The necessary header files are included and they are grouped into internal and external headers for better organization.
43-115: Functiondps_register_cloud_fill_datalooks good.The function correctly parses the payload, performs error checking, and fills the
cloud_conf_tstruct with the parsed data. The debug logging statements are also properly guarded.
117-132: Functioncloud_deregister_handlerlooks good.The function properly handles the cloud deregistration response, logs the result, and closes the session. The error logging statements are also guarded.
134-155: Functioncloud_deregisterlooks good.The function properly sends a DELETE request to deregister a device from the cloud. It performs the necessary checks, constructs the
oc_cloud_access_conf_tstruct, and passes the timeout parameter.
157-238: Functiondps_handle_set_cloud_responselooks good.The function properly handles the set cloud configuration response. It performs the necessary steps such as parsing the response, checking the current cloud status, deregistering from the old cloud if necessary, stopping the cloud manager, and setting the new configuration. The error handling and logging statements are also appropriate.
240-251: Functiondps_has_cloud_configurationlooks good.The function properly checks if a device has a cloud configuration by getting the cloud context and checking for the presence of a server URI and access token.
253-315: Functiondps_set_cloud_handlerlooks good.The function properly handles the set cloud configuration response. It performs the necessary checks on the current DPS status, resets the delayed callbacks, updates the DPS status, validates the response, and handles the response appropriately. The error handling, retry logic, and scheduling of the next provisioning step are all implemented correctly.
317-352: Functiondps_provisioning_set_cloud_encode_selected_gatewaylooks good.The function properly encodes the selected gateway information into the CBOR representation. It retrieves the necessary information from the cloud context, encodes the gateway URI and UUID into the CBOR map, and uses assertions to ensure the expected conditions are met.
354-374: Functiondps_provisioning_set_cloud_encode_payloadlooks good.The function properly encodes the payload for the set cloud configuration request. It retrieves the device ID, encodes it into the CBOR map, and calls the appropriate function to encode the selected gateway information. It returns a boolean value indicating the success of the encoding.
376-407: Functiondps_provisioning_set_cloudlooks good.The function properly sends a POST request to set the cloud configuration for a device. It performs the necessary checks on the device state, initializes the POST request, encodes the request payload, sets up the TLS connection, and sends the request with a timeout. It updates the DPS status accordingly and returns a boolean value indicating the success of dispatching the request.
api/plgd/device-provisioning-client/plgd_dps.c (5)
1-17: License header looks good.The file starts with a proper license header comment block that includes the copyright notice and Apache License 2.0 details.
36-44:dps_manager_status_cblooks good.The function is invoked when the manager status changes. It logs the status change and invokes the registered callback, if any. The implementation is clear and concise.
46-52:dps_status_callback_handlerlooks good.The function serves as an event callback handler. It invokes
dps_manager_status_cbwith the provided context. The implementation is straightforward.
126-147:dps_ep_session_event_handlerlooks good.The function handles session events for endpoints. It compares the provided endpoint with the context's endpoint and cloud server endpoint. It invokes
dps_handle_endpoint_eventfor matching endpoints and handles cloud server disconnection appropriately. The implementation is clear and follows the expected behavior.
159-165:dps_interface_event_handlerlooks good.The function handles interface events. When the network interface is up, it iterates over the DPS contexts and restarts the ones that are initialized. The implementation is straightforward and serves the intended purpose.
api/plgd/device-provisioning-client/plgd_dps_security.c (7)
45-50: LGTM!The code changes are approved.
52-95: LGTM!The code changes are approved. The function performs thorough ownership verification checks.
127-144: LGTM!The code changes are approved. The debug logging statements are properly guarded by the
DPS_DBG_IS_ENABLEDmacro.
146-202: LGTM!The code changes are approved. The function performs the necessary steps to transfer device ownership.
Please verify if closing existing TLS peer connections after ownership transfer using
oc_tls_close_peersis the desired behavior. Ensure that it doesn't have any unintended side effects.
339-398: LGTM!The code changes are approved. The function performs thorough credential verification and handles expired certificates appropriately.
400-410: LGTM!The code changes are approved. The function correctly checks the device's credentials and schedules certificate renewal.
412-427: LGTM!The code changes are approved. The function correctly retrieves the identity credential ID of the device.
api/plgd/device-provisioning-client/plgd_dps_cloud.c (15)
40-48: LGTM!The code changes are approved.
50-58: LGTM!The code changes are approved.
60-64: LGTM!The code changes are approved.
66-70: LGTM!The code changes are approved.
72-79: LGTM!The code changes are approved.
81-92: LGTM!The code changes are approved.
94-117: LGTM!The code changes are approved.
119-133: LGTM!The code changes are approved.
135-140: LGTM!The code changes are approved.
142-165: LGTM!The code changes are approved.
167-199: LGTM!The code changes are approved.
201-222: LGTM!The code changes are approved.
224-271: LGTM!The code changes are approved.
273-289: LGTM!The code changes are approved.
291-296: LGTM!The code changes are approved.
api/plgd/device-provisioning-client/plgd_dps_resource.c (16)
1-17: License header looks good!The code changes are approved.
19-44: Include statements look good!The code changes are approved.
46-66: Macro definitions look good!The code changes are approved.
68-74:dps_conf_update_tstruct definition looks good!The code changes are approved.
76-82:dps_conf_update_data_tstruct definition looks good!The code changes are approved.
153-173: Function looks good!The code changes are approved.
177-189: Function looks good!The code changes are approved.
191-205: Function looks good!The code changes are approved.
207-216: Function looks good!The code changes are approved.
218-224: Function looks good!The code changes are approved.
228-259: Function looks good!The code changes are approved.
261-285: Function looks good!The code changes are approved.
287-301: Function looks good!The code changes are approved.
305-322: Function looks good!The code changes are approved.
324-335: Function looks good!The code changes are approved.
336-363: Function looks good!The code changes are approved.
api/plgd/device-provisioning-client/plgd_dps_provision.c (15)
43-63: LGTM!The code changes are approved.
65-99: Skipping the review.The function is only used for debugging purposes.
101-137: LGTM!The code changes are approved.
139-204: LGTM!The code changes are approved.
206-226: LGTM!The code changes are approved.
228-302: LGTM!The code changes are approved.
304-328: LGTM!The code changes are approved.
330-334: LGTM!The code changes are approved.
336-344: LGTM!The code changes are approved.
346-354: LGTM!The code changes are approved.
356-364: LGTM!The code changes are approved.
366-374: LGTM!The code changes are approved.
376-384: LGTM!The code changes are approved.
392-411: LGTM!The code changes are approved.
413-432: LGTM!The code changes are approved.
include/plgd/plgd_dps.h (1)
127-519: Verify the usage ofplgd_dps_context_tin the codebase.Ensure that the
plgd_dps_context_tis properly initialized, started, and stopped in the codebase. Also, verify that the DPS status and errors are handled correctly.Run the following script to verify the usage of
plgd_dps_context_t:Verification successful
Verification Successful: Usage of
plgd_dps_context_tis CorrectThe
plgd_dps_context_tis properly initialized, started, and stopped in the codebase. The handling of DPS status and errors usingplgd_dps_status_tandplgd_dps_error_tis correctly implemented. No issues were found in the usage of these components.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the usage of `plgd_dps_context_t` in the codebase. # Test: Search for the initialization of `plgd_dps_context_t`. # Expect: At least one occurrence of `plgd_dps_init`. rg --type c -A 5 $'plgd_dps_init' # Test: Search for the starting of DPS manager. # Expect: At least one occurrence of `plgd_dps_manager_start`. rg --type c -A 5 $'plgd_dps_manager_start' # Test: Search for the stopping of DPS manager. # Expect: At least one occurrence of `plgd_dps_manager_stop`. rg --type c -A 5 $'plgd_dps_manager_stop' # Test: Search for the handling of DPS status. # Expect: Usage of `plgd_dps_status_t` and handling of different status values. rg --type c -A 10 $'plgd_dps_status_t' # Test: Search for the handling of DPS errors. # Expect: Usage of `plgd_dps_error_t` and handling of different error values. rg --type c -A 10 $'plgd_dps_error_t'Length of output: 37005
CMakeLists.txt (7)
80-82: LGTM!The addition of the
PLGD_DEV_TIME_ENABLEDandPLGD_DEV_DEVICE_PROVISIONING_ENABLEDoptions with default values ofOFFallows for explicit control over the PLGD features.
174-174: LGTM!Including the
tools/utils.cmakefile promotes a modular approach and improves the organization of utility functions.
238-238: LGTM!The refactoring of the logging level configuration using the
oc_set_maximum_log_levelfunction improves readability and maintainability by abstracting the conditional logic into a single function call.
407-412: LGTM!The code segment correctly handles the enabling of the
PLGD_DEV_TIMEfeature by adding the necessary compile definitions based on the value ofPLGD_DEV_TIME_ENABLED. The conditional check forBUILD_MBEDTLSensures proper handling when MbedTLS is used.
414-427: LGTM!The code segment adds robust error handling for the
PLGD_DEV_DEVICE_PROVISIONING_ENABLEDfeature. It ensures that the required features are enabled and prevents misconfigurations by throwing errors for incompatible feature combinations.
670-672: LGTM!The conditional inclusion of the
api/plgd/plgd.cmakefile based on the value ofPLGD_DEV_DEVICE_PROVISIONING_ENABLEDkeeps the CMake script modular and ensures that PLGD-related configurations are included only when necessary.
674-674: LGTM!Adding
${PLGD_DPS_SRC}to theclient-server-objlibrary ensures that the PLGD device provisioning source files are included when the feature is enabled. This change is consistent with the other modifications related to PLGD features.
Danielius1922
force-pushed
the
adam/feature/dps
branch
6 times, most recently
from
35f237b
to
6e436bc
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
Outside diff range, codebase verification and nitpick comments (1)
api/plgd/unittest/plgd_dps_endpoint.cpp (1)
83-203: LGTM, but consider using a certificate that is generated at runtime.The
DPSTLSPeerTesttest fixture contains a single test case that is correctly implemented and is testing the expected behavior of theverify_certificatefunction of theoc_tls_peer_tstruct. However, the test case is using a hardcoded certificate, which is not ideal.Consider using a certificate that is generated at runtime instead of a hardcoded certificate. This will make the test case more robust and less prone to breakage if the certificate is changed.
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (58)
- .github/workflows/cmake-linux.yml (1 hunks)
- .github/workflows/static-analysis.yml (2 hunks)
- CMakeLists.txt (8 hunks)
- api/plgd/device-provisioning-client/plgd_dps.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_apis.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_apis_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_cloud.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_cloud_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_context.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_context_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_dhcp.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_dhcp_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_endpoint.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_endpoint_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_endpoints.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_endpoints_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_log.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_log_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_manager.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_manager_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_pki.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_pki_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision_cloud.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision_cloud_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision_owner.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision_owner_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_resource.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_resource_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_retry.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_retry_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_security.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_security_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_store.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_store_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_tag.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_tag_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_time.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_time_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_verify_certificate.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_verify_certificate_internal.h (1 hunks)
- api/plgd/plgd.cmake (1 hunks)
- api/plgd/unittest/plgd_dps_apis.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_cloud.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_dhcp.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_endpoint.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_endpoints.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_log.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_manager.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_test.h (1 hunks)
- include/plgd/plgd_dps.h (1 hunks)
- messaging/coap/observe.c (1 hunks)
- security/oc_tls.c (1 hunks)
- tools/utils.cmake (1 hunks)
- util/oc_features.h (1 hunks)
- util/oc_memb.h (1 hunks)
Files skipped from review due to trivial changes (9)
- api/plgd/device-provisioning-client/plgd_dps_cloud_internal.h
- api/plgd/device-provisioning-client/plgd_dps_dhcp.c
- api/plgd/device-provisioning-client/plgd_dps_internal.h
- api/plgd/device-provisioning-client/plgd_dps_log_internal.h
- api/plgd/device-provisioning-client/plgd_dps_manager_internal.h
- api/plgd/device-provisioning-client/plgd_dps_verify_certificate_internal.h
- api/plgd/plgd.cmake
- security/oc_tls.c
- util/oc_memb.h
Files skipped from review as they are similar to previous changes (33)
- .github/workflows/cmake-linux.yml
- api/plgd/device-provisioning-client/plgd_dps.c
- api/plgd/device-provisioning-client/plgd_dps_apis.c
- api/plgd/device-provisioning-client/plgd_dps_apis_internal.h
- api/plgd/device-provisioning-client/plgd_dps_context_internal.h
- api/plgd/device-provisioning-client/plgd_dps_dhcp_internal.h
- api/plgd/device-provisioning-client/plgd_dps_endpoint.c
- api/plgd/device-provisioning-client/plgd_dps_endpoints.c
- api/plgd/device-provisioning-client/plgd_dps_endpoints_internal.h
- api/plgd/device-provisioning-client/plgd_dps_log.c
- api/plgd/device-provisioning-client/plgd_dps_manager.c
- api/plgd/device-provisioning-client/plgd_dps_pki.c
- api/plgd/device-provisioning-client/plgd_dps_pki_internal.h
- api/plgd/device-provisioning-client/plgd_dps_provision.c
- api/plgd/device-provisioning-client/plgd_dps_provision_cloud.c
- api/plgd/device-provisioning-client/plgd_dps_provision_cloud_internal.h
- api/plgd/device-provisioning-client/plgd_dps_provision_internal.h
- api/plgd/device-provisioning-client/plgd_dps_provision_owner.c
- api/plgd/device-provisioning-client/plgd_dps_resource.c
- api/plgd/device-provisioning-client/plgd_dps_resource_internal.h
- api/plgd/device-provisioning-client/plgd_dps_retry.c
- api/plgd/device-provisioning-client/plgd_dps_retry_internal.h
- api/plgd/device-provisioning-client/plgd_dps_security.c
- api/plgd/device-provisioning-client/plgd_dps_security_internal.h
- api/plgd/device-provisioning-client/plgd_dps_store.c
- api/plgd/device-provisioning-client/plgd_dps_store_internal.h
- api/plgd/device-provisioning-client/plgd_dps_tag.c
- api/plgd/device-provisioning-client/plgd_dps_tag_internal.h
- api/plgd/device-provisioning-client/plgd_dps_time.c
- api/plgd/device-provisioning-client/plgd_dps_time_internal.h
- api/plgd/device-provisioning-client/plgd_dps_verify_certificate.c
- include/plgd/plgd_dps.h
- tools/utils.cmake
Additional comments not posted (68)
api/plgd/unittest/plgd_dps_test.h (3)
1-17: LGTM!The Apache License, Version 2.0 header is correctly formatted and contains the necessary information.
28-29: LGTM!The
usingdeclaration forcontext_unique_ptris correctly defined with a custom deleter and placed inside thedpsnamespace.
31-42: LGTM!The
make_unique_contextfunction is correctly creating a unique pointer toplgd_dps_context_t, initializing the memory, and using the custom deleter to free the memory. The function is also placed inside thedpsnamespace.api/plgd/device-provisioning-client/plgd_dps_provision_owner_internal.h (1)
1-59: LGTM!The code follows the standard structure and conventions for a C header file. The code is well-documented with comments explaining the purpose of each function. The
dps_get_ownerfunction seems to be responsible for requesting ownership UUID by sending a GET request to a specific URI. Thedps_print_ownerfunction is wrapped in a debug macro, indicating that it is only used for debugging purposes. The code usesextern "C"to ensure C linkage when used in C++ code. The header guards prevent multiple inclusions of the header file..github/workflows/static-analysis.yml (2)
19-26: LGTM!The introduction of the matrix strategy for the
clang-tidy-linuxjob is a great improvement to the CI/CD pipeline. It allows for multiple build configurations to be tested in parallel, enabling a more comprehensive testing approach without duplicating job definitions.The
fail-fast: falseoption ensures that all matrix jobs are executed even if one fails, providing a complete picture of the build status across different configurations.The various
build_argsdefined in thematrixenable or disable specific features, allowing for a flexible testing setup.
51-51: LGTM!The modification to the
cmakecommand in the build step to utilize thematrix.build_argsis a necessary and complementary change to the introduction of the matrix strategy.This change allows for the build to be configured based on the
build_argsdefined in the matrix, enabling the workflow to run different builds with specific flags.The combination of the matrix strategy and the dynamic
cmakeconfiguration provides a powerful and flexible testing setup.api/plgd/unittest/plgd_dps_manager.cpp (1)
44-79: LGTM!The test case is well-structured and follows the AAA (Arrange-Act-Assert) pattern. It is testing the behavior of changing the DPS endpoint on retry by setting up a retry loop with a single attempt and adding multiple DPS endpoints. It is using the appropriate macros and functions to make assertions and wait for the retry loop to finish. The test case is approved.
util/oc_features.h (1)
91-95: LGTM!The code changes are approved for the following reasons:
- The new feature flag definition enhances the configurability of the code by allowing the inclusion of device provisioning features based on the defined compilation flags.
- The preprocessor conditions ensure that the necessary dependencies are met before enabling the feature flag.
- The code segment follows the existing coding style and conventions used in the file.
api/plgd/device-provisioning-client/plgd_dps_endpoint_internal.h (1)
1-115: LGTM!The code changes are approved. The new header file is well-structured, properly documented, and follows best practices. The functions are modular and reusable, and the code is guarded with appropriate macros for static analysis and conditional compilation.
api/plgd/unittest/plgd_dps_dhcp.cpp (3)
30-53: LGTM!The test case
DpsOptionsis well-structured and covers the expected functionality of setting and getting the vendor encapsulated option codes for the DPS endpoint and certificate fingerprint.
55-67: LGTM!The test case
ConvertISCDhcpOptionsToBytesis well-structured and covers the expected functionality of converting a hex string to bytes using theplgd_dps_hex_string_to_bytesfunction.
69-102: LGTM!The test case
ParseISCDhcpOptionsis well-structured and covers the expected functionality of parsing the vendor encapsulated options using thedps_dhcp_parse_vendor_encapsulated_optionsfunction.api/plgd/unittest/plgd_dps_log.cpp (4)
43-56: LGTM!The test case is correctly implemented and approved.
58-65: LGTM!The test case is correctly implemented and approved.
103-114: LGTM!The test case is correctly implemented and approved.
134-142: LGTM!The test cases are correctly implemented and approved.
Also applies to: 151-163
api/plgd/unittest/plgd_dps_cloud.cpp (2)
44-58: LGTM!The test case is correctly testing the
dps_cloud_observer_copy_endpoint_uuidfunction with different input scenarios.
75-148: LGTM!The test case is correctly testing the
dps_cloud_observer_on_server_changefunction with different input scenarios.api/plgd/unittest/plgd_dps_endpoints.cpp (3)
44-67: LGTM!The test case is well-structured and covers the important scenarios:
- Setting a valid endpoint and verifying that the endpoint is set correctly.
- Setting an invalid endpoint and verifying that the function returns an error.
69-75: LGTM!The test case is well-structured and covers the important scenarios:
- Verifying that the endpoint is empty and the selected endpoint address is
nullptrafter creating a new context.
77-169: LGTM!The test case is well-structured and covers the important scenarios:
- Adding multiple endpoints and verifying that the endpoints are added correctly.
- Removing endpoints and verifying that the endpoints are removed correctly.
- Selecting endpoints and verifying that the endpoints are selected correctly.
- Iterating over the endpoints and verifying that the endpoints are iterated correctly.
api/plgd/device-provisioning-client/plgd_dps_context.c (15)
39-43: LGTM!The code changes are approved.
45-49: LGTM!The code changes are approved.
51-55: LGTM!The code changes are approved.
57-61: LGTM!The code changes are approved.
63-67: LGTM!The code changes are approved.
69-73: LGTM!The code changes are approved.
75-84: LGTM!The code changes are approved.
86-113: LGTM!The code changes are approved.
115-126: LGTM!The code changes are approved.
128-143: LGTM!The code changes are approved.
145-153: LGTM!The code changes are approved.
155-164: LGTM!The code changes are approved.
166-172: LGTM!The code changes are approved.
174-178: LGTM!The code changes are approved.
180-190: LGTM!The code changes are approved.
api/plgd/unittest/plgd_dps_endpoint.cpp (3)
1-17: LGTM!The Apache License 2.0 header is correctly formatted and contains the necessary information.
21-22: LGTM!The preprocessor directive is correctly used to conditionally compile the code based on the
OC_HAS_FEATURE_PLGD_DEVICE_PROVISIONINGmacro.
41-81: LGTM!The
DPSApiTesttest fixture contains two test cases that are correctly implemented and are testing the expected behavior of thedps_endpoint_is_emptyanddps_endpoint_log_stringfunctions.api/plgd/unittest/plgd_dps_apis.cpp (9)
1-17: LGTM!The Apache 2.0 license header is correct and complete.
19-30: LGTM!The includes are correct and the feature flag
OC_HAS_FEATURE_PLGD_DEVICE_PROVISIONINGis used appropriately to conditionally compile the code.
36-45: LGTM!The
DPSApisTesttest fixture is correctly implemented. It initializes the runtime and sets the log level inSetUpTestCaseand shuts down the runtime inTearDownTestCase.
47-57: LGTM!The
IsEqualStringLentest covers all the important cases and is correctly implemented.
59-72: LGTM!The
IsEqualStringtest covers all the important cases and is correctly implemented.
74-107: LGTM!The
IsTimeoutErrortest covers all the important cases and is correctly implemented.
109-142: LGTM!The
IsConnectionErrortest covers all the important cases and is correctly implemented.
144-202: LGTM!The
RedirectResponsetest covers all the important cases and is correctly implemented. It verifies that the endpoint addresses are correctly updated based on the redirect response.
204-228: LGTM!The
RedirectResponse_Failtest covers all the important failure cases and is correctly implemented. It verifies that thedps_handle_redirect_responsefunction returns false when the redirect URI is missing or invalid.api/plgd/device-provisioning-client/plgd_dps_cloud.c (13)
1-17: LGTM!The Apache 2.0 license header looks good.
19-34: LGTM!The include statements look good:
- Internal header files are included with quotes.
- Public header files are included with angle brackets.
- Standard C header files are included last.
40-48: LGTM!The function looks good:
- It retrieves the cloud context for the given device.
- It returns false if the cloud context is NULL.
- It returns the result of
oc_cloud_manager_is_startedfor the cloud context.
50-58: LGTM!The function looks good:
- It retrieves the cloud context for the given device.
- It returns false if the cloud context is NULL.
- It returns true if the given status flag is set in the cloud status.
60-64: LGTM!The function looks good:
- It calls
cloud_check_statuswith theOC_CLOUD_REGISTEREDstatus flag.
66-70: LGTM!The function looks good:
- It calls
cloud_check_statuswith theOC_CLOUD_LOGGED_INstatus flag.
72-79: LGTM!The function looks good:
- It asserts that the
obspointer is not NULL.- It sets all fields of
obsto 0 usingmemset.- It sets default values for
obs->cfg.max_countandobs->cfg.interval_s.
81-92: LGTM!The function looks good:
- It casts the
user_datapointer toplgd_dps_context_t*.- It invokes the original callback if it is not NULL.
- It calls
dps_cloud_observer_on_server_changewith theplgd_dps_context_tpointer.
94-117: LGTM!The function looks good:
- It removes the
dps_cloud_observe_status_asynccallback usingoc_remove_delayed_callback.- It retrieves the cloud context for the device.
- If the cloud context is not NULL and the
on_selected_changecallback isdps_cloud_observer_on_cloud_server_change:
- It restores the original
on_selected_changecallback and data.- It sets the
original_on_selected_changefields to NULL.- It resets the
last_status,retry_count,initial_endpoint_uri,last_endpoint_uuid, andremaining_endpoint_changesfields.
119-133: LGTM!The function looks good:
- It checks if the
uuidpointer is NULL and uses a nil UUID if it is.- It checks if the
last_endpoint_uuidfield is equal to the given UUID and returns false if it is.- It copies the given UUID to the
last_endpoint_uuidfield usingmemcpy.- It returns true to indicate that the UUID was copied.
135-140: LGTM!The function looks good:
- It returns true if the
initial_endpoint_urifield is not NULL.
142-165: LGTM!The function looks good:
- It retrieves the selected cloud server address.
- It returns false if the selected address is NULL.
- It copies the URI of the selected address to the
initial_endpoint_urifield.- It copies the UUID of the selected address to the
last_endpoint_uuidfield usingdps_cloud_observer_copy_endpoint_uuid.- It sets the
remaining_endpoint_changesfield to the number of alternative cloud servers.- It resets the
retry_countandlast_statusfields.- It returns true to indicate that the initial state was loaded.
167-199: LGTM!The function looks good:
- If a server retry is ongoing, it calls
dps_cloud_observe_statusand returns.- It calls
dps_cloud_observer_loadto load the initial state of the cloud observer.- If loading the initial state fails, it calls
dps_manager_reprovision_and_restartand returns.- It retrieves the current
on_selected_changecallback and data.- If the current callback is not
dps_cloud_observer_on_cloud_server_change:
- It stores the current callback and data in the
original_on_selected_changefields.- It sets the
on_selected_changecallback todps_cloud_observer_on_cloud_server_changeand the data to theplgd_dps_context_tpointer.- It calls
dps_cloud_observe_status.CMakeLists.txt (6)
80-83: LGTM!The new CMake options for enabling plgd.dev features look good.
238-238: LGTM!Using the
oc_set_maximum_log_levelfunction improves readability and maintainability.
407-412: LGTM!The conditional logic for setting the
PLGD_DEV_TIMEcompile definition looks good.
414-428: LGTM!The error handling and dependency checks for enabling the device provisioning feature are well implemented.
671-675: LGTM!Including the necessary files and updating the library definition for the device provisioning feature looks good.
1097-1107: LGTM!Adding the
plgdtestunit test target for testing the plgd.dev features is a good practice.messaging/coap/observe.c (1)
109-121: LGTM!The conditional compilation logic for defining
OC_MIN_OBSERVE_SIZEbased onOC_DYNAMIC_ALLOCATIONand the relationship betweenOC_MAX_OBSERVE_SIZEandOC_MIN_APP_DATA_SIZElooks good. It enhances flexibility while maintaining the existing logic.
Danielius1922
changed the title
There was a problem hiding this comment.
Actionable comments posted: 2
Outside diff range, codebase verification and nitpick comments (1)
api/plgd/unittest/plgd_dps.cpp (1)
52-92: Consider refactoring the flag checking code.The code for checking the presence of status flags in the generated log string can be simplified by extracting it into a helper function. This will make the test case more readable and maintainable.
Here's a suggestion:
void ExpectStatusFlags(const std::string& logString, const std::unordered_set<std::string>& expectedFlags) { std::unordered_set<std::string> actualFlags; std::stringstream ss{logString}; std::string s; while (std::getline(ss, s, '|')) { actualFlags.insert(s); } EXPECT_EQ(expectedFlags, actualFlags); }Then, you can use this helper function in the test case:
ExpectStatusFlags(buffer.data(), { kPlgdDpsStatusInitialized, kPlgdDpsStatusGetTime, kPlgdDpsStatusHasTime, kPlgdDpsStatusGetOwner, kPlgdDpsStatusHasOwner, kPlgdDpsStatusGetCredentials, kPlgdDpsStatusHasCredentials, kPlgdDpsStatusGetAcls, kPlgdDpsStatusHasAcls, kPlgdDpsStatusGetCloud, kPlgdDpsStatusHasCloud, kPlgdDpsStatusProvisioned, kPlgdDpsStatusRenewCredentials, kPlgdDpsStatusTransientFailure, kPlgdDpsStatusFailure, });
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (14)
- .github/workflows/cmake-linux.yml (3 hunks)
- .github/workflows/sonar-cloud-analysis.yml (1 hunks)
- CMakeLists.txt (8 hunks)
- api/plgd/device-provisioning-client/plgd_dps_context.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_resource.c (1 hunks)
- api/plgd/unittest/plgd_dps.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_context.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_provision.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_provision_cloud.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_resource.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_retry.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_security.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_store.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_tag.cpp (1 hunks)
Files skipped from review as they are similar to previous changes (3)
- .github/workflows/cmake-linux.yml
- api/plgd/device-provisioning-client/plgd_dps_context.c
- api/plgd/device-provisioning-client/plgd_dps_resource.c
Additional comments not posted (73)
api/plgd/unittest/plgd_dps_retry.cpp (2)
55-69: LGTM!The test case looks good and correctly verifies the behavior of the
dps_retry_incrementfunction.
71-90: LGTM!The test case looks good and correctly verifies the behavior of the
dps_retry_resetfunction, including the case when thedefault_cfgsize is set to 0.api/plgd/unittest/plgd_dps_security.cpp (3)
29-45: LGTM!The test case is correctly testing the renewal interval for different certificate states.
47-53: LGTM!The test case is correctly testing the string representation of different certificate states.
55-79: LGTM!The test case is correctly testing the certificate state for different validity periods.
api/plgd/unittest/plgd_dps.cpp (5)
44-50: LGTM!The test case for setting and getting the skip verify flag looks good.
130-136: LGTM!The test case for getting the DPS context looks good.
138-146: LGTM!The test case for setting the self-owned flag looks good.
148-158: LGTM!The test case for setting the owner looks good.
160-181: LGTM!The test case for setting the DPS configuration resource looks good.
api/plgd/unittest/plgd_dps_tag.cpp (4)
142-163: LGTM!The test case is well-structured and covers the expected functionality.
167-186: LGTM!The test case is well-structured and covers the expected functionality.
188-206: LGTM!The test case is well-structured and covers the expected functionality.
208-227: LGTM!The test case is well-structured and covers the expected functionality.
api/plgd/unittest/plgd_dps_provision.cpp (5)
86-95: LGTM!The unit test correctly verifies the behavior of
dps_register_cloud_fill_datawhen the access token is missing.
97-106: LGTM!The unit test correctly verifies the behavior of
dps_register_cloud_fill_datawhen the auth provider is missing.
108-118: LGTM!The unit test correctly verifies the behavior of
dps_register_cloud_fill_datawhen the server is missing.
120-129: LGTM!The unit test correctly verifies the behavior of
dps_register_cloud_fill_datawhen the server ID is missing.
131-174: LGTM!The unit test correctly verifies the behavior of
dps_register_cloud_fill_datawhen all required fields are provided..github/workflows/sonar-cloud-analysis.yml (2)
30-30: Skipping review of the commented out code segment.The commented out code segment is not relevant to the current changes.
31-31: LGTM!The new build configuration enables cloud functionality, collection creation, and device provisioning while disabling OSCORE. The changes are consistent with the AI-generated summary and enhance the configurability of the
unit-testsjob.api/plgd/unittest/plgd_dps_store.cpp (10)
1-17: LGTM!The Apache License 2.0 header looks good.
19-40: LGTM!The
#includedirectives are in the correct order and look good.
47-82: LGTM!The
DPSStoreTestclass follows the Google Test framework conventions and looks good.
84-99: LGTM!The
compareStoresfunction correctly compares the relevant fields of theplgd_dps_store_tobjects.
101-130: LGTM!The
EncodeAndDecodetest correctly tests the encoding and decoding ofplgd_dps_store_tobjects.
132-149: LGTM!The
Decode_SelectedEndpointMissingURItest correctly tests the decoding of aplgd_dps_store_tobject with a missing URI for the selected endpoint.
151-172: LGTM!The
Decode_EndpointMissingURItest correctly tests the decoding of aplgd_dps_store_tobject with a missing URI for an endpoint.
174-218: LGTM!The
SaveAndLoadtest correctly tests the saving and loading ofplgd_dps_store_tobjects to/from storage.
220-244: LGTM!The
DPSStoreWithDeviceTestclass follows the Google Test framework conventions and looks good.
246-311: LGTM!The
DumpOnEndpointChangetest correctly tests the dumping ofplgd_dps_store_tobjects on endpoint changes.api/plgd/unittest/plgd_dps_context.cpp (14)
1-17: LGTM!The Apache License, Version 2.0 header is correctly added.
19-33: LGTM!The includes are correct and complete.
37-53: LGTM!The
TestDPSWithContextclass is correctly implemented.
55-61: LGTM!The
HasForcedReprovisiontest is correctly implemented.
63-69: LGTM!The
HasBeenProvisionedSinceResettest is correctly implemented.
71-77: LGTM!The
GetProvisionStatustest is correctly implemented.
79-85: LGTM!The
GetLastErrortest is correctly implemented.
87-105: LGTM!The
SetCloudObservertest is correctly implemented.
107-112: LGTM!The
SetExpiringLimittest is correctly implemented.
114-133: LGTM!The
SetEndpointtest is correctly implemented.
135-180: LGTM!The
SetRetrytest is correctly implemented.
182-196: LGTM!The
SetScheduleActiontest is correctly implemented.
198-241: LGTM!The
SetCertificateFingerprinttest is correctly implemented.
243-285: LGTM!The
SetValuesFromVendorEncapsulatedOptionstest is correctly implemented.api/plgd/unittest/plgd_dps_provision_cloud.cpp (6)
108-147: LGTM!The test case
HandleSetCloudResponseFaillooks good. It covers the necessary failure scenarios when handling set cloud responses, such as invalid payload, invalid sid, and invalid device.
149-223: LGTM!The test case
HandleSetCloudResponselooks good. It covers the necessary success scenarios when handling set cloud responses, such as updating signed-in cloud with same data, different cis, different apn, and different sid.
225-246: LGTM!The test case
HasCloudConfigurationlooks good. It covers the necessary scenarios for thedps_has_cloud_configurationfunction, such as invalid device, missing access token, no selected gateway, and a valid configuration.
248-298: LGTM!The test case
SetCloudHandlerlooks good. It covers the necessary scenarios for thedps_set_cloud_handlerfunction, such as missing flags, returned error code, invalid payload, and valid payload.
300-336: LGTM!The test cases
SetCloudEncodeSelectedGatewayFailandSetCloudEncodeSelectedGatewaylook good. They cover the necessary scenarios for thedps_provisioning_set_cloud_encode_selected_gatewayfunction, such as invalid device, encoding failure, and encoding success with and without a selected gateway.
338-378: LGTM!The test cases
SetCloudEncodePayloadFail,SetCloudEncodePayload,SetCloudFail, andSetCloudlook good. They cover the necessary scenarios for thedps_provisioning_set_cloud_encode_payloadanddps_provisioning_set_cloudfunctions, such as invalid device, encoding failure, encoding success, and setting cloud in different states.api/plgd/unittest/plgd_dps_resource.cpp (15)
1-17: License header looks good!The Apache License 2.0 header is correct and up-to-date.
21-22: Feature flag guards are used correctly!The file is properly guarded by the required feature flags to enable conditional compilation.
45-45: Test fixture looks good!The
DPSResourceTestclass serves as a base test fixture for the test cases.
62-85:parseDPSEndpointsfunction looks good!The function correctly parses the DPS endpoints from the given OCF representation and handles the case when the required properties are missing.
87-140:parseDPSDataPropertyfunction looks good!The function correctly parses the various properties of the DPS data from the given OCF representation and updates the
DPSDatastruct accordingly. The function is well-structured and handles different property types.
142-156:parseDPSDatafunction looks good!The function correctly parses the entire DPS data from the given OCF representation by iterating over the properties and calling the
parseDPSDataPropertyfunction for each property. It handles baseline interface properties and logs unexpected properties.
158-238:EncodeReadtest case looks good!The test case thoroughly tests the encoding of the DPS resource representation for the read interface. It covers various scenarios and verifies that the encoded representation can be parsed correctly. The test case is well-structured and uses helper functions for parsing the encoded data.
240-275:EncodeReadWritetest case looks good!The test case verifies that the encoded representation of the DPS resource for the read-write interface contains only the expected properties, such as the endpoint URI and name. It also ensures that the last error code and provision status are not included in the encoded representation.
277-369:StatusToStringtest case looks good!The test case thoroughly tests the
dps_status_to_strfunction by covering all possible combinations of DPS status flags and verifying that the function returns the expected string representation for each combination. It also ensures that the function handles invalid flag values correctly.
371-395:DPSResourceTestWithServertest fixture looks good!The test fixture sets up a test server for testing the DPS resource and defines static setup and teardown methods to manage the server and DPS context. It follows the RAII principle and is well-structured.
397-430:getRequestWithQueryfunction looks good!The function sends a GET request to the DPS resource with the specified query parameters and verifies the response. It is a template function that allows specifying the expected status code. The function is well-structured, handles the response using lambda functions, and ensures proper cleanup by terminating the test device and pooling the events.
432-445:GetRequest_FailNoDPStest case looks good!The test case covers the scenario when a GET request is sent to the DPS resource without initializing the DPS context. It verifies that an internal server error status code is returned in the response. The test case properly cleans up by deleting the manually created resource and reinitializing the DPS context.
447-458:GetRequest_FailNoDPSResourcetest case looks good!The test case covers the scenario when a GET request is sent to the DPS resource without setting the configuration resource. It verifies that a not found status code is returned in the response. The test case properly cleans up by re-enabling the configuration resource and setting the access permissions.
460-463:GetRequesttest case looks good!The test case covers a successful GET request to the DPS resource with the read interface. It verifies that the response contains the expected DPS data encoded in the payload.
465-468:GetRequestBaselinetest case looks good!The test case covers a successful GET request to the DPS resource with the baseline interface. It verifies that the response contains the expected DPS data encoded in the payload.
CMakeLists.txt (7)
80-83: LGTM!The code changes are approved.
175-175: LGTM!The code changes are approved.
239-239: LGTM!The code changes are approved.
408-436: LGTM!The code changes are approved.
679-681: LGTM!The code changes are approved.
683-683: LGTM!The code changes are approved.
1105-1114: LGTM!The code changes are approved.
Danielius1922
force-pushed
the
adam/feature/dps
branch
from
7ae7288
to
563973b
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (16)
- .github/workflows/cmake-linux.yml (2 hunks)
- .github/workflows/sonar-cloud-analysis.yml (3 hunks)
- .github/workflows/static-analysis.yml (2 hunks)
- CMakeLists.txt (8 hunks)
- api/plgd/device-provisioning-client/plgd_dps_context.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_resource.c (1 hunks)
- api/plgd/unittest/plgd_dps.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_context.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_provision.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_provision_cloud.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_resource.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_retry.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_security.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_store.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_tag.cpp (1 hunks)
- sonar-project.properties (1 hunks)
Files skipped from review due to trivial changes (2)
- api/plgd/unittest/plgd_dps_tag.cpp
- sonar-project.properties
Files skipped from review as they are similar to previous changes (13)
- .github/workflows/cmake-linux.yml
- .github/workflows/sonar-cloud-analysis.yml
- .github/workflows/static-analysis.yml
- api/plgd/device-provisioning-client/plgd_dps_context.c
- api/plgd/device-provisioning-client/plgd_dps_resource.c
- api/plgd/unittest/plgd_dps.cpp
- api/plgd/unittest/plgd_dps_context.cpp
- api/plgd/unittest/plgd_dps_provision.cpp
- api/plgd/unittest/plgd_dps_provision_cloud.cpp
- api/plgd/unittest/plgd_dps_resource.cpp
- api/plgd/unittest/plgd_dps_retry.cpp
- api/plgd/unittest/plgd_dps_security.cpp
- api/plgd/unittest/plgd_dps_store.cpp
Additional comments not posted (6)
CMakeLists.txt (6)
80-83: LGTM!The code changes are approved.
408-437: LGTM!The code changes are approved.
1105-1115: LGTM!The code changes are approved.
175-175: Verify the contents of the included file.Ensure that the included file
tools/utils.cmakecontains appropriate and reviewed code.Run the following script to verify the file contents:
Verification successful
The contents of
tools/utils.cmakeare appropriate and well-structured.The file includes necessary modules and defines utility functions for managing compile options and logging levels, with appropriate checks and error handling. No issues were found.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the contents of tools/utils.cmake. # Test: Output the contents of the file. Expect: Appropriate CMake utility functions. cat tools/utils.cmakeLength of output: 2758
679-683: Verify the contents of the included file and the source of PLGD_DPS_SRC.Ensure that:
- The included file
api/plgd/plgd.cmakecontains appropriate and reviewed code.- The source files in
PLGD_DPS_SRCare appropriate and reviewed.Run the following script to verify the file contents and source files:
Verification successful
Verification successful: The included file and source of PLGD_DPS_SRC are appropriate.
- The
api/plgd/plgd.cmakefile contains a global include guard and correctly usesfile(GLOB ...)to include.cfiles from theapi/plgd/device-provisioning-clientdirectory.- The
PLGD_DPS_SRCvariable is properly defined and used in theCMakeLists.txt.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the contents of api/plgd/plgd.cmake and the source of PLGD_DPS_SRC. # Test 1: Output the contents of the file. Expect: Appropriate CMake configuration. cat api/plgd/plgd.cmake # Test 2: Search for the definition of PLGD_DPS_SRC. Expect: Appropriate source file list. rg --type cmake $'PLGD_DPS_SRC'Length of output: 310
239-239: Verify the implementation of the CMake function.Ensure that the CMake function
oc_set_maximum_log_levelis implemented correctly and sets the maximum log level appropriately.Run the following script to verify the function implementation:
Verification successful
The CMake function
oc_set_maximum_log_levelis implemented correctly.The function maps log level strings to integers and handles invalid inputs appropriately. It sets the output variable in the parent scope, ensuring correct functionality. No issues found with the implementation.
- Function implementation is located in
tools/utils.cmake.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the implementation of oc_set_maximum_log_level. # Test: Search for the function definition. Expect: Appropriate CMake function definition. rg --type cmake $'oc_set_maximum_log_level'Length of output: 208
Script:
#!/bin/bash # Extract the implementation of the function oc_set_maximum_log_level from tools/utils.cmake ast-grep --lang cmake --pattern $'function(oc_set_maximum_log_level $_, $_) { $$$ }'Length of output: 196
Script:
#!/bin/bash # Use rg to search for the function definition and include context lines to capture the full implementation. rg --type-add 'cmake:*.cmake' --type cmake 'function\(oc_set_maximum_log_level' -A 10Length of output: 652
Script:
#!/bin/bash # Capture more lines to ensure the entire function implementation is reviewed. rg --type-add 'cmake:*.cmake' --type cmake 'function\(oc_set_maximum_log_level' -A 20Length of output: 1127
Danielius1922
force-pushed
the
adam/feature/dps
branch
from
563973b
to
d964998
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
Outside diff range, codebase verification and nitpick comments (1)
api/plgd/device-provisioning-client/plgd_dps_context.c (1)
156-165: Theplgd_dps_on_factory_resetfunction looks mostly good.Resetting the device provisioning context on factory reset is the correct behavior.
However, there is an unused code block at line 160-162 that sets some retry timeouts. This code is currently disabled using an ifdef.
Consider removing the unused code block:
-#ifdef PLGD_DPS_RESOURCE_TEST_PROPERTIES - oc_cloud_set_retry_timeouts(NULL, 0); -#endif /* PLGD_DPS_RESOURCE_TEST_PROPERTIES */
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (16)
- .github/workflows/cmake-linux.yml (2 hunks)
- .github/workflows/sonar-cloud-analysis.yml (3 hunks)
- .github/workflows/static-analysis.yml (2 hunks)
- CMakeLists.txt (8 hunks)
- api/plgd/device-provisioning-client/plgd_dps_context.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_resource.c (1 hunks)
- api/plgd/unittest/plgd_dps.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_context.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_provision.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_provision_cloud.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_resource.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_retry.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_security.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_store.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_tag.cpp (1 hunks)
- sonar-project.properties (1 hunks)
Files skipped from review as they are similar to previous changes (14)
- .github/workflows/cmake-linux.yml
- .github/workflows/sonar-cloud-analysis.yml
- .github/workflows/static-analysis.yml
- api/plgd/device-provisioning-client/plgd_dps_resource.c
- api/plgd/unittest/plgd_dps.cpp
- api/plgd/unittest/plgd_dps_context.cpp
- api/plgd/unittest/plgd_dps_provision.cpp
- api/plgd/unittest/plgd_dps_provision_cloud.cpp
- api/plgd/unittest/plgd_dps_resource.cpp
- api/plgd/unittest/plgd_dps_retry.cpp
- api/plgd/unittest/plgd_dps_security.cpp
- api/plgd/unittest/plgd_dps_store.cpp
- api/plgd/unittest/plgd_dps_tag.cpp
- sonar-project.properties
Additional context used
cppcheck
api/plgd/device-provisioning-client/plgd_dps_context.c
[error] 103-103: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
Additional comments not posted (22)
api/plgd/device-provisioning-client/plgd_dps_context.c (15)
1-17: License header looks good.The file contains the standard Apache License, Version 2.0 text with the correct copyright notice.
19-34: Header includes look good.The file is including all the necessary internal and external dependencies.
37-38: The global list and memory pool for device provisioning contexts look good.Using a global list and fixed-size memory pool is a common and acceptable pattern in IoTivity-Lite.
40-44: Thedps_on_endpoint_changecallback function looks good.Dumping the store asynchronously on endpoint change is a good way to persist the updated provisioning state.
46-56: Thedps_context_allocanddps_context_freefunctions look good.They are correctly using the memory pool to allocate and free device provisioning contexts.
58-68: Thedps_context_list_addanddps_context_list_removefunctions look good.They are correctly adding and removing device provisioning contexts from the global list.
70-74: Thedps_context_list_is_emptyfunction looks good.Checking the list length is the correct way to determine if the list is empty.
76-85: Thedps_contexts_iteratefunction looks good.It is using a standard and correct pattern to iterate over the global list and call a callback for each device provisioning context. Stopping the iteration based on the callback return value is also handled correctly.
87-114: Thedps_context_initfunction looks good.It is correctly initializing all the fields of the device provisioning context with default values. Allocating the endpoint during init is also fine.
Tools
cppcheck
[error] 103-103: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
116-127: Thedps_context_deinitfunction looks good.It is correctly cleaning up all the resources associated with the device provisioning context, including pending callbacks, the cloud observer, the store, and the endpoint.
129-144: Thedps_context_resetfunction looks good.It is correctly resetting the device provisioning context to its initial state by deinitializing and reinitializing its components, including the cloud observer, endpoint, manager, and store.
146-154: Theplgd_dps_get_contextfunction looks good.It is correctly retrieving a device provisioning context from the global list based on the device index by iterating over the list and comparing the device index of each context.
167-179: Theplgd_dps_set_skip_verifyandplgd_dps_get_skip_verifyfunctions look good.They are correctly setting and retrieving the skip_verify flag of a device provisioning context. The assert checks are also good to validate the input context pointer.
181-191: Theplgd_dps_set_manager_callbacksfunction looks good.It is correctly setting the manager callbacks of a device provisioning context by copying the provided callbacks struct. The assert check is also good to validate the input context pointer.
193-206: Theplgd_dps_force_reprovisionandplgd_dps_has_forced_reprovisionfunctions look good.They are correctly setting and retrieving the force_reprovision flag of a device provisioning context. The assert checks are also good to validate the input context pointer.
CMakeLists.txt (7)
80-83: LGTM!The code changes are approved.
175-175: LGTM!The code changes are approved.
239-239: LGTM!The code changes are approved.
408-437: LGTM!The code changes are approved.
679-681: LGTM!The code changes are approved.
683-683: LGTM!The code changes are approved.
1105-1115: LGTM!The code changes are approved.
Danielius1922
force-pushed
the
adam/feature/dps
branch
from
d964998
to
8f5ea68
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (22)
- .github/workflows/cmake-linux.yml (2 hunks)
- .github/workflows/sonar-cloud-analysis.yml (3 hunks)
- .github/workflows/static-analysis.yml (2 hunks)
- CMakeLists.txt (8 hunks)
- api/plgd/device-provisioning-client/plgd_dps.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_context.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_context_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_resource.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_retry.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_store.c (1 hunks)
- api/plgd/unittest/plgd_dps.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_context.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_dhcp.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_endpoint.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_provision.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_provision_cloud.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_resource.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_retry.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_security.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_store.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_tag.cpp (1 hunks)
- sonar-project.properties (1 hunks)
Files skipped from review due to trivial changes (2)
- api/plgd/unittest/plgd_dps_tag.cpp
- sonar-project.properties
Files skipped from review as they are similar to previous changes (16)
- .github/workflows/cmake-linux.yml
- .github/workflows/sonar-cloud-analysis.yml
- .github/workflows/static-analysis.yml
- api/plgd/device-provisioning-client/plgd_dps_context_internal.h
- api/plgd/device-provisioning-client/plgd_dps_resource.c
- api/plgd/device-provisioning-client/plgd_dps_retry.c
- api/plgd/unittest/plgd_dps.cpp
- api/plgd/unittest/plgd_dps_context.cpp
- api/plgd/unittest/plgd_dps_dhcp.cpp
- api/plgd/unittest/plgd_dps_endpoint.cpp
- api/plgd/unittest/plgd_dps_provision.cpp
- api/plgd/unittest/plgd_dps_provision_cloud.cpp
- api/plgd/unittest/plgd_dps_resource.cpp
- api/plgd/unittest/plgd_dps_retry.cpp
- api/plgd/unittest/plgd_dps_security.cpp
- api/plgd/unittest/plgd_dps_store.cpp
Additional context used
cppcheck
api/plgd/device-provisioning-client/plgd_dps_context.c
[error] 103-103: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_store.c
[error] 103-103: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps.c
[error] 103-103: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
Additional comments not posted (28)
api/plgd/device-provisioning-client/plgd_dps_context.c (8)
1-17: LGTM!The Apache 2.0 license header is correctly formatted.
40-44: LGTM!The
dps_on_endpoint_changefunction looks good. It is correctly casting thevoid*parameter toplgd_dps_context_t*before passing it todps_store_dump_async.
87-114: LGTM!The
dps_context_initfunction looks good. It is correctly initializing all the fields of theplgd_dps_context_tstruct.Tools
cppcheck
[error] 103-103: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
116-127: LGTM!The
dps_context_deinitfunction looks good. It is correctly deinitializing all the fields of theplgd_dps_context_tstruct and freeing the allocated memory.
129-144: LGTM!The
dps_context_resetfunction looks good. It is correctly resetting all the fields of theplgd_dps_context_tstruct to their initial state.
156-165: LGTM!The
plgd_dps_on_factory_resetfunction looks good. It is correctly resetting the context on a factory reset.
283-297: LGTM!The
plgd_dps_set_configuration_resourcefunction looks good. It is correctly managing the lifecycle of the configuration resource based on thecreate_resourceparameter.
103-103: Skipping the static analysis hint.The unknown macro error reported by cppcheck is a false positive and can be safely ignored as the
dps_endpoint_add_peerfunction is not used in this file.Tools
cppcheck
[error] 103-103: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_store.c (3)
226-232: LGTM!The use of the
oc_storageAPI for persistence is correct.Also applies to: 320-370
142-215: LGTM!The use of the
oc_repAPI for CBOR encoding/decoding is correct.Also applies to: 255-276, 311-318
281-307: LGTM!The use of dynamic memory allocation is correct. The allocated buffers are properly freed.
Also applies to: 326-355
api/plgd/device-provisioning-client/plgd_dps.c (11)
36-44: LGTM!The code changes are approved.
46-52: LGTM!The code changes are approved.
63-124: LGTM!The code changes are approved.
Tools
cppcheck
[error] 103-103: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
126-146: LGTM!The code changes are approved.
148-156: LGTM!The code changes are approved.
158-164: LGTM!The code changes are approved.
168-185: LGTM!The code changes are approved.
187-208: LGTM!The code changes are approved.
238-257: LGTM!The code changes are approved.
259-278: LGTM!The code changes are approved.
103-103: Skipping the static analysis hint.The unknown macro error reported by the static analysis tool is a false positive. The
dps_endpoint_add_peerfunction is defined in another file and is not a macro.Tools
cppcheck
[error] 103-103: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
CMakeLists.txt (6)
80-83: LGTM!The code changes are approved.
175-175: LGTM!The code changes are approved.
239-239: LGTM!The code changes are approved.
408-436: LGTM!The code changes are approved.
679-681: LGTM!The code changes are approved.
Also applies to: 683-683
1105-1114: LGTM!The code changes are approved.
Danielius1922
force-pushed
the
adam/feature/dps
branch
2 times, most recently
from
457f597
to
f9b0d8e
Compare
There was a problem hiding this comment.
Caution
Inline review comments failed to post
Actionable comments posted: 4
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (31)
- .dockerignore (1 hunks)
- .github/workflows/cmake-linux.yml (2 hunks)
- .github/workflows/plgd-dps-test-with-cfg.yml (1 hunks)
- .github/workflows/plgd-dps-tests.yml (1 hunks)
- .github/workflows/sonar-cloud-analysis.yml (3 hunks)
- .github/workflows/static-analysis.yml (2 hunks)
- CMakeLists.txt (8 hunks)
- api/plgd/device-provisioning-client/plgd_dps.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_context.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_context_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_resource.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_resource_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_retry.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_store.c (1 hunks)
- api/plgd/unittest/plgd_dps.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_context.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_dhcp.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_endpoint.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_provision.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_provision_cloud.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_resource.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_retry.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_security.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_store.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_tag.cpp (1 hunks)
- apps/CMakeLists.txt (1 hunks)
- apps/dps_cloud_server.c (1 hunks)
- docker/apps/Dockerfile.cloud-server (2 hunks)
- docker/apps/Dockerfile.dps-cloud-server (1 hunks)
- docker/apps/Dockerfile.dps-cloud-server-debug (1 hunks)
- sonar-project.properties (1 hunks)
Files skipped from review due to trivial changes (1)
- sonar-project.properties
Files skipped from review as they are similar to previous changes (16)
- .github/workflows/cmake-linux.yml
- .github/workflows/sonar-cloud-analysis.yml
- api/plgd/device-provisioning-client/plgd_dps_resource.c
- api/plgd/device-provisioning-client/plgd_dps_resource_internal.h
- api/plgd/device-provisioning-client/plgd_dps_retry.c
- api/plgd/unittest/plgd_dps.cpp
- api/plgd/unittest/plgd_dps_context.cpp
- api/plgd/unittest/plgd_dps_dhcp.cpp
- api/plgd/unittest/plgd_dps_endpoint.cpp
- api/plgd/unittest/plgd_dps_provision.cpp
- api/plgd/unittest/plgd_dps_provision_cloud.cpp
- api/plgd/unittest/plgd_dps_resource.cpp
- api/plgd/unittest/plgd_dps_retry.cpp
- api/plgd/unittest/plgd_dps_security.cpp
- api/plgd/unittest/plgd_dps_store.cpp
- api/plgd/unittest/plgd_dps_tag.cpp
Additional context used
actionlint
.github/workflows/plgd-dps-tests.yml
33-33: property "build_type" is not defined in object type {build_args: string}
(expression)
34-34: property "skip" is not defined in object type {build_args: string}
(expression)
.github/workflows/plgd-dps-test-with-cfg.yml
59-59: shellcheck reported issue in this script: SC2215:warning:2:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
59-59: shellcheck reported issue in this script: SC2215:warning:3:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
59-59: shellcheck reported issue in this script: SC2215:warning:4:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
59-59: shellcheck reported issue in this script: SC2215:warning:5:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
68-68: shellcheck reported issue in this script: SC2215:warning:3:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
68-68: shellcheck reported issue in this script: SC2215:warning:4:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
68-68: shellcheck reported issue in this script: SC2215:warning:5:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
68-68: shellcheck reported issue in this script: SC2215:warning:7:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
68-68: shellcheck reported issue in this script: SC2215:warning:8:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
68-68: shellcheck reported issue in this script: SC2215:warning:9:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
68-68: shellcheck reported issue in this script: SC2215:warning:10:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
68-68: shellcheck reported issue in this script: SC2215:warning:11:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
68-68: shellcheck reported issue in this script: SC2215:warning:12:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
68-68: shellcheck reported issue in this script: SC2215:warning:13:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
68-68: shellcheck reported issue in this script: SC2046:warning:14:14: Quote this to prevent word splitting
(shellcheck)
87-87: shellcheck reported issue in this script: SC2215:warning:2:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
87-87: shellcheck reported issue in this script: SC2215:warning:3:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
87-87: shellcheck reported issue in this script: SC2215:warning:4:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
87-87: shellcheck reported issue in this script: SC2215:warning:6:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
87-87: shellcheck reported issue in this script: SC2215:warning:7:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
87-87: shellcheck reported issue in this script: SC2215:warning:8:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
87-87: shellcheck reported issue in this script: SC2215:warning:9:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
87-87: shellcheck reported issue in this script: SC2215:warning:10:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
87-87: shellcheck reported issue in this script: SC2046:warning:11:18: Quote this to prevent word splitting
(shellcheck)
101-101: shellcheck reported issue in this script: SC2046:warning:1:62: Quote this to prevent word splitting
(shellcheck)
cppcheck
api/plgd/device-provisioning-client/plgd_dps_context.c
[error] 103-103: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_store.c
[error] 103-103: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps.c
[error] 103-103: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
Additional comments not posted (23)
.dockerignore (3)
4-6: Approved: Exclusion patterns for build artifacts.The addition of patterns
**/*.o,**/*.gcno, and**/*.gcdais appropriate as it helps in excluding build and coverage artifacts from Docker images, which optimizes the build process.
9-9: Approved: Enhanced directory exclusion pattern.Modifying the exclusion pattern from
build/tobuild*/is beneficial as it allows for the exclusion of any directories starting with "build", which can vary across different projects or configurations.
10-10: Approved: Exclusion of Docker directories.The addition of the
docker/pattern to the.dockerignorefile is a prudent choice to exclude unnecessary Docker-related directories from the build context, enhancing the build efficiency..github/workflows/plgd-dps-tests.yml (1)
10-13: Approved: Workflow trigger changes.Commenting out the
pushandpull_requesttriggers for the master branch aligns with the PR's objective to control workflow execution. Ensure to verify the impact on the CI/CD processes to avoid disrupting development workflows.Run the following script to verify the impact on CI/CD processes:
docker/apps/Dockerfile.dps-cloud-server-debug (1)
1-23: Approved: Dockerfile configuration for dps-cloud-server.The Dockerfile is well-configured for building the dps-cloud-server in a debug environment. It uses best practices such as non-root user setup and parameterized build commands to enhance security and flexibility.
docker/apps/Dockerfile.cloud-server (2)
1-1: Base image updated to Alpine 3.20.The update to
alpine:3.20in the build stage is approved as it likely includes security and performance enhancements.
20-20: Service stage base image updated to Alpine 3.20.The update to
alpine:3.20in the service stage is approved, ensuring consistency and likely benefiting from the latest Alpine improvements.docker/apps/Dockerfile.dps-cloud-server (3)
1-5: Initial setup and package installation approved.The use of
ubuntu:22.04as the base image and the installation of essential build tools and libraries are correctly implemented. The non-interactive mode and cleanup steps are best practices for Dockerfiles.
8-21: Build configuration and compilation setup approved.The CMake configuration and build commands are well-structured and include optimizations such as parallel builds using
nproc. The detailed feature flags indicate a tailored build process.
23-33: Service setup and security practices approved.The setup for the runtime environment, including running the server as a non-root user, is correctly implemented and follows security best practices.
.github/workflows/static-analysis.yml (1)
19-25: Matrix strategy setup forclang-tidy-linuxjob approved.The introduction of a matrix strategy with various build configurations enhances the testing process by allowing parallel testing of different scenarios. The
fail-fast: falsesetting is appropriate for comprehensive testing..github/workflows/plgd-dps-test-with-cfg.yml (2)
8-27: Workflow setup and environment variables are correctly configured.The use of
workflow_callmakes this workflow reusable, which is a good practice for modular CI/CD setups. The environment variables are appropriately set for Docker operations.
28-37: Job configuration and conditional execution are well-implemented.The job uses conditional execution based on the
skipinput, which is a good practice to control workflow runs. The choice of Ubuntu 22.04 ensures compatibility with recent software updates.api/plgd/device-provisioning-client/plgd_dps_context_internal.h (2)
19-31: Header guards and included headers are correctly configured.The header guards (
PLGD_DPS_CONTEXT_INTERNAL_H) are appropriately defined to prevent multiple inclusions. The included headers are necessary for the types and functions used in this file.
39-149: Structure definitions and function declarations are well-organized and clear.The structures
plgd_dps_store_tandplgd_dps_certificate_fingerprint_tare well-defined with clear documentation comments. Function declarations for context management are clear and include necessary attributes likeOC_NONNULLto enforce non-null arguments.api/plgd/device-provisioning-client/plgd_dps_context.c (2)
40-127: Function implementations and memory management are correctly handled.The functions for context allocation and deallocation use
oc_memb_allocandoc_memb_free, which are suitable for efficient memory management in embedded systems. The implementations are clear and follow the declarations in the header file.Tools
cppcheck
[error] 103-103: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
156-274: Error handling and provisioning logic are robust and well-documented.The functions for setting errors and handling provisioning status changes include comprehensive checks and notifications. The use of assertions to validate arguments is appropriate and helps prevent runtime errors.
apps/CMakeLists.txt (1)
230-236: Conditional inclusion ofdps_cloud_servertarget is correctly implemented.The changes to conditionally include the
dps_cloud_servertarget based on thePLGD_DEV_DEVICE_PROVISIONING_ENABLEDflag are correctly implemented. However, ensure that this flag is well-documented and set appropriately in the project's configuration files or documentation.Run the following script to verify the configuration of the
PLGD_DEV_DEVICE_PROVISIONING_ENABLEDflag:Verification successful
The
PLGD_DEV_DEVICE_PROVISIONING_ENABLEDflag is documented and configured correctly.The flag is defined with a default value and description in the CMakeLists.txt file, and there are appropriate checks to ensure it is only enabled when necessary dependencies are met. No further action is needed.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the configuration of the `PLGD_DEV_DEVICE_PROVISIONING_ENABLED` flag. # Test: Search for the flag definition. Expect: Definition or documentation of the flag. rg --type cmake 'PLGD_DEV_DEVICE_PROVISIONING_ENABLED'Length of output: 911
api/plgd/device-provisioning-client/plgd_dps_store.c (1)
19-28: Header organization and inclusion are appropriate for the functionality.The structure and organization of the headers in this file are appropriate and follow common C/C++ practices. This organization helps in understanding the dependencies and the specific role of this file within the device provisioning system.
api/plgd/device-provisioning-client/plgd_dps.c (2)
19-27: Header organization and inclusion are appropriate for the functionality.The structure and organization of the headers in this file are appropriate and follow common C/C++ practices. This organization helps in understanding the dependencies and the specific role of this file within the device provisioning system.
19-27: Verify macro definitions to address static analysis hint.The static analysis tool flagged an issue with an unknown macro. Please verify that all macros used in this file and its included headers are defined appropriately. This may require checking the configuration files or other parts of the codebase.
Run the following script to search for macro definitions in the codebase:
CMakeLists.txt (2)
80-84: Feature Flags Added for PLGDThe addition of
PLGD_DEV_TIME_ENABLED,PLGD_DEV_DEVICE_PROVISIONING_ENABLED, andPLGD_DEV_DEVICE_PROVISIONING_TEST_PROPERTIES_ENABLEDflags are correctly implemented to control feature-specific build processes.Run the following script to verify the usage of these flags in the build process:
Verification successful
Feature Flags Implementation Verified
The feature flags
PLGD_DEV_TIME_ENABLED,PLGD_DEV_DEVICE_PROVISIONING_ENABLED, andPLGD_DEV_DEVICE_PROVISIONING_TEST_PROPERTIES_ENABLEDare correctly implemented and consistently used throughout the CMake configuration. They effectively control feature-specific build processes and ensure necessary dependencies are met.
- The flags are used in conditional checks to append compile definitions and include necessary files.
- Compatibility checks with other features are in place to prevent configuration errors.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the usage of PLGD feature flags in the CMake configuration. # Test: Search for the usage of PLGD feature flags. Expect: Usage in conditional checks and configurations. rg --type cmake -A 5 $'PLGD_DEV_TIME_ENABLED|PLGD_DEV_DEVICE_PROVISIONING_ENABLED|PLGD_DEV_DEVICE_PROVISIONING_TEST_PROPERTIES_ENABLED'Length of output: 4074
683-683: Library Definition Updated with Conditional Source InclusionThe inclusion of
${PLGD_DPS_SRC}in theclient-server-objlibrary definition is correctly implemented. Ensure that${PLGD_DPS_SRC}is defined and populated conditionally based on the relevant feature flags.Run the following script to verify the definition and conditional inclusion of
${PLGD_DPS_SRC}:Verification successful
Conditional Inclusion of
${PLGD_DPS_SRC}VerifiedThe inclusion of
${PLGD_DPS_SRC}in theclient-server-objlibrary is correctly conditioned on thePLGD_DEV_DEVICE_PROVISIONING_ENABLEDfeature flag. This ensures that the device provisioning source files are only included when the feature is enabled, maintaining modularity in the build configuration.
- The
api/plgd/plgd.cmakefile is included conditionally inCMakeLists.txtusingif(PLGD_DEV_DEVICE_PROVISIONING_ENABLED).Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the definition and conditional inclusion of `${PLGD_DPS_SRC}` in the CMake configuration. # Test: Search for the definition and usage of `${PLGD_DPS_SRC}`. Expect: Definition based on feature flags and usage in library definitions. rg --type cmake -A 5 $'PLGD_DPS_SRC'Length of output: 826
Script:
#!/bin/bash # Description: Search for conditional logic related to `${PLGD_DPS_SRC}` in CMake files. # Test: Look for conditional statements that might affect the inclusion of `${PLGD_DPS_SRC}`. rg --type cmake -A 5 -B 5 'PLGD_DPS_SRC'Length of output: 1049
Comments failed to post (4)
.github/workflows/plgd-dps-tests.yml (1)
16-34: Suggest corrections for matrix strategy expressions.
The
workflow_dispatchconfiguration is correctly set up for manual triggers. However, the expressions used in the matrix strategy forbuild_typeandskipproperties need adjustments as they reference potentially undefined properties. Consider defining these properties explicitly in the matrix or adjusting the expressions to avoid runtime errors.Apply this diff to correct the matrix strategy expressions:
- build_type: ${{ (github.event_name == 'workflow_dispatch' && inputs.build_type) || (matrix.build_type || 'Debug') }} - skip: ${{ matrix.skip || false }} + build_type: ${{ github.event_name == 'workflow_dispatch' ? inputs.build_type : 'Debug' }} + skip: ${{ github.event_name == 'workflow_dispatch' ? inputs.skip : false }}Committable suggestion was skipped due to low confidence.
Tools
actionlint
33-33: property "build_type" is not defined in object type {build_args: string}
(expression)
34-34: property "skip" is not defined in object type {build_args: string}
(expression)
.github/workflows/plgd-dps-test-with-cfg.yml (1)
38-147: Address shell script issues and improve Docker command configurations.
Several shell scripts have been flagged by static analysis tools for potential issues such as improper flag usage and missing quotes. These issues can lead to script failures or unexpected behavior.
Consider addressing these issues by ensuring proper syntax and quoting in shell scripts. For example, ensure that all Docker run commands are properly formatted and that flags are not misinterpreted as commands.
# Example fix for shell script issues docker run --rm --log-driver local --network=host \ -e PREPARE_ENV=true \ -e RUN=false \ -v /tmp/data:/data \ -v /var/run/docker.sock:/var/run/docker.sock \ ${{ env.TEST_DPS_IMAGE }}Tools
actionlint
59-59: shellcheck reported issue in this script: SC2215:warning:2:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
59-59: shellcheck reported issue in this script: SC2215:warning:3:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
59-59: shellcheck reported issue in this script: SC2215:warning:4:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
59-59: shellcheck reported issue in this script: SC2215:warning:5:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
68-68: shellcheck reported issue in this script: SC2215:warning:3:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
68-68: shellcheck reported issue in this script: SC2215:warning:4:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
68-68: shellcheck reported issue in this script: SC2215:warning:5:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
68-68: shellcheck reported issue in this script: SC2215:warning:7:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
68-68: shellcheck reported issue in this script: SC2215:warning:8:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
68-68: shellcheck reported issue in this script: SC2215:warning:9:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
68-68: shellcheck reported issue in this script: SC2215:warning:10:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
68-68: shellcheck reported issue in this script: SC2215:warning:11:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
68-68: shellcheck reported issue in this script: SC2215:warning:12:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
68-68: shellcheck reported issue in this script: SC2215:warning:13:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
68-68: shellcheck reported issue in this script: SC2046:warning:14:14: Quote this to prevent word splitting
(shellcheck)
87-87: shellcheck reported issue in this script: SC2215:warning:2:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
87-87: shellcheck reported issue in this script: SC2215:warning:3:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
87-87: shellcheck reported issue in this script: SC2215:warning:4:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
87-87: shellcheck reported issue in this script: SC2215:warning:6:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
87-87: shellcheck reported issue in this script: SC2215:warning:7:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
87-87: shellcheck reported issue in this script: SC2215:warning:8:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
87-87: shellcheck reported issue in this script: SC2215:warning:9:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
87-87: shellcheck reported issue in this script: SC2215:warning:10:3: This flag is used as a command name. Bad line break or missing [ .. ]?
(shellcheck)
87-87: shellcheck reported issue in this script: SC2046:warning:11:18: Quote this to prevent word splitting
(shellcheck)
101-101: shellcheck reported issue in this script: SC2046:warning:1:62: Quote this to prevent word splitting
(shellcheck)
api/plgd/device-provisioning-client/plgd_dps_store.c (1)
19-28: > [!TIP]
Codebase Verification
Incomplete macro definition for
DPS_STORE_HAS_BEEN_PROVISIONED_SINCE_RESET.The macro
DPS_STORE_HAS_BEEN_PROVISIONED_SINCE_RESETinplgd_dps_store.cis defined with a backslash for continuation but lacks a continuation line. This incomplete definition is likely causing the static analysis tool to flag an unknown macro. Please review and correct this definition.
- File:
api/plgd/device-provisioning-client/plgd_dps_store.c- Line:
#define DPS_STORE_HAS_BEEN_PROVISIONED_SINCE_RESET \Analysis chain
Verify macro definitions to address static analysis hint.
The static analysis tool flagged an issue with an unknown macro. Please verify that all macros used in this file and its included headers are defined appropriately. This may require checking the configuration files or other parts of the codebase.
Run the following script to search for macro definitions in the codebase:
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Search for macro definitions in the codebase. # Test: Search for macro definitions. Expect: Definitions of all used macros. rg --type c 'define' | grep -i 'macro_name'Length of output: 41
Script:
#!/bin/bash # Description: Search for all macro usages in the file and verify their definitions in the codebase. # Step 1: Search for all macro usages in the file `plgd_dps_store.c`. rg --type c --no-filename --no-line-number '#\s*define' api/plgd/device-provisioning-client/plgd_dps_store.c # Step 2: Search for definitions of these macros in the codebase. # Note: Replace 'MACRO_NAME' with actual macro names found in Step 1. rg --type c 'define\s+(MACRO_NAME)'Length of output: 500
Script:
#!/bin/bash # Description: Verify definitions of macros found in `plgd_dps_store.c` across the codebase. # Search for definitions of each macro in the codebase. rg --type c 'DPS_STORE_NAME' rg --type c 'DPS_STORE_ENDPOINT' rg --type c 'DPS_STORE_ENDPOINT_NAME' rg --type c 'DPS_STORE_ENDPOINTS' rg --type c 'DPS_STORE_ENDPOINTS_URI' rg --type c 'DPS_STORE_ENDPOINTS_NAME' rg --type c 'DPS_STORE_OWNER' rg --type c 'DPS_STORE_HAS_BEEN_PROVISIONED_SINCE_RESET' rg --type c 'DPS_TAG_MAX'Length of output: 6409
apps/dps_cloud_server.c (1)
1829-1951: Main Function Setup for Device Provisioning Reviewed
The structure and setup in the
mainfunction are well-organized for handling device provisioning. However, consider enhancing error handling by centralizing it or using a function to handle repeated cleanup tasks to avoid redundancy and potential errors in future modifications.Consider implementing a cleanup function to centralize resource release and error logging, improving maintainability and reducing potential errors during future modifications.
Example refactor for centralized cleanup:
void cleanup(int exit_code) { shutdown(g_device_id); deinit(); exit(exit_code); } // Use in main function if (error_condition) { printf("ERROR: detailed error message\n"); cleanup(EXIT_FAILURE); }
Danielius1922
force-pushed
the
adam/feature/dps
branch
4 times, most recently
from
0e81ede
to
7ec74ef
Compare
There was a problem hiding this comment.
Caution
Inline review comments failed to post
Actionable comments posted: 2
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (35)
- .dockerignore (1 hunks)
- .github/workflows/check-format.yml (1 hunks)
- .github/workflows/cmake-linux.yml (3 hunks)
- .github/workflows/cmake-windows.yml (1 hunks)
- .github/workflows/doxygen-publish.yml (1 hunks)
- .github/workflows/doxygen.yml (1 hunks)
- .github/workflows/plgd-dps-test-with-cfg.yml (1 hunks)
- .github/workflows/plgd-dps-tests.yml (1 hunks)
- .github/workflows/sonar-cloud-analysis.yml (4 hunks)
- .github/workflows/static-analysis.yml (2 hunks)
- CMakeLists.txt (8 hunks)
- api/plgd/device-provisioning-client/plgd_dps.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_context.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_context_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_resource.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_resource_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_retry.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_store.c (1 hunks)
- api/plgd/unittest/plgd_dps.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_context.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_dhcp.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_endpoint.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_provision.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_provision_cloud.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_resource.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_retry.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_security.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_store.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_tag.cpp (1 hunks)
- apps/CMakeLists.txt (1 hunks)
- apps/dps_cloud_server.c (1 hunks)
- docker/apps/Dockerfile.cloud-server (2 hunks)
- docker/apps/Dockerfile.dps-cloud-server (1 hunks)
- docker/apps/Dockerfile.dps-cloud-server-debug (1 hunks)
- sonar-project.properties (1 hunks)
Files not reviewed due to server errors (3)
- api/plgd/device-provisioning-client/plgd_dps_context.c
- api/plgd/device-provisioning-client/plgd_dps_store.c
- api/plgd/device-provisioning-client/plgd_dps.c
Files skipped from review due to trivial changes (8)
- .github/workflows/check-format.yml
- .github/workflows/cmake-windows.yml
- .github/workflows/doxygen-publish.yml
- .github/workflows/doxygen.yml
- api/plgd/device-provisioning-client/plgd_dps_context_internal.h
- api/plgd/device-provisioning-client/plgd_dps_retry.c
- docker/apps/Dockerfile.cloud-server
- sonar-project.properties
Files skipped from review as they are similar to previous changes (20)
- .dockerignore
- .github/workflows/cmake-linux.yml
- .github/workflows/sonar-cloud-analysis.yml
- api/plgd/device-provisioning-client/plgd_dps_resource.c
- api/plgd/device-provisioning-client/plgd_dps_resource_internal.h
- api/plgd/unittest/plgd_dps.cpp
- api/plgd/unittest/plgd_dps_context.cpp
- api/plgd/unittest/plgd_dps_dhcp.cpp
- api/plgd/unittest/plgd_dps_endpoint.cpp
- api/plgd/unittest/plgd_dps_provision.cpp
- api/plgd/unittest/plgd_dps_provision_cloud.cpp
- api/plgd/unittest/plgd_dps_resource.cpp
- api/plgd/unittest/plgd_dps_retry.cpp
- api/plgd/unittest/plgd_dps_security.cpp
- api/plgd/unittest/plgd_dps_store.cpp
- api/plgd/unittest/plgd_dps_tag.cpp
- apps/CMakeLists.txt
- apps/dps_cloud_server.c
- docker/apps/Dockerfile.dps-cloud-server
- docker/apps/Dockerfile.dps-cloud-server-debug
Additional context used
actionlint
.github/workflows/plgd-dps-tests.yml
33-33: property "build_type" is not defined in object type {build_args: string}
(expression)
34-34: property "skip" is not defined in object type {build_args: string}
(expression)
.github/workflows/plgd-dps-test-with-cfg.yml
70-70: shellcheck reported issue in this script: SC2046:warning:2:369: Quote this to prevent word splitting
(shellcheck)
89-89: shellcheck reported issue in this script: SC2046:warning:1:345: Quote this to prevent word splitting
(shellcheck)
103-103: shellcheck reported issue in this script: SC2046:warning:1:62: Quote this to prevent word splitting
(shellcheck)
cppcheck
api/plgd/device-provisioning-client/plgd_dps_context.c
[error] 103-103: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_store.c
[error] 103-103: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps.c
[error] 103-103: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
Additional comments not posted (10)
.github/workflows/plgd-dps-tests.yml (1)
8-22: Approved manual trigger configuration.The changes to disable automatic triggers (
pushandpull_request) and enable manual triggering viaworkflow_dispatchare appropriate for controlled test execution environments. This setup prevents unintended executions and allows for manual control over when and how the tests are run..github/workflows/static-analysis.yml (2)
8-12: Approved manual trigger configuration.Similar to the previous file, disabling automatic triggers (
pushandpull_request) and enabling manual triggering viaworkflow_dispatchare appropriate for controlled execution environments. This setup allows for manual control over when and how the static analysis is run, which can be crucial for sensitive or resource-intensive analysis tasks.
19-25: Approved matrix strategy configuration.The introduction of a matrix strategy with various build arguments is a significant enhancement. It allows for parallel testing of multiple configurations, which improves the efficiency and comprehensiveness of the CI/CD pipeline. This setup enables the workflow to run different builds with specific flags, effectively testing various scenarios without the need to duplicate job definitions.
.github/workflows/plgd-dps-test-with-cfg.yml (1)
8-23: Approved workflow trigger and input configurations.The use of
workflow_callas a trigger and the well-defined inputs with descriptions and default values are excellent practices. These configurations enhance the modularity, reusability, and flexibility of the workflow, making it easy to integrate and trigger from other workflows.CMakeLists.txt (6)
81-81: Clarification on PLGD_DEV_TIME_ENABLED setting.The setting for
PLGD_DEV_TIME_ENABLEDhas been moved within the file. Ensure that this setting is correctly referenced throughout the project to avoid any build configuration issues.Verification successful
PLGD_DEV_TIME_ENABLED is correctly referenced.
The
PLGD_DEV_TIME_ENABLEDsetting is consistently used throughout theCMakeLists.txtfile, with appropriate conditional checks and dependencies. No issues were found with its references.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that PLGD_DEV_TIME_ENABLED is correctly referenced throughout the project. # Test: Search for the setting usage. Expect: Consistent usage across the project. rg --type cmake -A 5 $'PLGD_DEV_TIME_ENABLED'Length of output: 2140
239-239: Refactoring of logging level configuration.The introduction of
oc_set_maximum_log_levelfunction abstracts away the previous conditional logic into a single call. This enhances readability and maintainability. Ensure that this function is defined and used correctly throughout the project.Verification successful
Function
oc_set_maximum_log_levelis correctly defined and used.The function
oc_set_maximum_log_levelis defined intools/utils.cmakeand used inCMakeLists.txt, aligning with the intended refactoring to enhance readability and maintainability. No issues were found with its definition or usage.
- Definition:
tools/utils.cmake- Usage:
CMakeLists.txtScripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that oc_set_maximum_log_level function is defined and used correctly. # Test: Search for the function definition and usage. Expect: Correct definition and consistent usage. rg --type cmake -A 5 $'oc_set_maximum_log_level'Length of output: 931
82-82: New feature toggle added for device provisioning.The addition of
PLGD_DEV_DEVICE_PROVISIONING_ENABLEDis a significant change. Ensure that this feature is integrated correctly across the project and that all dependent features are enabled before this feature is activated.Verification successful
Feature toggle integration verified successfully.
The feature toggle
PLGD_DEV_DEVICE_PROVISIONING_ENABLEDis integrated correctly with appropriate conditional checks to ensure that all dependent features are enabled before activation. The checks inCMakeLists.txtprevent conflicts and ensure necessary dependencies are met. No issues found.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that all dependent features are enabled before PLGD_DEV_DEVICE_PROVISIONING_ENABLED is activated. # Test: Search for the feature usage. Expect: Correct conditional checks before activation. rg --type cmake -A 5 $'PLGD_DEV_DEVICE_PROVISIONING_ENABLED'Length of output: 2761
680-680: Inclusion of PLGD cmake configuration.The inclusion of
plgd.cmakeis a significant change that likely introduces additional configurations or dependencies. Ensure that this file is present in the project and that it is correctly formatted and functional.Verification successful
PLGD cmake configuration is present and correctly formatted.
The
plgd.cmakefile is present in the project and appears to be correctly formatted. It includes a global include guard and usesfile(GLOB ...)to gather source files, which are standard CMake practices. No issues were found with its inclusion.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that plgd.cmake file is present and correctly formatted. # Test: Check for the presence and content of plgd.cmake. Expect: File exists and is correctly formatted. cat api/plgd/plgd.cmakeLength of output: 139
1105-1114: Conditional compilation for PLGD tests.The conditional compilation for PLGD tests based on
PLGD_DEV_TIME_ENABLEDorPLGD_DEV_DEVICE_PROVISIONING_ENABLEDis a good practice to ensure that tests are only compiled when relevant features are enabled. Verify that the tests cover all necessary aspects of the PLGD features.
683-683: Library definition updated to include PLGD_DPS_SRC.The addition of
${PLGD_DPS_SRC}to theclient-server-objlibrary definition is crucial for including the necessary sources for device provisioning. Verify that this source variable is correctly set and that the sources it includes are appropriate for the build.Verification successful
PLGD_DPS_SRC is correctly set and includes appropriate sources. The
PLGD_DPS_SRCvariable is populated with multiple.cfiles from theapi/plgd/device-provisioning-clientdirectory, confirming that it is correctly set for the build. No issues were found with the inclusion of these sources.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that PLGD_DPS_SRC is correctly set and includes appropriate sources. # Test: Search for the variable definition and check included sources. Expect: Correctly set variable and appropriate sources. rg --type cmake -A 5 $'PLGD_DPS_SRC'Length of output: 826
Script:
#!/bin/bash # List all .c files in the api/plgd/device-provisioning-client directory to verify PLGD_DPS_SRC contents. fd --extension c --type f --strip-cwd-prefix api/plgd/device-provisioning-clientLength of output: 528
Script:
#!/bin/bash # Corrected command to list all .c files in the api/plgd/device-provisioning-client directory. fd --extension c --type f --strip-cwd-prefix . api/plgd/device-provisioning-clientLength of output: 278
Script:
#!/bin/bash # List all .c files in the api/plgd/device-provisioning-client directory without using --strip-cwd-prefix. fd --extension c --type f api/plgd/device-provisioning-clientLength of output: 509
Script:
#!/bin/bash # Use the suggested approach to list all .c files in the api/plgd/device-provisioning-client directory. fd . --extension c --type f api/plgd/device-provisioning-clientLength of output: 1164
Comments failed to post (2)
.github/workflows/plgd-dps-tests.yml (1)
23-34: Address undefined matrix properties.
The static analysis tool has flagged the use of
build_typeandskipproperties in the matrix configuration, which are not defined. This can lead to runtime errors. Consider defining these properties within the matrix or ensure their usage is properly handled to avoid issues.To resolve the issues, you can modify the matrix configuration as follows:
matrix: include: - build_args: "" + build_type: "Debug" # Default build type + skip: false # Default skip valueCommittable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.jobs: plgd-hub-test: strategy: fail-fast: false matrix: include: - build_args: "" build_type: "Debug" # Default build type skip: false # Default skip value uses: ./.github/workflows/plgd-dps-test-with-cfg.yml with: build_args: ${{ matrix.build_args }} build_type: ${{ (github.event_name == 'workflow_dispatch' && inputs.build_type) || (matrix.build_type || 'Debug') }} skip: ${{ matrix.skip || false }}Tools
actionlint
33-33: property "build_type" is not defined in object type {build_args: string}
(expression)
34-34: property "skip" is not defined in object type {build_args: string}
(expression)
.github/workflows/plgd-dps-test-with-cfg.yml (1)
70-111: Fix shell scripting issues to prevent word splitting.
Static analysis has flagged potential word splitting issues in shell commands. It's crucial to quote variables and command substitutions to prevent word splitting and ensure that the scripts behave as expected, especially when dealing with paths or inputs that might contain spaces or special characters.
To address these issues, apply the following fixes:
- docker run --privileged -d --network=host --log-driver local -v /tmp/data/certs/device:/device-provisioning-client/build/apps/pki_certs -v /tmp/data/coverage:/data/coverage --name dps-devsim dps-dbg:latest --create-conf-resource --no-verify-ca --cloud-observer-max-retry 10 --expiration-limit 10 --retry-configuration 5 --log-level="debug" --wait-for-reset dps-devsim-$(hostname) + docker run --privileged -d --network=host --log-driver local -v "/tmp/data/certs/device:/device-provisioning-client/build/apps/pki_certs" -v "/tmp/data/coverage:/data/coverage" --name dps-devsim dps-dbg:latest --create-conf-resource --no-verify-ca --cloud-observer-max-retry 10 --expiration-limit 10 --retry-configuration 5 --log-level="debug" --wait-for-reset "dps-devsim-$(hostname)"Committable suggestion was skipped due to low confidence.
Tools
actionlint
70-70: shellcheck reported issue in this script: SC2046:warning:2:369: Quote this to prevent word splitting
(shellcheck)
89-89: shellcheck reported issue in this script: SC2046:warning:1:345: Quote this to prevent word splitting
(shellcheck)
103-103: shellcheck reported issue in this script: SC2046:warning:1:62: Quote this to prevent word splitting
(shellcheck)
Danielius1922
force-pushed
the
adam/feature/dps
branch
from
7ec74ef
to
8f0f4bd
Compare
Danielius1922
force-pushed
the
adam/feature/dps
branch
3 times, most recently
from
de59084
to
0c2c0f3
Compare
There was a problem hiding this comment.
Actionable comments posted: 6
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files ignored due to path filters (1)
tools/doxygen.iniis excluded by!**/*.ini
Files selected for processing (82)
- .dockerignore (1 hunks)
- .github/workflows/cmake-linux.yml (2 hunks)
- .github/workflows/docker-build-publish-with-cfg.yml (1 hunks)
- .github/workflows/docker-build-publish.yml (1 hunks)
- .github/workflows/ghcr-check.yml (1 hunks)
- .github/workflows/plgd-device-test-with-cfg.yml (1 hunks)
- .github/workflows/plgd-dps-test-with-cfg.yml (1 hunks)
- .github/workflows/plgd-dps-tests.yml (1 hunks)
- .github/workflows/plgd-hub-test-with-cfg.yml (1 hunks)
- .github/workflows/sonar-cloud-analysis.yml (4 hunks)
- .github/workflows/static-analysis.yml (2 hunks)
- .github/workflows/unit-test-with-cfg.yml (1 hunks)
- CMakeLists.txt (7 hunks)
- api/oc_endpoint.c (1 hunks)
- api/oc_log.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_apis.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_apis_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_cloud.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_cloud_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_context.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_context_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_dhcp.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_dhcp_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_endpoint.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_endpoint_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_endpoints.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_endpoints_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_log.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_log_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_manager.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_manager_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_pki.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_pki_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision_cloud.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision_cloud_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision_owner.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision_owner_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_resource.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_resource_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_retry.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_retry_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_security.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_security_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_store.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_store_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_tag.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_tag_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_time.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_time_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_verify_certificate.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_verify_certificate_internal.h (1 hunks)
- api/plgd/unittest/plgd_dps.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_apis.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_cloud.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_context.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_dhcp.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_endpoint.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_endpoints.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_log.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_manager.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_pki.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_provision.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_provision_cloud.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_provision_owner.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_resource.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_retry.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_security.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_store.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_tag.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_test.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_test.h (1 hunks)
- api/plgd/unittest/plgd_dps_time.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_verify_certificate.cpp (1 hunks)
- apps/CMakeLists.txt (1 hunks)
- apps/dps_cloud_server.c (1 hunks)
- docker/apps/Dockerfile.cloud-server (2 hunks)
- docker/apps/Dockerfile.dps-cloud-server (1 hunks)
- docker/apps/Dockerfile.dps-cloud-server-debug (1 hunks)
Files not processed due to max files limit (9)
- include/oc_log.h
- include/plgd/plgd_dps.h
- messaging/coap/observe.c
- security/oc_pstat.c
- security/oc_tls.c
- sonar-project.properties
- tools/utils.cmake
- util/oc_features.h
- util/oc_memb.h
Files skipped from review due to trivial changes (11)
- .github/workflows/plgd-device-test-with-cfg.yml
- .github/workflows/plgd-hub-test-with-cfg.yml
- .github/workflows/unit-test-with-cfg.yml
- api/plgd/device-provisioning-client/plgd_dps_apis_internal.h
- api/plgd/device-provisioning-client/plgd_dps_dhcp_internal.h
- api/plgd/device-provisioning-client/plgd_dps_endpoint_internal.h
- api/plgd/device-provisioning-client/plgd_dps_retry_internal.h
- api/plgd/device-provisioning-client/plgd_dps_security.c
- api/plgd/device-provisioning-client/plgd_dps_tag_internal.h
- api/plgd/unittest/plgd_dps.cpp
- api/plgd/unittest/plgd_dps_apis.cpp
Files skipped from review as they are similar to previous changes (47)
- .dockerignore
- .github/workflows/cmake-linux.yml
- .github/workflows/docker-build-publish-with-cfg.yml
- .github/workflows/docker-build-publish.yml
- .github/workflows/ghcr-check.yml
- .github/workflows/plgd-dps-tests.yml
- .github/workflows/static-analysis.yml
- api/oc_endpoint.c
- api/oc_log.c
- api/plgd/device-provisioning-client/plgd_dps_cloud_internal.h
- api/plgd/device-provisioning-client/plgd_dps_context_internal.h
- api/plgd/device-provisioning-client/plgd_dps_dhcp.c
- api/plgd/device-provisioning-client/plgd_dps_endpoints_internal.h
- api/plgd/device-provisioning-client/plgd_dps_internal.h
- api/plgd/device-provisioning-client/plgd_dps_log.c
- api/plgd/device-provisioning-client/plgd_dps_log_internal.h
- api/plgd/device-provisioning-client/plgd_dps_manager_internal.h
- api/plgd/device-provisioning-client/plgd_dps_provision_cloud_internal.h
- api/plgd/device-provisioning-client/plgd_dps_provision_internal.h
- api/plgd/device-provisioning-client/plgd_dps_provision_owner_internal.h
- api/plgd/device-provisioning-client/plgd_dps_resource.c
- api/plgd/device-provisioning-client/plgd_dps_resource_internal.h
- api/plgd/device-provisioning-client/plgd_dps_retry.c
- api/plgd/device-provisioning-client/plgd_dps_store_internal.h
- api/plgd/device-provisioning-client/plgd_dps_tag.c
- api/plgd/device-provisioning-client/plgd_dps_time_internal.h
- api/plgd/device-provisioning-client/plgd_dps_verify_certificate.c
- api/plgd/device-provisioning-client/plgd_dps_verify_certificate_internal.h
- api/plgd/unittest/plgd_dps_cloud.cpp
- api/plgd/unittest/plgd_dps_context.cpp
- api/plgd/unittest/plgd_dps_dhcp.cpp
- api/plgd/unittest/plgd_dps_endpoint.cpp
- api/plgd/unittest/plgd_dps_manager.cpp
- api/plgd/unittest/plgd_dps_provision.cpp
- api/plgd/unittest/plgd_dps_provision_owner.cpp
- api/plgd/unittest/plgd_dps_retry.cpp
- api/plgd/unittest/plgd_dps_security.cpp
- api/plgd/unittest/plgd_dps_store.cpp
- api/plgd/unittest/plgd_dps_tag.cpp
- api/plgd/unittest/plgd_dps_test.cpp
- api/plgd/unittest/plgd_dps_test.h
- api/plgd/unittest/plgd_dps_time.cpp
- apps/CMakeLists.txt
- apps/dps_cloud_server.c
- docker/apps/Dockerfile.cloud-server
- docker/apps/Dockerfile.dps-cloud-server
- docker/apps/Dockerfile.dps-cloud-server-debug
Additional context used
cppcheck
api/plgd/device-provisioning-client/plgd_dps_endpoints.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_endpoint.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_apis.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_provision_owner.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_time.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_context.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_manager.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_store.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_pki.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_provision_cloud.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_provision.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
actionlint
.github/workflows/plgd-dps-test-with-cfg.yml
122-122: shellcheck reported issue in this script: SC2046:warning:1:62: Quote this to prevent word splitting
(shellcheck)
134-134: shellcheck reported issue in this script: SC2129:style:2:1: Consider using { cmd1; cmd2; } >> file instead of individual redirects
(shellcheck)
134-134: shellcheck reported issue in this script: SC2086:info:2:53: Double quote to prevent globbing and word splitting
(shellcheck)
134-134: shellcheck reported issue in this script: SC2086:info:3:61: Double quote to prevent globbing and word splitting
(shellcheck)
134-134: shellcheck reported issue in this script: SC2086:info:4:48: Double quote to prevent globbing and word splitting
(shellcheck)
Additional comments not posted (196)
api/plgd/device-provisioning-client/plgd_dps_security_internal.h (1)
1-101: LGTM!The new header file
plgd_dps_security_internal.his well-structured and follows best practices:
- It includes necessary headers and defines essential functions related to device ownership, credentials, and ACLs.
- The file is well-documented with comments explaining the purpose of each function.
- It uses appropriate header guards to prevent multiple inclusions.
- The file is properly formatted and follows a consistent coding style.
- The inclusion of debug functions wrapped in
DPS_DBG_IS_ENABLEDmacro allows for easy enabling/disabling of debug functionality.- The use of
extern "C"ensures C linkage when used in C++ code.- The header file does not contain any implementation details, which is a good practice.
Great job!
api/plgd/unittest/plgd_dps_log.cpp (4)
62-63: The past review comment regarding the mismatch between the number of format specifiers and arguments in theprintfformat string is still valid. Please address this issue.
69-84: LGTM!The function logic is correct, and the implementation is accurate.
86-97: LGTM!The test function is correctly implemented and tests the expected behavior.
99-103: LGTM!The function logic is correct, and the implementation is accurate.
api/plgd/device-provisioning-client/plgd_dps_pki_internal.h (5)
1-17: License header looks good.The Apache 2.0 license header is correctly formatted and contains the necessary information.
19-32: Header guard and includes look good.
- The header guard is correctly defined.
- The necessary header files are included.
- The extern "C" block is correctly used for C++ compatibility.
34-47: DPS credentials URI macro anddps_pki_send_csrfunction look good.
- The macro is correctly defined.
- The function is correctly declared with the necessary attributes and parameters.
- The function documentation is clear and complete.
52-114: Certificate state enum, PKI configuration struct, and certificate validation and renewal functions look good.
- The enum is correctly defined with the necessary values.
- The struct is correctly defined with the necessary fields and documentation.
- The functions are correctly declared with the necessary attributes, parameters, and documentation.
- The functions have clear and concise names that describe their purpose.
117-150: Asynchronous certificate renewal and replacement functions look good.
- The functions are correctly declared with the necessary attributes, parameters, and documentation.
- The functions have clear and concise names that describe their purpose.
- The extern "C" block is correctly closed.
- The header guard is correctly closed.
api/plgd/unittest/plgd_dps_pki.cpp (6)
48-56: LGTM!The test case correctly covers the failure scenario when an invalid device ID is passed to the
dps_pki_send_csrfunction.
58-63: LGTM!The test case correctly covers the failure scenario when an invalid device ID is passed to the
dps_pki_replace_certificatesfunction.
65-94: LGTM!The test case correctly covers different expiration time scenarios for the
dps_pki_calculate_renew_certificates_intervalfunction.
112-125: LGTM!The test case correctly covers the failure scenario when an invalid representation is passed to the
dps_pki_replace_certificatesfunction.
127-142: LGTM!The test case correctly covers the success scenario for the
dps_pki_try_renew_certificatesfunction.
144-165: LGTM!The test case correctly covers the success scenario for the
dps_pki_renew_certificates_asyncfunction.api/plgd/device-provisioning-client/plgd_dps_endpoints.c (11)
36-63: LGTM!The function logic is correct, and the implementation is accurate. The function correctly handles the case where the endpoint is already set and notifies observers when necessary.
65-82: LGTM!The function logic is correct, and the implementation is accurate. The function correctly handles the case where the selected endpoint has changed and disconnects the current endpoint if necessary.
84-90: LGTM!The function logic is correct, and the implementation is accurate. The function is a simple wrapper that calls
dps_set_endpointwith the correct parameters.
92-113: LGTM!The function logic is correct, and the implementation is accurate. The function correctly handles the case where no endpoint is set and returns an error if the provided buffer is too small.
Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
115-120: LGTM!The function logic is correct, and the implementation is accurate. The function correctly checks if the selected endpoint is NULL and returns the appropriate value.
122-132: LGTM!The function logic is correct, and the implementation is accurate. The function correctly initializes the DPS service endpoints using
oc_endpoint_addresses_init.
134-142: LGTM!The function logic is correct, and the implementation is accurate. The function correctly adds a DPS service endpoint address using
oc_endpoint_addresses_add.
144-149: LGTM!The function logic is correct, and the implementation is accurate. The function correctly removes a DPS service endpoint address using
oc_endpoint_addresses_remove.
151-158: LGTM!The function logic is correct, and the implementation is accurate. The function correctly iterates over the DPS service endpoint addresses using
oc_endpoint_addresses_iterate.
160-165: LGTM!The function logic is correct, and the implementation is accurate. The function correctly selects a DPS service endpoint address using
oc_endpoint_addresses_select.
167-171: LGTM!The function logic is correct, and the implementation is accurate. The function correctly returns the selected DPS service endpoint address using
oc_endpoint_addresses_selected.api/plgd/unittest/plgd_dps_endpoints.cpp (3)
44-67: LGTM!The test case is well-structured and covers the important scenarios for setting and getting the endpoint. It correctly verifies the return values and the endpoint value, and also tests an edge case with an invalid endpoint length.
69-75: LGTM!The test case correctly verifies that a newly created context has an empty endpoint and no selected endpoint address.
77-169: LGTM!The test case is comprehensive and covers a wide range of scenarios related to managing endpoints. It correctly verifies the expected behavior using helper functions and lambdas. The test case is well-structured and easy to follow.
api/plgd/device-provisioning-client/plgd_dps_endpoint.c (8)
36-51: LGTM!The function correctly initializes the endpoint context and clears the DNS cache if necessary.
80-123: LGTM!The function correctly adds a new peer to the endpoint with the necessary verification data and callback.
Regarding the static analysis hint:
The unknown macro hint is a false positive as
dps_endpoint_add_peeris not a macro. It's a regular function.Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
125-133: LGTM!The function correctly closes the endpoint session if the endpoint is not empty.
135-145: LGTM!The function correctly disconnects the endpoint by closing the session and resetting the state.
147-152: LGTM!The function correctly checks if the endpoint is empty using the
oc_endpoint_is_emptyfunction.
154-185: LGTM!The function correctly converts the endpoint to a log string and includes the session ID in debug mode.
187-198: LGTM!The function correctly sets up TLS for the endpoint by adding a new peer if one doesn't already exist.
200-206: LGTM!The function correctly resets the TLS configuration to use the default ciphersuite and certificates.
.github/workflows/plgd-dps-test-with-cfg.yml (4)
140-155: LGTM!The step correctly gathers coverage data by stopping and starting the containers and executing the
collect-coverage.shscript.
157-164: LGTM!The step correctly uploads the coverage data as an artifact using the output variables and file paths.
166-170: LGTM!The step correctly collects the logs of the
dps-devsimcontainer when the test fails.
172-176: LGTM!The step correctly collects the logs of the
dps-devsim-obtcontainer when the test fails.api/plgd/device-provisioning-client/plgd_dps_apis.c (12)
35-43: LGTM!The function correctly compares an
oc_string_twith a C string of a given length, handling the case where either string is NULL.
45-51: LGTM!The function correctly compares two
oc_string_tstrings, handling the case where the strings are empty.
53-61: LGTM!The function correctly checks if an
oc_rep_tproperty has a given type and name by performing the necessary comparisons.
63-73: LGTM!The function correctly returns the maximum value for
oc_clock_time_tbased on its size, handling different sizes appropriately.
75-90: LGTM!The function correctly resets a delayed callback with a given interval in milliseconds. It removes any existing delayed callback, adds a new one with the specified interval, and appropriately truncates the interval if it exceeds the maximum value for
oc_clock_time_t.
92-99: LGTM!The function correctly resets a delayed callback with a given interval in seconds by converting the interval to milliseconds and calling
dps_reset_delayed_callback_ms.
101-105: LGTM!The function correctly checks if an
oc_status_tcode represents a timeout error by comparing it against the appropriate timeout error codes.Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
107-112: LGTM!The function correctly checks if an
oc_status_tcode represents a connection error by comparing it against the appropriate connection error codes.
114-118: LGTM!The function correctly checks if an
oc_status_tcode represents an error by comparing it againstOC_STATUS_BAD_REQUEST.
120-130: LGTM!The function correctly maps an
oc_status_tcode to aplgd_dps_error_tcode by checking if the code represents a timeout error, connection error, or a general error.
132-182: LGTM!The function correctly handles a redirect response from the server. It checks for the presence of a "redirecturi" property in the payload and updates the endpoint list accordingly. It removes the original server from the list and selects the new server as expected.
184-201: LGTM!The function correctly checks the response from the server. It maps the
oc_status_tcode to aplgd_dps_error_tcode usingdps_response_get_error_code. If the payload is not NULL, it callsdps_handle_redirect_responseto handle any redirect response appropriately.api/plgd/device-provisioning-client/plgd_dps_provision_owner.c (2)
75-143: LGTM!The function is well-implemented and handles the GET owner response comprehensively. It checks for the device's status, handles errors appropriately, sets the device's owner, and schedules the next step in the provisioning process.
Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
182-209: LGTM!The function is well-implemented and provides useful debugging information about the device's ownership. The use of conditional compilation and code coverage exclusion comments is appropriate for debugging code.
.github/workflows/sonar-cloud-analysis.yml (4)
28-29: LGTM!The new build configuration enabling cloud, collection creation, push, rfotm, device provisioning, and device provisioning test properties together is a valid combination for testing the device provisioning functionality.
90-93: Great addition!Adding the
plgd-dps-testsjob to run device provisioning service tests with coverage enabled is an excellent addition. It aligns with the goal of the PR to add support for device provisioning and ensures the new functionality is properly tested and code quality is maintained.
102-102: Good catch!Adding
plgd-dps-teststo theneedslist for thesonar-cloud-scanjob is crucial to ensure the sonar analysis includes the coverage data from the newly added device provisioning service tests.
118-118: Verify the sonar-scanner property change.Enabling the
PLGD_DEV_DEVICE_PROVISIONING_ENABLEDflag in the cmake command at line 118 is necessary to include the device provisioning code in the sonar analysis.However, the change to the sonar-scanner command at line 146, replacing the
sonar.cfamily.build-wrapper-outputproperty withsonar.cfamily.compile-commands, needs verification.Please confirm that this change is intentional and doesn't negatively impact the sonar analysis. You can use the following script to verify:
If the analysis fails, please revert the change and use the original
sonar.cfamily.build-wrapper-outputproperty.Also applies to: 146-146
api/plgd/device-provisioning-client/plgd_dps_time.c (5)
48-52: LGTM!The function logic is correct, and the implementation is accurate.
54-60: LGTM!The function logic is correct, and the implementation is accurate.
62-71: LGTM!The function logic is correct, and the implementation is accurate.
73-97: LGTM, but address the past review comment.The function logic is correct, and the implementation is accurate. However, the past review comment about making the delta time configurable is still valid and should be addressed.
174-230: LGTM, but address the past review comment.The function logic is correct, and the implementation is accurate. However, the past review comment about enhancing error recovery strategies, such as adding more detailed error logs or retry mechanisms in case of time synchronization failures, is still valid and should be addressed.
api/plgd/unittest/plgd_dps_verify_certificate.cpp (4)
40-52: LGTM!The test case correctly verifies the allocation and deallocation of the
dps_verify_certificate_data_tstructure.
54-61: LGTM!The test case correctly verifies the failure scenario when an invalid device is provided to the
dps_verify_certificatefunction.
63-75: LGTM!The test case correctly verifies the failure scenario when the peer context is missing while verifying the certificate.
124-208: LGTM!The test case correctly verifies the certificate verification process with a device. It sets up the necessary context and endpoints, and validates the intermediate and leaf certificates.
api/plgd/device-provisioning-client/plgd_dps_context.c (16)
40-44: LGTM!The function logic is correct, and the implementation is accurate.
46-50: LGTM!The function logic is correct, and the implementation is accurate.
52-56: LGTM!The function logic is correct, and the implementation is accurate.
58-62: LGTM!The function logic is correct, and the implementation is accurate.
64-68: LGTM!The function logic is correct, and the implementation is accurate.
70-74: LGTM!The function logic is correct, and the implementation is accurate.
76-85: LGTM!The function logic is correct, and the implementation is accurate.
87-114: LGTM, but consider the past review comment.The function is correctly initializing the fields of the
plgd_dps_context_tstructure. However, the past review comment is still valid and applicable to the current code segment.Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
116-127: LGTM!The function logic is correct, and the implementation is accurate.
129-144: LGTM!The function logic is correct, and the implementation is accurate.
146-154: LGTM!The function logic is correct, and the implementation is accurate.
156-165: LGTM!The function logic is correct, and the implementation is accurate.
167-173: LGTM!The function logic is correct, and the implementation is accurate.
175-179: LGTM!The function logic is correct, and the implementation is accurate.
181-191: LGTM!The function logic is correct, and the implementation is accurate.
193-199: LGTM!The function logic is correct, and the implementation is accurate.
api/plgd/device-provisioning-client/plgd_dps_manager.c (16)
45-54: LGTM!The function correctly starts the DPS manager if it's not already started.
56-65: LGTM!The function correctly iterates over the credentials to find the manufacturer certificate.
67-78: LGTM!The function correctly checks if the device has a manufacturer certificate.
80-89: LGTM!The function correctly iterates over the credentials to find the manufacturer trusted root CA.
91-102: LGTM!The function correctly checks if the device has a manufacturer trusted root CA.
104-142: LGTM!The function correctly gets the provision and cloud observer flags based on the current state of the device.
Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
144-200: LGTM!The function correctly starts the DPS manager.
202-207: LGTM!The function correctly checks if the DPS manager is started.
209-218: LGTM!The function correctly starts the DPS manager asynchronously.
220-225: LGTM!The function correctly restarts the DPS manager.
227-243: LGTM!The function correctly stops the DPS manager.
245-259: LGTM!The function correctly stops the DPS manager.
261-275: LGTM!The function correctly forces reprovisioning and restarts the DPS manager.
277-283: LGTM!The function correctly forces reprovisioning and restarts the DPS manager asynchronously.
285-293: LGTM!The function correctly retries provisioning asynchronously.
295-349: LGTM!The function correctly provisions the device asynchronously.
api/plgd/device-provisioning-client/plgd_dps_store.c (15)
55-63: LGTM!The function logic is correct, and the implementation is accurate.
65-70: LGTM!The function logic is correct, and the implementation is accurate.
72-80: LGTM!The function logic is correct, and the implementation is accurate.
82-88: LGTM!The function logic is correct, and the implementation is accurate.
90-140: LGTM!The function logic is correct, and the implementation is accurate.
Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
142-215: LGTM!The function logic is correct, and the implementation is accurate.
217-224: LGTM!The function logic is correct, and the implementation is accurate.
226-232: LGTM!The function logic is correct, and the implementation is accurate.
234-245: LGTM!The function logic is correct, and the implementation is accurate.
247-253: LGTM!The function logic is correct, and the implementation is accurate.
255-276: LGTM!The function logic is correct, and the implementation is accurate.
278-309: LGTM!The function logic is correct, and the implementation is accurate.
311-318: LGTM!The function logic is correct, and the implementation is accurate.
320-361: LGTM!The function logic is correct, and the implementation is accurate.
363-370: LGTM!The function logic is correct, and the implementation is accurate.
api/plgd/unittest/plgd_dps_provision_cloud.cpp (7)
1-17: License header looks good!The Apache 2.0 license header is correctly formatted with the appropriate copyright notice and disclaimers.
19-46: Includes look good!The included headers seem appropriate and are organized in a logical manner.
47-106: Test fixture class looks good!The
DPSProvisionCloudWithServerTesttest fixture class is well-structured and contains the necessary setup and teardown methods. The helper methods are useful for the tests. The code follows the Google Test naming conventions and style guide.
108-147:HandleSetCloudResponseFailtest case looks good!The test case covers the important failure scenarios of the
dps_handle_set_cloud_responsefunction, such as invalid payload, invalid sid, invalid device, and logged in with no cloud server set. The test case is well-structured and follows the AAA (Arrange-Act-Assert) pattern.
149-223:HandleSetCloudResponsetest case looks good!The test case covers the important success scenarios of the
dps_handle_set_cloud_responsefunction, such as updating signed in cloud with same data, different cis, different apn, different sid but not connected to a cloud, and different sid and connected to a cloud. The test case is well-structured and follows the AAA (Arrange-Act-Assert) pattern.
225-246:HasCloudConfigurationtest case looks good!The test case covers the important scenarios of the
dps_has_cloud_configurationfunction, such as invalid device, missing access token, no selected gateway, and the success scenario. The test case is well-structured and follows the AAA (Arrange-Act-Assert) pattern.
248-380: Remaining test cases look good!The test cases for
SetCloudHandler,SetCloudEncodeSelectedGatewayFail,SetCloudEncodeSelectedGateway,SetCloudEncodePayloadFail,SetCloudEncodePayload,SetCloudFail, andSetCloudfunctions cover the important scenarios, including failure and success scenarios. The test cases are well-structured and follow the AAA (Arrange-Act-Assert) pattern. The code is well-organized and follows the Google Test naming conventions and style guide.api/plgd/device-provisioning-client/plgd_dps_pki.c (10)
50-57: LGTM!The function correctly initializes the PKI configuration with a default expiring limit.
59-103: LGTM!The function correctly generates and sends a CSR request to obtain new DPS certificates. It handles errors and returns the status of the operation.
120-125: LGTM!The function correctly checks if a certificate is expiring based on the current time and the expiring limit.
127-150: LGTM!The function correctly validates a certificate based on its validity period and the current time. It handles different certificate states.
152-178: LGTM!The function correctly updates a flag to indicate if credentials were replaced and logs debug information about the applied credential.
180-218: LGTM!The function correctly replaces the certificates based on the provided representation and endpoint. It handles the case when credentials are replaced or removed and closes TLS peers if credentials are modified.
220-224: LGTM!The function correctly checks if certificates can be replaced based on the provisioning status.
347-368: LGTM!The function correctly attempts to renew the certificates by sending a CSR request. It schedules a retry in case the response is not retrieved.
370-376: LGTM!The function correctly implements the asynchronous callback to retry the renewal of certificates.
378-397: LGTM!The function correctly implements the asynchronous callback to renew the certificates. It handles the case when certificates cannot be replaced or the renewal fails.
api/plgd/device-provisioning-client/plgd_dps_provision_cloud.c (1)
377-409: LGTM!The
dps_provisioning_set_cloudfunction looks good. It properly checks the device state, initializes the POST request, sets up TLS, and dispatches the request with a timeout. The error handling is appropriate.api/plgd/device-provisioning-client/plgd_dps.c (16)
38-46: LGTM!The function is correctly implemented. It logs the status change and calls the registered callback with the correct arguments.
48-54: LGTM!The function is correctly implemented. It calls
dps_manager_status_cbwith the correct arguments.
58-63: LGTM!The function is correctly implemented. It stops the manager and schedules a delayed callback to start the manager.
65-126: LGTM!The function is correctly implemented. It handles the endpoint events correctly based on the state and context. The function logs the events and takes appropriate actions.
Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
128-148: LGTM!The function is correctly implemented. It handles the session events correctly based on the endpoint and state. The function calls
dps_handle_endpoint_eventwith the correct arguments.
150-158: LGTM!The function is correctly implemented. It restarts the manager if the status is initialized.
160-166: LGTM!The function is correctly implemented. It calls
dps_contexts_iteratewithdps_restart_initializedif the event isNETWORK_INTERFACE_UP.
170-187: LGTM!The function is correctly implemented. It initializes the device provisioning contexts correctly. The function handles errors and logs messages appropriately.
189-210: LGTM!The function is correctly implemented. It shuts down the device provisioning contexts correctly. The function handles errors and logs messages appropriately.
214-218: LGTM!The function is correctly implemented. It adds the session event callback for a context.
220-224: LGTM!The function is correctly implemented. It removes the session event callback for a context.
226-230: LGTM!The function is correctly implemented. It adds the interface event callback.
232-236: LGTM!The function is correctly implemented. It removes the interface event callback.
240-259: LGTM!The function is correctly implemented. It tries to set the identity certificate chain for a device correctly. The function handles errors and logs messages appropriately.
261-280: LGTM!The function is correctly implemented. It starts the cloud manager for a device correctly. The function handles errors and logs messages appropriately.
282-315: LGTM!The function is correctly implemented. It sets the certificate fingerprint for a context correctly. The function handles errors and logs messages appropriately.
api/plgd/device-provisioning-client/plgd_dps_cloud.c (14)
40-48: LGTM!The function logic is correct, and the implementation is accurate. It properly retrieves the cloud context for the given device and returns the result of
oc_cloud_manager_is_startedon that context.
50-58: LGTM!The function logic is correct, and the implementation is accurate. It properly retrieves the cloud context for the given device and returns the result of a bitwise AND operation between the cloud status and the given status.
60-64: LGTM!The function logic is correct, and the implementation is accurate. It properly calls
cloud_check_statuswith the device and theOC_CLOUD_REGISTEREDstatus.
66-70: LGTM!The function logic is correct, and the implementation is accurate. It properly calls
cloud_check_statuswith the device and theOC_CLOUD_LOGGED_INstatus.
72-79: LGTM!The function logic is correct, and the implementation is accurate. It properly initializes the
plgd_cloud_status_observer_tstruct by setting themax_countandinterval_sfields of thecfgmember and zeroing out the rest of the struct.
81-92: LGTM!The function logic is correct, and the implementation is accurate. It properly invokes the original callback if it exists and calls
dps_cloud_observer_on_server_changewith theplgd_dps_context_tstruct.
94-117: LGTM!The function logic is correct, and the implementation is accurate. It properly deinitializes the
plgd_dps_context_tstruct by removing thedps_cloud_observe_status_asynccallback, restoring the originalon_selected_changecallback if it was replaced, and resetting thecloud_observermember of theplgd_dps_context_tstruct.
119-133: LGTM!The function logic is correct, and the implementation is accurate. It properly copies the given UUID to the
last_endpoint_uuidmember of theplgd_cloud_status_observer_tstruct if they are not equal and returnstrueif the UUID was copied andfalseotherwise.
135-140: LGTM!The function logic is correct, and the implementation is accurate. It properly returns
trueif theinitial_endpoint_urimember of theplgd_cloud_status_observer_tstruct is notNULLandfalseotherwise.
142-165: LGTM!The function logic is correct, and the implementation is accurate. It properly loads the
plgd_cloud_status_observer_tstruct with data from theoc_cloud_context_tstruct by retrieving the selected cloud server address, copying its URI to theinitial_endpoint_urimember, copying its UUID to thelast_endpoint_uuidmember, setting theremaining_endpoint_changesmember to the number of alternative cloud servers, and resetting theretry_countandlast_statusmembers.
167-199: LGTM!The function logic is correct, and the implementation is accurate. It properly initializes the cloud observer when cloud provisioning starts by checking if a server retry is ongoing and reinitializing the cloud observer if it is. Otherwise, it loads the cloud observer with data from the cloud context, replaces the
on_selected_changecallback withdps_cloud_observer_on_cloud_server_change, and callsdps_cloud_observe_statusto start observing the cloud status.
201-222: LGTM!The function logic is correct, and the implementation is accurate. It properly handles the cloud server UUID change by stopping the cloud manager, removing the
dps_status_callback_handlercallback, resetting the provisioning state, and scheduling the next provisioning step.
224-271: LGTM!The function logic is correct, and the implementation is accurate. It properly handles the cloud server change by checking if there are any remaining endpoint changes and forcing reprovisioning if there are none. It then checks if the initial cloud server has been reached and forces reprovisioning if it has. Otherwise, it selects the next cloud server and calls
dps_cloud_observe_statusto start observing the cloud status.
273-289: LGTM!The function logic is correct, and the implementation is accurate. It properly sets the configuration of the
plgd_dps_context_tstruct by checking if the givenretry_interval_sis not zero and returningfalseif it is. Otherwise, it sets themax_countandinterval_smembers of thecfgmember of thecloud_observermember of theplgd_dps_context_tstruct and returnstrue.api/plgd/unittest/plgd_dps_resource.cpp (8)
62-85: LGTM!The function correctly parses the DPS endpoints from the representation and handles parsing failures by returning an empty vector.
87-140: LGTM!The function correctly parses the different types of DPS data properties from the representation and returns a boolean indicating if the property was parsed.
142-156: LGTM!The function correctly parses the DPS data from the representation by iterating over the properties and calling
parseDPSDataPropertyfor each property.
158-238: LGTM!The test function correctly tests encoding and parsing of DPS data for the read interface. It sets up test data, encodes it, parses it back, and verifies the parsed data matches the original data. It also tests various scenarios like missing status and multiple endpoints.
240-275: LGTM!The test function correctly tests encoding and parsing of DPS data for the read-write interface. It sets up test data, encodes it, parses it back, and verifies the parsed data matches the expected data.
277-380: LGTM!The test function correctly tests the
dps_status_to_strfunction for converting DPS status to string. It tests various DPS status values and verifies the returned strings match the expected values.
408-441: LGTM!The function correctly sends a GET request to the DPS resource with the specified query, handles the response, and verifies the response payload matches the expected DPS data.
481-507: LGTM!The function correctly sends a POST request to the DPS resource with the payload generated by the provided lambda function, handles the response, and verifies the response status is changed.
api/plgd/device-provisioning-client/plgd_dps_provision.c (15)
43-63: LGTM!The function correctly handles the provisioning server response, setting the appropriate error status and code for both success and failure cases.
65-99: Looks good!The debug function provides detailed logging of the ACL being applied, which can be very useful for debugging purposes. The use of conditional compilation and code coverage exclusion comments is appropriate.
101-137: The past review comment is still valid.The function continues to handle the ACL application process effectively, including error handling and conditional debugging. The existing error messages provide sufficient context about the failures.
Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
139-204: LGTM!The function correctly handles the GET ACLs response, with appropriate checks for duplicate calls, expected status validation, response checking, and response handling. It also correctly schedules the next provisioning step on success or retries on failure.
206-229: Looks good!The function correctly initiates the GET ACLs request by checking the device state, setting up TLS, dispatching the GET request, and updating the status.
231-305: LGTM!The function correctly handles the GET credentials response, with appropriate checks for duplicate calls, expected status validation, response checking, certificate replacement, renewal scheduling, identity chain setting, and scheduling the next provisioning step on success or retries on failure.
307-334: Looks good!The function correctly initiates the GET credentials request by checking the device state and sending the CSR.
336-340: LGTM!The function correctly schedules the next provisioning step.
342-350: Looks good!The function correctly gets the DPS time as the next provisioning step.
352-360: LGTM!The function correctly gets the DPS ownership as the next provisioning step.
362-370: Looks good!The function correctly sets the cloud configuration as the next provisioning step.
372-380: LGTM!The function correctly gets the DPS credentials as the next provisioning step.
382-390: Looks good!The function correctly gets the DPS ACLs as the next provisioning step.
398-417: LGTM!The function correctly starts the cloud registration as the next provisioning step by checking the certificate renewal status, rechecking credentials if needed, and starting the cloud registration.
548-602: The past review comment is still valid.The function continues to handle the cloud provisioning start comprehensively, covering various scenarios such as cloud context checks and handling both restarts and initial starts.
CMakeLists.txt (9)
80-84: LGTM!The CMake options for plgd.dev features are correctly defined with appropriate default values.
239-239: LGTM!The maximum log level is correctly set using the
oc_set_maximum_log_levelfunction based on theOC_LOG_MAXIMUM_LOG_LEVELvariable.
242-243: LGTM!The
OC_LOG_MAXIMUM_LEVELdefinition is correctly appended to thePRIVATE_COMPILE_DEFINITIONSandTEST_COMPILE_DEFINITIONSlists with the appropriate value based onOC_LOG_MAXIMUM_LOG_LEVEL_INT.
245-245: LGTM!The
OC_LOG_MAXIMUM_LEVELdefinition is correctly appended to theMBEDTLS_COMPILE_DEFINITIONSlist with the appropriate value based onOC_LOG_MAXIMUM_LOG_LEVEL_INTwhenBUILD_MBEDTLSis enabled.
407-412: LGTM!The code segment correctly handles the
PLGD_DEV_TIME_ENABLEDoption by appending thePLGD_DEV_TIMEdefinition to the appropriate compile definitions lists based on the conditions.
414-434: LGTM!The code segment correctly handles the
PLGD_DEV_DEVICE_PROVISIONING_ENABLEDoption by:
- Checking for the required dependencies and printing appropriate error messages if they are not met.
- Appending the
PLGD_DEV_DEVICE_PROVISIONINGdefinition to thePUBLIC_COMPILE_DEFINITIONSlist when enabled.- Setting the maximum log level for Plgd DPS using the
oc_set_maximum_log_levelfunction based on thePLGD_DPS_MAXIMUM_LOG_LEVELvariable.- Appending the
PLGD_DPS_LOG_MAXIMUM_LEVELdefinition to the appropriate compile definitions lists with the correct value.
436-441: LGTM!The code segment correctly handles the
PLGD_DEV_DEVICE_PROVISIONING_TEST_PROPERTIES_ENABLEDoption by appending thePLGD_DPS_RESOURCE_TEST_PROPERTIESdefinition to the appropriate compile definitions lists based on the conditions.
684-688: LGTM!The code segment correctly sets the
PLGD_DPS_SRCvariable to the appropriate source files whenPLGD_DEV_DEVICE_PROVISIONING_ENABLEDis enabled.
690-690: LGTM!The code segment correctly adds the
PLGD_DPS_SRCvariable to the list of source files for theclient-server-objlibrary, ensuring that the Plgd DPS source files are included whenPLGD_DEV_DEVICE_PROVISIONING_ENABLEDis enabled.
There was a problem hiding this comment.
Actionable comments posted: 0
Outside diff range and nitpick comments (1)
api/plgd/unittest/plgd_dps_verify_certificate.cpp (1)
124-208: LGTM with a suggestion!The test case correctly tests the success scenario of the
dps_verify_certificatefunction. The test case is also correctly setting up the test environment by converting a hex string to bytes and setting the values from the vendor encapsulated options.However, the test case is using a hardcoded certificate for the validation. It would be better to use a generated certificate to avoid the test case failing if the certificate expires.
Consider generating a certificate for the test case instead of using a hardcoded one. This will make the test case more resilient to certificate expiration.
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files ignored due to path filters (1)
tools/doxygen.iniis excluded by!**/*.ini
Files selected for processing (82)
- .dockerignore (1 hunks)
- .github/workflows/cmake-linux.yml (2 hunks)
- .github/workflows/docker-build-publish-with-cfg.yml (1 hunks)
- .github/workflows/docker-build-publish.yml (1 hunks)
- .github/workflows/ghcr-check.yml (1 hunks)
- .github/workflows/plgd-device-test-with-cfg.yml (1 hunks)
- .github/workflows/plgd-dps-test-with-cfg.yml (1 hunks)
- .github/workflows/plgd-dps-tests.yml (1 hunks)
- .github/workflows/plgd-hub-test-with-cfg.yml (1 hunks)
- .github/workflows/sonar-cloud-analysis.yml (4 hunks)
- .github/workflows/static-analysis.yml (2 hunks)
- .github/workflows/unit-test-with-cfg.yml (1 hunks)
- CMakeLists.txt (7 hunks)
- api/oc_endpoint.c (1 hunks)
- api/oc_log.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_apis.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_apis_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_cloud.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_cloud_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_context.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_context_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_dhcp.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_dhcp_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_endpoint.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_endpoint_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_endpoints.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_endpoints_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_log.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_log_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_manager.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_manager_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_pki.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_pki_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision_cloud.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision_cloud_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision_owner.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision_owner_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_resource.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_resource_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_retry.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_retry_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_security.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_security_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_store.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_store_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_tag.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_tag_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_time.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_time_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_verify_certificate.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_verify_certificate_internal.h (1 hunks)
- api/plgd/unittest/plgd_dps.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_apis.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_cloud.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_context.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_dhcp.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_endpoint.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_endpoints.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_log.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_manager.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_pki.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_provision.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_provision_cloud.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_provision_owner.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_resource.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_retry.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_security.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_store.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_tag.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_test.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_test.h (1 hunks)
- api/plgd/unittest/plgd_dps_time.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_verify_certificate.cpp (1 hunks)
- apps/CMakeLists.txt (1 hunks)
- apps/dps_cloud_server.c (1 hunks)
- docker/apps/Dockerfile.cloud-server (2 hunks)
- docker/apps/Dockerfile.dps-cloud-server (1 hunks)
- docker/apps/Dockerfile.dps-cloud-server-debug (1 hunks)
Files not processed due to max files limit (9)
- include/oc_log.h
- include/plgd/plgd_dps.h
- messaging/coap/observe.c
- security/oc_pstat.c
- security/oc_tls.c
- sonar-project.properties
- tools/utils.cmake
- util/oc_features.h
- util/oc_memb.h
Files skipped from review due to trivial changes (12)
- .github/workflows/plgd-device-test-with-cfg.yml
- .github/workflows/plgd-hub-test-with-cfg.yml
- .github/workflows/unit-test-with-cfg.yml
- api/plgd/device-provisioning-client/plgd_dps_cloud_internal.h
- api/plgd/device-provisioning-client/plgd_dps_dhcp_internal.h
- api/plgd/device-provisioning-client/plgd_dps_endpoint_internal.h
- api/plgd/device-provisioning-client/plgd_dps_provision_owner_internal.h
- api/plgd/device-provisioning-client/plgd_dps_retry_internal.h
- api/plgd/device-provisioning-client/plgd_dps_security.c
- api/plgd/device-provisioning-client/plgd_dps_security_internal.h
- api/plgd/device-provisioning-client/plgd_dps_tag_internal.h
- api/plgd/unittest/plgd_dps.cpp
Files skipped from review as they are similar to previous changes (48)
- .dockerignore
- .github/workflows/cmake-linux.yml
- .github/workflows/docker-build-publish-with-cfg.yml
- .github/workflows/docker-build-publish.yml
- .github/workflows/ghcr-check.yml
- .github/workflows/plgd-dps-tests.yml
- .github/workflows/static-analysis.yml
- api/oc_endpoint.c
- api/oc_log.c
- api/plgd/device-provisioning-client/plgd_dps_cloud.c
- api/plgd/device-provisioning-client/plgd_dps_dhcp.c
- api/plgd/device-provisioning-client/plgd_dps_endpoints_internal.h
- api/plgd/device-provisioning-client/plgd_dps_internal.h
- api/plgd/device-provisioning-client/plgd_dps_log.c
- api/plgd/device-provisioning-client/plgd_dps_log_internal.h
- api/plgd/device-provisioning-client/plgd_dps_manager_internal.h
- api/plgd/device-provisioning-client/plgd_dps_pki_internal.h
- api/plgd/device-provisioning-client/plgd_dps_provision_cloud_internal.h
- api/plgd/device-provisioning-client/plgd_dps_provision_internal.h
- api/plgd/device-provisioning-client/plgd_dps_resource.c
- api/plgd/device-provisioning-client/plgd_dps_resource_internal.h
- api/plgd/device-provisioning-client/plgd_dps_retry.c
- api/plgd/device-provisioning-client/plgd_dps_store_internal.h
- api/plgd/device-provisioning-client/plgd_dps_tag.c
- api/plgd/device-provisioning-client/plgd_dps_time_internal.h
- api/plgd/device-provisioning-client/plgd_dps_verify_certificate.c
- api/plgd/device-provisioning-client/plgd_dps_verify_certificate_internal.h
- api/plgd/unittest/plgd_dps_apis.cpp
- api/plgd/unittest/plgd_dps_cloud.cpp
- api/plgd/unittest/plgd_dps_context.cpp
- api/plgd/unittest/plgd_dps_dhcp.cpp
- api/plgd/unittest/plgd_dps_endpoint.cpp
- api/plgd/unittest/plgd_dps_endpoints.cpp
- api/plgd/unittest/plgd_dps_manager.cpp
- api/plgd/unittest/plgd_dps_provision.cpp
- api/plgd/unittest/plgd_dps_provision_owner.cpp
- api/plgd/unittest/plgd_dps_retry.cpp
- api/plgd/unittest/plgd_dps_security.cpp
- api/plgd/unittest/plgd_dps_store.cpp
- api/plgd/unittest/plgd_dps_tag.cpp
- api/plgd/unittest/plgd_dps_test.cpp
- api/plgd/unittest/plgd_dps_test.h
- api/plgd/unittest/plgd_dps_time.cpp
- apps/CMakeLists.txt
- apps/dps_cloud_server.c
- docker/apps/Dockerfile.cloud-server
- docker/apps/Dockerfile.dps-cloud-server
- docker/apps/Dockerfile.dps-cloud-server-debug
Additional context used
cppcheck
api/plgd/device-provisioning-client/plgd_dps_endpoints.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_endpoint.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_apis.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_provision_owner.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_time.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_context.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_manager.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_store.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_pki.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_provision_cloud.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_provision.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
actionlint
.github/workflows/plgd-dps-test-with-cfg.yml
122-122: shellcheck reported issue in this script: SC2046:warning:1:62: Quote this to prevent word splitting
(shellcheck)
134-134: shellcheck reported issue in this script: SC2129:style:2:1: Consider using { cmd1; cmd2; } >> file instead of individual redirects
(shellcheck)
134-134: shellcheck reported issue in this script: SC2086:info:2:53: Double quote to prevent globbing and word splitting
(shellcheck)
134-134: shellcheck reported issue in this script: SC2086:info:3:61: Double quote to prevent globbing and word splitting
(shellcheck)
134-134: shellcheck reported issue in this script: SC2086:info:4:48: Double quote to prevent globbing and word splitting
(shellcheck)
Additional comments not posted (222)
api/plgd/device-provisioning-client/plgd_dps_apis_internal.h (11)
38-40: LGTM!The function declaration is clear and follows the coding conventions.
43-44: LGTM!The function declaration is clear and follows the coding conventions.
47-49: LGTM!The function declaration is clear and follows the coding conventions. The
OC_NONNULLannotation is a good practice to catch potential NULL pointer issues at compile time.
52-53: LGTM!The function declaration is clear and follows the coding conventions. The function name clearly describes its purpose.
57-58: LGTM!The function declaration is clear and follows the coding conventions. The function name clearly describes its purpose.
62-62: LGTM!The function declaration is clear and follows the coding conventions. The function name clearly describes its purpose.
66-66: LGTM!The function declaration is clear and follows the coding conventions. The function name clearly describes its purpose.
69-69: LGTM!The function declaration is clear and follows the coding conventions. The function name clearly describes its purpose.
73-74: LGTM!The function declaration is clear and follows the coding conventions. The
OC_NONNULLannotation is a good practice to catch potential NULL pointer issues at compile time.
86-87: LGTM!The function declaration is clear and follows the coding conventions. The
OC_NONNULL(1)annotation is a good practice to catch potential NULL pointer issues at compile time.
91-91: LGTM!The function declaration is clear and follows the coding conventions. The function name clearly describes its purpose.
api/plgd/unittest/plgd_dps_log.cpp (6)
32-36: LGTM!The function logic is correct, and the implementation is accurate.
39-52: LGTM!The test function is correctly logging messages at different log levels and verifying the log level setting.
58-67: Skip generating a similar comment as the past review comment is still valid.The
printfstatement at line 62 still has a mismatch between the number of format specifiers and arguments.
73-84: LGTM!The function logic is correct, and the implementation is accurate.
86-97: LGTM!The test function is correctly setting the log level and log function, and logging messages at different log levels.
105-116: LGTM!The test function is correctly setting the log level and log function, and logging messages at different log levels.
api/plgd/unittest/plgd_dps_pki.cpp (6)
48-56: LGTM!The test case correctly verifies the failure scenario when an invalid device ID is provided to the
dps_pki_send_csrfunction.
58-63: LGTM!The test case correctly verifies the failure scenario when an invalid device ID is provided to the
dps_pki_replace_certificatesfunction.
65-94: LGTM!The test case correctly verifies the
dps_pki_calculate_renew_certificates_intervalfunction by testing different certificate expiration scenarios and checking the expected renewal intervals.
112-125: LGTM!The test case correctly verifies the failure scenario when an invalid representation is provided to the
dps_pki_replace_certificatesfunction.
127-142: LGTM!The test case correctly verifies the
dps_pki_try_renew_certificatesfunction by providing a valid device context and checking the expected behavior.
144-165: LGTM!The test case correctly verifies the
dps_pki_renew_certificates_asyncfunction by providing a valid device context and cloud context, and checking the expected behavior.api/plgd/device-provisioning-client/plgd_dps_endpoints.c (10)
36-63: LGTM!The function correctly sets the DPS service endpoint, handling the case where the endpoint is already set. The error handling and logging are appropriate.
65-82: LGTM!The function correctly sets the DPS service endpoints, handling the case where the selected endpoint has changed. The error handling is appropriate.
84-90: LGTM!The function is a simple wrapper around
dps_set_endpointand is correctly implemented.
92-113: LGTM!The function correctly gets the DPS service endpoint, handling the case where no endpoint is set or the provided buffer is too small. The error handling and logging are appropriate.
Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
115-120: LGTM!The function is a simple wrapper around
oc_endpoint_addresses_selectedand is correctly implemented.
122-132: LGTM!The function is a simple wrapper around
oc_endpoint_addresses_initand is correctly implemented.
134-142: LGTM!The function is a simple wrapper around
oc_endpoint_addresses_addand is correctly implemented.
144-149: LGTM!The function is a simple wrapper around
oc_endpoint_addresses_removeand is correctly implemented.
151-158: LGTM!The function is a simple wrapper around
oc_endpoint_addresses_iterateand is correctly implemented.
167-171: LGTM!The function is a simple wrapper around
oc_endpoint_addresses_selectedand is correctly implemented.api/plgd/device-provisioning-client/plgd_dps_context_internal.h (1)
1-154: LGTM!The new header file looks clean, well-structured, and well-commented. The data structures and functions are clearly named and serve well-defined purposes in the provisioning client context.
Some specific good practices I noticed:
- Proper use of header guards and
extern "C"block for C++ compatibility.- Inclusion of all necessary headers.
- Clear and concise comments explaining the purpose of key data structures and fields.
- Use of
OC_NONNULLto annotate functions expecting non-null parameters.- Typedef for iteration callback, allowing flexible traversal of provisioning contexts.
I didn't find any issues or improvements to suggest. Great job!
api/plgd/device-provisioning-client/plgd_dps_endpoint.c (8)
36-51: LGTM!The function correctly initializes the endpoint in the DPS context and clears the DNS cache.
80-123: LGTM!The function correctly adds a new peer to the endpoint and handles the verification data.
Regarding the unknown macro error reported by cppcheck, it's a false positive because
dps_endpoint_add_peeris not a macro. Feel free to ignore it.Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
125-133: LGTM!The function correctly closes the endpoint session if the endpoint is not empty.
135-145: LGTM!The function correctly disconnects the endpoint in the DPS context by closing the session, clearing the endpoint data, and setting the state to disconnected.
147-152: LGTM!The function correctly checks if the endpoint is empty using the
oc_endpoint_is_emptyfunction.
154-185: LGTM!The function correctly converts the endpoint to a log string and includes the session ID if debug is enabled. It also handles the case where the endpoint string is empty or too long.
187-198: LGTM!The function correctly sets up TLS for the endpoint in the DPS context by adding a new peer if one doesn't already exist.
200-206: LGTM!The function correctly resets the TLS configuration to use the default ciphersuite and enable the selection of the identity cert chain.
.github/workflows/plgd-dps-test-with-cfg.yml (12)
86-103: This comment is a duplicate of the following past review comment:Quote
$(hostname)in the container name to prevent word splitting issues.The step uses
$(hostname)in the container name without quoting, which may cause word splitting issues as indicated by the static analysis hint.Apply this diff to fix the issue:
- dps-devsim-$(hostname) + dps-devsim-"$(hostname)"
106-119: This comment is a duplicate of the following past review comment:Quote
$(hostname)in the container name to prevent word splitting issues.The step uses
$(hostname)in the container name without quoting, which may cause word splitting issues as indicated by the static analysis hint.Apply this diff to fix the issue:
- dps-devsim-obt-$(hostname) "" + dps-devsim-obt-"$(hostname)" ""
121-129: This comment is a duplicate of the following past review comment:Quote
$(hostname)in the--hostnameargument to prevent word splitting issues.The step uses
$(hostname)in the--hostnameargument without quoting, which may cause word splitting issues as indicated by the static analysis hint.Apply this diff to fix the issue:
- --hostname=$(hostname) + --hostname="$(hostname)"Tools
actionlint
122-122: shellcheck reported issue in this script: SC2046:warning:1:62: Quote this to prevent word splitting
(shellcheck)
131-138: This comment is a duplicate of the following past review comment:Fix required: Use
$()instead of backticks for command substitution, use{ cmd1; cmd2; } >> fileinstead of individual redirects, and quote variables to prevent word splitting issues.The step uses backticks for command substitution, which is a legacy syntax as indicated by the static analysis hint. It also uses multiple redirects to append to the
$GITHUB_OUTPUTfile, which can be simplified as indicated by the static analysis hint. Additionally, it uses unquoted variables in theechocommands, which may cause word splitting issues as indicated by the static analysis hint.Apply this diff to fix the issues:
- SUFFIX=`echo "-DCMAKE_BUILD_TYPE=${{ inputs.build_type }} ${{ inputs.build_args }} -DBUILD_TESTING=ON ${{ inputs.args }}" | sha1sum | cut -f 1 -d ' '` - echo "filename=coverage-plgd-dps-${SUFFIX}.json" >> $GITHUB_OUTPUT - echo "filename_obt=coverage-plgd-dps-obt-${SUFFIX}.json" >> $GITHUB_OUTPUT - echo "artifact=plgd-dps-${SUFFIX}-coverage" >> $GITHUB_OUTPUT + SUFFIX=$(echo "-DCMAKE_BUILD_TYPE=${{ inputs.build_type }} ${{ inputs.build_args }} -DBUILD_TESTING=ON ${{ inputs.args }}" | sha1sum | cut -f 1 -d ' ') + { + echo "filename=coverage-plgd-dps-${SUFFIX}.json" + echo "filename_obt=coverage-plgd-dps-obt-${SUFFIX}.json" + echo "artifact=plgd-dps-${SUFFIX}-coverage" + } >> "$GITHUB_OUTPUT"Tools
actionlint
134-134: shellcheck reported issue in this script: SC2129:style:2:1: Consider using { cmd1; cmd2; } >> file instead of individual redirects
(shellcheck)
134-134: shellcheck reported issue in this script: SC2086:info:2:53: Double quote to prevent globbing and word splitting
(shellcheck)
134-134: shellcheck reported issue in this script: SC2086:info:3:61: Double quote to prevent globbing and word splitting
(shellcheck)
134-134: shellcheck reported issue in this script: SC2086:info:4:48: Double quote to prevent globbing and word splitting
(shellcheck)
48-51: LGTM!The step is correctly checking out the repository with submodules.
53-57: LGTM!The step is correctly configuring
vm.mmap_rnd_bitsfor sanitizers based on the provided build arguments.
59-68: LGTM!The step is correctly building the dps-cloudserver docker image using the provided Dockerfile and build arguments.
70-71: LGTM!The step is correctly pulling the device-provisioning-service tests image.
73-83: LGTM!The step is correctly preparing the test environment by creating directories, setting permissions, and running a docker container.
140-155: LGTM!The step is correctly gathering coverage data by stopping and starting docker containers and executing a script to collect coverage.
157-164: LGTM!The step is correctly uploading the coverage data as an artifact.
166-176: LGTM!The steps are correctly collecting dps cloud server logs when the test fails.
api/plgd/device-provisioning-client/plgd_dps_apis.c (12)
35-43: LGTM!The function correctly compares an
oc_string_twith a C string of a given length, handling the case when theoc_string_tis NULL.
45-51: LGTM!The function correctly compares two
oc_string_tstrings, handling the case when both strings are empty.
53-61: LGTM!The function correctly checks if a given
oc_rep_thas a specific property name and type by performing the necessary comparisons.
63-73: LGTM!The function correctly returns the maximum value for
oc_clock_time_tbased on its size, handling different sizes ofoc_clock_time_t.
75-90: LGTM!The function correctly resets a delayed callback with a given interval in milliseconds. It removes the existing callback, calculates the interval in
oc_clock_time_t, and adds a new timed event callback. It also handles the case when the interval exceeds the maximum value foroc_clock_time_tby truncating it.
92-99: LGTM!The function correctly resets a delayed callback with a given interval in seconds by calling
dps_reset_delayed_callback_mswith the interval converted to milliseconds.
101-105: LGTM!The function correctly checks if a given
oc_status_tcode represents a timeout error by comparing it with the specific timeout error codes.Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
107-112: LGTM!The function correctly checks if a given
oc_status_tcode represents a connection error by comparing it with the specific connection error codes.
114-118: LGTM!The function correctly checks if a given
oc_status_tcode represents an error by comparing it withOC_STATUS_BAD_REQUEST.
120-130: LGTM!The function correctly maps an
oc_status_tcode to aplgd_dps_error_tcode by checking if the code represents a timeout error, connection error, or a general error, and returning the correspondingplgd_dps_error_tcode.
132-182: LGTM!The function correctly handles a redirect response from the server. It checks if the payload contains a valid "redirecturi" property, adds it to the list of endpoints if not already selected, removes the original server from the list, selects the new server, and disconnects the endpoint. The logic is sound and follows the necessary steps to handle a redirect response.
184-201: LGTM!The function correctly checks the response from the server. It maps the
oc_status_tcode to aplgd_dps_error_tcode usingdps_response_get_error_code, returns the error code if it's notPLGD_DPS_OK, and callsdps_handle_redirect_responseto handle any redirect response if the payload is not NULL. The logic is sound and follows the necessary steps to check the response from the server.api/plgd/device-provisioning-client/plgd_dps_provision_owner.c (2)
75-143: LGTM!The function is well-implemented and handles the GET owner response comprehensively. It checks the device status, handles errors, sets the owner, and updates the device status appropriately.
Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
182-209: LGTM!The debugging function is well-implemented and provides useful information about the owner. The use of
DPS_DBG_IS_ENABLEDmacro and the exclusion from code coverage are justified..github/workflows/sonar-cloud-analysis.yml (4)
28-29: LGTM!The addition of a new build configuration with cloud, device provisioning, and testing features enabled is a positive change that improves the test coverage.
90-93: Excellent addition!The new
plgd-dps-testsjob, which utilizes the existingplgd-dps-test-with-cfg.ymlworkflow with coverage enabled, is a valuable addition to the testing strategy. It ensures that device provisioning functionality is thoroughly tested and coverage is reported.
102-102: Good catch!Updating the
needsconfiguration for thesonar-cloud-scanjob to include theplgd-dps-testsjob is essential to ensure that all relevant tests are executed before running the Sonar Cloud scan. This maintains the correct execution order and dependencies between the jobs.
118-118: Please clarify the reason for changing the sonar-scanner output definition.Enabling additional features related to device provisioning in the CMake command is a good change that expands the code analysis coverage.
However, I noticed that the sonar-scanner command has been modified to change the output definition from
sonar.cfamily.build-wrapper-outputtosonar.cfamily.compile-commands. Can you please provide more context on the reason for this change and how it impacts the analysis phase?Also applies to: 146-146
api/plgd/device-provisioning-client/plgd_dps_time.c (6)
48-52: LGTM!The function logic is correct, and the implementation is accurate.
54-60: LGTM!The function logic is correct, and the implementation is accurate.
62-71: LGTM!The function logic is correct, and the implementation is accurate.
73-97: LGTM, but address the TODO comment.The function logic is correct, and the implementation is accurate.
Address TODO: Make time delta configurable.
The hardcoded delta time in
g_dps_time_cfgcould limit flexibility in different deployment scenarios. Consider implementing a mechanism to configure this delta time through external configuration files or environment variables.Do you want me to help implement this configuration feature or open a GitHub issue to track this enhancement?
99-172: LGTM, but consider enhancing error recovery strategies.The function logic is correct, and the implementation is accurate.
Effective Time Synchronization Handling
The function
dps_get_plgd_timeeffectively handles fetching the current time from a trusted source. Consider enhancing error recovery strategies, such as adding more detailed error logs or retry mechanisms in case of time synchronization failures.Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
174-230: LGTM!The function logic is correct, and the implementation is accurate.
api/plgd/unittest/plgd_dps_verify_certificate.cpp (5)
40-52: LGTM!The test case correctly tests the allocation and deallocation of the
dps_verify_certificate_data_tstruct.
54-61: LGTM!The test case correctly tests the failure scenario when an invalid device is passed to the
dps_verify_certificatefunction.
63-75: LGTM!The test case correctly tests the failure scenario when the peer context is missing in the
dps_verify_certificatefunction. The test case is also correctly managing the context lifecycle by adding and removing it from the context list.
77-93: LGTM!The test case correctly tests the failure scenario when an invalid fingerprint algorithm is used in the
dps_verify_certificatefunction. The test case is also correctly managing the context lifecycle by adding and removing it from the context list.
95-122: LGTM!The test fixture correctly sets up and tears down the test environment for the device provisioning client. The helper function to convert a string to an endpoint is also a nice addition to improve the readability of the tests.
api/plgd/device-provisioning-client/plgd_dps_context.c (20)
40-44: LGTM!The function logic is correct, and the implementation is accurate.
46-50: LGTM!The function logic is correct, and the implementation is accurate.
52-56: LGTM!The function logic is correct, and the implementation is accurate.
58-62: LGTM!The function logic is correct, and the implementation is accurate.
64-68: LGTM!The function logic is correct, and the implementation is accurate.
70-74: LGTM!The function logic is correct, and the implementation is accurate.
76-85: LGTM!The function logic is correct, and the implementation is accurate.
87-114: LGTM, but consider the past review comment.The function is correctly initializing the fields of the
plgd_dps_context_tstructure. However, please consider the past review comment about initializing all fields at the start of the function before performing any operations that could potentially fail.Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
116-127: LGTM!The function logic is correct, and the implementation is accurate.
129-144: LGTM!The function logic is correct, and the implementation is accurate.
146-154: LGTM!The function logic is correct, and the implementation is accurate.
156-165: LGTM!The function logic is correct, and the implementation is accurate.
167-173: LGTM!The function logic is correct, and the implementation is accurate.
175-179: LGTM!The function logic is correct, and the implementation is accurate.
181-191: LGTM!The function logic is correct, and the implementation is accurate.
193-199: LGTM!The function logic is correct, and the implementation is accurate.
201-206: LGTM!The function logic is correct, and the implementation is accurate.
208-224: LGTM!The function logic is correct, and the implementation is accurate.
226-231: LGTM!The function logic is correct, and the implementation is accurate.
233-238: LGTM!The function logic is correct, and the implementation is accurate.
api/plgd/device-provisioning-client/plgd_dps_manager.c (17)
45-54: LGTM!The function correctly starts the DPS manager if it's not already started.
56-65: LGTM!The function correctly iterates over the credentials to find the manufacturer certificate.
67-78: LGTM!The function correctly checks if the device has a manufacturer certificate.
80-89: LGTM!The function correctly iterates over the credentials to find the manufacturer trusted root CA.
91-102: LGTM!The function correctly checks if the device has a manufacturer trusted root CA.
104-142: LGTM!The function correctly gets the provision and cloud observer flags based on the current state of the device.
Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
144-200: LGTM!The function correctly starts the DPS manager after performing the necessary checks.
202-207: LGTM!The function correctly checks if the DPS manager is started.
209-218: LGTM!The function correctly starts the DPS manager asynchronously.
220-225: LGTM!The function correctly restarts the DPS manager by stopping and starting it.
227-243: LGTM!The function correctly stops the DPS manager by removing all the delayed callbacks and deinitializing the cloud observer.
245-259: LGTM!The function correctly stops the DPS manager by deinitializing the session and interface callbacks, removing the delayed callbacks, and disconnecting the endpoint.
261-275: LGTM!The function correctly forces reprovisioning and restarts the DPS manager by stopping the cloud manager and restarting the DPS manager.
277-283: LGTM!The function correctly calls
dps_manager_reprovision_and_restartasynchronously.
285-293: LGTM!The function correctly retries provisioning asynchronously by disconnecting the endpoint, incrementing the retry count, and calling
dps_manager_provision_async.
295-349: LGTM!The function correctly provisions the device asynchronously by checking if the device is already provisioned, if the DPS is initialized, if the endpoint is empty, and then starting the provisioning process. It also handles retrying on error by incrementing the retry count and calling itself after a delay.
104-104: Skipping the static analysis hint.The unknown macro error reported by the static analysis tool for
dps_endpoint_add_peerat line 104 is a false positive becausedps_endpoint_add_peeris not used in the provided code. The error can be safely ignored.Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_store.c (17)
55-63: LGTM!The function logic is correct, and the implementation is accurate.
65-70: LGTM!The function logic is correct, and the implementation is accurate.
72-80: LGTM!The function logic is correct, and the implementation is accurate.
82-88: LGTM!The function logic is correct, and the implementation is accurate.
90-140: LGTM!The function logic is correct, and the implementation is accurate.
Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
103-104: Skipping the static analysis hint.The static analysis tool has flagged an unknown macro at line 103. However, this is a false positive as the code is not using any unknown macro. The
dps_endpoint_add_peerfunction is defined in another file.Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
142-215: LGTM!The function logic is correct, and the implementation is accurate.
217-224: LGTM!The function logic is correct, and the implementation is accurate.
226-232: LGTM!The function logic is correct, and the implementation is accurate.
234-245: LGTM!The function logic is correct, and the implementation is accurate.
247-253: LGTM!The function logic is correct, and the implementation is accurate.
255-276: LGTM!The function logic is correct, and the implementation is accurate.
278-309: LGTM!The function logic is correct, and the implementation is accurate.
1-2: Duplicate comment.The past review comment about missing tests is still valid as there are no tests added for this function.
311-318: LGTM!The function logic is correct, and the implementation is accurate.
320-361: LGTM!The function logic is correct, and the implementation is accurate.
363-370: LGTM!The function logic is correct, and the implementation is accurate.
api/plgd/unittest/plgd_dps_provision_cloud.cpp (10)
108-147: LGTM!The test case comprehensively covers the failure scenarios of the
dps_handle_set_cloud_responsefunction. The test structure and assertions look good.
149-223: LGTM!The test case comprehensively covers the success scenarios of the
dps_handle_set_cloud_responsefunction. The test structure and assertions look good.
225-246: LGTM!The test case comprehensively covers the scenarios of the
dps_has_cloud_configurationfunction. The test structure and assertions look good.
248-298: LGTM!The test case comprehensively covers the scenarios of the
dps_set_cloud_handlerfunction. The test structure and assertions look good.
300-310: LGTM!The test case comprehensively covers the failure scenarios of the
dps_provisioning_set_cloud_encode_selected_gatewayfunction. The test structure and assertions look good.
312-336: LGTM!The test case comprehensively covers the scenarios of the
dps_provisioning_set_cloud_encode_selected_gatewayfunction. The test structure and assertions look good.
338-347: LGTM!The test case comprehensively covers the failure scenarios of the
dps_provisioning_set_cloud_encode_payloadfunction. The test structure and assertions look good.
349-355: LGTM!The test case covers the success scenario of the
dps_provisioning_set_cloud_encode_payloadfunction. The test structure and assertion look good.
357-368: LGTM!The test case covers the failure scenario of the
dps_provisioning_set_cloudfunction where the device must be in RFNOP state. The test structure and assertion look good.
370-378: LGTM!The test case covers the success scenario of the
dps_provisioning_set_cloudfunction. The test structure and assertion look good.api/plgd/device-provisioning-client/plgd_dps_pki.c (16)
50-57: LGTM!The function logic is correct, and the implementation is accurate.
112-118: The following comment from the previous review is still applicable:coderabbitai[bot]: Add Runtime Check for Certificate State Conversion
The function
dps_pki_certificate_state_to_struses an assertion to ensure the state index is within bounds, which is suitable for debug builds. Consider adding a runtime check for production builds to prevent potential out-of-bounds access.- assert((size_t)state < ARRAY_SIZE(g_dps_certificate_state_str)); + if ((size_t)state >= ARRAY_SIZE(g_dps_certificate_state_str)) { + return "unknown state"; + }
120-125: LGTM!The function logic is correct, and the implementation is accurate.
127-150: LGTM!The function correctly validates the certificate based on its validity period and the current time, returning the appropriate certificate state.
152-178: LGTM!The function correctly updates the
credentials_replacedflag and logs detailed information about the applied credential when debug logging is enabled.
180-218: LGTM!The function correctly replaces the certificates by retrieving the credential resource, setting the stale tag, updating the pstat, applying the credentials, removing stale credentials, and handling the case when credentials are replaced or removed.
220-224: LGTM!The function correctly checks if the certificates can be replaced based on the provisioning status.
226-246: LGTM!The function correctly schedules the renewal of certificates by calculating the renewal interval, handling the case when the interval calculation fails, substituting the minimal allowed interval if necessary, and scheduling the renewal callback.
248-285: LGTM!The function correctly calculates the interval for renewing certificates based on the expiration time and the current time, handling different expiration time ranges and returning the appropriate interval.
287-294: The following comment from the previous review is still applicable:coderabbitai[bot]: Retry Mechanism for Replacing Credentials Approved
The
dps_pki_replace_credentials_retryfunction integrates well with the retry mechanism, providing a robust fallback for credential replacement. Consider adding more detailed error handling to capture specific failure scenarios.+ if (!result) { + DPS_ERR("Retry failed for credentials replacement"); + }
296-345: The following comment from the previous review is still applicable:coderabbitai[bot]: Refactor Suggestion for Credentials Replacement Handler
The
dps_pki_replace_credentials_handlerfunction handles various scenarios effectively but is complex. Consider refactoring to reduce complexity and improve readability. Reducing the use ofgotostatements and breaking down the function into smaller parts could enhance maintainability.+ // Refactor into smaller functions for each major block + bool handle_response_code(...) { + // handle different response codes + } + bool process_payload(...) { + // process the payload + }
347-368: LGTM!The function correctly attempts to renew the certificates by sending a CSR request, scheduling a retry in case the response is not retrieved, and updating the provisioning status and last error.
370-376: LGTM!The function correctly increments the retry count and calls
dps_pki_renew_certificates_asyncas an asynchronous callback for retrying the renewal of certificates.
378-397: LGTM!The function correctly handles the asynchronous renewal of certificates by checking if the certificates can be replaced, attempting to renew the certificates, and handling the case when the renewal fails by rescheduling or forcing reprovision.
399-406: LGTM!The function correctly sets the expiring limit
59-103: Add Runtime Checks for Null ArgumentsThe function is implemented correctly. However, to enhance production safety, consider adding runtime checks to handle potential null arguments gracefully:
- assert(ctx != NULL); - assert(handler != NULL); + if (ctx == NULL || handler == NULL) { + DPS_ERR("Context or handler is null"); + return false; + }Likely invalid or redundant comment.
api/plgd/device-provisioning-client/plgd_dps_provision_cloud.c (10)
43-115: ** Review ofdps_register_cloud_fill_datafunction: Error handling and memory management.**The past review comment is still applicable:
This function performs key extraction from a payload and assigns them to a
cloud_conf_tstructure. The error handling is robust, with checks for null pointers after each key extraction. However, consider the following improvements:
- Memory Management: The function assigns pointers to strings within the
oc_rep_tstructure directly to thecloud_conf_tstructure. Ensure that the lifetime of theoc_rep_tpayload outlasts thecloud_conf_tusage or consider copying the strings.- Error Logging: The error messages are helpful, but they could include more context about the payload to aid debugging.
- Return Early Pattern: The function uses multiple return points, which is generally fine, but consider using a single exit point for cleaner flow and easier maintenance.
Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
117-132: ** Review ofcloud_deregister_handler: Simplify error handling.**The past review comment is still applicable:
The function
cloud_deregister_handlerlogs different messages based on the response code. Consider simplifying the error handling by using a switch-case or mapping response codes to messages to reduce redundancy and improve maintainability.
134-155: ** Potential issue with assert usage incloud_deregister.**The past review comment is still applicable:
The function uses
assertto ensurecloud_epis not null. While this is acceptable for debug builds, in a production build where asserts might be disabled, this could lead to undefined behavior ifcloud_epis null. Consider adding runtime checks and proper error handling for production builds.
240-251: ** Simplifydps_has_cloud_configurationby using helper functions.**The past review comment is still applicable:
This function checks if the cloud configuration is set by verifying server URI and access token. Consider using helper functions to encapsulate these checks, improving readability and reusability.
253-315: ** Error handling and status management indps_set_cloud_handler.**The past review comment is still applicable:
This handler function manages cloud setting responses and updates device status accordingly. The error handling is extensive, but the function could benefit from separating the status update logic into a separate function for clarity and reusability.
317-352: ** Review ofdps_provisioning_set_cloud_encode_selected_gateway: Ensure robust error handling.**The past review comment is still applicable:
This function encodes the selected gateway for cloud provisioning. It uses asserts to ensure non-null pointers, which is risky in production. Consider adding runtime checks and returning meaningful error messages or codes if the assumptions are violated.
354-374: ** Potential improvements indps_provisioning_set_cloud_encode_payload.**The past review comment is still applicable:
This function encodes the payload for cloud provisioning. It has robust error handling but could be simplified by abstracting some of the repetitive tasks into helper functions or macros, especially the UUID handling and string operations.
377-409: ** Improve error handling and replace assertions.**The past review comment is still applicable:
The function
dps_provisioning_set_clouduses assertions to ensure the endpoint is not null and checks the device state. Consider replacing assertions with runtime checks to prevent potential issues in production environments where assertions may be disabled.Additionally, improve error handling by providing more specific error messages or codes when checks fail, to aid in debugging and maintenance.
104-104: ** cppcheck: Unknown macro error can be ignored.**The unknown macro error reported by cppcheck at line 104 appears to be a false positive because:
- The macro
dps_endpoint_add_peeris not used in the provided code snippet.- Line 104 is an empty line.
- cppcheck often reports false positives for unknown macros when it lacks the full context of the codebase.
Feel free to ignore this cppcheck error.
Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
157-238: ** Complexity and error handling indps_handle_set_cloud_response.**The past review comment is still applicable:
This function is quite complex, handling multiple scenarios for cloud configuration and response parsing. Consider breaking it down into smaller, more manageable functions. Additionally, ensure that all error paths properly clean up any allocated resources to prevent memory leaks.
Would you like me to help refactor this function into smaller parts? I can open a new GitHub issue to track this refactoring task.
api/plgd/unittest/plgd_dps_resource.cpp (12)
62-85: LGTM!The function correctly parses an array of DPS endpoints from an
oc_rep_tobject and handles the case of missing properties by returning an empty vector.
87-140: LGTM!The function correctly parses a single property of DPS data from an
oc_rep_tobject and handles all the expected property types.
142-156: LGTM!The function correctly parses DPS data from an
oc_rep_tobject, skips baseline interface properties, and logs unexpected properties using theparseDPSDataPropertyhelper function.
158-238: LGTM!The test case is well-structured and covers various scenarios for encoding and decoding DPS resource representations for the "oic.if.r" interface.
240-275: LGTM!The test case is well-structured and covers the scenario for encoding and decoding DPS resource representations for the "oic.if.rw" interface.
277-380: LGTM!The test case is well-structured and covers various scenarios for the
dps_status_to_strfunction.
382-406: LGTM!The test fixture is well-structured and correctly sets up and tears down the test server and DPS context.
408-441: LGTM!The function correctly sends a GET request to the DPS resource with an optional query parameter, checks the response code, and parses the DPS data from the response payload.
443-456: LGTM!The test case is well-structured and covers the scenario of sending a GET request to the DPS resource when the DPS context is not initialized, expecting an internal server error response.
458-469: LGTM!The test case is well-structured and covers the scenario of sending a GET request to the DPS resource when the DPS resource is not created, expecting a not found response.
481-507: LGTM!The function correctly sends a POST request to the DPS resource with a payload encoded by the provided function, checks the response code, and logs the response payload.
509-570: LGTM!The test case is well-structured and covers the scenario of sending a POST request to the DPS resource with a payload containing endpoints, checking the selected endpoint and iterating over all the endpoints to verify their URIs and names.
api/plgd/device-provisioning-client/plgd_dps_provision.c (13)
43-63: LGTM!The function correctly handles the response from the DPS server and sets the appropriate error status and last error.
65-98: LGTM!The debug function is correctly implemented and the conditional compilation ensures that it is not included in the release build.
139-204: LGTM!The function correctly handles the response from the DPS server for the GET ACLs request and schedules the next step in the provisioning process.
206-229: LGTM!The function correctly sends the GET ACLs request to the DPS server after checking the device state and setting up the TLS connection.
231-305: LGTM!The function correctly handles the response from the DPS server for the GET credentials request and schedules the next step in the provisioning process.
307-334: LGTM!The function correctly sends the GET credentials request to the DPS server after checking the device state and sending the CSR.
336-340: LGTM!The function correctly schedules the next step in the provisioning process.
342-350: LGTM!The function correctly gets the DPS time as the next step in the provisioning process.
352-360: LGTM!The function correctly gets the DPS ownership as the next step in the provisioning process.
362-370: LGTM!The function correctly gets the cloud configuration as the next step in the provisioning process.
372-380: LGTM!The function correctly gets the DPS credentials as the next step in the provisioning process.
382-390: LGTM!The function correctly gets the DPS ACLs as the next step in the provisioning process.
630-654: LGTM!The function correctly handles the failure in the provisioning process by checking the retry count and forcing a full reprovisioning if necessary. It also schedules a retry if requested.
CMakeLists.txt (10)
80-84: Skipped comment & approved new variables.Skipped generating a comment about
PLGD_DEV_TIME_ENABLEDas the past review comment is still valid.The new CMake variable additions
PLGD_DEV_DEVICE_PROVISIONING_ENABLEDandPLGD_DEV_DEVICE_PROVISIONING_TEST_PROPERTIES_ENABLEDlook good.
239-246: LGTM!The refactoring of the logging level configuration using the
oc_set_maximum_log_levelfunction enhances the readability and maintainability of the CMake file. The log level is correctly appended to the necessary compile definition lists.
407-412: LGTM!The changes correctly handle the
PLGD_DEV_TIME_ENABLEDflag by appending the necessary compile definitions based on its value and theBUILD_MBEDTLSflag.
414-434: LGTM!The changes introduce a robust control flow that prevents misconfigurations arising from incompatible feature combinations when enabling
PLGD_DEV_DEVICE_PROVISIONING_ENABLED. The necessary compile definitions are correctly added based on the flag's value and the required dependencies. The maximum log level for the Plgd DPS is also correctly set and appended to the necessary compile definition lists.
436-441: LGTM!The changes correctly handle the
PLGD_DEV_DEVICE_PROVISIONING_TEST_PROPERTIES_ENABLEDflag by appending the necessary compile definitions based on its value and theBUILD_TESTINGflag.
684-688: LGTM!The changes correctly gather the necessary source files for the Plgd device provisioning client when
PLGD_DEV_DEVICE_PROVISIONING_ENABLEDis enabled using thefile(GLOB)command.
690-690: LGTM!The change correctly adds the Plgd device provisioning client source files (
PLGD_DPS_SRC) to theclient-server-objtarget whenPLGD_DEV_DEVICE_PROVISIONING_ENABLEDis enabled, ensuring that the necessary source files are compiled and linked with the target.
1112-1121: LGTM!The changes correctly add a new test target (
plgdtest) for the Plgd features when eitherPLGD_DEV_TIME_ENABLEDorPLGD_DEV_DEVICE_PROVISIONING_ENABLEDis enabled. Thefile(GLOB)command is used correctly to get the necessary test source files, and theoc_package_add_testfunction is called with the correct arguments to create the test target with the necessary source files and environment variables.
1315-1319: LGTM!The changes correctly install the necessary header file (
include/plgd/plgd_time.h) for the Plgd time feature whenPLGD_DEV_TIME_ENABLEDis enabled. The header file is installed to the correct directory (${CMAKE_INSTALL_INCLUDEDIR}/iotivity-lite/plgd) and as part of thedevcomponent.
1321-1326: LGTM!The changes correctly install the necessary header file (
include/plgd/plgd_dps.h) for the Plgd device provisioning feature whenPLGD_DEV_DEVICE_PROVISIONING_ENABLEDis enabled. The header file is installed to the correct directory (${CMAKE_INSTALL_INCLUDEDIR}/iotivity-lite/plgd) and as part of thedevcomponent.api/plgd/device-provisioning-client/plgd_dps.c (14)
38-46: LGTM!The function correctly handles the manager status change by logging the status and calling the registered callback if it exists.
48-54: LGTM!The function correctly handles the event by calling
dps_manager_status_cbwith the context and returningOC_EVENT_DONE.
58-63: LGTM!The function correctly restarts the manager by stopping it and scheduling an asynchronous call to
dps_manager_start_async.
65-126: LGTM!The function correctly handles endpoint events by performing different actions based on the event state and context. The debug logging is conditionally compiled based on the
DPS_DBG_IS_ENABLEDmacro, which is a good practice.Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
128-148: LGTM!The function correctly handles session events for both the context endpoint and the cloud server endpoint by comparing the provided endpoint and performing appropriate actions based on the session state.
150-158: LGTM!The function correctly restarts the manager if the status is initialized. It is used as a callback function for iterating over contexts.
160-166: LGTM!The function correctly handles interface events by restarting initialized contexts when the network interface is up using
dps_contexts_iteratewithdps_restart_initializedas the callback.
170-187: LGTM!The function correctly initializes the DPS contexts for each device. It properly handles memory allocation failures and returns the appropriate status code.
189-210: LGTM!The function correctly shuts down the DPS contexts for each device, cleaning up resources and removing callbacks. The session event callback removal is conditionally compiled based on the
OC_SESSION_EVENTSmacro, which is a good practice.
214-224: LGTM!The functions
plgd_dps_session_callbacks_initandplgd_dps_session_callbacks_deinitcorrectly add and remove session event callbacks respectively. The conditional compilation based on theOC_SESSION_EVENTSmacro is a good practice.
226-236: LGTM!The functions
plgd_dps_interface_callbacks_initandplgd_dps_interface_callbacks_deinitcorrectly add and remove network interface event callbacks respectively. The conditional compilation based on theOC_SESSION_EVENTSmacro is a good practice.
240-259: LGTM!The function correctly tries to set the identity certificate chain by retrieving the identity credential ID and the cloud context, comparing the current identity certificate chain with the retrieved credential ID, and updating it if necessary. It returns the appropriate boolean value based on the success of the operation.
261-280: LGTM!The function correctly starts the cloud manager by retrieving the cloud context, logging relevant information, and starting the cloud manager with the provided callbacks. It returns the appropriate boolean value based on the success of the operation. The debug logging is conditionally compiled based on the
DPS_INFO_IS_ENABLEDmacro, which is a good practice.
282-315: LGTM!The function correctly sets the certificate fingerprint by validating the provided message digest type, comparing the provided fingerprint with the current fingerprint, and updating it if necessary. It logs the fingerprint if debug logging is enabled, which is a good practice. It returns the appropriate boolean value based on the success of the operation.
There was a problem hiding this comment.
Actionable comments posted: 1
Outside diff range and nitpick comments (1)
api/plgd/device-provisioning-client/plgd_dps_pki_internal.h (1)
49-114: Enum, struct, and most function declarations look good. Consider passing PKI configuration by const reference.The
dps_certificate_state_tenum anddps_pki_configuration_tstruct are correctly defined. Most of the function declarations are also correctly formatted and documented with the necessary information about the parameters and return values.However, the
dps_pki_validate_certificatefunction takes the PKI configuration by value, which may be inefficient for larger structs.Consider passing the PKI configuration by const reference instead:
-int dps_pki_validate_certificate(dps_pki_configuration_t cfg, +int dps_pki_validate_certificate(const dps_pki_configuration_t& cfg, uint64_t valid_from, uint64_t valid_to);
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files ignored due to path filters (1)
tools/doxygen.iniis excluded by!**/*.ini
Files selected for processing (82)
- .dockerignore (1 hunks)
- .github/workflows/cmake-linux.yml (2 hunks)
- .github/workflows/docker-build-publish-with-cfg.yml (1 hunks)
- .github/workflows/docker-build-publish.yml (1 hunks)
- .github/workflows/ghcr-check.yml (1 hunks)
- .github/workflows/plgd-device-test-with-cfg.yml (1 hunks)
- .github/workflows/plgd-dps-test-with-cfg.yml (1 hunks)
- .github/workflows/plgd-dps-tests.yml (1 hunks)
- .github/workflows/plgd-hub-test-with-cfg.yml (1 hunks)
- .github/workflows/sonar-cloud-analysis.yml (4 hunks)
- .github/workflows/static-analysis.yml (2 hunks)
- .github/workflows/unit-test-with-cfg.yml (1 hunks)
- CMakeLists.txt (7 hunks)
- api/oc_endpoint.c (1 hunks)
- api/oc_log.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_apis.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_apis_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_cloud.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_cloud_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_context.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_context_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_dhcp.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_dhcp_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_endpoint.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_endpoint_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_endpoints.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_endpoints_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_log.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_log_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_manager.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_manager_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_pki.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_pki_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision_cloud.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision_cloud_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision_owner.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision_owner_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_resource.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_resource_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_retry.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_retry_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_security.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_security_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_store.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_store_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_tag.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_tag_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_time.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_time_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_verify_certificate.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_verify_certificate_internal.h (1 hunks)
- api/plgd/unittest/plgd_dps.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_apis.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_cloud.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_context.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_dhcp.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_endpoint.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_endpoints.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_log.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_manager.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_pki.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_provision.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_provision_cloud.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_provision_owner.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_resource.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_retry.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_security.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_store.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_tag.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_test.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_test.h (1 hunks)
- api/plgd/unittest/plgd_dps_time.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_verify_certificate.cpp (1 hunks)
- apps/CMakeLists.txt (1 hunks)
- apps/dps_cloud_server.c (1 hunks)
- docker/apps/Dockerfile.cloud-server (2 hunks)
- docker/apps/Dockerfile.dps-cloud-server (1 hunks)
- docker/apps/Dockerfile.dps-cloud-server-debug (1 hunks)
Files not processed due to max files limit (9)
- include/oc_log.h
- include/plgd/plgd_dps.h
- messaging/coap/observe.c
- security/oc_pstat.c
- security/oc_tls.c
- sonar-project.properties
- tools/utils.cmake
- util/oc_features.h
- util/oc_memb.h
Files skipped from review due to trivial changes (12)
- .github/workflows/plgd-device-test-with-cfg.yml
- .github/workflows/plgd-hub-test-with-cfg.yml
- .github/workflows/unit-test-with-cfg.yml
- api/plgd/device-provisioning-client/plgd_dps_cloud_internal.h
- api/plgd/device-provisioning-client/plgd_dps_dhcp_internal.h
- api/plgd/device-provisioning-client/plgd_dps_endpoint_internal.h
- api/plgd/device-provisioning-client/plgd_dps_endpoints_internal.h
- api/plgd/device-provisioning-client/plgd_dps_log_internal.h
- api/plgd/device-provisioning-client/plgd_dps_retry_internal.h
- api/plgd/device-provisioning-client/plgd_dps_security.c
- api/plgd/device-provisioning-client/plgd_dps_security_internal.h
- api/plgd/device-provisioning-client/plgd_dps_tag_internal.h
Files skipped from review as they are similar to previous changes (45)
- .dockerignore
- .github/workflows/cmake-linux.yml
- .github/workflows/docker-build-publish-with-cfg.yml
- .github/workflows/docker-build-publish.yml
- .github/workflows/ghcr-check.yml
- .github/workflows/plgd-dps-tests.yml
- .github/workflows/static-analysis.yml
- api/oc_endpoint.c
- api/oc_log.c
- api/plgd/device-provisioning-client/plgd_dps_cloud.c
- api/plgd/device-provisioning-client/plgd_dps_dhcp.c
- api/plgd/device-provisioning-client/plgd_dps_internal.h
- api/plgd/device-provisioning-client/plgd_dps_log.c
- api/plgd/device-provisioning-client/plgd_dps_provision_cloud_internal.h
- api/plgd/device-provisioning-client/plgd_dps_provision_internal.h
- api/plgd/device-provisioning-client/plgd_dps_provision_owner_internal.h
- api/plgd/device-provisioning-client/plgd_dps_resource.c
- api/plgd/device-provisioning-client/plgd_dps_resource_internal.h
- api/plgd/device-provisioning-client/plgd_dps_retry.c
- api/plgd/device-provisioning-client/plgd_dps_store_internal.h
- api/plgd/device-provisioning-client/plgd_dps_tag.c
- api/plgd/device-provisioning-client/plgd_dps_time_internal.h
- api/plgd/device-provisioning-client/plgd_dps_verify_certificate.c
- api/plgd/device-provisioning-client/plgd_dps_verify_certificate_internal.h
- api/plgd/unittest/plgd_dps.cpp
- api/plgd/unittest/plgd_dps_apis.cpp
- api/plgd/unittest/plgd_dps_cloud.cpp
- api/plgd/unittest/plgd_dps_context.cpp
- api/plgd/unittest/plgd_dps_dhcp.cpp
- api/plgd/unittest/plgd_dps_endpoint.cpp
- api/plgd/unittest/plgd_dps_endpoints.cpp
- api/plgd/unittest/plgd_dps_manager.cpp
- api/plgd/unittest/plgd_dps_provision.cpp
- api/plgd/unittest/plgd_dps_provision_owner.cpp
- api/plgd/unittest/plgd_dps_retry.cpp
- api/plgd/unittest/plgd_dps_security.cpp
- api/plgd/unittest/plgd_dps_store.cpp
- api/plgd/unittest/plgd_dps_test.cpp
- api/plgd/unittest/plgd_dps_test.h
- api/plgd/unittest/plgd_dps_time.cpp
- apps/CMakeLists.txt
- apps/dps_cloud_server.c
- docker/apps/Dockerfile.cloud-server
- docker/apps/Dockerfile.dps-cloud-server
- docker/apps/Dockerfile.dps-cloud-server-debug
Additional context used
cppcheck
api/plgd/device-provisioning-client/plgd_dps_endpoints.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_endpoint.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_apis.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_provision_owner.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_time.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_context.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_manager.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_store.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_pki.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_provision_cloud.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_provision.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
actionlint
.github/workflows/plgd-dps-test-with-cfg.yml
122-122: shellcheck reported issue in this script: SC2046:warning:1:62: Quote this to prevent word splitting
(shellcheck)
134-134: shellcheck reported issue in this script: SC2129:style:2:1: Consider using { cmd1; cmd2; } >> file instead of individual redirects
(shellcheck)
134-134: shellcheck reported issue in this script: SC2086:info:2:53: Double quote to prevent globbing and word splitting
(shellcheck)
134-134: shellcheck reported issue in this script: SC2086:info:3:61: Double quote to prevent globbing and word splitting
(shellcheck)
134-134: shellcheck reported issue in this script: SC2086:info:4:48: Double quote to prevent globbing and word splitting
(shellcheck)
Additional comments not posted (233)
api/plgd/device-provisioning-client/plgd_dps_manager_internal.h (6)
1-17: LGTM!The Apache 2.0 license header is correctly formatted and includes the appropriate copyright notice.
19-27: LGTM!The header guards and includes are correctly set up:
- The header guard macro is properly named and follows the standard format.
- The necessary headers are included, covering both the public header for this module and the required oc_* headers.
32-47: LGTM!The function declarations for starting, stopping, and reprovisioning the DPS manager are well-designed:
- The functions are properly documented using Doxygen-style comments.
- The
OC_NONNULLattribute is used to enforce non-null parameters.- The naming and signatures of the functions are clear and consistent.
49-70: LGTM!The callback function declarations for provisioning the device using DPS are well-designed:
- The functions are properly documented using Doxygen-style comments.
- The
OC_NO_DISCARD_RETURNattribute is used to enforce that the return value is used.- The naming and signatures of the functions are clear and consistent.
72-76: LGTM!The
provision_and_cloud_observer_flags_tstruct definition is well-designed:
- The struct encapsulates related fields for provisioning flags and cloud observer status.
- The fields have appropriate types and naming.
78-80: LGTM!The
dps_get_provision_and_cloud_observer_flagsfunction declaration is well-designed:
- The function returns the provisioning flags and cloud observer status based on the current state, which is a clear and focused responsibility.
- The function takes a pointer to the DPS context as a parameter, which is necessary for determining the current state.
- The
OC_NONNULLattribute is used to enforce that the parameter is not null.api/plgd/device-provisioning-client/plgd_dps_apis_internal.h (11)
38-40: LGTM!The function logic is correct, and the implementation is accurate.
43-44: LGTM!The function logic is correct, and the implementation is accurate.
47-49: LGTM!The function logic is correct, and the implementation is accurate.
52-53: LGTM!The function logic is correct, and the implementation is accurate.
57-58: LGTM!The function logic is correct, and the implementation is accurate.
62-62: LGTM!The function logic is correct, and the implementation is accurate.
66-66: LGTM!The function logic is correct, and the implementation is accurate.
69-69: LGTM!The function logic is correct, and the implementation is accurate.
73-74: LGTM!The function logic is correct, and the implementation is accurate.
86-87: LGTM!The function logic is correct, and the implementation is accurate.
91-91: LGTM!The function logic is correct, and the implementation is accurate.
api/plgd/unittest/plgd_dps_log.cpp (4)
39-52: LGTM!The test case looks good. It's logging messages at all levels and verifying that the log level can be changed to
TRACEand that subsequentDEBUGandTRACElevel messages are logged.
58-67: The past review comment about theprintfformat string issue is outdated.The format string issue flagged in the past review comment has been fixed in the current code. The
printLogfunction looks good now.
86-97: LGTM!The test case looks good. It's setting the log level to
NOTICE, setting a custom log function that expects onlyERROR,WARNING, andNOTICElevel messages, and then logging messages at all levels and verifying that only the expected levels are logged.
105-116: LGTM!The test case looks good. It's setting the log level to
TRACE, setting a custom log function that fails the test if any log message is received, and then logging messages at all levels and verifying that no messages are logged.api/plgd/unittest/plgd_dps_tag.cpp (4)
68-87: LGTM!The test case follows the AAA pattern and correctly tests the expected behavior of setting and removing the stale tag for credentials.
91-110: LGTM!The test case correctly verifies the expected behavior when there are no credentials. It checks that the tag remains null after setting and removing the stale tag.
112-130: LGTM!The test case correctly verifies the expected behavior of setting and removing the stale tag for ACLs. It adds a bootstrap ACL, sets the tag to the DPS tag, and asserts the expected behavior after setting and removing the stale tag.
132-151: LGTM!The test case correctly verifies the expected behavior when there are no ACLs. It checks that the tag remains null after setting and removing the stale tag.
api/plgd/device-provisioning-client/plgd_dps_pki_internal.h (4)
1-17: License header looks good.The Apache 2.0 license header is correctly formatted and contains the necessary information.
19-33: Header guards and extern "C" declaration look good.The header guards are correctly implemented to prevent multiple inclusions of the header file. The extern "C" declaration is also correctly used for C++ compatibility.
34-47: DPS credentials URI macro anddps_pki_send_csrfunction declaration look good.The macro for the DPS credentials URI is correctly defined. The
dps_pki_send_csrfunction declaration is also correctly formatted and documented with the necessary information about the parameters and return values.
116-150: Certificate renewal function declarations, extern "C" block, and header guards look good.The function declarations related to renewing DPS certificates are correctly formatted and documented with the necessary information about the parameters and return values. The extern "C" block and header guards are also correctly closed at the end of the file.
api/plgd/unittest/plgd_dps_pki.cpp (6)
42-46: LGTM!The
TestPKIclass is correctly implemented as a test fixture that initializes and shuts down the OC runtime for each test case, following the Google Test framework conventions.
48-56: LGTM!The
TestPKI::SendCSR_FailInvalidDeviceIDtest case is correctly implemented and verifies the failure of sending a CSR with an invalid device ID.
58-63: LGTM!The
TestPKI::ReplaceCertificates_FailInvalidDeviceIDtest case is correctly implemented and verifies the failure of replacing certificates with an invalid device ID.
65-94: LGTM!The
TestPKI::CalculateRenewCertificatesIntervaltest case is correctly implemented and verifies the calculation of the certificate renewal interval based on the expiration time for different scenarios.
96-110: LGTM!The
TestPKIWithDeviceclass is correctly implemented as a test fixture that starts and stops the test device server for each test case, following the Google Test framework conventions.
112-165: LGTM!The following test cases are correctly implemented and verify the expected behavior:
TestPKIWithDevice::ReplaceCertificates_FailInvalidRep: Verifies the failure of replacing certificates with an invalid representation.TestPKIWithDevice::TryRenewCertificates: Verifies the attempt to renew certificates.TestPKIWithDevice::RenewCertificates: Verifies the renewal of certificates.api/plgd/device-provisioning-client/plgd_dps_endpoints.c (12)
36-63: LGTM!The function logic is correct, and the implementation is accurate. The function correctly handles the case where the endpoint is already set and notifies observers when necessary.
65-82: LGTM!The function logic is correct, and the implementation is accurate. The function correctly handles the case where the selected endpoint has changed and disconnects the current endpoint if necessary.
84-90: LGTM!The function logic is correct, and the implementation is accurate. The function is a simple wrapper that calls the
dps_set_endpointfunction with thenotifyparameter set to true.
92-113: LGTM!The function logic is correct, and the implementation is accurate. The function correctly handles the case where no endpoint is set and returns early. It also checks if the provided buffer is large enough to hold the endpoint and returns an error if it is not.
Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
115-120: LGTM!The function logic is correct, and the implementation is accurate. The function correctly checks if the selected endpoint is NULL and returns true if it is.
122-132: LGTM!The function logic is correct, and the implementation is accurate. The function is a simple wrapper that calls the
oc_endpoint_addresses_initfunction with the provided parameters.
134-142: LGTM!The function logic is correct, and the implementation is accurate. The function is a simple wrapper that calls the
oc_endpoint_addresses_addfunction with the provided parameters.
144-149: LGTM!The function logic is correct, and the implementation is accurate. The function is a simple wrapper that calls the
oc_endpoint_addresses_removefunction with the provided parameters.
151-158: LGTM!The function logic is correct, and the implementation is accurate. The function is a simple wrapper that calls the
oc_endpoint_addresses_iteratefunction with the provided parameters.
160-165: LGTM!The function logic is correct, and the implementation is accurate. The function is a simple wrapper that calls the
oc_endpoint_addresses_selectfunction with the provided parameters.
167-171: LGTM!The function logic is correct, and the implementation is accurate. The function is a simple wrapper that calls the
oc_endpoint_addresses_selectedfunction with the provided parameters.
104-104: Skipping the static analysis hint.The static analysis tool cppcheck reported an error about an unknown macro
dps_endpoint_add_peer. However, this macro is not used in the file, so the error can be safely ignored.Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_context_internal.h (4)
1-17: LGTM!The license header is properly formatted and includes the correct information.
19-34: LGTM!The header guards are properly defined, and the necessary headers are included in a logical order.
39-118: LGTM!The structs and typedefs are well-defined and have clear and descriptive names. The fields within the structs are properly documented, and the use of typedefs for function pointers improves code readability.
91-148: LGTM!The function declarations follow a consistent naming convention and have appropriate parameter types. The use of the
OC_NONNULLmacro helps catch potential null pointer dereferences. The functions are well-documented, and their declarations are organized in a logical order.api/plgd/device-provisioning-client/plgd_dps_endpoint.c (9)
36-51: LGTM!The function correctly initializes the endpoint in the DPS context and clears the DNS cache.
55-77: LGTM!The debug function correctly prints the peers for an endpoint and is properly excluded from coverage.
80-123: LGTM!The function correctly adds a new peer for an endpoint with the appropriate ciphersuite and verification data.
Regarding the static analysis hint:
The unknown macro error is a false positive because
dps_endpoint_add_peeris not a macro. It can be safely ignored.Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
125-133: LGTM!The function correctly closes the session for a non-empty endpoint.
135-145: LGTM!The function correctly disconnects the endpoint in the DPS context by closing the endpoint, clearing the endpoint memory, and setting the endpoint state to disconnected.
147-152: LGTM!The function correctly checks if an endpoint is empty by asserting that the endpoint is not NULL and returning the result of
oc_endpoint_is_empty.
154-185: LGTM!The function correctly converts an endpoint to a string and logs it with the following steps:
- Converts the endpoint to a string using
oc_endpoint_to_string.- Checks if the string length is valid and fits in the provided buffer.
- Includes the session ID in the log string if debug is enabled.
- Frees the endpoint string and returns true if successful.
187-198: LGTM!The function correctly sets up TLS for an endpoint in the DPS context with the following steps:
- Checks if a peer already exists for the endpoint and returns if true.
- Adds a new peer for the endpoint and logs an error if it fails.
- Logs a debug message indicating the setup of TLS with cloud ciphersuite and manufacturer certificates.
200-206: LGTM!The function correctly resets the TLS configuration with the following steps:
- Resets the ciphersuite using
oc_tls_reset_ciphersuite.- Enables the selection of the identity cert chain using
oc_tls_select_identity_cert_chain.- Logs a debug message indicating the reset of TLS to use the default ciphersuite and certificates.
.github/workflows/plgd-dps-test-with-cfg.yml (7)
86-103: The following past review comment is still valid and applicable:Quote
$(hostname)in the container name to prevent word splitting issues.The step uses
$(hostname)in the container name without quoting, which may cause word splitting issues as indicated by the static analysis hint.Apply this diff to fix the issue:
- dps-devsim-$(hostname) + dps-devsim-"$(hostname)"
106-119: The following past review comment is still valid and applicable:Quote
$(hostname)in the container name to prevent word splitting issues.The step uses
$(hostname)in the container name without quoting, which may cause word splitting issues as indicated by the static analysis hint.Apply this diff to fix the issue:
- dps-devsim-obt-$(hostname) "" + dps-devsim-obt-"$(hostname)" ""
121-129: The following past review comment is still valid and applicable:Quote
$(hostname)in the--hostnameargument to prevent word splitting issues.The step uses
$(hostname)in the--hostnameargument without quoting, which may cause word splitting issues as indicated by the static analysis hint.Apply this diff to fix the issue:
- --hostname=$(hostname) + --hostname="$(hostname)"Tools
actionlint
122-122: shellcheck reported issue in this script: SC2046:warning:1:62: Quote this to prevent word splitting
(shellcheck)
132-138: The following past review comment is still valid and applicable:Fix required: Use
$()instead of backticks for command substitution, use{ cmd1; cmd2; } >> fileinstead of individual redirects, and quote variables to prevent word splitting issues.The step uses backticks for command substitution, which is a legacy syntax as indicated by the static analysis hint. It also uses multiple redirects to append to the
$GITHUB_OUTPUTfile, which can be simplified as indicated by the static analysis hint. Additionally, it uses unquoted variables in theechocommands, which may cause word splitting issues as indicated by the static analysis hint.Apply this diff to fix the issues:
- SUFFIX=`echo "-DCMAKE_BUILD_TYPE=${{ inputs.build_type }} ${{ inputs.build_args }} -DBUILD_TESTING=ON ${{ inputs.args }}" | sha1sum | cut -f 1 -d ' '` - echo "filename=coverage-plgd-dps-${SUFFIX}.json" >> $GITHUB_OUTPUT - echo "filename_obt=coverage-plgd-dps-obt-${SUFFIX}.json" >> $GITHUB_OUTPUT - echo "artifact=plgd-dps-${SUFFIX}-coverage" >> $GITHUB_OUTPUT + SUFFIX=$(echo "-DCMAKE_BUILD_TYPE=${{ inputs.build_type }} ${{ inputs.build_args }} -DBUILD_TESTING=ON ${{ inputs.args }}" | sha1sum | cut -f 1 -d ' ') + { + echo "filename=coverage-plgd-dps-${SUFFIX}.json" + echo "filename_obt=coverage-plgd-dps-obt-${SUFFIX}.json" + echo "artifact=plgd-dps-${SUFFIX}-coverage" + } >> "$GITHUB_OUTPUT"Tools
actionlint
134-134: shellcheck reported issue in this script: SC2129:style:2:1: Consider using { cmd1; cmd2; } >> file instead of individual redirects
(shellcheck)
134-134: shellcheck reported issue in this script: SC2086:info:2:53: Double quote to prevent globbing and word splitting
(shellcheck)
134-134: shellcheck reported issue in this script: SC2086:info:3:61: Double quote to prevent globbing and word splitting
(shellcheck)
134-134: shellcheck reported issue in this script: SC2086:info:4:48: Double quote to prevent globbing and word splitting
(shellcheck)
140-155: LGTM!The step for gathering coverage data looks good. The commands for stopping and starting the containers, and executing the
collect-coverage.shscript are correctly implemented.
157-164: LGTM!The step for uploading coverage data looks good. The
actions/upload-artifactaction is correctly configured with the appropriate inputs.
166-176: LGTM!The steps for collecting dps cloud server logs when the test fails look good. The commands for stopping the containers and collecting the logs are correctly implemented.
api/plgd/device-provisioning-client/plgd_dps_apis.c (12)
35-43: LGTM!The function logic is correct, and the implementation is accurate.
45-51: LGTM!The function logic is correct, and the implementation is accurate.
53-61: LGTM!The function logic is correct, and the implementation is accurate.
63-73: LGTM!The function logic is correct, and the implementation is accurate.
75-90: LGTM!The function logic is correct, and the implementation is accurate. It correctly handles the case where the interval exceeds the maximum value of
oc_clock_time_t.
92-99: LGTM!The function logic is correct, and the implementation is accurate.
101-105: LGTM!The function logic is correct, and the implementation is accurate.
Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
107-112: LGTM!The function logic is correct, and the implementation is accurate.
114-118: LGTM!The function logic is correct, and the implementation is accurate.
120-130: LGTM!The function logic is correct, and the implementation is accurate. It correctly maps the status codes to the corresponding error codes.
132-182: LGTM!The function logic is correct, and the implementation is accurate. It correctly handles the redirect response by updating the list of endpoints and selecting the new server.
184-201: LGTM!The function logic is correct, and the implementation is accurate. It correctly checks the response status code and handles the redirect response if the payload is not NULL.
api/plgd/device-provisioning-client/plgd_dps_provision_owner.c (4)
43-73: The past review comment is still valid and applicable:Robust Handling of GET Owner Response
The function
dps_handle_get_owner_responseis well-implemented with robust checks and detailed error logging. Consider enhancing the error handling by providing more specific error messages or recovery options when unexpected properties are encountered.
75-143: LGTM!The function
dps_get_owner_handleris well-implemented and handles various aspects of the GET owner response. It checks the status of the device and the response code before processing the response, sets the appropriate status and error flags based on the response, schedules the next step in the provisioning process if the owner is set successfully, and handles failures by setting the appropriate error flags and scheduling a retry if necessary.Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
156-178: The past review comment is still valid and applicable:Comprehensive Implementation of GET Owner Request
The function
dps_get_owneris well-structured and handles various aspects of sending a GET request for ownership information. Consider improving the handling of TLS errors by adding retries or more detailed error reporting.
182-209: LGTM!The function
dps_print_owneris well-implemented and serves its purpose of printing the owner information for debugging. It retrieves the owner information from various security structures and prints them using theDPS_DBGmacro. The function is appropriately wrapped in aDPS_DBG_IS_ENABLEDmacro to ensure it is only compiled when debugging is enabled and is marked withGCOVR_EXCL_STARTandGCOVR_EXCL_STOPcomments to exclude it from code coverage analysis..github/workflows/sonar-cloud-analysis.yml (4)
28-29: LGTM!The addition of a new build configuration that enables device provisioning and associated test properties aligns with the PR objective. This is a valid approach to incorporate device provisioning functionality into the build matrix.
90-93: LGTM!Introducing a dedicated job for device provisioning service tests is a good practice to ensure comprehensive testing coverage. Enabling coverage reporting for the job will provide valuable insights into the test coverage of the device provisioning service. This addition enhances the overall testing framework.
102-102: LGTM!Updating the
needsconfiguration of thesonar-cloud-scanjob to include theplgd-dps-testsjob is necessary to maintain the correct execution order. This ensures that the Sonar Cloud scan will run after the successful completion of the device provisioning tests, providing a more comprehensive analysis.
118-118: Verify the Sonar Scanner command change.Enabling additional features, including device provisioning, in the CMake command is consistent with the PR objective and ensures that the Sonar Cloud analysis covers the relevant code paths. This change is approved.
However, please verify that changing the Sonar Scanner command to use
sonar.cfamily.compile-commandsinstead ofsonar.cfamily.build-wrapper-outputproduces the expected results. This modification may impact how the analysis processes compilation commands.To verify the Sonar Scanner command change, you can run the following script:
Please review the analysis results and confirm that the command change does not introduce any unexpected behavior or errors.
Also applies to: 146-146
api/plgd/device-provisioning-client/plgd_dps_time.c (5)
48-52: LGTM!The function logic is correct, and the implementation is accurate.
62-71: LGTM!The function logic is correct, and the implementation is accurate.
73-97: Effective Time Synchronization HandlingThe function logic is correct. As mentioned in the past review comment, the function effectively handles fetching the current time from a trusted source.
174-230: Effective Time Synchronization HandlingThe function logic is correct. As mentioned in the past review comment, the function effectively handles fetching the current time from a trusted source. Consider enhancing error recovery strategies, such as adding more detailed error logs or retry mechanisms in case of time synchronization failures.
54-60: Address the past review comment about making the delta time configurable.The function logic is correct. However, the past review comment about making the hardcoded delta time in
g_dps_time_cfgconfigurable through external configuration files or environment variables is still valid.Do you want me to help implement this configuration feature or open a GitHub issue to track this enhancement?
api/plgd/unittest/plgd_dps_verify_certificate.cpp (6)
40-52: LGTM!The test case correctly checks the allocation and deallocation of
dps_verify_certificate_data_tstruct.
54-61: LGTM!The test case correctly checks the failure of
dps_verify_certificatefunction when an invalid device is provided.
63-75: LGTM!The test case correctly checks the failure of
dps_verify_certificatefunction when the peer context is missing.
77-93: LGTM!The test case correctly checks the failure of
dps_verify_certificatefunction when an invalid fingerprint is provided.
95-122: LGTM!The test fixture correctly sets up and tears down the test device server and provides a helper method to convert a string to an
oc_endpoint_tstruct.
124-208: LGTM!The test case correctly checks the
dps_verify_certificatefunction with a valid certificate. It sets up the necessary context and validates the intermediate and leaf certificates.api/plgd/device-provisioning-client/plgd_dps_context.c (20)
40-44: LGTM!The function logic is correct, and the implementation is accurate.
46-50: LGTM!The function logic is correct, and the implementation is accurate.
52-56: LGTM!The function logic is correct, and the implementation is accurate.
58-62: LGTM!The function logic is correct, and the implementation is accurate.
64-68: LGTM!The function logic is correct, and the implementation is accurate.
70-74: LGTM!The function logic is correct, and the implementation is accurate.
76-85: LGTM!The function logic is correct, and the implementation is accurate.
87-114: Address the past review comment.The function logic is correct. However, please address the past review comment:
Consider initializing all fields at the start of the function before performing any operations that could potentially fail.
Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
116-127: LGTM!The function logic is correct, and the implementation is accurate.
129-144: LGTM!The function logic is correct, and the implementation is accurate.
146-154: LGTM!The function logic is correct, and the implementation is accurate.
156-165: LGTM!The function logic is correct, and the implementation is accurate.
167-173: LGTM!The function logic is correct, and the implementation is accurate.
175-179: LGTM!The function logic is correct, and the implementation is accurate.
181-191: LGTM!The function logic is correct, and the implementation is accurate.
193-199: LGTM!The function logic is correct, and the implementation is accurate.
201-206: LGTM!The function logic is correct, and the implementation is accurate.
208-224: LGTM!The function logic is correct, and the implementation is accurate.
226-231: LGTM!The function logic is correct, and the implementation is accurate.
233-238: LGTM!The function logic is correct, and the implementation is accurate.
api/plgd/device-provisioning-client/plgd_dps_manager.c (17)
45-54: LGTM!The function correctly starts the DPS manager if it's not already started.
56-65: LGTM!The function correctly iterates over the credentials to find the manufacturer certificate.
67-78: LGTM!The function correctly checks if the device has a manufacturer certificate.
80-89: LGTM!The function correctly iterates over the credentials to find the manufacturer trusted root CA.
91-102: LGTM!The function correctly checks if the device has a manufacturer trusted root CA.
104-142: LGTM!The function correctly gets the provision and cloud observer flags based on the current state of the device.
Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
144-200: LGTM!The function correctly starts the DPS manager and performs the necessary checks and initializations.
202-207: LGTM!The function correctly checks if the DPS manager is started.
209-218: LGTM!The function correctly starts the DPS manager asynchronously.
220-225: LGTM!The function correctly restarts the DPS manager.
227-243: LGTM!The function correctly stops the DPS manager and removes all the delayed callbacks.
245-259: LGTM!The function correctly stops the DPS manager and deinitializes the session and interface callbacks.
261-275: LGTM!The function correctly forces reprovisioning and restarts the DPS manager.
277-283: LGTM!The function correctly forces reprovisioning and restarts the DPS manager asynchronously.
285-293: LGTM!The function correctly retries provisioning asynchronously.
295-349: LGTM!The function correctly provisions the device asynchronously and handles various scenarios such as:
- Checking if the device is already provisioned and starting the cloud observer if it is.
- Checking if the DPS is initialized and skipping provisioning if it's not.
- Checking if the endpoint is empty and stopping the DPS manager if it is.
- Initializing the endpoint and setting the device as self-owned.
- Starting provisioning and retrying on error.
104-104: Skip the static analysis hint.The static analysis hint about the unknown macro
dps_endpoint_add_peeris a false positive as the macro is not used in the provided code. The hint can be safely ignored.Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_store.c (13)
55-63: LGTM!The function logic is correct, and the implementation is accurate.
65-70: LGTM!The function logic is correct, and the implementation is accurate.
72-80: LGTM!The function logic is correct, and the implementation is accurate.
82-88: LGTM!The function logic is correct, and the implementation is accurate.
90-140: LGTM!The function logic is correct, and the implementation is accurate. The static analysis hint and past review comment about the unknown macro
dps_endpoint_add_peerare likely false positives, as there is no usage of this macro in the function.Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
142-215: LGTM!The function logic is correct, and the implementation is accurate.
217-224: LGTM!The function logic is correct, and the implementation is accurate.
226-232: LGTM!The function logic is correct, and the implementation is accurate.
234-245: LGTM!The function logic is correct, and the implementation is accurate.
247-253: LGTM!The function logic is correct, and the implementation is accurate.
255-276: LGTM!The function logic is correct, and the implementation is accurate.
311-318: LGTM!The function logic is correct, and the implementation is accurate.
363-370: LGTM!The function logic is correct, and the implementation is accurate.
api/plgd/unittest/plgd_dps_provision_cloud.cpp (10)
51-55: LGTM!The test case setup logic is correct, and the implementation is accurate.
57-63: LGTM!The test case teardown logic is correct, and the implementation is accurate.
65-69: LGTM!The test setup logic is correct, and the implementation is accurate.
71-77: LGTM!The test teardown logic is correct, and the implementation is accurate.
79-91: LGTM!The function logic to clear the cloud servers is correct, and the implementation is accurate.
93-105: LGTM!The function logic to encode the conf resource payload is correct, and the implementation is accurate.
108-147: LGTM!The test function logic is correct, and the implementation is accurate. The test covers the failure scenarios of the
dps_handle_set_cloud_responsefunction.
149-223: LGTM!The test function logic is correct, and the implementation is accurate. The test covers the success scenarios of the
dps_handle_set_cloud_responsefunction.
225-246: LGTM!The test function logic is correct, and the implementation is accurate. The test covers the scenarios of the
dps_has_cloud_configurationfunction.
248-298: LGTM!The test function logic is correct, and the implementation is accurate. The test covers the scenarios of the
dps_set_cloud_handlerfunction.api/plgd/device-provisioning-client/plgd_dps_pki.c (15)
50-57: LGTM!The function correctly initializes the PKI configuration with a default expiring limit.
59-103: LGTM!The function correctly generates and sends the CSR request to obtain new DPS certificates. It handles errors and manages the TLS context appropriately.
112-118: Skipped commenting.The past review comment suggesting adding a runtime check for the state index is still valid and applicable.
120-125: LGTM!The function correctly checks if a certificate is expiring based on the current time and the expiring limit.
127-150: LGTM!The function correctly validates a certificate based on its validity period and the current time. It returns the appropriate certificate state enum and handles the case when the current time cannot be obtained.
152-178: LGTM!The function correctly updates the
credentials_replacedflag and logs debug information about the applied credential. It serves its purpose as a callback function.
180-218: LGTM!The function correctly replaces the certificates by retrieving the credential resource, setting the stale tag, applying the credential update, removing stale credentials, and handling the case when credentials are replaced or removed. It follows the necessary steps to ensure a successful certificate replacement.
220-224: LGTM!The function correctly checks if certificates can be replaced based on the provisioning status using the
dps_is_provisioned_with_cloud_startedfunction.
226-246: LGTM!The function correctly schedules the renewal of certificates by calculating the renewal interval using the
dps_pki_calculate_renew_certificates_intervalfunction, ensuring that the interval is not less than the minimum allowed interval, and scheduling the renewal using thedps_reset_delayed_callback_msfunction. It follows the necessary steps to ensure timely renewal of certificates.
248-285: LGTM!The function correctly calculates the interval for renewing certificates based on the current time and the certificate's expiration time. It handles different scenarios based on the remaining time until expiration and returns the calculated interval in milliseconds. The logic for determining the renewal interval is sound and ensures timely renewal of certificates.
287-294: Skipped commenting.The past review comment approving the retry mechanism for replacing credentials is still valid and applicable.
296-345: Skipped commenting.The past review comment suggesting refactoring the
dps_pki_replace_credentials_handlerfunction to reduce complexity is still valid and applicable. Consider breaking down the function into smaller, more focused functions to improve readability and maintainability.
347-368: LGTM!The function correctly attempts to renew certificates by sending a CSR request using the
dps_pki_send_csrfunction. It schedules a retry in case the response is not retrieved and updates the provisioning status and last error accordingly. The function follows the necessary steps to ensure a smooth certificate renewal process.
370-376: LGTM!The function correctly serves as an asynchronous callback for retrying certificate renewal. It increments the retry count using the
dps_retry_incrementfunction and calls thedps_pki_renew_certificates_asyncfunction to initiate the renewal process. The implementation is straightforward and fulfills its intended purpose.
378-397: LGTM!The function correctly serves as an asynchronous callback for renewing certificates. It checks if certificates can be replaced using the
dps_pki_can_replace_certificatesfunction and attempts to renew them using thedps_pki_try_renew_certificatesfunction. If the renewal fails, it increments the retry count, reschedules the renewal using thedps_check_credentials_and_schedule_renewalfunction, or forces reprovisioning using thedps_manager_reprovision_and_restartfunction. The function follows the necessary steps to ensure a robust certificate renewal process.api/plgd/device-provisioning-client/plgd_dps_provision_cloud.c (9)
43-115: ** Review ofdps_register_cloud_fill_datafunction: Error handling and memory management.**The past review comment is still valid and applicable to the current code segment:
This function performs key extraction from a payload and assigns them to a
cloud_conf_tstructure. The error handling is robust, with checks for null pointers after each key extraction. However, consider the following improvements:
- Memory Management: The function assigns pointers to strings within the
oc_rep_tstructure directly to thecloud_conf_tstructure. Ensure that the lifetime of theoc_rep_tpayload outlasts thecloud_conf_tusage or consider copying the strings.- Error Logging: The error messages are helpful, but they could include more context about the payload to aid debugging.
- Return Early Pattern: The function uses multiple return points, which is generally fine, but consider using a single exit point for cleaner flow and easier maintenance.
Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
117-132: ** Review ofcloud_deregister_handler: Simplify error handling.**The past review comment is still valid and applicable to the current code segment:
The function
cloud_deregister_handlerlogs different messages based on the response code. Consider simplifying the error handling by using a switch-case or mapping response codes to messages to reduce redundancy and improve maintainability.
134-155: ** Potential issue with assert usage incloud_deregister.**The past review comment is still valid and applicable to the current code segment:
The function uses
assertto ensurecloud_epis not null. While this is acceptable for debug builds, in a production build where asserts might be disabled, this could lead to undefined behavior ifcloud_epis null. Consider adding runtime checks and proper error handling for production builds.
157-238: ** Complexity and error handling indps_handle_set_cloud_response.**The past review comment is still valid and applicable to the current code segment:
This function is quite complex, handling multiple scenarios for cloud configuration and response parsing. Consider breaking it down into smaller, more manageable functions. Additionally, ensure that all error paths properly clean up any allocated resources to prevent memory leaks.
Would you like me to help refactor this function into smaller parts?
240-251: ** Simplifydps_has_cloud_configurationby using helper functions.**The past review comment is still valid and applicable to the current code segment:
This function checks if the cloud configuration is set by verifying server URI and access token. Consider using helper functions to encapsulate these checks, improving readability and reusability.
253-315: ** Error handling and status management indps_set_cloud_handler.**The past review comment is still valid and applicable to the current code segment:
This handler function manages cloud setting responses and updates device status accordingly. The error handling is extensive, but the function could benefit from separating the status update logic into a separate function for clarity and reusability.
317-352: ** Review ofdps_provisioning_set_cloud_encode_selected_gateway: Ensure robust error handling.**The past review comment is still valid and applicable to the current code segment:
This function encodes the selected gateway for cloud provisioning. It uses asserts to ensure non-null pointers, which is risky in production. Consider adding runtime checks and returning meaningful error messages or codes if the assumptions are violated.
354-374: ** Potential improvements indps_provisioning_set_cloud_encode_payload.**The past review comment is still valid and applicable to the current code segment:
This function encodes the payload for cloud provisioning. It has robust error handling but could be simplified by abstracting some of the repetitive tasks into helper functions or macros, especially the UUID handling and string operations.
377-409: ** Improve error handling and replace assertions.**The past review comment is still valid and applicable to the current code segment:
The function
dps_provisioning_set_clouduses assertions to ensure the endpoint is not null and checks the device state. Consider replacing assertions with runtime checks to prevent potential issues in production environments where assertions may be disabled.Additionally, improve error handling by providing more specific error messages or codes when checks fail, to aid in debugging and maintenance.
api/plgd/device-provisioning-client/plgd_dps.c (16)
38-46: LGTM!The function logic is correct, and the implementation is accurate.
48-54: LGTM!The function logic is correct, and the implementation is accurate.
65-126: LGTM!The function logic is correct, and the implementation is accurate. It handles the DPS endpoint events correctly based on the event state and performs the appropriate actions.
Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
128-148: LGTM!The function logic is correct, and the implementation is accurate. It correctly handles the session events for the DPS endpoint and the cloud server endpoint.
150-158: LGTM!The function logic is correct, and the implementation is accurate. It correctly restarts the DPS manager if the DPS status is initialized.
160-166: LGTM!The function logic is correct, and the implementation is accurate. It correctly handles the network interface up event and restarts the DPS manager for each initialized DPS context.
170-187: LGTM!The function logic is correct, and the implementation is accurate. It correctly initializes the DPS contexts for each device and handles the error case when the DPS context allocation fails.
189-210: LGTM!The function logic is correct, and the implementation is accurate. It correctly shuts down the DPS contexts for each device and cleans up the associated resources.
214-218: LGTM!The function logic is correct, and the implementation is accurate. It correctly initializes the DPS session callbacks for a DPS context.
220-224: LGTM!The function logic is correct, and the implementation is accurate. It correctly deinitializes the DPS session callbacks for a DPS context.
226-230: LGTM!The function logic is correct, and the implementation is accurate. It correctly initializes the DPS interface callbacks.
232-236: LGTM!The function logic is correct, and the implementation is accurate. It correctly deinitializes the DPS interface callbacks.
240-259: LGTM!The function logic is correct, and the implementation is accurate. It correctly tries to set the identity certificate chain for a device based on the identity credential ID and the cloud context.
261-280: LGTM!The function logic is correct, and the implementation is accurate. It correctly starts the cloud manager for a DPS context using the provided callbacks.
282-315: LGTM!The function logic is correct, and the implementation is accurate. It correctly sets the certificate fingerprint for a DPS context after validating the message digest type and fingerprint size.
317-323: LGTM!The function logic is correct, and the implementation is accurate. It correctly sets the certificate fingerprint for a DPS context by calling the
dps_set_certificate_fingerprintfunction.api/plgd/unittest/plgd_dps_resource.cpp (8)
62-85: LGTM!The function correctly parses the DPS endpoints from the representation and handles parsing failures by returning an empty vector.
87-140: LGTM!The function correctly parses the individual DPS data properties from the representation based on their type and key. It returns false for unknown properties to allow further processing.
142-156: LGTM!The function correctly parses the DPS data from the representation by iterating over the properties and invoking
parseDPSDataPropertyfor each one.
158-238: LGTM!The test function thoroughly verifies the encoding of the DPS resource for the read interface. It covers different scenarios such as the presence/absence of status and multiple endpoints. The parsed values are correctly asserted against the expected values.
240-275: LGTM!The test function verifies the encoding of the DPS resource for the read-write interface. It correctly asserts that the last error code and provision status are not present in the encoded representation, while the endpoint and force reprovision flag are correctly encoded and parsed.
277-380: LGTM!The test function extensively verifies the conversion of DPS status flags to their string representations. It covers individual flags, combinations of flags, and the handling of unknown flags. The expected string values are correctly compared against the actual values returned by the
dps_status_to_strfunction.
408-441: LGTM!The
getRequestWithQueryfunction template sends a GET request to the DPS resource with an optional query parameter. It correctly handles the response, verifies the status code, and parses the DPS data from the payload. The function is flexible enough to accept a custom status code for testing error scenarios.
481-507: LGTM!The
postRequestfunction template sends a POST request to the DPS resource. It takes an encoding function as a parameter, allowing customization of the request payload. The function correctly sends the request, handles the response, and verifies the expected status code.api/plgd/device-provisioning-client/plgd_dps_provision.c (15)
43-63: LGTM!The function logic is correct, and the implementation is accurate. It checks the response from the DPS server using
dps_check_response, sets the error status based on the result, and returns the appropriate value.
65-99: LGTM!The debug function is correctly implemented and is excluded from the code coverage analysis using the appropriate comments. It prints the details of the ACL being applied, which can be helpful for debugging purposes.
139-204: LGTM!The function is correctly implemented and handles the response from the DPS server for the GET ACLs request. It checks the status of the DPS context, handles the response using
dps_provisioning_check_responseanddps_handle_get_acls_response, and schedules the next step in the provisioning process or handles the failure appropriately.
206-229: LGTM!The function is correctly implemented and sends a GET request to the DPS server to retrieve the ACLs. It checks if the device is in the RFNOP state, sets up the TLS connection, sends the request using
oc_do_get_with_timeout, and sets the appropriate status and error codes.
231-305: LGTM!The function is correctly implemented and handles the response from the DPS server for the GET credentials request. It checks the status of the DPS context, handles the response using
dps_provisioning_check_response, replaces the certificates usingdps_pki_replace_certificates, checks the credentials and schedules the renewal usingdps_check_credentials_and_schedule_renewal, sets the identity chain usingdps_try_set_identity_chain, and schedules the next step in the provisioning process or handles the failure appropriately.
307-334: LGTM!The function is correctly implemented and sends a POST request to the DPS server to retrieve the credentials. It checks if the device is in the RFNOP state, sends the CSR using
dps_pki_send_csr, and sets the appropriate status and error codes.
336-340: LGTM!The function is correctly implemented and schedules the next step in the provisioning process using
dps_reset_delayed_callbackwith thedps_provision_next_step_asynccallback.
342-350: LGTM!The function is correctly implemented and gets the DPS time using
dps_get_plgd_time. It returnstrueif successful andfalseotherwise.
352-360: LGTM!The function is correctly implemented and gets the DPS ownership using
dps_get_owner. It returnstrueif successful andfalseotherwise.
362-370: LGTM!The function is correctly implemented and gets the cloud configuration using
dps_provisioning_set_cloud. It returnstrueif successful andfalseotherwise.
372-380: LGTM!The function is correctly implemented and gets the DPS credentials using
dps_get_credentials. It returnstrueif successful andfalseotherwise.
382-390: LGTM!The function is correctly implemented and gets the DPS ACLs using
dps_get_acls. It returnstrueif successful andfalseotherwise.
398-417: LGTM!The function is correctly implemented and starts the cloud registration. It checks if the renewal of certificates is scheduled using
oc_has_delayed_callback, rechecks the credentials and reschedules the callback to replace expired certificates usingdps_check_credentials_and_schedule_renewalif not scheduled, and starts the cloud registration usingdps_provisioning_start_cloud. It returns the appropriate status code based on the result.
419-438: LGTM!The function is correctly implemented and returns the next action in the provisioning process based on the status of the DPS context. It checks the status flags in the correct order and returns the appropriate action.
440-509: LGTM!The function is correctly implemented and is the async callback for the next step in the provisioning process. It checks the status of the DPS context and calls the appropriate functions to get the time, owner, cloud configuration, credentials, and ACLs. It also starts the cloud registration if the device is provisioned and not already started. It sets the appropriate status and error codes and schedules the retry if necessary.
CMakeLists.txt (12)
80-84: LGTM!The code changes are consistent with the AI-generated summary. The
PLGD_DEV_TIME_ENABLED,PLGD_DEV_DEVICE_PROVISIONING_ENABLED, andPLGD_DEV_DEVICE_PROVISIONING_TEST_PROPERTIES_ENABLEDoptions are being explicitly set and managed within the CMake configuration.
175-175: LGTM!The code change is consistent with the AI-generated summary. The inclusion of
tools/utils.cmakesuggests a shift towards a more modular approach for handling utility functions.
239-239: LGTM!The code change is consistent with the AI-generated summary. The new function call
oc_set_maximum_log_levelis replacing the previous conditional logic for setting the maximum log level, which enhances readability and maintainability of the CMake file.
242-245: LGTM!The code changes are wrapping the maximum log level in parentheses to avoid triggering bugprone-macro-parentheses warning from clang-tidy. This is a minor change and looks good to me.
407-412: LGTM!The code changes are consistent with the AI-generated summary. The compile definitions for
PLGD_DEV_TIMEare being added based on the value ofPLGD_DEV_TIME_ENABLEDoption.
414-434: LGTM!The code changes are consistent with the AI-generated summary. The compile definitions for
PLGD_DEV_DEVICE_PROVISIONINGare being added based on the value ofPLGD_DEV_DEVICE_PROVISIONING_ENABLEDoption. The code is also checking for the required dependencies such asOC_CLOUD_ENABLED,OC_SECURITY_ENABLED, andPLGD_DEV_TIME_ENABLED. The maximum log level for Plgd DPS is being set using theoc_set_maximum_log_levelfunction. This introduces a more robust control flow that prevents misconfigurations that could arise from incompatible feature combinations.
436-441: LGTM!The code changes are adding compile definitions for
PLGD_DPS_RESOURCE_TEST_PROPERTIESbased on the value ofPLGD_DEV_DEVICE_PROVISIONING_TEST_PROPERTIES_ENABLEDoption. This seems to be a new feature related to device provisioning test properties. The changes are consistent with the overall theme of the PR.
684-690: LGTM!The code changes are consistent with the AI-generated summary. The
PLGD_DPS_SRCfiles are being added to theclient-server-objlibrary based on the value ofPLGD_DEV_DEVICE_PROVISIONING_ENABLEDoption. This is required to include the device provisioning client functionality in the library.
1112-1121: LGTM!The code changes are adding a new unit test target
plgdtestbased on the value ofPLGD_DEV_TIME_ENABLEDorPLGD_DEV_DEVICE_PROVISIONING_ENABLEDoptions. This is required to test the functionality related to plgd.dev features. The changes are consistent with the overall theme of the PR.
1315-1319: LGTM!The code changes are installing the
plgd_time.hheader file based on the value ofPLGD_DEV_TIME_ENABLEDoption. This is required to expose the plgd.dev time functionality to the users of the library. The changes are consistent with the overall theme of the PR.
1321-1325: LGTM!The code changes are installing the
plgd_dps.hheader file based on the value ofPLGD_DEV_DEVICE_PROVISIONING_ENABLEDoption. This is required to expose the plgd.dev device provisioning functionality to the users of the library. The changes are consistent with the overall theme of the PR.
81-81: The existing comment from the previous review is still valid and applicable to the current code segment. It mentions that the option has been moved within the file and is now set toOFFby default. The removal ofFORCEfrom the cache option might affect how this variable is overridden in different contexts, which could lead to unexpected behaviors if not handled properly.
SiMet
added
OCF Conformance Testing
Danielius1922
added
OCF Conformance Testing
SiMet
added
OCF Conformance Testing
Danielius1922
force-pushed
the
adam/feature/dps
branch
from
0c2c0f3
to
1f59b01
Compare
ocf-conformance-test-tool
bot
removed
the
OCF Conformance Testing
There was a problem hiding this comment.
Actionable comments posted: 1
Outside diff range and nitpick comments (2)
api/plgd/device-provisioning-client/plgd_dps_endpoints.c (2)
36-63: LGTM!The function correctly handles setting a new endpoint and notifying observers of the change. The logic is sound and follows good practices such as disconnecting the current endpoint before setting a new one.
Consider providing more specific error messages to aid in debugging. For example, instead of a generic "failed to set endpoint" message, include the specific reason for the failure.
65-82: LGTM!The function correctly handles setting multiple endpoints and detects changes to the selected endpoint. The logic is sound and follows good practices such as triggering a disconnect when the selected endpoint changes.
Consider providing more specific error messages to aid in debugging. For example, instead of a generic "failed to set endpoints" message, include the specific reason for the failure.
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files ignored due to path filters (1)
tools/doxygen.iniis excluded by!**/*.ini
Files selected for processing (82)
- .dockerignore (1 hunks)
- .github/workflows/cmake-linux.yml (2 hunks)
- .github/workflows/docker-build-publish-with-cfg.yml (1 hunks)
- .github/workflows/docker-build-publish.yml (1 hunks)
- .github/workflows/ghcr-check.yml (1 hunks)
- .github/workflows/plgd-device-test-with-cfg.yml (1 hunks)
- .github/workflows/plgd-dps-test-with-cfg.yml (1 hunks)
- .github/workflows/plgd-dps-tests.yml (1 hunks)
- .github/workflows/plgd-hub-test-with-cfg.yml (1 hunks)
- .github/workflows/sonar-cloud-analysis.yml (4 hunks)
- .github/workflows/static-analysis.yml (2 hunks)
- .github/workflows/unit-test-with-cfg.yml (1 hunks)
- CMakeLists.txt (7 hunks)
- api/oc_endpoint.c (1 hunks)
- api/oc_log.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_apis.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_apis_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_cloud.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_cloud_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_context.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_context_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_dhcp.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_dhcp_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_endpoint.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_endpoint_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_endpoints.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_endpoints_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_log.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_log_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_manager.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_manager_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_pki.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_pki_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision_cloud.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision_cloud_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision_owner.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision_owner_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_resource.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_resource_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_retry.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_retry_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_security.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_security_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_store.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_store_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_tag.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_tag_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_time.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_time_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_verify_certificate.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_verify_certificate_internal.h (1 hunks)
- api/plgd/unittest/plgd_dps.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_apis.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_cloud.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_context.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_dhcp.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_endpoint.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_endpoints.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_log.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_manager.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_pki.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_provision.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_provision_cloud.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_provision_owner.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_resource.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_retry.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_security.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_store.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_tag.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_test.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_test.h (1 hunks)
- api/plgd/unittest/plgd_dps_time.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_verify_certificate.cpp (1 hunks)
- apps/CMakeLists.txt (1 hunks)
- apps/dps_cloud_server.c (1 hunks)
- docker/apps/Dockerfile.cloud-server (2 hunks)
- docker/apps/Dockerfile.dps-cloud-server (1 hunks)
- docker/apps/Dockerfile.dps-cloud-server-debug (1 hunks)
Files not processed due to max files limit (9)
- include/oc_log.h
- include/plgd/plgd_dps.h
- messaging/coap/observe.c
- security/oc_pstat.c
- security/oc_tls.c
- sonar-project.properties
- tools/utils.cmake
- util/oc_features.h
- util/oc_memb.h
Files skipped from review due to trivial changes (9)
- .github/workflows/plgd-device-test-with-cfg.yml
- .github/workflows/plgd-hub-test-with-cfg.yml
- .github/workflows/unit-test-with-cfg.yml
- api/plgd/device-provisioning-client/plgd_dps_cloud_internal.h
- api/plgd/device-provisioning-client/plgd_dps_dhcp_internal.h
- api/plgd/device-provisioning-client/plgd_dps_retry_internal.h
- api/plgd/device-provisioning-client/plgd_dps_security_internal.h
- api/plgd/unittest/plgd_dps.cpp
- api/plgd/unittest/plgd_dps_apis.cpp
Files skipped from review as they are similar to previous changes (52)
- .dockerignore
- .github/workflows/cmake-linux.yml
- .github/workflows/docker-build-publish-with-cfg.yml
- .github/workflows/docker-build-publish.yml
- .github/workflows/ghcr-check.yml
- .github/workflows/plgd-dps-tests.yml
- .github/workflows/sonar-cloud-analysis.yml
- .github/workflows/static-analysis.yml
- api/oc_endpoint.c
- api/oc_log.c
- api/plgd/device-provisioning-client/plgd_dps_apis_internal.h
- api/plgd/device-provisioning-client/plgd_dps_cloud.c
- api/plgd/device-provisioning-client/plgd_dps_dhcp.c
- api/plgd/device-provisioning-client/plgd_dps_endpoint_internal.h
- api/plgd/device-provisioning-client/plgd_dps_endpoints_internal.h
- api/plgd/device-provisioning-client/plgd_dps_internal.h
- api/plgd/device-provisioning-client/plgd_dps_log.c
- api/plgd/device-provisioning-client/plgd_dps_log_internal.h
- api/plgd/device-provisioning-client/plgd_dps_manager_internal.h
- api/plgd/device-provisioning-client/plgd_dps_pki_internal.h
- api/plgd/device-provisioning-client/plgd_dps_provision_cloud_internal.h
- api/plgd/device-provisioning-client/plgd_dps_provision_internal.h
- api/plgd/device-provisioning-client/plgd_dps_provision_owner_internal.h
- api/plgd/device-provisioning-client/plgd_dps_resource.c
- api/plgd/device-provisioning-client/plgd_dps_resource_internal.h
- api/plgd/device-provisioning-client/plgd_dps_retry.c
- api/plgd/device-provisioning-client/plgd_dps_store_internal.h
- api/plgd/device-provisioning-client/plgd_dps_tag.c
- api/plgd/device-provisioning-client/plgd_dps_tag_internal.h
- api/plgd/device-provisioning-client/plgd_dps_time_internal.h
- api/plgd/device-provisioning-client/plgd_dps_verify_certificate.c
- api/plgd/device-provisioning-client/plgd_dps_verify_certificate_internal.h
- api/plgd/unittest/plgd_dps_cloud.cpp
- api/plgd/unittest/plgd_dps_context.cpp
- api/plgd/unittest/plgd_dps_dhcp.cpp
- api/plgd/unittest/plgd_dps_endpoint.cpp
- api/plgd/unittest/plgd_dps_endpoints.cpp
- api/plgd/unittest/plgd_dps_manager.cpp
- api/plgd/unittest/plgd_dps_provision.cpp
- api/plgd/unittest/plgd_dps_provision_owner.cpp
- api/plgd/unittest/plgd_dps_retry.cpp
- api/plgd/unittest/plgd_dps_security.cpp
- api/plgd/unittest/plgd_dps_store.cpp
- api/plgd/unittest/plgd_dps_test.cpp
- api/plgd/unittest/plgd_dps_test.h
- api/plgd/unittest/plgd_dps_time.cpp
- api/plgd/unittest/plgd_dps_verify_certificate.cpp
- apps/CMakeLists.txt
- apps/dps_cloud_server.c
- docker/apps/Dockerfile.cloud-server
- docker/apps/Dockerfile.dps-cloud-server
- docker/apps/Dockerfile.dps-cloud-server-debug
Additional context used
cppcheck
api/plgd/device-provisioning-client/plgd_dps_endpoints.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_endpoint.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_apis.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_provision_owner.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_time.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_context.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_manager.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_store.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_pki.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_provision_cloud.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_provision.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
actionlint
.github/workflows/plgd-dps-test-with-cfg.yml
122-122: shellcheck reported issue in this script: SC2046:warning:1:62: Quote this to prevent word splitting
(shellcheck)
134-134: shellcheck reported issue in this script: SC2129:style:2:1: Consider using { cmd1; cmd2; } >> file instead of individual redirects
(shellcheck)
134-134: shellcheck reported issue in this script: SC2086:info:2:53: Double quote to prevent globbing and word splitting
(shellcheck)
134-134: shellcheck reported issue in this script: SC2086:info:3:61: Double quote to prevent globbing and word splitting
(shellcheck)
134-134: shellcheck reported issue in this script: SC2086:info:4:48: Double quote to prevent globbing and word splitting
(shellcheck)
Additional comments not posted (180)
api/plgd/unittest/plgd_dps_log.cpp (6)
30-37: LGTM!The
TestDPSLogclass is a well-designed test fixture that properly manages the logging state before and after each test. TheTearDownmethod ensures isolation between tests by resetting the logging function and log level.
39-52: LGTM!The
LogToStdouttest function thoroughly verifies that messages are correctly logged at different levels. It also tests the behavior when setting the log level toOC_LOG_LEVEL_TRACE.
54-67: LGTM!The
printLogfunction correctly formats and prints the log message to stdout. The use ofOC_PRINTF_FORMATattribute ensures that the format string is checked for consistency with the arguments.
69-84: LGTM!The
expectUpToNoticefunction correctly verifies that the log level is up toOC_LOG_LEVEL_NOTICEand prints the log message using theprintLogfunction. The use ofOC_PRINTF_FORMATattribute ensures that the format string is checked for consistency with the arguments.
86-97: LGTM!The
LogToFunctiontest function thoroughly verifies that logs can be directed to a custom logging function. It sets the log function toexpectUpToNoticeand checks that only logs up to the notice level are printed.
105-116: LGTM!The
SkipLogByComponenttest function correctly verifies that when no components are set, no logs are produced. It sets the log function toexpectNoLogand checks that no logs are generated when logging messages at various levels.api/plgd/unittest/plgd_dps_tag.cpp (5)
35-64: LGTM!The
TestDPSTagclass follows the Google Test framework conventions and provides the necessary setup and teardown methods for testing device provisioning functionalities. TheAppInitmethod initializes the OCF platform and adds a mock device, ensuring a valid context for the tests.
68-87: LGTM!The
TagCredentialstest case is well-structured and covers the essential scenarios for credential tagging. It verifies the correct behavior of thedps_credentials_set_stale_taganddps_credentials_remove_stale_tagfunctions by checking the tag values on the added identity certificate.
91-110: LGTM!The
TagNoCredentialstest case covers the scenario where no credentials are present and ensures that the tagging functions behave correctly. It verifies that the tag values remain null even after calling thedps_credentials_set_stale_tagfunction.
112-130: LGTM!The
TagACLstest case covers the essential scenarios for ACL tagging and ensures the correct behavior of thedps_acls_set_stale_taganddps_acls_remove_stale_tagfunctions. It verifies the tag values on the ACE after adding a bootstrap ACL and calling the tagging functions.
132-151: LGTM!The
TagNoACLstest case covers the scenario where no ACLs are present and ensures that the tagging functions behave correctly. It verifies that the tag values remain null even after calling thedps_acls_set_stale_tagfunction.api/plgd/unittest/plgd_dps_pki.cpp (2)
42-94: LGTM!The
TestPKIclass is a well-structured test fixture that correctly initializes and shuts down the runtime environment. The test cases are testing the behavior of the PKI functions with invalid inputs and calculating the renew certificates interval. The test cases are using the Google Test framework correctly.
96-165: LGTM!The
TestPKIWithDeviceclass is a well-structured test fixture that correctly starts and stops the test device server. The test cases are testing the behavior of the PKI functions with a test device. The test cases are using the Google Test framework correctly.api/plgd/device-provisioning-client/plgd_dps_endpoints.c (9)
84-90: LGTM!The function is a simple wrapper around
dps_set_endpointthat automatically notifies observers. The logic is correct and the assertion ensures that the endpoint string doesn't exceed the maximum allowed length.
92-113: LGTM!The function correctly retrieves the selected endpoint and copies it into the provided buffer. It includes appropriate checks to ensure that an endpoint is selected and that the buffer is large enough to hold the endpoint string.
Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
115-120: LGTM!The function is a simple wrapper around
oc_endpoint_addresses_selectedthat provides a convenient way to check if an endpoint is selected. The logic is correct and straightforward.
122-132: LGTM!The function correctly initializes the endpoint addresses using the
oc_endpoint_addresses_initfunction. It uses the appropriate memory pool and sets a reasonable default for the initial endpoint address.
134-142: LGTM!The function correctly adds an endpoint address to the context using the
oc_endpoint_addresses_addfunction. It creates anoc_endpoint_address_tobject with the provided URI and name, and the logic is straightforward.
144-149: LGTM!The function is a simple wrapper around
oc_endpoint_addresses_removethat removes an endpoint address from the context. The logic is correct and straightforward.
151-158: LGTM!The function correctly iterates over the stored endpoint addresses using the
oc_endpoint_addresses_iteratefunction. It takes a callback function and a data pointer as arguments, providing flexibility to the caller.
160-165: LGTM!The function is a simple wrapper around
oc_endpoint_addresses_selectthat selects an endpoint address in the context. The logic is correct and straightforward.
167-171: LGTM!The function is a simple wrapper around
oc_endpoint_addresses_selectedthat provides a convenient way to retrieve the currently selected endpoint address. The logic is correct and straightforward.api/plgd/device-provisioning-client/plgd_dps_context_internal.h (13)
39-45: LGTM!The
plgd_dps_store_tstruct declaration looks good. The fields are appropriate for maintaining OCF endpoints and provisioning status.
47-52: LGTM!The
plgd_dps_certificate_fingerprint_tstruct declaration looks good. The fields are appropriate for storing the fingerprint of the DPS server certificate and the hash algorithm used.
54-88: LGTM!The
plgd_dps_context_tstruct declaration looks good. It encapsulates all the necessary information for managing a provisioning context, including callbacks, endpoint states, retry configurations, and more. The fields are well-defined and serve their intended purposes.
91-91: LGTM!The
dps_context_allocfunction declaration looks good. It takes no parameters and returns a pointer toplgd_dps_context_t, which is appropriate for allocating a provisioning context.
94-94: LGTM!The
dps_context_freefunction declaration looks good. It takes a pointer toplgd_dps_context_tas a parameter and returns void, which is appropriate for deallocating a provisioning context. TheOC_NONNULLannotation ensures that the parameter cannot be NULL.
97-97: LGTM!The
dps_context_list_addfunction declaration looks good. It takes a pointer toplgd_dps_context_tas a parameter and returns void, which is appropriate for adding a provisioning context to the global list. TheOC_NONNULLannotation ensures that the parameter cannot be NULL.
100-100: LGTM!The
dps_context_list_removefunction declaration looks good. It takes a const pointer toplgd_dps_context_tas a parameter and returns void, which is appropriate for removing a provisioning context from the global list. TheOC_NONNULLannotation ensures that the parameter cannot be NULL.
103-103: LGTM!The
dps_context_list_is_emptyfunction declaration looks good. It takes no parameters and returns a boolean value, which is appropriate for checking if the global list of contexts is empty.
113-114: LGTM!The
dps_contexts_iterate_fn_ttypedef looks good. It defines a function pointer that takes a pointer toplgd_dps_context_tand avoidpointer as parameters and returns a boolean value, which is appropriate for a callback function used for iterating over provisioning contexts. TheOC_NONNULLannotation ensures that the first parameter cannot be NULL.
117-118: LGTM!The
dps_contexts_iteratefunction declaration looks good. It takes adps_contexts_iterate_fn_tfunction pointer and avoidpointer as parameters and returns void, which is appropriate for iterating over the list of provisioning contexts. TheOC_NONNULLannotation ensures that the first parameter cannot be NULL.
121-121: LGTM!The
dps_context_initfunction declaration looks good. It takes a pointer toplgd_dps_context_tand asize_tas parameters and returns void, which is appropriate for initializing a provisioning context. TheOC_NONNULLannotation ensures that the parameters cannot be NULL.
124-124: LGTM!The
dps_context_deinitfunction declaration looks good. It takes a pointer toplgd_dps_context_tas a parameter and returns void, which is appropriate for deinitializing a provisioning context. TheOC_NONNULLannotation ensures that the parameter cannot be NULL.
127-127: LGTM!The
dps_context_resetfunction declaration looks good. It takes a pointer toplgd_dps_context_tas a parameter and returns void, which is appropriate for clearing a provisioning context. TheOC_NONNULLapi/plgd/device-provisioning-client/plgd_dps_endpoint.c (8)
36-51: LGTM!The function correctly initializes the endpoint context by converting the string representation to the endpoint structure and manages the DNS cache. The error handling and return status code are appropriate.
55-77: LGTM!The debug function correctly prints the list of peers for an endpoint. The use of the
DPS_DBG_IS_ENABLEDmacro ensures that the function is only compiled in debug builds, and theGCOVR_EXCL_STARTandGCOVR_EXCL_STOPcomments appropriately exclude the code from coverage analysis.
80-123: LGTM!The function correctly adds a new peer to the TLS context by selecting the appropriate ciphersuite and identity certificate chain, and using a verification process for the peer's certificate. The error handling and return value are appropriate.
Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
125-133: LGTM!The function safely closes an endpoint session by first checking if the endpoint is not NULL and not empty, and then closing the session using the
oc_close_sessionfunction. The debug message is appropriate.
135-145: LGTM!The function correctly handles the disconnection process by closing the endpoint using the
dps_endpoint_closefunction, clearing the endpoint structure, and setting the endpoint state toOC_SESSION_DISCONNECTED. The debug message is appropriate.
147-152: LGTM!The function correctly checks if an endpoint is uninitialized by calling the
oc_endpoint_is_emptyfunction with the provided endpoint. The assertion ensures that the provided endpoint is not NULL.
154-185: LGTM!The function correctly formats the endpoint information into a string for logging purposes. It handles the conversion of the endpoint to a string, checks if the resulting string fits in the provided buffer, and includes the session ID in the formatted string if debug is enabled. The error handling and return values are appropriate.
187-198: LGTM!The function correctly sets up TLS for communication if a peer doesn't already exist. It checks if a peer already exists using the
oc_tls_get_peerfunction, and if not, it adds a new peer using thedps_endpoint_add_peerfunction. The error handling and debug messages are appropriate..github/workflows/plgd-dps-test-with-cfg.yml (6)
103-103: ****The following comment from the previous review is still valid and applicable:
Quote
$(hostname)in the container name to prevent word splitting issues.The step uses
$(hostname)in the container name without quoting, which may cause word splitting issues as indicated by the static analysis hint.Apply this diff to fix the issue:
- dps-devsim-$(hostname) + dps-devsim-"$(hostname)"Please address this issue.
119-119: ****The following comment from the previous review is still valid and applicable:
Quote
$(hostname)in the container name to prevent word splitting issues.The step uses
$(hostname)in the container name without quoting, which may cause word splitting issues as indicated by the static analysis hint.Apply this diff to fix the issue:
- dps-devsim-obt-$(hostname) "" + dps-devsim-obt-"$(hostname)" ""Please address this issue.
131-138: ****The following comment from the previous review is still valid and applicable:
Use
{ cmd1; cmd2; } >> fileinstead of individual redirects and quote variables to prevent word splitting issues.The step uses multiple redirects to append to the
$GITHUB_OUTPUTfile, which can be simplified as indicated by the static analysis hint. Additionally, it uses unquoted variables in theechocommands, which may cause word splitting issues as indicated by the static analysis hint.Apply this diff to fix the issues:
- echo "filename=coverage-plgd-dps-${SUFFIX}.json" >> $GITHUB_OUTPUT - echo "filename_obt=coverage-plgd-dps-obt-${SUFFIX}.json" >> $GITHUB_OUTPUT - echo "artifact=plgd-dps-${SUFFIX}-coverage" >> $GITHUB_OUTPUT + { + echo "filename=coverage-plgd-dps-${SUFFIX}.json" + echo "filename_obt=coverage-plgd-dps-obt-${SUFFIX}.json" + echo "artifact=plgd-dps-${SUFFIX}-coverage" + } >> "$GITHUB_OUTPUT"Please address these issues.
Tools
actionlint
134-134: shellcheck reported issue in this script: SC2129:style:2:1: Consider using { cmd1; cmd2; } >> file instead of individual redirects
(shellcheck)
134-134: shellcheck reported issue in this script: SC2086:info:2:53: Double quote to prevent globbing and word splitting
(shellcheck)
134-134: shellcheck reported issue in this script: SC2086:info:3:61: Double quote to prevent globbing and word splitting
(shellcheck)
134-134: shellcheck reported issue in this script: SC2086:info:4:48: Double quote to prevent globbing and word splitting
(shellcheck)
140-155: LGTM!The step for gathering coverage data looks good. It correctly stops and restarts the containers, executes the coverage collection script, and stores the data in the mounted volume.
157-164: LGTM!The step for uploading coverage data looks good. It correctly uses the
actions/upload-artifactaction to upload the coverage JSON files as an artifact.
166-176: LGTM!The steps for collecting logs from the DPS cloud server containers when the test fails look good. They correctly stop the containers and output their logs for debugging purposes.
api/plgd/device-provisioning-client/plgd_dps_apis.c (12)
35-43: LGTM!The function correctly compares two strings by length and content, while handling null strings appropriately.
45-51: LGTM!The function correctly compares two
oc_string_tstrings by size and content.
53-61: LGTM!The function correctly verifies if a representation matches a specified property type and name.
63-73: LGTM!The function correctly calculates the maximum time value based on the size of the clock type.
75-90: LGTM!The function correctly schedules a callback with a specified delay in milliseconds, while handling the case where the delay exceeds the maximum allowable time.
92-99: LGTM!The function correctly schedules a callback with a specified delay in seconds by converting the delay to milliseconds and calling
dps_reset_delayed_callback_ms.
101-105: LGTM!The function correctly checks if a status code represents a timeout error.
Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
107-112: LGTM!The function correctly checks if a status code represents a connection error.
114-118: LGTM!The function correctly checks if a status code represents an error.
120-130: LGTM!The function correctly translates a status code into a specific DPS error code by checking for timeout, connection, and general errors.
132-182: LGTM!The function correctly processes a redirect response by retrieving the redirect URI, updating the list of endpoints, selecting the new server, and disconnecting the endpoint.
184-201: LGTM!The function correctly orchestrates the response checking process by translating the status code, handling null payloads, and processing redirect responses.
api/plgd/device-provisioning-client/plgd_dps_provision_owner.c (2)
43-73: LGTM!The function
dps_handle_get_owner_responseis well-implemented with robust checks and detailed error logging. The logic for extracting the owner UUID from the response payload and updating the device's context is correct.
183-209: LGTM!The function
dps_print_owneris a useful debugging utility that provides insights into the device's ownership status. It is well-structured and retrieves the relevant information from the device's security resources (DOXM, PSTAT, CREDS, ACL) to print the associated UUIDs.api/plgd/device-provisioning-client/plgd_dps_time.c (6)
48-52: LGTM!The function logic is correct, and the implementation is accurate.
62-71: LGTM!The function logic is correct, and the implementation is accurate. It effectively handles the selection between system time and PLGD time based on synchronization.
73-97: LGTM!The function logic is correct, and the implementation is accurate. It effectively sets the system time and handles logging based on the debug and info logging configurations.
99-172: Skipping comment generation.The past review comment on lines 174-230 about effective time synchronization handling is still valid and applicable to the current implementation.
Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
174-230: Skipping comment generation.The past review comment on lines 36-46 about making the delta time configurable is still valid and applicable to the current implementation.
54-60: LGTM!The function logic is correct, and the implementation is accurate. It effectively checks if the system time is synchronized with the PLGD time based on the configured delta.
api/plgd/device-provisioning-client/plgd_dps_context.c (13)
46-50: LGTM!The function correctly allocates memory for a
plgd_dps_context_tstructure using theoc_memb_allocfunction and theg_dps_context_poolmemory pool.
52-56: LGTM!The function correctly frees memory allocated for a
plgd_dps_context_tstructure using theoc_memb_freefunction and theg_dps_context_poolmemory pool.
58-62: LGTM!The function correctly adds a
plgd_dps_context_tstructure to theg_dps_context_listlinked list using theoc_list_addfunction.
64-68: LGTM!The function correctly removes a
plgd_dps_context_tstructure from theg_dps_context_listlinked list using theoc_list_removefunction.
70-74: LGTM!The function correctly checks if the
g_dps_context_listlinked list is empty by comparing the length of the list to 0 using theoc_list_lengthfunction.
76-85: LGTM!The function correctly iterates over the
g_dps_context_listlinked list and calls the provided callback function for each context. The iteration stops if the callback function returns false.
87-114: LGTM!The function correctly initializes all fields of the
plgd_dps_context_tstructure to default values and calls the necessary initialization functions for sub-structures.Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
116-127: LGTM!The function correctly deinitializes various fields of the
plgd_dps_context_tstructure by removing callbacks, freeing memory, and setting pointers to NULL. It also calls the necessary deinitialization functions for sub-structures.
129-144: LGTM!The function correctly resets various fields of the
plgd_dps_context_tstructure to their default values. It deinitializes sub-structures, disconnects the endpoint, stops the manager, and reinitializes the store. The function also resets the last error, status, transient retry count, and certificate fingerprint fields to their default values and dumps the store asynchronously.
146-154: LGTM!The function correctly retrieves a
plgd_dps_context_tstructure from theg_dps_context_listlinked list based on the provided device ID. It iterates over the linked list and returns the context if a match is found, otherwise it returns NULL.
156-165: LGTM!The function correctly performs a factory reset on a
plgd_dps_context_tstructure. It asserts that the context pointer is not NULL, callsoc_cloud_set_retry_timeoutswith NULL and 0 ifPLGD_DPS_RESOURCE_TEST_PROPERTIESis defined, and callsdps_context_resetto reset the context to its default values. The function returns 0 to indicate success.
167-173: LGTM!The function correctly sets the
skip_verifyfield of aplgd_dps_context_tstructure. It asserts that the context pointer is not NULL, logs a debug message with the new value ofskip_verify, and sets theskip_verifyfield of the context to the provided value.
175-179: LGTM!The function correctly returns the value of the
skip_verifyfield of aplgd_dps_context_tstructure.api/plgd/device-provisioning-client/plgd_dps_manager.c (9)
45-54: LGTM!The function correctly initializes the DPS manager if it hasn't been started yet, sets up necessary callbacks, and signals the event loop.
56-65: LGTM!The function correctly iterates over credentials to find the manufacturer certificate and stops the iteration when found.
67-78: LGTM!The function correctly checks if the device has a manufacturer certificate by iterating over the credentials and returns the appropriate boolean value.
80-89: LGTM!The function correctly iterates over credentials to find the manufacturer trusted root CA and stops the iteration when found.
91-102: LGTM!The function correctly checks if the device has a manufacturer trusted root CA by iterating over the credentials and returns the appropriate boolean value.
104-142: LGTM!The function correctly determines the provision and cloud observer flags based on the current state of the DPS context by checking various conditions and updating the flags accordingly.
Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
144-200: LGTM!The function correctly starts the DPS manager by performing the necessary checks, updating the status and flags, resetting the retry, starting the DPS store dump, and initializing session and interface callbacks.
202-207: LGTM!The function correctly checks if the DPS manager is started by returning the value of the
manager_startedflag from the context.
209-218: LGTM!The function correctly starts the DPS manager asynchronously by freeing the existing endpoint, creating a new endpoint, and starting the DPS manager.
api/plgd/device-provisioning-client/plgd_dps_store.c (10)
56-63: LGTM!The function logic is correct, and the implementation is accurate.
65-70: LGTM!The function logic is correct, and the implementation is accurate.
72-80: LGTM!The function logic is correct, and the implementation is accurate.
82-88: LGTM!The function logic is correct, and the implementation is accurate.
90-140: LGTM!The function logic is correct, and the implementation is accurate.
Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
103-104: False positive from static analysis.The static analysis tool has flagged an unknown macro
dps_endpoint_add_peerat this line. However, there is no usage of this macro in thedps_store_set_endpointsfunction. This appears to be a false positive and can be ignored.Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
142-215: LGTM!The function logic is correct, and the implementation is accurate.
278-309: LGTM, but please address the missing tests.The function logic is correct, and the implementation is accurate. However, I wanted to remind you about the missing tests for this function as indicated by the past review comment.
Do you want me to generate the unit testing code or open a GitHub issue to track this task?
311-318: LGTM!The function logic is correct, and the implementation is accurate.
363-370: LGTM!The function logic is correct, and the implementation is accurate.
api/plgd/unittest/plgd_dps_provision_cloud.cpp (15)
1-17: License header looks good!It's a good practice to include the Apache 2.0 license header in the source files.
19-34: Header file includes look good!The included header files are relevant and in a logical order.
35-39: Google Test header includes look good!The Google Test framework is being used for writing unit tests, and the necessary headers are included.
41-45: Standard library header includes look good!The included standard library headers are commonly used and necessary for the code.
47-47: Constant definition looks good!Using a constant for the device ID is a good practice to avoid magic numbers and improve code readability.
49-106: Test fixture class looks good!The
DPSProvisionCloudWithServerTestclass provides the necessary setup and teardown methods for running the test cases. The utility methods encapsulate common functionality used across multiple test cases, which promotes code reuse and maintainability.
108-147: Test case looks good!The
HandleSetCloudResponseFailtest case thoroughly covers the failure scenarios of thedps_handle_set_cloud_responsefunction. It uses the Google Test assertions to verify the expected behavior and follows the AAA pattern, making it easy to understand and maintain.
149-223: Test case looks good!The
HandleSetCloudResponsetest case thoroughly covers the success scenarios of thedps_handle_set_cloud_responsefunction. It uses the Google Test assertions to verify the expected behavior and follows the AAA pattern, making it easy to understand and maintain.
225-246: Test case looks good!The
HasCloudConfigurationtest case thoroughly tests thedps_has_cloud_configurationfunction. It covers various scenarios and uses the Google Test assertions to verify the expected behavior. The test case follows the AAA pattern, making it easy to understand and maintain.
248-298: Test case looks good!The
SetCloudHandlertest case thoroughly tests thedps_set_cloud_handlerfunction. It covers various scenarios and uses the Google Test assertions to verify the expected behavior. The test case follows the AAA pattern, making it easy to understand and maintain.
300-310: Test case looks good!The
SetCloudEncodeSelectedGatewayFailtest case thoroughly tests the failure scenarios of thedps_provisioning_set_cloud_encode_selected_gatewayfunction. It covers scenarios such as invalid device and failure to encode the selected gateway. The test case uses the Google Test assertions to verify the expected behavior and follows the AAA pattern, making it easy to understand and maintain.
312-336: Test case looks good!The
SetCloudEncodeSelectedGatewaytest case thoroughly tests the success scenarios of thedps_provisioning_set_cloud_encode_selected_gatewayfunction. It covers scenarios such as encoding with a selected gateway and encoding without a selected gateway and selected gateway ID. The test case uses the Google Test assertions to verify the expected behavior and follows the AAA pattern, making it easy to understand and maintain.
338-347: Test case looks good!The
SetCloudEncodePayloadFailtest case thoroughly tests the failure scenarios of thedps_provisioning_set_cloud_encode_payloadfunction. It covers scenarios such as invalid device and failure to encode the payload. The test case uses the Google Test assertions to verify the expected behavior and follows the AAA pattern, making it easy to understand and maintain.
349-355: Test case looks good!The
SetCloudEncodePayloadtest case tests the success scenario of thedps_provisioning_set_cloud_encode_payloadfunction. It uses the Google Test assertions to verify the expected behavior and follows the AAA pattern, making it easy to understand and maintain.
357-368: Test case looks good!The
SetCloudFailtest case tests the failure scenario of thedps_provisioning_set_cloudfunction when the device is not in theRFNOPstate. It uses the Google Test assertionsapi/plgd/device-provisioning-client/plgd_dps_pki.c (11)
51-57: LGTM!The function correctly initializes the PKI configuration with a default expiring limit of 1 hour.
59-103: LGTM!The function correctly generates a CSR and sends it to the provisioning service via a POST request. The payload includes the device ID and the CSR data. The function handles the TLS setup and teardown appropriately.
112-118: LGTM!The function correctly converts a certificate state enum to its corresponding string representation. The assertion ensures that the
statevalue is within the bounds of the string array.
127-150: LGTM!The function correctly validates a certificate based on its validity period and the current time. It returns the appropriate certificate state enum value depending on whether the certificate is not yet valid, expiring, expired, or valid.
180-218: LGTM!The function correctly replaces the device's certificates with new ones obtained from the provisioning service. It handles the credential resource update, stale tag management, and provisioning status transitions appropriately. If any credentials are replaced or removed, it closes the TLS connections to the peers to ensure the new credentials are used for future connections.
226-246: LGTM!The function correctly schedules the renewal of certificates based on their expiration time. It calculates the renewal interval using
dps_pki_calculate_renew_certificates_intervaland ensures that the interval is not less than the specified minimum. It then schedules thedps_pki_renew_certificates_asyncfunction to run after the calculated interval.
287-294: LGTM!The function correctly implements the retry logic for replacing credentials. It retrieves the retry delay, increments the retry counter for the
PLGD_DPS_RENEW_CREDENTIALSaction, and callsdps_check_credentials_and_schedule_renewalwith the retry delay. The function returns the result ofdps_check_credentials_and_schedule_renewal.
296-345: LGTM!The function correctly handles the response from the provisioning service for replacing credentials. It performs the necessary checks and retries if the response is invalid or if replacing the certificates fails. If the credentials are successfully renewed, it updates the provisioning status, resets the retry counters, and closes the endpoint. If retrying fails, it forces reprovisioning to ensure a consistent state.
347-368: LGTM!The function correctly attempts to renew the certificates by sending a CSR to the provisioning service. It calls
dps_pki_send_csrto send the CSR and returns false if it fails. It also schedules a retry in case the response is not retrieved and updates the provisioning status and last error accordingly. The function returns true if the CSR is successfully sent.
378-397: LGTM!The function correctly implements the asynchronous renewal of certificates. It checks if replacing certificates is allowed and attempts to renew them using
dps_pki_try_renew_certificates. If renewing fails, it retrieves the retry delay, increments the retry counter, and reschedules the renewal. If rescheduling fails, it forces reprovisioning to ensure a consistent state. The function returnsOC_EVENT_DONEto indicate the completion of the asynchronous operation.
399-413: LGTM!The
plgd_dps_pki_set_expiring_limitfunction correctly sets the certificate expiring limit, and the `plgd_dps_pki_get_expapi/plgd/device-provisioning-client/plgd_dps_provision_cloud.c (9)
43-115: Ensure safe string assignments and consider other improvements.This function performs key extraction from a payload and assigns them to a
cloud_conf_tstructure. The error handling is robust, with checks for null pointers after each key extraction. However, consider the following improvements:
- Potential Undefined Behavior: The function assigns pointers to strings within the
oc_rep_tstructure directly to thecloud_conf_tstructure. Ensure that the lifetime of theoc_rep_tpayload outlasts thecloud_conf_tusage, otherwise the behavior is undefined when the payload is freed. Consider copying the strings to be safe.- Error Logging: The error messages are helpful, but they could include more context about the payload to aid debugging.
- Control Flow: The function uses multiple return points, which is generally fine, but consider using a single exit point for cleaner control flow and easier maintenance.
Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
117-132: Review ofcloud_deregister_handler: Simplify error handling.The function
cloud_deregister_handlerlogs different messages based on the response code. Consider simplifying the error handling by using a switch-case or mapping response codes to messages to reduce redundancy and improve maintainability.
134-155: Potential issue with assert usage incloud_deregister.The function uses
assertto ensurecloud_epis not null. While this is acceptable for debug builds, in a production build where asserts might be disabled, this could lead to undefined behavior ifcloud_epis null. Consider adding runtime checks and proper error handling for production builds.
157-238: Complexity and error handling indps_handle_set_cloud_response.This function is quite complex, handling multiple scenarios for cloud configuration and response parsing. Consider breaking it down into smaller, more manageable functions. This will improve readability and maintainability.
Additionally, ensure that all error paths properly clean up any allocated resources to prevent memory leaks.
Would you like me to help refactor this function into smaller parts?
240-251: Simplifydps_has_cloud_configurationby using helper functions.This function checks if the cloud configuration is set by verifying server URI and access token. Consider using helper functions to encapsulate these checks, improving readability and reusability.
253-315: Error handling and status management indps_set_cloud_handler.This handler function manages cloud setting responses and updates device status accordingly. The error handling is extensive, but the function could benefit from separating the status update logic into a separate function for clarity and reusability.
317-352: Review ofdps_provisioning_set_cloud_encode_selected_gateway: Ensure robust error handling.This function encodes the selected gateway for cloud provisioning. It uses asserts to ensure non-null pointers, which is risky in production. Consider adding runtime checks and returning meaningful error messages or codes if the assumptions are violated.
354-374: Potential improvements indps_provisioning_set_cloud_encode_payload.This function encodes the payload for cloud provisioning. It has robust error handling but could be simplified by abstracting some of the repetitive tasks into helper functions or macros, especially the UUID handling and string operations.
377-409: Improve error handling and replace assertions.The function
dps_provisioning_set_clouduses assertions to ensure the endpoint is not null and checks the device state. Consider replacing assertions with runtime checks to prevent potential issues in production environments where assertions may be disabled.Additionally, improve error handling by providing more specific error messages or codes when checks fail, to aid in debugging and maintenance.
api/plgd/device-provisioning-client/plgd_dps.c (10)
38-46: LGTM!The function correctly handles the provisioning manager status change by logging it and invoking the registered callback.
48-54: LGTM!The function correctly handles the event by invoking
dps_manager_status_cbwith the DPS context and returnsOC_EVENT_DONE.
58-63: LGTM!The function correctly restarts the provisioning manager by stopping it and scheduling an asynchronous callback to start it again.
65-126: LGTM!The function correctly handles the endpoint connection and disconnection events. It updates the endpoint state, session ID, and provisioning status based on the event. The logic for handling various scenarios such as insecure TLS session, provisioning errors, and retries looks good.
Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
128-148: LGTM!The function correctly handles session events for both DPS and cloud endpoints. It invokes
dps_handle_endpoint_eventfor events related to the DPS endpoint and observes the cloud status for disconnection events related to the cloud server endpoint. The logic for comparing endpoints and handling events looks good.
150-158: LGTM!The function correctly restarts the provisioning manager for initialized DPS contexts. It checks the DPS status and invokes
dps_manager_restartif the status isPLGD_DPS_INITIALIZED. The function serves its purpose as a callback for iterating over DPS contexts.
160-166: LGTM!The function correctly handles network interface events by restarting initialized DPS contexts when the network interface is up. It uses
dps_contexts_iterateto iterate over all DPS contexts and passesdps_restart_initializedas the callback function. The logic ensures that provisioning is restarted when the network becomes available.
170-187: LGTM!The function correctly initializes the DPS contexts for each device. It allocates memory for each context, initializes it with the device index, loads existing provisioning data from storage, and adds the context to the context list. The error handling for memory allocation failure is appropriate. The logic ensures proper initialization of DPS contexts.
189-210: LGTM!The function correctly shuts down the DPS contexts for each device. It retrieves the DPS context for each device, stops the provisioning manager, removes session event callbacks, closes endpoints, deinitializes the context, removes it from the context list, and frees the memory. The cleanup steps ensure proper shutdown and resource deallocation. The logic is thorough and handles all necessary cleanup tasks.
214-218: LGTM!The function correctly initializes session event callbacks for a DPS context by adding the
dps_ep_session_event_handlercallback function to the context usingoc_add_session_event_callback_v1. The logic is simple and straightforward.api/plgd/device-provisioning-client/plgd_dps_security.c (10)
46-50: LGTM!The function correctly checks the device ownership status based on the provisioning state. The logic is sound and the implementation is clear.
52-95: Comprehensive ownership validation!The function performs a thorough validation of the device's ownership status by checking the owner UUID across multiple security resources (
pstat,doxm,creds,acls). It also verifies additional conditions to ensure the device is in the correct state for ownership. The logic is robust and the implementation is well-structured.
97-107: LGTM!The function correctly checks if a device is self-owned by comparing the device UUID with the
deviceuuidstored indoxmand then callingdps_is_ownedto validate the ownership. The logic is straightforward and the implementation is clear.
109-125: Selective credential clearing!The function clears the credentials of a device while preserving the manufacturer certificates and trust CAs that are not DPS-specific. It iterates over each credential and removes the ones that don't meet the skip conditions. The logic is well-defined and the implementation is straightforward.
127-144: LGTM!The function correctly determines if a peer endpoint is a server by checking the
rolefield of theoc_tls_peer_tstructure. The debug logging statements provide useful information when enabled. The logic is simple and the implementation is clear.
146-202: Comprehensive device ownership process!The function performs a complete device ownership process by updating the provisioning status, device owner transfer method, credentials, and access control lists based on the provided owner UUID. It ensures that the device state is set to
OC_DOS_RFOTMbefore proceeding with the ownership transfer. The logic is well-structured and covers all the necessary steps. The implementation is robust and follows a clear sequence of operations.
204-214: LGTM!The function correctly sets the owner of a device by first checking if the device is already owned by the provided owner. If not, it sets the device state to
OC_DOS_RFOTMand callsdps_own_deviceto perform the ownership process. The logic is straightforward and the implementation is clear.
216-226: LGTM!The function correctly sets a device as self-owned by first checking if the device is already self-owned. If not, it retrieves the device UUID, sets the device state to
OC_DOS_RFOTM, and callsdps_own_deviceto perform the ownership process with the device UUID as the owner. The logic is straightforward and the implementation is clear.
228-239: LGTM!The function correctly checks if a device has an owner by first verifying that the device is owned and not self-owned. It then retrieves the owner UUID from the
devowneruuidfield ofdoxmand callsdps_is_ownedto validate the ownership. The logic is straightforward and the implementation is clear.
241-246: LGTM!The function correctly performs a factory reset on a device by asserting that the device is owned and then calling
oc_reset_device_v1to handle theapi/plgd/unittest/plgd_dps_resource.cpp (11)
1-17: The Apache 2.0 license header looks good.The license header is correctly formatted and contains the necessary information. The Apache 2.0 license is a permissive open-source license that is appropriate for this project.
19-22: The conditional compilation directives are used correctly.The code is included only if the necessary features are enabled. This is a good practice to keep the code modular and avoid compilation errors when the features are not available.
24-35: The#includedirectives are used correctly.The necessary header files are included in a consistent order and are guarded by the conditional compilation directives.
41-45: The constant andusingdirective are used appropriately.The
kDeviceIDconstant is used to identify the device in the tests, and theusingdirective is used to avoid verbosity when usingstd::chronoliterals.
47-60: TheDPSEndpointDataandDPSDatastructs are well-defined.The structs contain the necessary fields to store the DPS endpoint and data information. The naming conventions are followed, and the structs are well-structured.
62-85: TheparseDPSEndpointsfunction is implemented correctly.The function parses the DPS endpoints from the given
oc_rep_trepresentation. It extracts theuriandnamefields for each endpoint and stores them in aDPSEndpointDatastruct. The function returns an empty vector if any required field is missing, which is a good error handling practice. The naming conventions are followed, and the function has a clear purpose.
87-140: TheparseDPSDataPropertyfunction is implemented correctly.The function parses a single DPS data property from the given
oc_rep_trepresentation and updates theDPSDatastruct. It handles different types of properties based on theoc_rep_ttype and updates the corresponding fields in theDPSDatastruct. The function returnstrueif the property is successfully parsed andfalseotherwise, which is a good error handling practice. The naming conventions are followed, and the function has a clear purpose.
142-156: TheparseDPSDatafunction is implemented correctly.The function parses the DPS data from the given
oc_rep_trepresentation and updates theDPSDatastruct. It iterates over the representation, skips the baseline interface properties, and calls theparseDPSDataPropertyfunction to parse each non-baseline property. If a property is not parsed successfully, it logs a debug message indicating an unexpected property. The function returnstrueafter parsing all the properties. The naming conventions are followed, and the function has a clear purpose.
158-238: TheEncodeReadtest case is implemented correctly.The test case verifies the encoding and decoding of DPS data using the
dps_resource_encodefunction and theparseDPSDatafunction. It initializes adps_resource_data_tstruct with sample data, encodes it, and then parses the encoded payload to verify that the parsed data matches the original data. The test case covers different scenarios, such as when the provision status is not set and when there are multiple endpoints. It follows the AAA pattern and has clear assertions. The test case is well-structured and provides good coverage for the encoding and decoding functionality.
240-275: TheEncodeReadWritetest case is implemented correctly.The test case verifies the encoding of DPS data using the
dps_resource_encodefunction with theOC_IF_RWinterface. It initializes adps_resource_data_tstruct with sample data, encodes it using theOC_IF_RWinterface, and then parses the encoded payload to verify that the parsed data matches the expected data. The test case ensures that the last error and provision status are not included in the encoded payload when using theOC_IF_RWinterface. It follows the AAA pattern and has clear assertions. The test case provides good coverage for the encoding functionality with theOC_IF_RWinterface.
277-380: TheStatusToStringtest case is implemented correctly.The test case verifies the conversion of DPS status flags to their corresponding string representations using the
dps_status_to_strfunction. It covers various DPS status flags and their combinations, ensuring that the returned string matches the expected string representation for each flag. The test case also verifies that thedps_status_to_strfunction returnsnullptrfor unknown status flags. It follows the AAA pattern and has clear assertions. The test case provides comprehensive coverage for thedps_status_to_strfunction and ensures its correctness.api/plgd/device-provisioning-client/plgd_dps_provision.c (4)
43-63: LGTM!The function correctly handles the response from the provisioning server and sets the appropriate error status. The logic for handling transient failures is sound.
139-204: LGTM!The function correctly handles the response from the GET ACLs request, performing the necessary checks and updates. The modular approach using
dps_provisioning_check_responseanddps_handle_get_acls_responseis good. The scheduling of the next provisioning step on success and handling of failure on error is appropriate. The logic and syntax are sound.
206-229: LGTM!The function correctly sends a GET request to retrieve the ACLs, handling the setup and error cases. The check for the device state ensures that the device is in the correct state before sending the request. The use of
dps_setup_tlsandoc_do_get_with_timeoutprovides a secure and reliable way to send the request. The error handling and status updates are appropriate. The logic and syntax are sound.
231-305: LGTM!The function correctly handles the response from the GET credentials request, performing the necessary checks and updates. The modular approach using
dps_pki_replace_certificates,dps_check_credentials_and_schedule_renewal, anddps_try_set_identity_chainis good. The scheduling of the next provisioning step on success and handling of failure on error is appropriate. The logic and syntax are sound.CMakeLists.txt (9)
82-83: LGTM!The new CMake options for the plgd device provisioning feature are introduced with appropriate default values.
175-175: Modularizing utility functions.The inclusion of
tools/utils.cmakeis a good step towards a more modular approach for handling utility functions. This change aligns with the removal of theoc_add_compile_optionsfunction.
239-239: Streamlining log level configuration.The introduction of the
oc_set_maximum_log_levelfunction enhances the readability and maintainability of the CMake file by abstracting the conditional logic into a single call.
242-245: Propagating log level configuration.The log level configuration is correctly propagated to the
PRIVATE_COMPILE_DEFINITIONS,TEST_COMPILE_DEFINITIONS, andMBEDTLS_COMPILE_DEFINITIONSlists. The use of parentheses around the value helps avoid triggering thebugprone-macro-parentheseswarning in clang-tidy.
407-441: Robust control flow for plgd features.The conditional logic for the plgd features introduces a more robust control flow that prevents misconfigurations arising from incompatible feature combinations. The checks for the prerequisites of the
PLGD_DEV_DEVICE_PROVISIONING_ENABLEDoption ensure that it is only activated when the necessary features are enabled. The use of theoc_set_maximum_log_levelfunction for setting the plgd DPS log level is consistent with the previous changes.
684-688: Conditional inclusion of device provisioning client source files.The conditional addition of the
PLGD_DPS_SRCvariable to theclient-server-objlibrary ensures that the device provisioning client source files are only included when the feature is enabled. This change aligns with the implementation of device provisioning functionalities mentioned in the AI-generated summary.
690-690: Including device provisioning client source files in the library.The addition of the
PLGD_DPS_SRCvariable to theclient-server-objlibrary definition ensures that the device provisioning client source files are compiled and linked with the library. This change is consistent with the conditional inclusion of thePLGD_DPS_SRCvariable based on thePLGD_DEV_DEVICE_PROVISIONING_ENABLEDoption.
1112-1121: Conditional addition of plgd unit tests.The conditional addition of the
plgdtesttarget ensures that the plgd-specific unit tests are only built and executed when the relevant features are enabled. The inclusion of the common test source files and the plgd-specific test source files in theplgdtesttarget ensures that the necessary test cases are compiled and linked. The use of theoc_package_add_testmacro is consistent with the other unit test targets.
1315-1325: Conditional installation of plgd header files.The conditional installation of the plgd-specific header files ensures that they are only installed when the relevant features are enabled. The installation of the header files to the
${CMAKE_INSTALL_INCLUDEDIR}/iotivity-lite/plgddirectory is consistent with the installation of other header files.
Danielius1922
force-pushed
the
adam/feature/dps
branch
from
1f59b01
to
829b3a5
Compare
|
@coderabbitai create a PR description focusing on describing device provisioning service features for external developers. |
|
Tip For best results, initiate chat on the files or code changes. Here is a PR description focusing on the Device Provisioning Service features for external developers: Device Provisioning Service (DPS) IntegrationThis pull request introduces a comprehensive Device Provisioning Service (DPS) to the IoTivity-Lite framework, enabling devices to securely and efficiently connect to cloud services with minimal manual intervention. The DPS automates the provisioning process, managing device credentials, ownership, and cloud configurations seamlessly. Key Features1. Automatic Device Provisioning
2. Secure PKI Implementation
3. Robust Retry Mechanism
4. Extensive Logging and Debugging Support
5. Comprehensive Testing Suite
Benefits for External Developers
Getting StartedEnabling DPS in Your BuildTo utilize the DPS features, enable the following build options in your -DPLGD_DEV_DEVICE_PROVISIONING_ENABLED=ONAdditional options for enhanced functionality:
Sample UsageInitialize and start the DPS manager in your application code: #include "plgd_dps_manager.h"
int main() {
// Initialize the IoTivity-Lite stack
oc_main_init(...);
// Start the Device Provisioning Service manager
plgd_dps_manager_start();
// Your application logic here
// Shutdown the IoTivity-Lite stack
oc_main_shutdown();
return 0;
}Ensure that your device has access to the necessary manufacturer certificates and that cloud configurations are set up as per your deployment environment. Detailed Overview of Changes
Additional Information
Let me know if you need any further adjustments or additional information included in the description. |
There was a problem hiding this comment.
Actionable comments posted: 2
Outside diff range and nitpick comments (2)
api/plgd/device-provisioning-client/plgd_dps_endpoints.c (2)
36-63: LGTM!The function implementation looks good overall. It correctly handles the case when the endpoint is already set, disconnects the current endpoint before setting a new one, and notifies observers of the change.
Consider providing more specific error messages to aid in debugging. For example, instead of a generic "failed to set endpoint" message, include the specific reason for the failure.
65-82: LGTM!The function implementation looks good overall. It correctly compares the selected endpoint with the current one to determine if a change is required and triggers a disconnect when necessary.
Consider providing more specific error messages to aid in debugging. For example, instead of a generic "failed to set endpoints" message, include the specific reason for the failure.
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files ignored due to path filters (1)
tools/doxygen.iniis excluded by!**/*.ini
Files selected for processing (82)
- .dockerignore (1 hunks)
- .github/workflows/cmake-linux.yml (2 hunks)
- .github/workflows/docker-build-publish-with-cfg.yml (1 hunks)
- .github/workflows/docker-build-publish.yml (1 hunks)
- .github/workflows/ghcr-check.yml (1 hunks)
- .github/workflows/plgd-device-test-with-cfg.yml (1 hunks)
- .github/workflows/plgd-dps-test-with-cfg.yml (1 hunks)
- .github/workflows/plgd-dps-tests.yml (1 hunks)
- .github/workflows/plgd-hub-test-with-cfg.yml (1 hunks)
- .github/workflows/sonar-cloud-analysis.yml (4 hunks)
- .github/workflows/static-analysis.yml (2 hunks)
- .github/workflows/unit-test-with-cfg.yml (1 hunks)
- CMakeLists.txt (7 hunks)
- api/oc_endpoint.c (1 hunks)
- api/oc_log.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_apis.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_apis_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_cloud.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_cloud_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_context.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_context_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_dhcp.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_dhcp_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_endpoint.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_endpoint_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_endpoints.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_endpoints_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_log.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_log_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_manager.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_manager_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_pki.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_pki_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision_cloud.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision_cloud_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision_owner.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_provision_owner_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_resource.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_resource_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_retry.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_retry_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_security.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_security_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_store.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_store_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_tag.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_tag_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_time.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_time_internal.h (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_verify_certificate.c (1 hunks)
- api/plgd/device-provisioning-client/plgd_dps_verify_certificate_internal.h (1 hunks)
- api/plgd/unittest/plgd_dps.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_apis.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_cloud.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_context.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_dhcp.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_endpoint.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_endpoints.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_log.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_manager.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_pki.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_provision.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_provision_cloud.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_provision_owner.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_resource.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_retry.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_security.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_store.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_tag.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_test.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_test.h (1 hunks)
- api/plgd/unittest/plgd_dps_time.cpp (1 hunks)
- api/plgd/unittest/plgd_dps_verify_certificate.cpp (1 hunks)
- apps/CMakeLists.txt (1 hunks)
- apps/dps_cloud_server.c (1 hunks)
- docker/apps/Dockerfile.cloud-server (2 hunks)
- docker/apps/Dockerfile.dps-cloud-server (1 hunks)
- docker/apps/Dockerfile.dps-cloud-server-debug (1 hunks)
Files not processed due to max files limit (9)
- include/oc_log.h
- include/plgd/plgd_dps.h
- messaging/coap/observe.c
- security/oc_pstat.c
- security/oc_tls.c
- sonar-project.properties
- tools/utils.cmake
- util/oc_features.h
- util/oc_memb.h
Files skipped from review due to trivial changes (8)
- .github/workflows/plgd-device-test-with-cfg.yml
- .github/workflows/unit-test-with-cfg.yml
- api/plgd/device-provisioning-client/plgd_dps_cloud_internal.h
- api/plgd/device-provisioning-client/plgd_dps_context_internal.h
- api/plgd/device-provisioning-client/plgd_dps_dhcp_internal.h
- api/plgd/device-provisioning-client/plgd_dps_internal.h
- api/plgd/device-provisioning-client/plgd_dps_security.c
- api/plgd/unittest/plgd_dps_apis.cpp
Files skipped from review as they are similar to previous changes (58)
- .dockerignore
- .github/workflows/cmake-linux.yml
- .github/workflows/docker-build-publish-with-cfg.yml
- .github/workflows/docker-build-publish.yml
- .github/workflows/ghcr-check.yml
- .github/workflows/plgd-dps-tests.yml
- .github/workflows/plgd-hub-test-with-cfg.yml
- .github/workflows/sonar-cloud-analysis.yml
- .github/workflows/static-analysis.yml
- CMakeLists.txt
- api/oc_endpoint.c
- api/oc_log.c
- api/plgd/device-provisioning-client/plgd_dps_apis_internal.h
- api/plgd/device-provisioning-client/plgd_dps_cloud.c
- api/plgd/device-provisioning-client/plgd_dps_dhcp.c
- api/plgd/device-provisioning-client/plgd_dps_endpoint_internal.h
- api/plgd/device-provisioning-client/plgd_dps_endpoints_internal.h
- api/plgd/device-provisioning-client/plgd_dps_log.c
- api/plgd/device-provisioning-client/plgd_dps_log_internal.h
- api/plgd/device-provisioning-client/plgd_dps_manager_internal.h
- api/plgd/device-provisioning-client/plgd_dps_pki_internal.h
- api/plgd/device-provisioning-client/plgd_dps_provision_cloud_internal.h
- api/plgd/device-provisioning-client/plgd_dps_provision_internal.h
- api/plgd/device-provisioning-client/plgd_dps_provision_owner_internal.h
- api/plgd/device-provisioning-client/plgd_dps_resource.c
- api/plgd/device-provisioning-client/plgd_dps_resource_internal.h
- api/plgd/device-provisioning-client/plgd_dps_retry.c
- api/plgd/device-provisioning-client/plgd_dps_retry_internal.h
- api/plgd/device-provisioning-client/plgd_dps_security_internal.h
- api/plgd/device-provisioning-client/plgd_dps_store_internal.h
- api/plgd/device-provisioning-client/plgd_dps_tag.c
- api/plgd/device-provisioning-client/plgd_dps_tag_internal.h
- api/plgd/device-provisioning-client/plgd_dps_time_internal.h
- api/plgd/device-provisioning-client/plgd_dps_verify_certificate.c
- api/plgd/device-provisioning-client/plgd_dps_verify_certificate_internal.h
- api/plgd/unittest/plgd_dps.cpp
- api/plgd/unittest/plgd_dps_cloud.cpp
- api/plgd/unittest/plgd_dps_context.cpp
- api/plgd/unittest/plgd_dps_dhcp.cpp
- api/plgd/unittest/plgd_dps_endpoint.cpp
- api/plgd/unittest/plgd_dps_endpoints.cpp
- api/plgd/unittest/plgd_dps_manager.cpp
- api/plgd/unittest/plgd_dps_pki.cpp
- api/plgd/unittest/plgd_dps_provision.cpp
- api/plgd/unittest/plgd_dps_provision_owner.cpp
- api/plgd/unittest/plgd_dps_retry.cpp
- api/plgd/unittest/plgd_dps_security.cpp
- api/plgd/unittest/plgd_dps_store.cpp
- api/plgd/unittest/plgd_dps_tag.cpp
- api/plgd/unittest/plgd_dps_test.cpp
- api/plgd/unittest/plgd_dps_test.h
- api/plgd/unittest/plgd_dps_time.cpp
- api/plgd/unittest/plgd_dps_verify_certificate.cpp
- apps/CMakeLists.txt
- apps/dps_cloud_server.c
- docker/apps/Dockerfile.cloud-server
- docker/apps/Dockerfile.dps-cloud-server
- docker/apps/Dockerfile.dps-cloud-server-debug
Additional context used
cppcheck
api/plgd/device-provisioning-client/plgd_dps_endpoints.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_endpoint.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_apis.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_provision_owner.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_time.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_context.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_manager.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_store.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_pki.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_provision_cloud.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
api/plgd/device-provisioning-client/plgd_dps_provision.c
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
actionlint
.github/workflows/plgd-dps-test-with-cfg.yml
134-134: shellcheck reported issue in this script: SC2129:style:2:1: Consider using { cmd1; cmd2; } >> file instead of individual redirects
(shellcheck)
134-134: shellcheck reported issue in this script: SC2086:info:2:53: Double quote to prevent globbing and word splitting
(shellcheck)
134-134: shellcheck reported issue in this script: SC2086:info:3:61: Double quote to prevent globbing and word splitting
(shellcheck)
134-134: shellcheck reported issue in this script: SC2086:info:4:48: Double quote to prevent globbing and word splitting
(shellcheck)
Additional comments not posted (143)
api/plgd/unittest/plgd_dps_log.cpp (6)
30-37: LGTM!The
TestDPSLogclass is a well-designed test fixture that provides setup and teardown methods to manage the logging state before and after each test. TheTearDownmethod ensures isolation between tests by resetting the logging function and setting the log level to a default state.
39-52: LGTM!The
LogToStdouttest function thoroughly validates the logging behavior at different levels. It ensures that messages are correctly logged and verifies that the log level is set as expected.
54-67: LGTM!The
printLogfunction provides a comprehensive logging mechanism that includes additional information such as file, line, function name, and log level. It formats the log message appropriately and flushes the stdout stream to ensure immediate visibility.
69-84: LGTM!The
expectUpToNoticefunction is a useful utility that validates that logs are only generated up to the notice level. It leverages the Google Test framework'sEXPECT_TRUEmacro to assert the log level and calls theprintLogfunction to print the log message.
86-97: LGTM!The
LogToFunctiontest function demonstrates the flexibility of the logging framework by allowing logs to be directed to a custom logging function. It sets the log level to notice and uses theexpectUpToNoticefunction to validate that only logs up to the notice level are generated.
105-116: LGTM!The
SkipLogByComponenttest function validates an important aspect of the logging system by confirming that when no components are set, no logs are produced. It sets the log level to trace and uses theexpectNoLogfunction to fail the test if any log is generated, ensuring the expected behavior.api/plgd/device-provisioning-client/plgd_dps_endpoints.c (9)
84-90: LGTM!The function implementation looks good. It correctly calculates the endpoint string length, ensures it doesn't exceed the maximum allowed length, and calls the
dps_set_endpointfunction with the appropriate arguments.
92-113: LGTM!The function implementation looks good. It correctly checks if an endpoint is currently selected, ensures that the provided buffer is large enough to hold the endpoint string, and uses appropriate logging statements.
Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
115-120: LGTM!The function implementation looks good. It correctly checks if an endpoint is currently selected by comparing the result of
oc_endpoint_addresses_selectedwithNULL.
122-132: LGTM!The function implementation looks good. It correctly initializes the endpoint addresses using the
oc_endpoint_addresses_initfunction with the appropriate arguments.
134-142: LGTM!The function implementation looks good. It correctly adds an endpoint address using the
oc_endpoint_addresses_addfunction with the appropriate arguments.
144-149: LGTM!The function implementation looks good. It correctly removes an endpoint address using the
oc_endpoint_addresses_removefunction with the appropriate arguments.
151-158: LGTM!The function implementation looks good. It correctly iterates over the endpoint addresses using the
oc_endpoint_addresses_iteratefunction with the appropriate arguments.
160-165: LGTM!The function implementation looks good. It correctly selects an endpoint address using the
oc_endpoint_addresses_selectfunction with the appropriate arguments.
167-171: LGTM!The function implementation looks good. It correctly retrieves the currently selected endpoint address using the
oc_endpoint_addresses_selectedfunction.api/plgd/device-provisioning-client/plgd_dps_endpoint.c (9)
36-51: LGTM!The function correctly initializes the endpoint context and handles potential errors. The usage of
OC_DNS_CACHEmacro ensures that the DNS cache is cleared only when necessary.
55-77: LGTM!The debug function correctly prints the list of peers for an endpoint. The usage of
DPS_DBG_IS_ENABLEDmacro ensures that the function is only compiled in debug mode, and the exclusion from code coverage is appropriate for a debug function.
80-123: LGTM!The function correctly adds a new peer to the TLS context with the appropriate ciphersuite and identity certificate chain selection. The usage of
dps_verify_certificate_data_tstructure ensures that the peer's certificate is properly verified.The unknown macro error reported by cppcheck is a false positive, as the function is not a macro.
Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
125-133: LGTM!The function safely closes an endpoint session by first checking if the endpoint is not empty. The usage of
assertensures that the endpoint is not NULL.
135-145: LGTM!The function correctly handles the disconnection process by closing the endpoint, clearing its memory, and setting the appropriate endpoint state. The usage of
assertensures that the context is not NULL.
147-152: LGTM!The utility function correctly checks if an endpoint is uninitialized by using the
oc_endpoint_is_emptyfunction. The usage ofassertensures that the endpoint is not NULL.
154-185: LGTM!The function correctly formats the endpoint information into a string for logging purposes. It handles potential errors and frees the allocated memory. The usage of
DPS_DBG_IS_ENABLEDmacro ensures that the session ID is included in the formatted string only in debug mode.
187-198: LGTM!The function correctly sets up the TLS context with the appropriate security parameters for communication. It checks if a peer already exists and adds a new peer if necessary. The error handling and logging ensure that any issues are properly reported.
200-206: LGTM!The function correctly resets the TLS context to use the default ciphersuite and certificates. The usage of
oc_tls_reset_ciphersuiteandoc_tls_select_identity_cert_chainensures that the TLS context is properly reset..github/workflows/plgd-dps-test-with-cfg.yml (3)
1-5: Looks good!The comment block provides a clear and important disclaimer about the usage of uncertified actions in the workflow. It's a good practice to include such disclaimers to inform users about potential risks and separate governance terms.
8-39: Well-defined workflow trigger and input parameters!The usage of
workflow_callallows the workflow to be invoked from other workflows, providing flexibility. The input parameters cover various important aspects such as build arguments, coverage, and skip option. Providing default values for optional parameters is a good practice.
40-176: Comprehensive and well-structured workflow!The remaining code segments define a comprehensive and well-structured workflow for running tests and collecting coverage data. The usage of Docker containers provides isolation and reproducibility. The workflow includes necessary steps for checking out the repository, building Docker images, running tests, and collecting coverage data. It also handles test failures and collects logs appropriately.
The past review comments have been addressed, and no new issues are identified in the remaining code segments.
Tools
actionlint
134-134: shellcheck reported issue in this script: SC2129:style:2:1: Consider using { cmd1; cmd2; } >> file instead of individual redirects
(shellcheck)
134-134: shellcheck reported issue in this script: SC2086:info:2:53: Double quote to prevent globbing and word splitting
(shellcheck)
134-134: shellcheck reported issue in this script: SC2086:info:3:61: Double quote to prevent globbing and word splitting
(shellcheck)
134-134: shellcheck reported issue in this script: SC2086:info:4:48: Double quote to prevent globbing and word splitting
(shellcheck)
api/plgd/device-provisioning-client/plgd_dps_apis.c (12)
35-43: LGTM!The function logic is correct, and the implementation is accurate. It handles null strings appropriately and compares the strings by length and content.
45-51: LGTM!The function logic is correct, and the implementation is accurate. It handles empty strings appropriately and compares the strings by size and content.
53-61: LGTM!The function logic is correct, and the implementation is accurate. It checks if a representation matches a specified property type and name by comparing the type, name length, and name content.
63-73: LGTM!The function logic is correct, and the implementation is accurate. It calculates the maximum time value based on the size of the clock type, ensuring that the appropriate maximum value is returned for the available integer type.
75-90: LGTM!The function logic is correct, and the implementation is accurate. It schedules a callback with a specified delay in milliseconds, removing any existing delayed callback with the same data and callback function. It also handles the case where the specified delay exceeds the maximum allowable time by truncating the delay and logging a debug message.
92-99: LGTM!The function logic is correct, and the implementation is accurate. It schedules a callback with a specified delay in seconds by converting the delay to milliseconds and calling
dps_reset_delayed_callback_ms.
101-105: LGTM!The function logic is correct, and the implementation is accurate. It checks if a status code represents a timeout error by comparing it with the predefined timeout error codes.
Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
107-112: LGTM!The function logic is correct, and the implementation is accurate. It checks if a status code represents a connection error by comparing it with the predefined connection error codes.
114-118: LGTM!The function logic is correct, and the implementation is accurate. It checks if a status code represents an error by comparing it with the predefined error code range.
120-130: LGTM!The function logic is correct, and the implementation is accurate. It translates a status code into a specific DPS error code by checking if the status code represents a timeout error, a connection error, or a general error, and returns the corresponding DPS error code.
132-182: LGTM!The function logic is correct, and the implementation is accurate. It processes a redirect response by extracting the redirect URI from the payload, checking if it's valid, adding it to the list of endpoints if it's not already present, removing the original server from the list, selecting the new server based on the redirect URI, and disconnecting the DPS endpoint.
184-201: LGTM!The function logic is correct, and the implementation is accurate. It checks the response status code and payload by getting the DPS error code corresponding to the status code, returning the error code if it's not
PLGD_DPS_OK, returningPLGD_DPS_OKif the payload is null, logging a debug message indicating that the response is OK, handling the redirectapi/plgd/device-provisioning-client/plgd_dps_provision_owner.c (2)
42-73: LGTM!The function
dps_handle_get_owner_responseis well-implemented with robust checks and detailed error logging. The logic for extracting the owner UUID from the response payload and updating the device's context is correct.
182-209: LGTM!The debug function
dps_print_owneris well-implemented and provides useful information for debugging purposes. It correctly retrieves the owner UUIDs from various security resources and prints them using theDPS_DBGmacro.api/plgd/device-provisioning-client/plgd_dps_time.c (5)
48-52: LGTM!The function logic is correct, and the implementation is accurate.
62-71: LGTM!The function logic is correct, and the implementation is accurate. It effectively handles the time retrieval based on the synchronization status between the system time and PLGD time.
73-97: LGTM!The function logic is correct, and the implementation is accurate. It effectively sets the system time based on the provided time, logging the operation and checking for synchronization issues.
99-172: LGTM!The function logic is correct, and the implementation is accurate. It effectively processes the response from a time retrieval request, updating the context status and handling errors appropriately.
Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
174-230: LGTM!The function logic is correct, and the implementation is accurate. It effectively initiates a request to fetch the PLGD time, handling certificate verification based on the context's configuration.
api/plgd/device-provisioning-client/plgd_dps_context.c (12)
46-50: LGTM!The function correctly allocates memory for a
plgd_dps_context_tstructure using theoc_memb_allocfunction and theg_dps_context_poolmemory pool.
52-56: LGTM!The function correctly frees memory allocated for a
plgd_dps_context_tstructure using theoc_memb_freefunction and theg_dps_context_poolmemory pool.
58-62: LGTM!The function correctly adds a
plgd_dps_context_tstructure to theg_dps_context_listlinked list using theoc_list_addfunction.
64-68: LGTM!The function correctly removes a
plgd_dps_context_tstructure from theg_dps_context_listlinked list using theoc_list_removefunction.
70-74: LGTM!The function correctly checks if the
g_dps_context_listlinked list is empty by comparing the length of the list to 0 using theoc_list_lengthfunction.
76-85: LGTM!The function correctly iterates over the
g_dps_context_listlinked list and calls the callback functionfnfor each element. The iteration stops if the callback function returns false.
87-114: LGTM!The function correctly initializes a
plgd_dps_context_tstructure by setting default values for various fields and calling initialization functions for sub-structures.Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
116-127: LGTM!The function correctly deinitializes a
plgd_dps_context_tstructure by calling deinitialization functions for sub-structures and freeing memory allocated for theendpointfield.
129-144: LGTM!The function correctly resets a
plgd_dps_context_tstructure to its initial state by calling deinitialization and reinitialization functions for sub-structures and resetting various fields to their default values.
146-154: LGTM!The function correctly retrieves a
plgd_dps_context_tstructure from theg_dps_context_listlinked list based on the provideddeviceargument by iterating over the list until it finds a matching structure or reaches the end of the list.
156-165: LGTM!The function correctly performs a factory reset on a
plgd_dps_context_tstructure by callingdps_context_resetto reset the structure to its initial state.The purpose of the
oc_cloud_set_retry_timeoutscall with NULL arguments when thePLGD_DPS_RESOURCE_TEST_PROPERTIESmacro is defined is unclear from the provided context. Please verify the intended behavior and ensure that it aligns with the expected functionality of the factory reset operation.
167-173: **LGTMapi/plgd/device-provisioning-client/plgd_dps_manager.c (10)
45-54: LGTM!The function correctly initializes the DPS manager if it hasn't been started yet, sets up necessary callbacks, and signals the event loop. The logic is sound and the implementation is accurate.
56-65: LGTM!The function correctly iterates over credentials to find the manufacturer certificate by checking the necessary conditions. It sets the found credential pointer and returns false to stop iteration as expected. The logic is sound and the implementation is accurate.
67-78: LGTM!The function correctly checks if the device has a manufacturer certificate by retrieving the credentials and iterating over them using the appropriate callback. It logs a debug message if found and returns the correct boolean value. The logic is sound and the implementation is accurate.
80-89: LGTM!The function correctly iterates over credentials to find the manufacturer trusted root CA by checking the necessary conditions. It sets the found credential pointer and returns false to stop iteration as expected. The logic is sound and the implementation is accurate.
91-102: LGTM!The function correctly checks if the device has a manufacturer trusted root CA by retrieving the credentials and iterating over them using the appropriate callback. It logs a debug message if found and returns the correct boolean value. The logic is sound and the implementation is accurate.
104-142: LGTM!The function correctly determines the provision and cloud observer flags based on the current state of the device. It checks the necessary conditions and sets the appropriate flags using bitwise operations. The logic for setting the flags is sound and follows the expected behavior. The implementation is accurate and there are no apparent issues.
Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
144-200: LGTM!The function correctly starts the DPS manager by performing the necessary checks and initializations. It handles various scenarios such as the DPS manager already being started, the DPS endpoint being empty, and the absence of required certificates. It calculates the new status based on the current state and resets the retry count and provisioned since reset flag appropriately. It starts the DPS manager and initializes the necessary callbacks. The logic is sound and the implementation is accurate. There are no apparent issues.
202-207: LGTM!The function correctly checks if the DPS manager is started by returning the value of the
manager_startedflag from the context. It asserts that the context pointer is not NULL, which is a good practice to catch invalid arguments. The logic is straightforward and the implementation is accurate. There are no apparent issues.
209-218: LGTM!The function correctly starts the DPS manager asynchronously by calling
dps_manager_start. It frees the existing endpoint and allocates a new one, ensuring a clean start. It memsets the new endpoint to zero, which is a good practice to initialize the memory. It returnsOC_EVENT_DONEto indicate the completion of the event, which is the expected behavior for an asynchronous event callback. The logic is sound and the implementation is accurate. There are no apparent issues.
220-225: LGTM!The function correctly restarts the DPS manager by first stopping it using
plgd_dps_manager_stopand then starting it usingplgd_dps_manager_start. It returns the result ofplgd_dps_manager_start, which indicates the success or failureapi/plgd/device-provisioning-client/plgd_dps_store.c (9)
56-63: LGTM!The function logic is correct, and the implementation is accurate. The error handling and logging are appropriate.
65-70: LGTM!The function logic is correct, and the implementation is accurate. Resetting the delayed callback and signaling the event loop is the appropriate way to trigger an asynchronous dump of the DPS store.
72-80: LGTM!The function logic is correct, and the implementation is accurate. Deinitializing the store and initializing the endpoints with the provided callback and data is the appropriate way to initialize the DPS store.
82-88: LGTM!The function logic is correct, and the implementation is accurate. Deinitializing the endpoint addresses, setting the owner string to NULL, and resetting the
has_been_provisioned_since_resetflag is the appropriate way to deinitialize the DPS store.
90-140: LGTM!The function logic is correct, and the implementation is accurate. Reinitializing the endpoint addresses with the selected URI and name, iterating over the provided endpoints, and adding them to the store if they don't already exist is the appropriate way to set the endpoints in the DPS store. The error handling and logging are also appropriate.
Tools
cppcheck
[error] 104-104: There is an unknown macro here somewhere. Configuration is required. If dps_endpoint_add_peer is a macro then please configure it.
(unknownMacro)
142-215: LGTM!The function logic is correct, and the implementation is accurate. Iterating over the representation, retrieving the corresponding values, setting the endpoints in the store, copying the owner string, and setting the
has_been_provisioned_since_resetflag is the appropriate way to decode the DPS store from a representation. The error handling and logging are also appropriate.
278-309: LGTM, but please address the missing tests.The function logic is correct, and the implementation is accurate. Allocating a buffer, reading the store from storage, decoding it, and freeing the buffer is the appropriate way to load the DPS store from storage. The error handling and logging are also appropriate.
However, I wanted to remind you about the missing tests for this function.
Do you want me to generate the unit testing code or open a GitHub issue to track this task?
311-318: LGTM!The function logic is correct, and the implementation is accurate. Starting the root object, encoding the store with a map, ending the root object, and returning the result of
oc_rep_get_cbor_errnois the appropriate way to encode the DPS store to a representation.
363-370: LGTM!The function logic is correct, and the implementation is accurate. Generating a tag for the store and calling
dps_store_dump_internalwith the tag and store is the appropriate way to dump the DPS store to storage.api/plgd/unittest/plgd_dps_provision_cloud.cpp (16)
1-17: License header looks good!The file includes the standard Apache License 2.0 header with the correct copyright notice and disclaimers.
19-34: Header includes look good!The necessary header files are included in a logical order, with the project-specific headers first, followed by the external library headers.
35-39: Google Test includes look good!The necessary Google Test header files are included for writing the unit tests in this file.
41-45: C++ standard library includes look good!The necessary C++ standard library header files are included in alphabetical order, which is a good practice.
47-47: Constant definition looks good!The
kDeviceIDconstant is defined with a value of 0, following the Google C++ Style Guide naming convention for constants.
49-106: Test fixture class looks good!The
DPSProvisionCloudWithServerTestclass is well-structured and follows the Google Test framework conventions. The setup and teardown methods are used to initialize and clean up the test environment, and the utility methods are used to perform common operations in the test cases.
108-147: Test case looks good!The
HandleSetCloudResponseFailtest case is well-structured and covers a good range of failure scenarios for thedps_handle_set_cloud_responsefunction. The test case uses the Google Test assertions to verify the expected behavior and the utility methods to set up the test environment and encode the payload.
149-223: Test case looks good!The
HandleSetCloudResponsetest case is well-structured and covers a good range of success scenarios for thedps_handle_set_cloud_responsefunction. The test case uses the Google Test assertions to verify the expected behavior and the utility methods to set up the test environment and encode the payload.
225-246: Test case looks good!The
HasCloudConfigurationtest case is well-structured and covers a good range of scenarios for thedps_has_cloud_configurationfunction. The test case uses the Google Test assertions to verify the expected behavior and the utility methods to set up the test environment and clear the cloud servers.
248-298: Test case looks good!The
SetCloudHandlertest case is well-structured and covers a good range of scenarios for thedps_set_cloud_handlerfunction. The test case uses the Google Test assertions to verify the expected behavior and the utility methods to set up the test environment and encode the payload.
300-310: Test case looks good!The
SetCloudEncodeSelectedGatewayFailtest case is well-structured and covers a good range of failure scenarios for thedps_provisioning_set_cloud_encode_selected_gatewayfunction. The test case uses the Google Test assertions to verify the expected behavior and the utility methods to set up the test environment.
312-336: Test case looks good!The
SetCloudEncodeSelectedGatewaytest case is well-structured and covers a good range of success scenarios for thedps_provisioning_set_cloud_encode_selected_gatewayfunction. The test case uses the Google Test assertions to verify the expected behavior and the utility methods to set up the test environment and clear the cloud servers.
338-347: Test case looks good!The
SetCloudEncodePayloadFailtest case is well-structured and covers a good range of failure scenarios for thedps_provisioning_set_cloud_encode_payloadfunction. The test case uses the Google Test assertions to verify the expected behavior and the utility methods to set up the test environment.
349-355: Test case looks good!The
SetCloudEncodePayloadtest case is well-structured and covers the success scenario for thedps_provisioning_set_cloud_encode_payloadfunction. The test case uses the Google Test assertions to verify the expected behavior and the utility methods to set up the test environment.
357-368: Test case looks good!The
SetCloudFailtest case is well-structured and covers the failure scenario for thedps_provisioning_set_cloudfunction when the device is not in the RFNOP state. The test case uses the Google Test assertions to verify the expected behavior and the utility methods to set up the test environment.
370-378: Test case looks good!The
SetCloudtest case isapi/plgd/device-provisioning-client/plgd_dps_pki.c (10)
51-57: LGTM!The function correctly initializes the PKI configuration with a default expiring limit of 1 hour.
59-103: LGTM!The function correctly generates and sends a CSR to the provisioning service. It handles errors gracefully and sets up TLS for secure communication. The code is well-structured and follows a logical flow.
112-118: LGTM!The function correctly maps the certificate state enum values to their corresponding string representations. It uses an assertion to ensure that the input
statevalue is within the valid range.
127-150: LGTM!The function correctly validates a certificate based on its validity period and the current time. It handles the case where the current time cannot be retrieved and uses the
dps_pki_certificate_is_expiringfunction to check if the certificate is expiring. The code is well-structured and follows a logical flow.
180-218: LGTM!The function correctly replaces the certificates for a device. It handles the case where the credential resource cannot be found and sets the credentials to a stale state before applying the new credentials. It tracks if any credentials were replaced or removed and closes TLS connections accordingly. The code is well-structured and follows a logical flow.
226-246: LGTM!The function correctly schedules the renewal of certificates based on the calculated renewal interval. It handles the case where the interval calculation fails gracefully and ensures that the renewal interval is not less than the specified minimum interval. The code is well-structured and follows a logical flow.
287-294: LGTM!The function correctly retries the replacement of credentials. It retrieves the retry delay and increments the retry count before checking the credentials and scheduling the renewal. The code is well-structured and follows a logical flow.
296-345: LGTM!The function correctly handles the response from the provisioning service for replacing credentials. It performs various checks and actions based on the response code and payload, such as replacing the certificates, checking the credentials, and scheduling the renewal. It retries the replacement if the response is invalid or the replacement fails, and forces reprovisioning if the retry fails. The code is well-structured and follows a logical flow.
347-368: LGTM!The function correctly attempts to renew the certificates by sending a CSR request to the provisioning service. It handles the case where the CSR request fails and schedules a retry for the renewal. It updates the provisioning status and last error accordingly. The code is well-structured and follows a logical flow.
399-406: LGTM!The function correctly sets the expiring limit for certificates. It asserts that the input
ctxpointer is not null to prevent dereferencing a null pointer and logs the new expiring limit value for debugging purposes. The code is well-structured and follows a logical flow.
|
Device Provisioning Service (DPS) Integration
This pull request introduces a comprehensive Device Provisioning Service (DPS) to the IoTivity-Lite framework, enabling devices to securely and efficiently connect to cloud services with minimal manual intervention. The DPS automates the provisioning process, managing device credentials, ownership, and cloud configurations seamlessly.
Key Features
1. Automatic Device Provisioning
2. Secure PKI Implementation
3. Robust Retry Mechanism
4. Extensive Logging and Debugging Support
OC_LOG_COMPONENT_DEVICE_PROVISIONINGfor DPS-specific logs.5. Comprehensive Testing Suite
Benefits for External Developers
Detailed Overview of Changes
api/plgd/device-provisioning-client/containing the core DPS implementation.api/plgd/unittest/covering various DPS functionalities.CMakeLists.txtand workflow files to include new build options and configurations for DPS.Additional Information