Guidelines for using repository mapping metadata to have more than one image repository, and how to check that metadata in the more complicated cases

[jhdalek55]

Though the Uptane Standard supports implementations containing one Director and one Image repository, it does not negate adoption by legacy systems utilizing multiple repositories. In this case, repository mapping metadata will need to designate the repositories required to sign the targets metadata for images. What would such metadata look like, and what else would be entailed in the deployment of such a configuration?

[jhdalek55]

Some quick background--This issue emerged from discussions centered around the closed issue #53 on the Standards repo. We need a volunteer to develop some initial text to address this issue, preferably someone who has worked with multiple repositories.

[zabbal]

uptane/uptane-standard#53 - are you referring to this issue?

[jhdalek55]

Yes. That is the relevant issue.

[allen-cain-tm]

Below is proposed wording to address the issue of "supporting Uptane on legacy system using multiple repositories".

In cases where a previous OTA systems exist, there may be a need to integrate these systems with Uptane-compliant OTA systems.
For these use cases there are several topics to consider (some of which are outside the scope of this document) including but not limited to: API security, server-to-server communication, cloud security (if applicable), version management across OTA systems, software inventory management across OTA systems, in-vehicle client compatibility, human machine interface (HMI) for both server-side and in-vehicle, forced rollback use cases, interdependence between OTA updates, vehicle-to-server communication security, etc.

For simplicity, this document only addresses high-level architecture compatibility, presumed to be necessary, between the previous OTA system and the new Uptane-compliant OTA system (henceforth "previous" and "new").

1. The previous and new OTA systems need to establish an agreed upon software asset inventory database.
   Ideally, the software asset inventory is only stored on one OTA system.
   However, this can be accommodated to be stored on both OTA systems if required.
   In the event that asset inventory is handled in multiple locations, the implications of doing so should be considered before proceeding.
   These implications include but are not limited to: adding across multiple databases, removing from multiple databases, updating across multiple databases, etc.

2. The previous and new OTA systems need to establish an agreed upon method for version management.
   Ideally, the version management for a specific ECU is only stored on one OTA system.
   However, this can be accommodated to be stored on both OTA systems.
   In the event that the version management for a specific ECU is handled in multiple locations, the implications of doing so should be considered before proceeding.
   These implications include but are not limited to: updating ECU versions across databases, performing OTA campaigns with the latest ECU version, etc.

3. The OTA systems shall have an agreed upon method for determining what updates are included in a single OTA campaign.
   Ideally, OTA campaigns and their update contents are controlled by a single OTA system.
   However, including content across multiple OTA systems (i.e., including updates from both the old and new OTA system in a single OTA campaign) can be accommodated.
   In the event that OTA campaigns accommodate updates from multiple locations, the implications of doing so should be considered before proceeding.
   These implications include but are not limited to: malicious compromise of single OTA system results in potential malicious firmware pushed to ECU, rollback conditions on specific update contents within the update campaign, etc.

[pattivacek]

I think we're talking about two different things here. Not that this text isn't usable, but this seems to be about transitioning from a legacy system to Uptane. My understanding was that we need text to cover an Uptane system with multiple Image repositories. I seem to recall that it was generally agreed that multiple Director repositories was not recommended.

Two drafts of the text that were considered for the standard to cover this case can be found in uptane/uptane-standard#99 and uptane/uptane-standard#106. Ultimately the decision was made to keep only the simple case in the standard, and that was merged in uptane/uptane-standard#111. However, we might be able to pull some of the good bits of the two PRs that were closed to start something here.

[jhdalek55]

So, should we cobble a bit from all the above and put it out there as a starting point? I'd be happy to take a stab at this, but it might be more effective is someone with a bit more technical expertise than me took a run at it.

[jhdalek55]

As we begin work towards a stable PDF of the deployment pages, do we want to address this issue, or is it best if we just keep this in limbo and wait to see if the community lets us know its something we have to address?

[tkfu]

So, to clarify, this issue was opened to write guidelines for how repository mapping metadata can be used in the case where you need to use multiple image repositories. It's not particularly related to transitioning from legacy repositories.

To do list here:

• Explain the extra checks that a vehicle would need to do in the presence of repository mapping metadata that indicated more than one image repository
• Briefly give an example of where you might want to use multiple image repos
• Explain that the actual images don't necessarily need to live on the Image repo; they can be on a CDN or be sourced from different repos using download URLs specified in custom targets metadata fields. (Because in almost all cases this will be preferable to actually using multiple image repos.)

[jhdalek55]

Thanks for the change in topic.

[jhdalek55]

We welcome input on this issue here or on the mailing lists and will discuss this issue on our phone call of 3/31,

[jhdalek55]

Can we perhaps initiate some conversation on this issue before we discuss it on our 4/14 call?

[jhdalek55]

Again, just following up on open issues. I know we have discussed this in connect with other issues on the Standard , including #162, but I don't recall if we agreed on any resolution.

[mnm678]

In discussion on the 9/1 call, we decided to point tap 4 for anyone interested in using multiple image repositories. In a future version of the deployment considerations we can revisit this issue as needed.

[tkfu]

@mnm678 I added an explanation of how to use multiple different download locations without actually using multiple image repos in #49. It also briefly references TAP-4. It doesn't address anything about the situations where you might actually want to have multiple image repos, though.

[jhdalek55]

Are we flagging this for 2.0.0 to resolve the larger issue?

[jhdalek55]

Per our meeting on 9/1, it was decided that this issue should be flagged for inclusion into a separate deployment page to go with for Version 2.0.0. The thinking was making such a change now might be of questionable usefulness. right now. @tkfu or @patrickvacek can you change the milestone here to 2.0.0.?

[pattivacek]

I don't appear to have the rights, but for anyone who does, it should be a trivial thing to do.

[jhdalek55]

As this is an issue with no immediate resolution in site, it was decided in the 4/13 Uptane Standard meeting to leave this issue open, but change its status to "deferred."

[jhdalek55]

We have not discussed this issue since April 2021. Can we decide if its a question we should continue to ask, and if so, when we might reasonably have an answer? Since no discussion has presented itself in a year and a half, it seems to me its not an issue for which a response is handy or even wanted at this point.

[jhdalek55]

This is a possible use case in our look at transition issues. We need to open a new issue dealing with this and other issues. So we should close this out.

[jhdalek55]

During discussion at the 2/14 Standards meeting, we decided that this topic would be better addressed as a use case in a larger examination of transition issues. As such, we have closed this issue and opened Issue #145 to collect other use cases and challenges. Multiple repositories will be one use case.