This issue tracks the implementation part of kubernetes/release#2383

Goal is to add the file signing logic to the sign package:

Unit tests have to be written as well.

Our git package has several calls to the git package. In order to be able to use our binaries in leaner container images (ie distroless) we need to write alternatives to some of its functions to pure go, and drop the calls to the git binary.

As per the email sent to kubernetes-dev[1], please create a SECURITY_CONTACTS
file.

The template for the file can be found in the kubernetes-template repository[2].
A description for the file is in the steering-committee docs[3], you might need
to search that page for "Security Contacts".

Please feel free to ping me on the PR when you make it, otherwise I will see when
you close this issue. :)

Thanks so much, let me know if you have any questions.

(This issue was generated from a tool, apologies for any weirdness.)

[1] https://groups.google.com/forum/#!topic/kubernetes-dev/codeiIoQ6QE
[2] https://github.com/kubernetes/kubernetes-template-project/blob/master/SECURITY_CONTACTS
[3] https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance-template-short.md

This issue tracks the implementation part of kubernetes/release#2383

Goal is to add the signature verification logic for files to the sign package:

Unit tests have to be written as well.

If an image is not signed but has an sbom attached, passing it to sign.IsSigned() will return a false positive.

Can be rproduced with this reference :
gcr.io/ulabs-cloud-tests/supply-chain-demo@sha256:97fa9dd10904972265ca625373490ceed4066062d50063b910b020b80fdd7f20

# Download its signature
cosign download signature gcr.io/ulabs-cloud-tests/supply-chain-demo@sha256:97fa9dd10904972265ca625373490ceed4066062d50063b910b020b80fdd7f20
Error: no signatures associated with gcr.io/ulabs-cloud-tests/supply-chain-demo@sha256:97fa9dd10904972265ca625373490ceed4066062d50063b910b020b80fdd7f20
main.go:46: error during command execution: no signatures associated with gcr.io/ulabs-cloud-tests/supply-chain-demo@sha256:97fa9dd10904972265ca625373490ceed4066062d50063b910b020b80fdd7f20

# Download its SBOM:
cosign download sbom gcr.io/ulabs-cloud-tests/supply-chain-demo@sha256:97fa9dd10904972265ca625373490ceed4066062d50063b910b020b80fdd7f20
Found SBOM of media type: text/spdx
SPDXVersion: SPDX-2.2
DataLicense: CC0-1.0
SPDXID: SPDXRef-DOCUMENT
DocumentName: github.com/puerco/supply-chain-demo
DocumentNamespace: http://spdx.org/spdxpackages/github.com/puerco/supply-chain-demo
Creator: Tool: ko 0.11.0
....

This issue tracks the implementation part of kubernetes/release#2383

Goal is to add the container image signing logic to the sign package:

Unit tests have to be written as well.

We recently added a GitHub action job to e2e test the image signing: https://github.com/kubernetes-sigs/release-sdk/blob/main/test/e2e/sign_test.go

Goal is to do the same for file signatures.

@kubernetes-sigs/release-engineering I think this is a good first issue to get in touch with the code base. Is there anyone who want to work on this?

Part of kubernetes/enhancements#3031

please see sigstore/sigstore#384 for context

How do we approach this problem?

We should update our implementation to work with the cosign v2 module, which is a breaking change compared to v1.

This issue tracks the implementation part of kubernetes/release#2383

Goal is to implement integration tests for the whole sign package as well as running them for every PR via prow.

This issue tracks the implementation part of kubernetes/release#2383

Goal is to add the signature verification logic for container images to the sign package:

Unit tests have to be written as well.

What would you like to be added:

Our signing library should implement signing of in-toto attestations

Why is this needed:

We need to build our own attestation signing code for three main reasons:

1. Signing our provenance attestations during the release process
2. Being able to attest of image promoter runs via a signed attestation
3. Making sure we can produce general purpose code and tools that other projects in the kubernetes org (and elsewhere) can leverage to generate attestation and build attesting features into other projects.

/kind feature

It seems that we need to pass reference to apiRecord initializer, i.e.

	result := []*github.RepositoryTag{}
-	record := apiRecord{Result: result}
+	record := apiRecord{Result: &result}

As per the email sent to kubernetes-dev[1], please create a SECURITY_CONTACTS
file.

The template for the file can be found in the kubernetes-template repository[2].
A description for the file is in the steering-committee docs[3], you might need
to search that page for "Security Contacts".

Please feel free to ping me on the PR when you make it, otherwise I will see when
you close this issue. :)

Thanks so much, let me know if you have any questions.

(This issue was generated from a tool, apologies for any weirdness.)

[1] https://groups.google.com/forum/#!topic/kubernetes-dev/codeiIoQ6QE
[2] https://github.com/kubernetes/kubernetes-template-project/blob/master/SECURITY_CONTACTS
[3] https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance-template-short.md

We can (TTL) cache the transports as well as the information if an image has a signature available or not. This way we can lookup the cache on signature verification:

Omit parsing the reference multiple times:

Reuse the transport for digest lookup:

We can also add a new API to batch verify multiple images in parallel.

API users like promo-tools can then pass around the signer to keep the information available during application lifecycle.

Refers to kubernetes-sigs/promo-tools#637

GitHub API supports conditional requests using ETag and If-None-Match. By using gregjones/httpcache, this will reduce GitHub API rate limit quota consumption when local cache is still "current" — particularly useful in release notes workflow for release team when generating both markdown and JSON in one sitting.

What happened:

Cannot build release-sdk commands without pulling in MPL-licensed projects not in the CNCF allowlist.

go mod why github.com/hashicorp/go-retryablehttp shows this path to github.com/hashicorp/go-retryablehttp which is MPL-licensed and not included in the CNCF allowlist:

# github.com/hashicorp/go-retryablehttp
sigs.k8s.io/release-sdk/sign
github.com/sigstore/cosign/cmd/cosign/cli/rekor
github.com/sigstore/rekor/pkg/client
github.com/hashicorp/go-retryablehttp

https://github.com/cncf/foundation/blob/main/license-exceptions/

https://github.com/cncf/foundation/blob/main/allowed-third-party-license-policy.md#cncf-allowlist-license-policy

cncf/foundation#138

What you expected to happen:

No dependencies on MPL-licensed projects not explicitly allowlisted

How to reproduce it (as minimally and precisely as possible):

run go mod vendor to see code actually used/linked by release-sdk and observe go-retryablehttp code is required to build.

The SignedObject object returned when signing and verifying images/artifacts signed with the sign package is currently empty. We should put some information about the signed artifact in that object, so consumers can use it for validation or exposing that information to users.

We can include information such as:

• SHA/digest of the signed image/artifact
• Link to the signature (.sig) file

Eventually, we might want to include other information as needed.