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.
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
Make unsafe uses of
Verify
function explicit / makeVerify
options safe by default #3Make unsafe uses of
Verify
function explicit / makeVerify
options safe by default #3Changes from 2 commits
3b4f23e
91f6fc3
06f8f08
c24c5e7
e00c64c
643a681
3fc2f32
11ccc70
f8a40f9
392c5e5
8dc24e5
650a0e4
340d95e
975b16c
6f268a1
fc8568c
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Don't we need to fail if no identities are passed? Or will verify unsafe fail if the set of identities is empty/nil?
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.
Good catch! No harm in enforcing it in both spots, actually.
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.
I think it's confusing to have so many ways of specifying
CertificateIdentity
. Should the user callverify.WithCertificateIdentity
, or pass it in toVerify*
(or both?)Ideally, there would be one way for the user to specify this information.
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.
Yeah, there should probably only be one way, for security products the API complexity should be minimal. Would it make sense to open an issue or GDoc for a discussion of the API for sigstore-go? Having an orthogonal API is crucial IMO.
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.
Okay, so another idea @phillmv and I discussed 1-1: instead of having
Verify*
functions, go back to having oneVerify
function, but have it take arguments likeinsecureWithoutArtifactIsOkay
orinsecureWithoutCertificateIdentityIsOkay
. ThenVerify
can look at the policy options, and if the the policy option is missing it can check if the correspondinginsecure*
option was passed.That way there's one way to specify the certificate identity, and you still support broad use cases, and you're still requiring the developer type
insecure
.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.
Yes, and, what if they're just a positional
ArtifactPolicyConfigurator
/IdentityPolicyConfigurator
, so we don't have to change any of the existing logic / add new interfaces?i.e.
and
and the existing logic stays the same.
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.
hrm maybe it'd be like,
Verify(entity, ArtifactPolicyConfigurator, IdentityPolicyConfigurator…)
so you can be like,
Verify(entity, WithArtifact(), WithCertIdentity(), WithCertIdentity()…)
The only thing it forecloses is the ability to add new policy enforcement options in the future.
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.
If we care for extensibility, for not have an options struct? Very simple to work with, and can easily extend the struct in the future without braking the API (i.e parameters added/removed). That is if course as long as the struct can be created with sensible defaults. I'm personally not a fan of the functional config pattern, even though I know it's popular in the Go world.
But @phillmv 's latest suggestion
Looks good I think.
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.
Had a little chat with @kommendorkapten, and maybe an options struct is the way. Something like:
This would preserve the option of extending policy in the future, for example, maybe adding the ability to enforce a predicate type?
Barring any objections, I think I'll try whipping this up!
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.
OK, I've gone ahead and implemented this.