asraa

hey! we are one step closer. I have a "POC" that performs a goreleaser build and creates Sigstore signed SLSA 3 provenance. There's obvious missing parts that I didn't do...

I believe the checks are in the tscommon file.ts now, so I think we have the library, and right now secure-upload-folder and download are using them

Yes! I'm fairly certain it doesn't even have to be a valid JSON of the type we have - i don't think javascript enforced that. Meaning, we could produce some...

I think it is this entire piece https://github.com/slsa-framework/slsa-github-generator/blob/7f9306a166326f33f0aeb3c1a217cedf3fb981c5/.github/actions/generate-attestations/src/attestation.ts#L42 I'm not sure how the type casting to types.Layout works with errors, but basically the idea is that if I add in...

Yes - it was more for robustness for the TRW author to see if they are getting an error.

> I'll be filing another issue to improve the process (so it would be easier to keep this file updated in future) but this bug is just about updating the...

> Originally the thought was that we'd want to use the V1 root, because users could audit that root and check it matches what was publicly signed. Yes - but...

> We should also provide a script to verify a root against V1, handling the incompatibilities. It’ll either need to check out an old version of go-TUF or configure using...

I think a good recomendation is that we can fix this in sigstore/sigstore with a new release, but ideally the new TUF client in sigstore-go would be modeled after the...

No I don't think so: https://github.com/sigstore/sigstore/blob/c28fdeb7e90a0976ce9733308bc5cb7b16239821/pkg/tuf/client.go#L269 Either way, it would be better to close when a test is added.