specification
specification copied to clipboard
theupdateframework
Incomplete information (and inconsistent behaviour) about dealing with custom metadata matching
Sometimes, we need to check targets metadata from different sources, and make sure that the metadata from all sources matches. There are two broad cases where this is necessary: Multi-role delegations (TAP-3), and multi-repository consensus (TAP-4 use case 3).
In both cases, the TAP specifies that only the non-custom metadata must match, but does not provide any guidance about what to do with custom metadata in case it differs.
The reference implementation of the client exhibits inconsistent behaviour between the two cases: in the multi-repo (TAP-4) case, it creates directories for each repository and saves the complete targets metadata from each; custom metadata is not checked. In the multi-role (TAP-3) case, it finds a consensus group according to the specified behaviour, then returns and saves only the metadata (custom and non-custom) from the highest-priority role in the consensus group (based on the standard pre-order DFS).
I'd like to solve this with a new TAP adding an optional mustMatch field to custom targets metadata. If that field is present (and the implementation complies with the new TAP), it simply treats anything inside mustMatch just like versions and hashes: if it doesn't match, the verification fails.
Of course, this approach doesn't solve the problem of what to do with non-matching custom metadata outside the mustMatch field, but I think that this is less of a problem once there's an option to explicitly declare within the metadata what parts are important for matching. Depending on their needs, implementations could then make their own choices.
This issue/proposal came up because of work on Uptane: in Uptane, we use multi-repository consensus to direct specific automotive ECUs to install updates. In actuality, we should be verifying that certain custom metadata fields match (release counter and hardware ID), but we also have custom metadata fields that by definition can only appear in the director repository's metadata (ECU identifier for the specific ECU that should install the update).
Okay, I'd like to discuss this with you, @Marina Moore [email protected], and @Trishank Kuppusamy [email protected] (if he has time).
We had discussions about a design similar to this in the past when adding the custom metadata field. I want to be sure we're able to capture the issue and solve this in a general enough way that we're not adding a MustMatch2 field in the near future (for 2 of 3 parties needed to match, etc.). However, we also don't want to add features that aren't needed. So let's discuss and think about how best to do this.
On Thu, Apr 4, 2019 at 11:18 AM Jon Oster [email protected] wrote:
I'd like to solve this with a new TAP adding an optional mustMatch field to custom targets metadata. If that field is present (and the implementation complies with the new TAP), it simply treats anything inside mustMatch just like versions and hashes: if it doesn't match, the verification fails.
Of course, this approach doesn't solve the problem of what to do with non-matching custom metadata outside the mustMatch field, but I think that this is less of a problem once there's an option to explicitly declare within the metadata what parts are important for matching. Depending on their needs, implementations could then make their own choices.
This issue/proposal came up because of work on Uptane: in Uptane, we use multi-repository consensus to direct specific automotive ECUs to install updates. In actuality, we should be verifying that certain custom metadata fields match (release counter and hardware ID), but we also have custom metadata fields that by definition can only appear in the director repository's metadata (ECU identifier for the specific ECU that should install the update).
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/theupdateframework/specification/issues/41#issuecomment-479941546, or mute the thread https://github.com/notifications/unsubscribe-auth/AA0XDx7yfERcntYfrOCZrpDn8vezoKnRks5vdhfEgaJpZM4cdCnf .
Happy to discuss. Should we schedule a meeting sometime early next week?
Sure, how about 2PM Monday?
Anything we all should read / prep for the meeting?
On Fri, Apr 5, 2019 at 12:11 PM Trishank K Kuppusamy < [email protected]> wrote:
Happy to discuss. Should we schedule a meeting sometime early next week?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/theupdateframework/specification/issues/41#issuecomment-480333723, or mute the thread https://github.com/notifications/unsubscribe-auth/AA0XDyPAtOg99ouv90WG-ZMitXd8SQtSks5vd3XNgaJpZM4cdCnf .