asraa

That sounds right! The package was removed from the final version of intoto released. There should be some way of indicated `direct` only with the `allow` option with dependabot https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#allow...

Hmmmm maybe I see what you're saying with the library issue. I think this would be fixed with the next version of slsa-verifier 2.3.0 right? This updates the library code...

Dupe of https://github.com/slsa-framework/slsa-verifier/issues/21, I'll close that one. > We also have an idea of supporting cosign OPA policies, which may be an easier way forward to support various builders Yeah,...

> This would be a new flag that mirrors the https://slsa.dev/spec/v0.1/requirements requirements. It would need to be flexible enough. Having a single flag with sub-options is pretty cool, it leaves...

Good point. It seems like we probably do the right thing. We currently set the provenance printed statement to the v01IntotoStatement. This doesn't include the human readable summary in the...

We can test out that slsaPredicate was NOT included (but note, it IS signed over). I think the signing algorithm/PAE difference is a spec incompatibiilty..

I think I misunderstood you: multiple provenances actually meant multiple in the lists of provenance. Got it! Ignore my first statements.

Oh, it's possible! In that case, I'll put up a cleanup fix after this patch release.

+1 Are you looking to validate the SLSA 1 provenance against a policy? If so, then using a policy validator is best here. The main responsibility of slsa-verifier is to...

@kpk47 would be good to use as an example for verifying GCB in blog posts