-
Notifications
You must be signed in to change notification settings - Fork 27
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
Comments
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:
|
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 😀 |
If you are able to draft some text or open a pull request, that'll help this move faster. Thanks! |
I'm transferring this here, as we will archive the separate deployment-considerations repo soon. |
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:
Any thoughts?
The text was updated successfully, but these errors were encountered: