DockerCLI/dockerfiles/Dockerfile.vendor

43 lines
1.0 KiB
Docker
Raw Normal View History

# syntax=docker/dockerfile:1
update go to go1.20.5 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: https://github.com/golang/go/compare/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. Signed-off-by: Sebastiaan van Stijn <github@gone.nl> (cherry picked from commit 3b8d5da66b608e5458cd44c2b271dce38c323df2) Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2023-06-14 07:25:57 -04:00
ARG GO_VERSION=1.20.5
ARG ALPINE_VERSION=3.17
ARG MODOUTDATED_VERSION=v0.8.0
FROM golang:${GO_VERSION}-alpine${ALPINE_VERSION} AS base
RUN apk add --no-cache bash git rsync
WORKDIR /src
FROM base AS vendored
Dockerfile.vendor: update GOPROXY to use default with fallback Use the default proxy, to assist with vanity domains mis-behaving, but keep a fallback for situations where we need to get modules from GitHub directly. This should hopefully help with the gopkg.in/yaml.v2 domain often going AWOL; #14 245.9 gopkg.in/yaml.v2@v2.4.0: unrecognized import path "gopkg.in/yaml.v2": reading https://gopkg.in/yaml.v2?go-get=1: 502 Bad Gateway #14 245.9 server response: Cannot obtain refs from GitHub: cannot talk to GitHub: Get https://github.com/go-yaml/yaml.git/info/refs?service=git-upload-pack: write tcp 10.131.9.188:60820->140.82.121.3:443: write: broken pipe curl 'https://gopkg.in/yaml.v2?go-get=1' Cannot obtain refs from GitHub: cannot talk to GitHub: Get https://github.com/go-yaml/yaml.git/info/refs?service=git-upload-pack: write tcp 10.131.9.188:60820->140.82.121.3:443: write: broken pipe From the Go documentation; https://go.dev/ref/mod#goproxy-protocol > List elements may be separated by commas (,) or pipes (|), which determine error > fallback behavior. When a URL is followed by a comma, the go command falls back > to later sources only after a 404 (Not Found) or 410 (Gone) response. When a URL > is followed by a pipe, the go command falls back to later sources after any error, > including non-HTTP errors such as timeouts. This error handling behavior lets a > proxy act as a gatekeeper for unknown modules. For example, a proxy could respond > with error 403 (Forbidden) for modules not on an approved list (see Private proxy > serving private modules). Signed-off-by: Sebastiaan van Stijn <github@gone.nl> (cherry picked from commit 6458dcbe5140d8fbf71e60da24f3355d3f1852ba) Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2023-06-02 07:12:35 -04:00
ENV GOPROXY=https://proxy.golang.org|direct
RUN --mount=target=/context \
--mount=target=.,type=tmpfs \
--mount=target=/go/pkg/mod,type=cache <<EOT
set -e
rsync -a /context/. .
./scripts/vendor update
mkdir /out
cp -r vendor.mod vendor.sum vendor /out
EOT
FROM scratch AS update
COPY --from=vendored /out /out
FROM vendored AS validate
RUN --mount=target=/context \
--mount=target=.,type=tmpfs <<EOT
set -e
rsync -a /context/. .
git add -A
rm -rf vendor
cp -rf /out/* .
./scripts/vendor validate
EOT
FROM psampaz/go-mod-outdated:${MODOUTDATED_VERSION} AS go-mod-outdated
FROM base AS outdated
RUN --mount=target=.,rw \
--mount=target=/go/pkg/mod,type=cache \
--mount=from=go-mod-outdated,source=/home/go-mod-outdated,target=/usr/bin/go-mod-outdated \
./scripts/vendor outdated