[proposal] google/go-containerregistry as replacement for regclient library to use cosign oci package

[hown3d]

trafficstars

Is your feature request related to a problem? Please describe. Fetching artifacts from container images is currently done by accessing the registry with regclient. Accessing the SBOM and attestation references requires manually constructing the registry references with string interpolation.

Describe the solution you'd like Cosign, one of the pioneers of storing security artifacts inside OCI registries, offers a library to access SBOM, signature, and attestation references by using their oci package, which tightly integrates with google/go-containerregistry.

Therefore, using google/go-containerregistry as the main library to access OCI content on registries should benefit in the long run when integrating with the sigstore landscape.

Describe alternatives you've considered An alternative library to use would be oras-go, which would not fix the problem described above.

Additional context google/go-containerregistry is spread much wider and adopted by more projects than the oras-go or regclient library. It is used as a direct dependency by 411 repositories.

deps.dev shows that in the newest version, regclient is adopted by 4 repositories (including guac), while oras-go has 18 direct adoptions.

Open for discussion This issue should be used to discuss this change moving to google/go-containerregistry and the impact on this project. It came up from a discussion in #1449.

[naveensrinivasan]

cosgin has too many dependencies https://deps.dev/go/github.com%2Fsigstore%2Fcosign/v1.13.1/dependencies and must be factored into the decision making.

That is one of the reasons https://github.com/sigstore/sigstore-go was built.

[hown3d]

cosgin has too many dependencies https://deps.dev/go/github.com%2Fsigstore%2Fcosign/v1.13.1/dependencies and must be factored into the decision making.

That is one of the reasons https://github.com/sigstore/sigstore-go was built.

sigstore-go seems to be more for verifying the signatures/attestations instead of fetching them from container images at the moment. I'm not sure what the roadmap looks like for the library.

[ridhoq]

Hi @hown3d, thanks for creating the issue. It sounds like the intent behind this change is to move towards "integrating with the sigstore landscape". If GUAC were to collect signatures from other sources such as Notary, should we tightly couple to the OCI package for sigstore?

[ridhoq]

FYI @sudo-bmitch who may also have input here

[sudo-bmitch]

Accessing the SBOM and attestation references requires manually constructing the registry references with string interpolation.

If I understand the concern correctly, storing metadata using the cosign tags is considered a temporary state until OCI is able to GA the subject/referrers work. Once that's done, sigstore has indicated they intend to transition to using the subject/referrers method to store their metadata (it's already supported with experimental flags), same at notation has been doing, along with various other projects.

regclient isn't going to add all of the signing libraries of cosign to replicate its functionality (as mentioned, that adds a lot of dependencies). So if verification of the signatures is needed, I'd understand if you wanted to go that direction.

[pxp928]

cosgin has too many dependencies https://deps.dev/go/github.com%2Fsigstore%2Fcosign/v1.13.1/dependencies and must be factored into the decision making. That is one of the reasons https://github.com/sigstore/sigstore-go was built.

sigstore-go seems to be more for verifying the signatures/attestations instead of fetching them from container images at the moment. I'm not sure what the roadmap looks like for the library.

@hown3d Sorry for the delay in responding to this issue (Kubecon NA just ended). So currently we have a separate verifier that works with the parsers in order to verify the signatures. As @ridhoq stated, we do not want to couple the verification of the signature with the collectors such that other "verifiers" (such as notary) can be added as needed. The "verifiers" are still a WIP and there is an initial implementation of sigstore that needs to be updated.

[pxp928]

It would be good to move to the current verifier to start using https://github.com/sigstore/sigstore-go as mentioned by @naveensrinivasan.