-
Notifications
You must be signed in to change notification settings - Fork 57
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
Checking attestors for duplicates #332
Closed
Closed
Changes from all commits
Commits
Show all changes
13 commits
Select commit
Hold shift + click to select a range
53649d3
added all imports
ChaosInTheCRD a9c82b0
fixing go sum
ChaosInTheCRD c7e725e
changing go-witness back for now, makes more sense
ChaosInTheCRD e828be0
moved witness to using new in-toto/go-witness module
ChaosInTheCRD 98b06f1
adding change to test now following newer version of policy
ChaosInTheCRD 9514e0a
running docgen as changes found from use of new module
ChaosInTheCRD da03354
checking for duplicate attestors declared on `witness run`
ChaosInTheCRD 7955bff
updating go mod
ChaosInTheCRD f208908
Merge branch 'main' into checking-new-attestors
ChaosInTheCRD 7377a06
updating go sum
ChaosInTheCRD 4ccf0d5
removing autobuild for declarative in CodeQL
ChaosInTheCRD 0fce4c8
Merge branch 'main' into checking-new-attestors
ChaosInTheCRD 12564de
Merge branch 'main' into checking-new-attestors
ChaosInTheCRD File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Do we want to fail at the first attestor, or would it be better to continue trying to add the subsequent attestors and give the user an error with all failed attestors?
My question is, because we do it for duplicated ones, we warn the user. Is there any reason to fail at the first attestors?
Example: Let's say the user sends attestors
a, b, c, d, e, f
a
andc
are duplicatedd
return error.b
,e
,f
are good.We will warn the user about
a
, includeb
, warn the user aboutc
, and fail ine
,Feel free to ignore if I'm missing some context here :)
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.
hmmm, so I don't feel really strongly either way, but I suppose you're asking 'if failing to create an attestor fails, should we fail?'.
If the
AddAttestor
function fails, I think we should stop. I don't think awitness run
should continue if not all the expected attestations are going to be generated. I think that I am confident that the command should fail on failed attestor creation.Going back to the original problem that this PR removes, I tackled this by warning the user that they have repeated themselves / declared an attestor that has already been declared (e.g., by default). Possibly it could be a better practice to just fail in this situation. After all, it may be better to be simple and say "you've duplicated attestor defintion, please fix the invocation".
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.
@jkjell @mikhailswift, any thoughts?
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.
To throw a 🔧 in the conversation, I create #340 to capture thoughts around a future idea that may be counter to this one.
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.
@jkjell I think that what you mention in #340 makes sense, but I don't think it collides too much with this due to the fact that (at least for now) there is no reason why you would want to run an attestor more than once. I think that we should merge this for now, and we could potentially change it in future if/when we implement #340.