GPG signed release artifacts/sha256sums

[jcpunk]

What would you like to be added:
Can the binary releases or sha sums be signed with a GPG key?

Why is this needed:
For folks who are pulling down these artifacts, having a signature they can check against would be helpful for verifying the supply chain.

[BenTheElder]

The binary builds are reproducible and cheap to perform.

The sha256 are available for integrity checking of downloads.

We do not have a GPG key and there is not precedent in the Kubernetes project for doing this.

[jcpunk]

There is some mention of SIG Security up at kubernetes/enhancements#3031 but I'm really not super familiar with this whole ecosystem....

[BenTheElder]

That is not GPG signing.

[aojea]

this one kubernetes/release#914

[BenTheElder]

To elaborate: GPG signing things has been a long thread in Kubernetes that has not, as of yet, landed anywhere.

I do not want to sidetrack into developing key management infrastructure or evaluating signing ecosystems ahead of other high-priority issues in Kubernetes that we can directly improve (the KIND maintainers are also Kubernetes maintainers because kind exists first and foremost so SIG Testing can test Kubernetes more easily: https://kind.sigs.k8s.io/docs/contributing/project-scope/, however we do not lead the Release SIG).

If and when the rest of the organization has a better answer for signing binaries, we will consider steps to adopt it.

[BenTheElder]

There is a current thread regarding the dependency on Googlers and Google-internal package signing for Kubernetes' Debian + RPM packages and active recent discussion about how to replace that, but it remains to be seen where that lands and if it's easily reusable. kubernetes/release#913

[BenTheElder]

We're not going to deviate from SIG release on new signing mechanisms, when sigstore signing is mature in Kubernetes we'll look into this route.

As is the binaries are reproducible and it's quick and straightforward to build kind from source.