laurentsimon

We may also rename this to `externalParameters`, to be consistent with v1.0

@asraa I think you landed some of the features in the check list above, correct?

- [ ] Improve regression tests. I tried using us-west2-docker.pkg.dev/slsa-tooling/example-package-repo/e2e-gcb-tag-main-annotated-slsa3@sha256:87db6d5226440e72f7134b71163df45282127a3f7b0600c946683cb2f43a70a9 in function Test_runVerifyGCBArtifactImage. I used `crane manifest $IMAGE` but the hash calculation does not match: it outputs d8e178223968fd3f4a95826978796e6cb49ed67cb323625dc582475692ee5c7a instead of...

Maven and Python packages are GA https://cloud.google.com/build/docs/release-notes/

Note: Getting the provenance is currently cumbersome: https://cloud.google.com/build/docs/securing-builds/view-build-provenance#view_provenance_for_non-container_artifacts ideally there should be a new command: ```shell gcloud artifacts packages describe example-package-laurentsimon --format json --show-provenance ```

note: https://github.com/slsa-framework/slsa-verifier/issues/550 is relevant here. If we supported only intoto format, then we could easily support provenance for these additional artifacts, without a requirement on *which* gcloud API is used...

Why would users expect example-package to generate "great" provenance? Is it because it serves as example repo? I'm worried with env variables, because they let anyone - not just us...

It would avoid re-generating the examples for the generic container. But there are only a few tests and they use the same image. I'll keep the idea in mind.

We also need to add examples in the CLI tests within this repo

btw, using an env variable works, but we jut need to make use of `GITHUB_REPOSITORY` instead of creating our own: ```golang // The trusted builders needs to build themselves at...