-
Notifications
You must be signed in to change notification settings - Fork 2
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
Instead of continuing when Attestation data is not present, this shou… #6
base: main
Are you sure you want to change the base?
Conversation
…ld be failing with a clear error. Otherwise it will incorrectly return success
@sudo-bmitch PTAL - I think the previous change inadvertently marked the request successful, where as this should fail, just not crash like it was. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Thinking through this, the for loop on 35 feels like the issue. We continue if the uuid's don't match. It's a success if the for loop is empty or only has bad uuid entries. It fails if any one of the entries is bad. And I'm guessing we want logic that succeeds if any entry matches, and fails for all other scenarios. |
Here's a diff of the option I'm thinking of:
However, that does trigger an error with the validation we're trying to run. Looking at the log entry, Attestation is allowed to be nil and is not marked as a required field, so I suspect we want to validate based on the Body which is required: Looking at that body field in at least one failing command, it appears to be base64 encoded data, but since it's an empty interface, we probably can't assume it will always be the same format:
TL;DR we can prevent the false positives, but I think there's still work to validate when Attestation is nil to prevent false negatives. |
…ld be failing with a clear error. Otherwise it will incorrectly return success