search

in-toto / attestation-verifier

Prototype in-toto attestation verifier based on ITE-10 and ITE-11 layouts
Other
15 stars 7 forks source link

Added guac support in verifier #39

Open Yaxhveer opened 4 months ago

Yaxhveer commented 4 months ago

The PR allow us to retrieve attestations (slsa and sbom) from the GUAC GraphQL server and proceed with the verification of the attestations. We can save these retrieved attestations using the --save-attestation flag. To specify which step's attestation should be retrieved from the GraphQL server, the fromGuac field has been added to the layout structure. Setting this field to true within a step indicates that the attestation will be fetched from the GUAC server. We can define a subject in the layout, which will be used to retrieve the relevant attestation. The subject field is optional, and users can also pass it though the command line using the --subject/-s flag. The subject can be a package (purl) or an artifact (alg:hash). Layout structure:

steps:
  - name: "build"
    fromGUAC: true
    subject: "pkg:guac/generic/bin/foo"

Command: attestation-verifier -l layouts/layout.yml -a test-data -s pkg:guac/generic/bin/foo Also the attestation step name is matched against it origin file name. Once the attestation is retrieved, it is wrapped in a DSSE envelope, which would requires a private key. One can either provide the key as a PEM file, or the verifier can generate a private key. This private key is then added as a functionary for the respective step. After being encapsulated in a DSSE envelope, the attestations are passed through the ITE-10 verifier, where the artifact rules are verified.

PradyumnaKrishna commented 4 months ago

Most of utilities are expanding GUAC's functionality. such as parsing predicates from GUAC model, which does not directly relates to the attestation-verifier. Perhaps we could discuss reaching out to GUAC maintainers to integrate these utilities into the GUAC API?

What are your thoughts on this, @SantiagoTorres?

Yaxhveer commented 4 months ago

Hey @PradyumnaKrishna, the guac related utility are actually taken from guac known query command. It is just used to retrieve slsa and sbom from graphql server.

PradyumnaKrishna commented 4 months ago

Yes, You did a great job there! I was thinking that if the utilities were integrated into the GUAC library, it would allow us to easily retrieve the parsed Predicate according to the specifications. It could potentially benefit others using the GUAC library, although I'm not entirely sure.

trishankatdatadog commented 3 months ago

Hi both: before you go too far, would it be worthwhile to have a chat about what you are trying to do, and what the best approach might be? 🙂

Yaxhveer commented 3 months ago

Hey @trishankatdatadog, I am currently contributing as an LFX mentee in in-toto for the project to add native support of GUAC in in-toto. Aim of the project is to retrieve attestation from guac graphql server using purl and verify them against layout. Till now I have created slsa and sbom (cdx and spdx) parser and skipping the verification of dsse envelope in verifier.

trishankatdatadog commented 3 months ago

I am currently contributing as an LFX mentee in in-toto for the project to add native support of GUAC in in-toto. Aim of the project is to retrieve attestation from guac graphql server using purl and verify them against layout.

Understood.

Till now I have created slsa and sbom (cdx and spdx) parser and skipping the verification of dsse envelope in verifier.

Before you go too far, we should talk about your approach, though. I'll DM you on Slack, and we'll go from there. Thanks!

trishankatdatadog commented 3 months ago

Actually, I don't see your name on Slack...

Yaxhveer commented 3 months ago

@trishankatdatadog Ok, I will dm you.

marcelamelara commented 2 months ago

Since this PR is still in draft, can we convert this to a draft PR until it's actually ready for review?

Yaxhveer commented 2 months ago

Hey @marcelamelara, the PR is ready for review.

adityasaky commented 2 months ago

Disclaimer: I haven't had a chance to review this PR yet.

Why not simply do all the work of fetching attestations from GUAC and signing them (are they currently unsigned?) outside of attestation-verifier? You could prepare this bundle of attestations however you like, and after that simply call the attestation-verifier unchanged.

True, but there are a lot of places to draw the line. That functionality could be in a separate repo, a separate package with its own main for CLI composability (attestation-fetcher ... | attestation-verifier -l layout.yml), part of the verifier package, etc. I think that keeping this functionality in this repository is fine, especially if it doesn't touch the core verifier package too much. After all, attestation-verifier is meant to be a prototype / sandbox for testing ideas, let's not litter @in-toto with lots of prototype repositories.

While we are interested in whether we should instruct the attestation-verifier how to dynamically fetch and compile a bundle attestations at the time of verification, I don't feel that this PR solves that problem in a general manner. Unfortunately, it only works for GUAC, and it'd be much nicer to have a more general mechanism that works with different attestation storage backends.

I agree we want to make this generic eventually (eg. support for archivista, OCI, etc.) but I don't think we can start with a fully generic solution. In fact, my hunch is that the guac integration is likely to be the most distinct of these backends (eg. less straightforward queries, the fact that attestations are constructed for the query raising questions about whether they're signed, etc.), so exploring that one also is very reasonable to me. We could probably combine our experiences / findings of the guac integration with the experiences integrating witness and archivista to construct the generic mechanism for fetching from attestation storage backends.