-
Notifications
You must be signed in to change notification settings - Fork 225
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
Clarify how end-users can know the expected value of resourceUri in a VSA #1212
Comments
I wonder if we want to steer clear of prescribing how artifacts are named / identified? Maybe what we ought to do is highlight this needs to be consistent between the producer and the consumer, perhaps via out of band mechanisms? I could see being prescriptive problematic in cases where an existing scheme exists and there's interest in just plugging that in.
|
I don't think we need to mandate anything, but we can probably suggest?
Yeah a separate issue would be good. |
Makes sense! I think suggesting some ways (such as what you have about it matching the download location of the artifact) is fine and we could add a note that ultimately it just needs to be consistent between the producer and the consumer? |
When verifying VSAs consumers are expected to match the resourceUri with the 'expected value' but the spec doesn't currently indicate how that expected value is to be determined. In this change we suggest the resourceUri be set to the URI the consumer will fetch the artifact from. If it's set to something else the producer MUST tell the user how to determine the expected value. fixes slsa-framework#1212 Signed-off-by: Tom Hennen <[email protected]>
In #1191 @zachariahcox says
On
I think this really boils down to better define (or suggest) how the resourceUri should be set.
Internally we prefer that the resourceUri match (or be derivable from) the URI used to fetch the artifact being verified. The consumer knows "I'm fetching binary X. Let me make sure says the binary I got is approved to be X".
Reading the existing draft recommendations this way of using the
resourceUri
is implicit. Making it explicit would be helpful.The text was updated successfully, but these errors were encountered: