Support verification of generic builders

[netomi]

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]

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]

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]

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]

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

[laurentsimon]

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

[fmoessbauer]

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]

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

[fmoessbauer]

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]

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