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

Handling failure to verify latest time #189

Open
lorchrob opened this issue Dec 6, 2023 · 4 comments
Open

Handling failure to verify latest time #189

lorchrob opened this issue Dec 6, 2023 · 4 comments

Comments

@lorchrob
Copy link

lorchrob commented Dec 6, 2023

To my reading, sections 3.1.1.1 and 3.1.1.3 seem to offer diverging advice as to how a primary ECU should handle a failure to verify the latest time from an external time source. In 3.1.1.1, it says “If it [primary ECU] fails to meet this [verification] criteria, discard the response and continue the procedure without an updated time”. However, 3.1.1.3 says “If any check fails, the ECU SHOULD NOT overwrite its current attested time, but SHOULD jump to the last step …”.

To make things consistent, any of the following changes could be made:

  • Section 3.1.1.1 could instruct the Primary ECU should jump to the last step to report the error, to match with what 3.1.1.3 says already
  • Section 3.1.1.3 could instruct ECUs to continue without an updated time, to match with what 3.1.1.1 says already
  • Section 3.1.1.3 could instruct only secondary ECUs to jump to the last step, to avoid conflicting with section 3.1.1.1
  • Both sections (3.1.1.1 and 3.1.1.3) could allow both options
  • Anything else that is consistent between the two sections

Any thoughts?

@mnm678
Copy link
Contributor

mnm678 commented Dec 19, 2023

Thanks for the question!

Based on discussion in the Uptane Standards meeting, as the time source is not specified by Uptane, we will leave the choice of what counts as a "fatal" error" of the time source up to the implementation. This can be based on knowledge about the time source (such as reliability, whether there is a backup source of time, etc). We will update this in the text to clarify that if such a fatal error occurs, the update should not continue.

New text ideas:

  • "If all steps are completed without fatal error..."
  • "If the time checking process fails fatally..."

@lorchrob
Copy link
Author

Hi, thanks for the response! I agree that a change in this direction would help disambiguate things. Regarding textual updates, is there anything you need from my end, i.e. drafts of changes? If so, just let me know, otherwise I'm happy to let you guys take it from here 😀

@mnm678
Copy link
Contributor

mnm678 commented Feb 5, 2024

If you are able to draft some text or open a pull request, that'll help this move faster. Thanks!

@tkfu tkfu transferred this issue from uptane/deployment-considerations Feb 27, 2024
@tkfu
Copy link
Member

tkfu commented Feb 27, 2024

I'm transferring this here, as we will archive the separate deployment-considerations repo soon.

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

3 participants