Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How do we handle government updates? #162

Open
pattivacek opened this issue Apr 1, 2020 · 23 comments
Open

How do we handle government updates? #162

pattivacek opened this issue Apr 1, 2020 · 23 comments
Milestone

Comments

@pattivacek
Copy link
Collaborator

Governments and regulatory bodies may require automakers to grant them full control over a vehicle in emergency situations. How can Uptane be extended to allow secure access for such a situation?

This may require two Directors and Image Repositories (one each from the government and the OEM). Delegations are not good enough to solve this, as the government will have a higher authority than the OEM, but the government probably won't want to micromanage OEM's non-emergency updates.

This may be better covered in the Deployment Considerations, and this may build upon uptane/deployment-considerations#4.

Note: this issue is split off from #161 to consider the government emergency use case. Discussion of the non-emergency location-based updates continues on that issue.

@JustinCappos
Copy link
Contributor

Delegations are not good enough to solve this,

I just want to make a minor comment. It is possible to do this with delegations on the same repository, but either the government or OEM will have to control the repository, which may not be desirable / permitted.

@iramcdonald
Copy link

iramcdonald commented Apr 1, 2020 via email

@cameronmott
Copy link

This is an interesting issue, indeed. We will need clarity on whether this is a design requirement or is handled outside of Uptane. My current expectation is that this is outside of Uptane but I'd like to explore the possibilities.

Some complications that I would anticipate that need to be addressed:

  1. Interoperability between OEMs
    If a government agency is to have the ability to override functionality of a vehicle remotely in an emergency situation, it would need to be implemented for multiple OEMs. Are there separate systems for each of the different OEMs? One system that incorporates all of the POUFs and also stores all of the updates for each ECU per OEM?
  2. Extent of "full control"
    Is this a case of fail-operational control where the vehicle's functionality can be adjusted (pull to the side of the road, reduce speed to below 25 MPH at a safe deceleration rate) or fail-safe control where the vehicle comes to a stop. Another option may be triggering a mode that is built-in by the OEM such as a limp-mode or location tether where the vehicle's functionality is restricted by simple rules.

I believe that there are parallels here with fleet vehicle updates (updates that are not necessarily OEM controlled) as well as after-market vehicle updates. It will be important to understand how these may (or may not) play a part in these scenarios.

@jhdalek55
Copy link
Contributor

On the 4/28 Uptane Standards call, it was decided we would put this issue on hold for the time being, pending the deliberations of other standards teams. A discussion of this use case might be appropriate on the Deployment pages if a volunteer wanted to frame such a discussion.

@jhdalek55
Copy link
Contributor

On the 6/9 Uptane Standards call it was decided that though this issue remains on hold in terms of the Standard, we may want to issue a white paper that summarizes the status quo for this issue and current efforts to resolve it.

@jhdalek55
Copy link
Contributor

@patrickvacek or @tkfu ---can we get this issue flagged as a milestone for V.2.0.0?

@pattivacek pattivacek added this to the Uptane 2.0.0 milestone Aug 17, 2020
@pattivacek
Copy link
Collaborator Author

Done.

@jhdalek55
Copy link
Contributor

We can leave this flagged for 2.0.0 for now, but based on discussions at our 12/8 meeting, it is most likely something that may need to wait for an even later version.

@jhdalek55
Copy link
Contributor

Per our 3/16 meeting, it was recommended by @iramcdonald that we add a mention of this issue to the Deployment pages as a way of letting the community know we are aware of this issue. Draft text could be added to "Exceptional Operations" page.

@jhdalek55
Copy link
Contributor

At our 4/13 meeting, it was agreed we should add an "Emerging Issues" page to Deployment Best Practices that would address topics like this one where no definitive solution is on the horizon. PR # 104 opened a file for this page and @jhdalek55 will draft some initial text. In addition to this issue, the text will address Issues #200, #201 and Issue #86 on the Deployment pages.

@jhdalek55
Copy link
Contributor

At the Uptane Standard meeting on 8/3, it was suggested we may add some text about this issue may be added to the Deployment pages. This will focus only on the problems and will not put forward any solutions.

@jhdalek55
Copy link
Contributor

We need a volunteer to ad some text to the Deployment pages on this topic.

@jhdalek55
Copy link
Contributor

Though we have mentioned the issue on the "Emerging Issues" page, it probably should have some text directly addressing it. While I would much prefer this be addressed by someone with more knowledge than I on the subject, I will put together some rough text if several of the group members will give it a careful reading.

@jhdalek55
Copy link
Contributor

@pattivacek ...when you get a chance, can you change the title of this issue to "How do we handle government updates?"

This is per @iramcdonald's comments in the 9/28 Uptane Standard meeting that these updates may not always involve an emergency. Thanks,

@pattivacek pattivacek changed the title How should we handle emergency updates? How do we handle government updates? Sep 29, 2021
@pattivacek
Copy link
Collaborator Author

can you change the title of this issue to "How do we handle government updates?"

Done.

@jhdalek55
Copy link
Contributor

Thanks, Patti.

@jhdalek55
Copy link
Contributor

jhdalek55 commented Oct 9, 2021

PR #118, recently merged in Deployment Best Practices, provides a partial answer to this issue. It does not close out the issue.

@jhdalek55
Copy link
Contributor

Since this issue cannot be resolved at this time, can we make a new label, perhaps PENDING, for issues like this for which cannot say when they answered? I would prefer we did not leave issues like this (#162 #198) labeled "2.0.0" on the repo as it gives the appearance that we did not completed these on-time. Failing that can we leave it posted without a version label at all?

@mnm678 mnm678 modified the milestones: Uptane 2.0.0, Future Nov 23, 2021
@jhdalek55
Copy link
Contributor

On 1-4-22, we reviewed all the open issues to see if any required reframing. After some discussion, we felt that this is clearly stated, and so we will leave it as is.

@jhdalek55
Copy link
Contributor

jhdalek55 commented Jan 31, 2023

After discussing this at the 1/31/23 Uptane Standard meeting, the group felt there is nothing we can specifically address with this issue as it stands. However, this may actually be part of a much larger issue, how to address the needs of fleet operators. Government updates could be one use case, but there are probably more common and addressable ones than this under this umbrella.

@jhdalek55
Copy link
Contributor

Given the discussion we had earlier in the year (see comment above) do we want to close this issue and re-open a new one that embraces this issue as the needs of fleet operators?

@iramcdonald
Copy link

iramcdonald commented Mar 24, 2023 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants