feat(getsops/sops): SLSA provenance

[scop]

https://github.com/getsops/sops/releases

Check List

• Read CONTRIBUTING.md
  • Read OSS Contribution Guide
• All commits are signed
  • This repository enables Require signed commits, so all commits must be signed
• Avoid force push
• Install and execute the package and confirm if the package works well
• Execute cmdx s to scaffold code

[suzuki-shunsuke]

Thank you!

[suzuki-shunsuke]

https://github.com/getsops/sops/releases/tag/v3.8.0

In addition to SLSA Provenance, Cosign was also supported.

Verify checksums file signature
The checksums file provided within the artifacts attached to this release is signed using Cosign with GitHub OIDC. To validate the signature of this file, run the following commands:

Verify artifact provenance
The SLSA provenance of the binaries, packages, and SBOMs can be found within the artifacts associated with this release. It is presented through an in-toto link metadata file named sops-v3.8.0.intoto.jsonl. To verify the provenance of an artifact, you can utilize the slsa-verifier tool:

[scop]

AFAIU SLSA provenance contains everything that the cosign blob signatures have (and some more). Because of that, and because SLSA verification is built in in aqua as opposed to cosign which is a separate install, is there a general benefit of adding cosign if SLSA provenance is available?

I can understand that having both could be nice to have for completeness, as well as if for some reason the user has disabled SLSA verification but has cosign enabled. But I think those are kind of corner cases.

[suzuki-shunsuke]

Good point.
This pr is already closed and this should be discussed in an issue, so I created an issue.

• Discussion: Should aqua verify both SLSA Provenance and Cosign? aqua#3551

SLSA verification is built in in aqua as opposed to cosign which is a separate install

This isn't correct.
aqua installs a binary slsa-verifier.