Add OtaChecksumType validation per Matter Spec R1.4.2 #701
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Validate that OtaChecksumType is within the allowed list [1, 7, 8, 10, 11, 12] per IANA Named Information Hash Algorithm Registry (RFC 6920) when OtaUrl is provided. These values correspond to hash algorithms with minimum 256-bit digest length: sha-256, sha-384, sha-512, sha3-256, sha3-384, sha3-512.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Background
The Connectivity Standards Alliance Distributed Compliance Ledger (DCL) does not enforce the Matter Specification requirements for validating OtaChecksumType in OTA Software Image records. The DCL accepts any integer value from 0 to 65535, including reserved values, unassigned values, and weak hash algorithms with less than 256-bit security. According to the Matter Specification, only values [1, 7, 8, 10, 11, 12] representing ≥256-bit hash algorithms (sha-256, sha-384, sha-512, sha3-256, sha3-384, sha3-512) shall be accepted. This may lead to firmware update failures or undefined behavior in downstream OTA Providers and Matter devices that cannot interpret invalid hash algorithm identifiers.
This pull request introduces stricter validation for the
OtaChecksumTypefield in theMsgCreateModelVersionmessage, ensuring that only specific, IANA-approved checksum types are allowed when an OTA URL is provided. It also updates error handling and unit tests to reflect these new requirements.Validation and error handling improvements:
ErrOtaChecksumTypeInvalid, and an associated error constructor to handle cases where the OTA checksum type is not valid. (x/model/types/errors.go) [1] [2]IsValidOtaChecksumTypehelper function to check if a given checksum type is allowed. (x/model/types/messages_model_version.go)ValidateBasicmethod forMsgCreateModelVersionto enforce that the OTA checksum type must be one of the allowed values if an OTA URL is set, returning the new error if validation fails. (x/model/types/messages_model_version.go)Unit test updates:
MsgCreateModelVersion.ValidateBasicto cover invalid and valid OTA checksum types, ensuring proper error handling and coverage for all allowed and disallowed values. (x/model/types/messages_model_version_test.go) [1] [2]