Support verification of generic builders

netomi commented 5 months ago

Right now the slsa-verifier is designed around a closed-world assumption, i.e. it can validate attestations generated by known builders and rejects attestations for unknown builders.

Ideally, there would be a set of generic requirements that must be fulfilled by any SLSA compliant builder which can be verified by the slsa-verifier in order to conclude if the given attestation is valid.

This would help to work on other builders.

laurentsimon commented 5 months ago

Thanks for the issue. @ramonpetgrave64 Can you give an overview of a solution that you'd like to see? We've considered using an internal cue / rego or other policy engine so that users with private builders can more easily integrate new builders in slsa-verifier. Would that be god enough or not?

I think it'd be useful to have one tool to verify many builders, as it improves UX for end-users

netomi commented 5 months ago

I dont have a technical solution in mind as of now, but wanted to create this ticket to raise awareness that we will need some kind of generic way to verify attestations generated from different builders unless you put all the burden to the user to figure out by himself how artifacts with attestations can be verified.

laurentsimon commented 4 months ago

Would something like an interface https://github.com/slsa-framework/slsa-verifier/blob/main/verifiers/internal/gcb/slsaprovenance/iface/provenance.go help?

Do you imagine some sort of plugin mechanism or a way for developers to extend the slsa-verifier with a fork where they add their own code, eg via an interface as above?

@ramonpetgrave64

ramonpetgrave64 commented 4 months ago

What kinds of unknown builders are you thinking? Are they still github actions?

laurentsimon commented 4 months ago

They may be builder for CircleCI or others, even private builder. So there are not GitHub based

fmoessbauer commented 3 months ago

I would also like to see this. While the SLSA data formats themselves are generic and pretty well documented, the infrastructure around is quite use-case specific.

I'm considering generating provenance attestation data in KAS. The implementation is quite straight-forward, but testing this is nearly impossible as I can only verify the data with my own tooling. By that, I can't be sure to correctly generate the "statement" and the DSSEv1 "envelope". This makes it impossible to check interoperability. Also a lot of documentation, tooling and end-to-end examples are still based on the in-toto v0.1 spec (link format), which is not very helpful.

For a wider adoption of in-toto / SLSA, it would tremendously help to have a generic tool that works on information passed on the command line:

take at least one artifact file as input (corresponds to "subject")
take a DSSEv1 envelope as input + some params for checking the signature (like a GPG keyid, PEM file, ...)

The tool should check the following:

the signature is correct
the resource descriptors are syntactically valid
the attestation format is a well-known one
For well-known formats, also check if the format is syntactically valid

laurentsimon commented 3 months ago

Will any of you attend the OSS@NA in Seattle next month?

fmoessbauer commented 3 months ago

Will any of you attend the OSS@NA in Seattle next month?

I will be at the co-located "Embedded OSS Summit". Let's meet.

laurentsimon commented 3 months ago

Great. How do we get in touch? Slack? Email?

slsa-framework / slsa-verifier

Support verification of generic builders #734