Major For reasons unknown the module version of binaries built from openshift/kubernetes via the hyperkube build have changed from `(devel)` to `v0.0.0` this appears to have happened along the demarcation line of builds that are produced using Go 1.24, however building the binaries locally via `make WHAT=cmd/kube-apiserver` produces yet different results using either Go 1.24 or 1.25. So the suspicion is that this may be something introduced by the build pipeline.
Here's the Go version and module version of the kube-apiserver binary across 4.19.15, 4.19.16, 4.20.0, 4.20.1, and 4.21.0-ec.2.
~ for v in 4.19.15 4.19.16 4.20.0 4.20.1 4.21.0-ec.2; do podman rm container && podman run --replace --name container -it --entrypoint /bin/sleep `oc adm release info ${v} --image-for hyperkube` 5 &sleep 3 && podman cp container:/usr/bin/kube-apiserver . && echo ${v} && go version -m ./kube-apiserver | grep -e k8s.io/kubernetes -e go1.2 && fg; done # output trimmed just a bit for clarity 4.19.15 ./kube-apiserver: go1.23.9 (Red Hat 1.23.9-1.el9_6) X:strictfipsruntime path k8s.io/kubernetes/cmd/kube-apiserver mod k8s.io/kubernetes (devel) 4.19.16./kube-apiserver: go1.23.9 (Red Hat 1.23.9-1.el9_6) X:strictfipsruntime path k8s.io/kubernetes/cmd/kube-apiserver mod k8s.io/kubernetes (devel) 4.20.0./kube-apiserver: go1.24.4 (Red Hat 1.24.4-2.el9) X:strictfipsruntime path k8s.io/kubernetes/cmd/kube-apiserver mod k8s.io/kubernetes v0.0.0-20250925192037-d61639ac10e9+dirty 4.20.1./kube-apiserver: go1.24.4 (Red Hat 1.24.4-2.el9) X:strictfipsruntime path k8s.io/kubernetes/cmd/kube-apiserver mod k8s.io/kubernetes v0.0.0-20251021111528-46835c79ded0+dirty 4.21.0-ec.2./kube-apiserver: go1.24.6 (Red Hat 1.24.6-1.el9_6) X:strictfipsruntime path k8s.io/kubernetes/cmd/kube-apiserver mod k8s.io/kubernetes v0.0.0-20251017171021-7884145a7524+dirty
Finally, here's the output from a local build built using `make WHAT=cmd/kube-apiserver` this would be the ideal output format as it ensures that security scanners accurately represent at least the upstream version from which we're built on top of. We're aware that many of those tags are missing and I can add them to currently supported versions as soon as we understand why this is happening and know that it won't cause further issues.
go version -m _output/bin/kube-apiserver | grep -e k8s.io/kubernetes -e go1.2 _output/bin/kube-apiserver: go1.24.9 path k8s.io/kubernetes/cmd/kube-apiserver mod k8s.io/kubernetes v1.33.6-0.20251028225526-debdebd535dc
The reason we're asking about this is that the v0.0 is causing security scanner tools to flag these binaries as being vulnerable to items long since fixed in kube 1.21 for instance.