update go to go1.20.5, alpine 3.17

[thaJeztah]

go1.20.5 (released 2023-06-06) includes four security fixes to the cmd/go and runtime packages, as well as bug fixes to the compiler, the go command, the runtime, and the crypto/rsa, net, and os packages. See the Go 1.20.5 milestone on our issue tracker for details:

https://github.com/golang/go/issues?q=milestone%3AGo1.20.5+label%3ACherryPickApproved

full diff: golang/go@go1.20.4...go1.20.5

These minor releases include 3 security fixes following the security policy:

• cmd/go: cgo code injection The go command may generate unexpected code at build time when using cgo. This may result in unexpected behavior when running a go program which uses cgo.

  This may occur when running an untrusted module which contains directories with newline characters in their names. Modules which are retrieved using the go command, i.e. via "go get", are not affected (modules retrieved using GOPATH-mode, i.e. GO111MODULE=off, may be affected).

  Thanks to Juho Nurminen of Mattermost for reporting this issue.

  This is CVE-2023-29402 and Go issue https://go.dev/issue/60167.

• runtime: unexpected behavior of setuid/setgid binaries

  The Go runtime didn't act any differently when a binary had the setuid/setgid bit set. On Unix platforms, if a setuid/setgid binary was executed with standard I/O file descriptors closed, opening any files could result in unexpected content being read/written with elevated prilieges. Similarly if a setuid/setgid program was terminated, either via panic or signal, it could leak the contents of its registers.

  Thanks to Vincent Dehors from Synacktiv for reporting this issue.

  This is CVE-2023-29403 and Go issue https://go.dev/issue/60272.

• cmd/go: improper sanitization of LDFLAGS

  The go command may execute arbitrary code at build time when using cgo. This may occur when running "go get" on a malicious module, or when running any other command which builds untrusted code. This is can by triggered by linker flags, specified via a "#cgo LDFLAGS" directive.

  Thanks to Juho Nurminen of Mattermost for reporting this issue.

  This is CVE-2023-29404 and CVE-2023-29405 and Go issues https://go.dev/issue/60305 and https://go.dev/issue/60306.

- What I did

- How I did it

- How to verify it

- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)

[thaJeztah]

Ah, fun;

ERROR: failed to solve: golang:1.20.5-alpine3.16: docker.io/library/golang:1.20.5-alpine3.16: not found

[thaJeztah]

Ah, fun, are we're hitting the regression they mentioned in the release (?);

> [gotestsum 1/1] RUN --mount=type=cache,target=/root/.cache/go-build --mount=type=cache,target=/go/pkg/mod GOBIN=/out GO111MODULE=on go install "gotest.tools/gotestsum@v1.8.2" && /out/gotestsum --version:
#0 1.155 go: downloading golang.org/x/sys v0.0.0-20220715151400-c0bba94af5f8
#0 2.609 go: downloading golang.org/x/sync v0.0.0-20220601150217-0de741cfad7f
#0 2.644 go: downloading golang.org/x/term v0.0.0-20220526004731-065cf7ba2467
#0 3.871 go: downloading golang.org/x/mod v0.6.0-dev.0.20220419223038-86c51ed26bb4
#29 21.95 # runtime/cgo
#29 21.95 In file included from _cgo_export.c:3:
#29 21.95 /usr/include/fortify/stdlib.h:23:15: fatal error: stdlib.h: No such file or directory
#29 21.95 23 | #include_next <stdlib.h>
#29 21.95 | ^~~~~~~~~~
#29 21.95 compilation terminated.

Regression was;

cmd/go: improper sanitization of LDFLAGS

The go command may execute arbitrary code at build time when using cgo. This may
occur when running "go get" on a malicious module, or when running any other
command which builds untrusted code. This is can by triggered by linker flags,
specified via a "#cgo LDFLAGS" directive.

Due to an unfortunate mistake, this change will break the use of "#cgo
LDFLAGS" directives when using -compiler=gccgo. Most people using
gccgo or GoLLVM use the cmd/go that is distributed with those tools,
and that is unaffected. Therefore, we will fix this in the next minor
release. The current minor releases 1.20.5 and 1.19.10 are
unfortunately broken for some cases when using gccgo or GoLLVM. Our
apologies for the mishap. Thanks to Jeffrey Tolar for spotting the
problem.

Ian

[thaJeztah]

moved the first commit to #4354 to make sure it's not the alpine upgrade causing the issue.

[thaJeztah]

...and.... looks like it is;

#17 5.065 # runtime/cgo
#17 5.065 In file included from _cgo_export.c:3:
#17 5.065 /usr/include/fortify/stdlib.h:23:15: fatal error: stdlib.h: No such file or directory
#17 5.065 23 | #include_next <stdlib.h>
#17 5.065 | ^~~~~~~~~~

[thaJeztah]

Looks like alpine 3.17 still works, and latest golang also has a variant for 3.17, so let's pick that for now

[codecov-commenter]

Codecov Report

Merging #4350 (3b8d5da) into master (7d723e2) will not change coverage.
The diff coverage is n/a.

Additional details and impacted files

@@ Coverage Diff @@## master #4350 +/- ##
=======================================
Coverage 59.29% 59.29% =======================================
Files 288 288 Lines 24770 24770 =======================================
Hits 14688 14688 Misses 9198 9198 Partials 884 884