go version in images doesn't match local builds

[pit1sIBM]

Type of question

Open question

Question

What did you do?

Hello 👋 I was checking Go version used in the latest tags on quay.io when I noticed master is still using go 1.18.10

❯ docker run --rm -it --entrypoint ansible-operator quay.io/operator-framework/ansible-operator:master version
Unable to find image 'quay.io/operator-framework/ansible-operator:master' locally
master: Pulling from operator-framework/ansible-operator
...
Digest: sha256:8f06dbdd9f3dbcd8c6adca5ae2ddb22f74c906d35e7fcdfe55f2ff4ff7f46d2d
Status: Downloaded newer image for quay.io/operator-framework/ansible-operator:master
ansible-operator version: "v1.28.0-4-g82b28e85", commit: "82b28e85707d2448e1cdd385ce0444ea16e5eb75", kubernetes version: "v1.26.0", go version: "go1.18.10", GOOS: "linux", GOARCH: "amd64"

What did you expect to see?

I expected to see the same as when built locally, which is version 1.19.8

root@84c4c93d83ad:/tmp/operator-sdk# go version $(which ansible-operator)
/go/bin/ansible-operator: go1.19.8
root@84c4c93d83ad:/tmp/operator-sdk# ansible-operator version
ansible-operator version: "82b28e85", commit: "82b28e85707d2448e1cdd385ce0444ea16e5eb75", kubernetes version: "v1.26.0", go version: "go1.19.8", GOOS: "linux", GOARCH: "amd64"

What did you see instead? Under which circumstances?

Expected to see the same Go version used, however I see that the golang image in the Dockerfiles were not updated when the go.mod was updated

First time opening an issue and wasn't sure if this was intentional or not. I can update the images and docs if not.

Environment

Operator type:

Kubernetes cluster type:

$ operator-sdk version

$ go version (if language is Go)

$ kubectl version

Additional context

Go 1.18.10 has some CVEs tied to it that are resolved in the 1.19 stream so there may be an additional benefit to updating

[pit1sIBM]

@OchiengEd I opened a PR here (if it helps): #6398

[OchiengEd]

@pit1sIBM Thank you for the heads up on the PR. Definitely helps

[simararneja]

May I know what is blocking to deliver the PR connected to this issue ? There are lot of known vulnerabilities with Golang 1.18.

[OchiengEd]

@simararneja I have changed the milestone to v1.30.0. I will try to get some eyes on this as well.

[pit1sIBM]

Thanks all for taking a look, had a quick question that may require a separate issue. Should the images built using the golang image use the registry.redhat.io/rhel8/go-toolset image instead? AFAIK the golang image isn't FIPS-compliant, where the go-toolset image is.

I know previously a workaround was required for FIPS (see #5723) and that was resolved, but perhaps using the toolset image going forward (or tagging a separate image) would be beneficial?