Tom Hennen

[Here's a proposal](https://docs.google.com/document/d/10B-8R3NIGvcPuoIhqb-p18oOe78m6SiiukfE7NyvnYQ/edit#) for attestations that the VCS can issue to attest to the security posture of the source in a given repo. Join [slsa-discussion](https://groups.google.com/g/slsa-discussion) to get access to the...

I agree with @dn-scribe that it probably doesn't make sense to combine vuln scans and code reviews in a single type. I also agree that leaning on the VCS (or...

> > Is the desire to have a generic way to determine if a given commit was reviewed regardless of the VCS/review system used? > > In my mind, I...

Would it make any sense to start with some definition of the policies we'd like to evaluate on these predicates?

That is a pretty exhaustive list of things that could go into an attestation. Do we have any thoughts about who the audience for the attestations would be? Would the...

That makes sense to me. One thing that could be clarified is what scope each of those statements apply to. E.g. does 'code-review' apply to just a single change while...

Gotcha. So I think it would be pretty easy to create a predicate type that indicate the various items mentioned above. It should probably be clear about what the scope...

> we would include the attestor in the object because we want that id to be explicit and in authenticated data Yes exactly. We take the same approach with builder.id...

We discussed inclusion of https://github.com/in-toto/attestation/issues/136 at today's maintainers meeting. While we understand the use case combining a lot of predicates into one statement can be an anti-pattern in that it...

Oh note that it may be entirely possible to handle this just by defining a new predicateType, which won't block on versioning.