Skip to content
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

Open
TomHennen opened this issue Oct 21, 2024 · 3 comments · May be fixed by #1220
Open

Clarify how end-users can know the expected value of resourceUri in a VSA #1212

TomHennen opened this issue Oct 21, 2024 · 3 comments · May be fixed by #1220
Assignees
Labels

Comments

@TomHennen
Copy link
Contributor

In #1191 @zachariahcox says

On

Threat: Replace the package with one built using an unofficial CI/CD pipeline
that does not build in the correct way.

Mitigation: Verifier requires provenance showing that the builder matched an
This is a great place to expand. Thanks for starting this.

I think the mitigation for this is essentially:

  • Have a way to know what "correct" looks like for this resourceUri.

    • If you have access to such a thing, you can verify the artifact yourself by inspecting the data in the provenance attestation.
    • If you do not, you must rely on a VSA with access to definition of "correct"
    • If you do not have either, you cannot know whether the artifact is safe to use, even if it was SLSA Build L3

I think in the example below "build L3" is conflated with "built in the correct way" which is not necessarily the case.
https://github.com/slsa-framework/slsa/pull/1191/files#r1806779663

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.

@adityasaky
Copy link
Member

adityasaky commented Oct 24, 2024

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.

Side note: I wonder if we want to also provide guidance about the resourceUri and how it matches / relates to the attestation's subject's name or uri. Can a VSA apply to multiple artifacts? At the subject layer it seems to be yes but not within the predicate's resourceUri? Happy to file a separate issue for this. Opened #1219 for this.

@TomHennen
Copy link
Contributor Author

I don't think we need to mandate anything, but we can probably suggest?

Side note: I wonder if we want to also provide guidance about the resourceUri and how it matches / relates to the attestation's subject's name or uri. Can a VSA apply to multiple artifacts? At the subject layer it seems to be yes but not within the predicate's resourceUri? Happy to file a separate issue for this.

Yeah a separate issue would be good.

@adityasaky
Copy link
Member

I don't think we need to mandate anything, but we can probably suggest?

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?

@TomHennen TomHennen self-assigned this Oct 24, 2024
TomHennen added a commit to TomHennen/slsa that referenced this issue Oct 24, 2024
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]>
@TomHennen TomHennen linked a pull request Oct 24, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: 🆕 New
Development

Successfully merging a pull request may close this issue.

2 participants