Description
First off, sorry if this is in the wrong place! I looked for any similar issues, but could not find any, so figured I'd open an issue report here 😄
What version of Go are you using (go version
)?
$ go version go version go1.16.2 linux/amd64
Does this issue reproduce with the latest release?
Yes, using the latest version of the Go 1.16 alpine Docker image (hash 52dbfc81ec12df22e2ab1e7c9c4f4ee3dff73514e56a54924714d29ac03ff791
)
What operating system and processor architecture are you using (go env
)?
go env
Output
$ go env (sorry for the formatting, this is from Jenkins)[2021-04-01T19:44:26.092Z] #19 0.727 GO111MODULE=""
[2021-04-01T19:44:26.092Z] #19 0.727 GOARCH="amd64"
[2021-04-01T19:44:26.092Z] #19 0.727 GOBIN=""
[2021-04-01T19:44:26.092Z] #19 0.727 GOCACHE="/root/.cache/go-build"
[2021-04-01T19:44:26.092Z] #19 0.727 GOENV="/root/.config/go/env"
[2021-04-01T19:44:26.092Z] #19 0.727 GOEXE=""
[2021-04-01T19:44:26.092Z] #19 0.727 GOFLAGS=""
[2021-04-01T19:44:26.092Z] #19 0.727 GOHOSTARCH="amd64"
[2021-04-01T19:44:26.092Z] #19 0.727 GOHOSTOS="linux"
[2021-04-01T19:44:26.092Z] #19 0.727 GOINSECURE=""
[2021-04-01T19:44:26.092Z] #19 0.727 GOMODCACHE="/go/pkg/mod"
[2021-04-01T19:44:26.093Z] #19 0.727 GONOPROXY=""
[2021-04-01T19:44:26.093Z] #19 0.727 GONOSUMDB="mycompany.org/*"
[2021-04-01T19:44:26.093Z] #19 0.727 GOOS="linux"
[2021-04-01T19:44:26.093Z] #19 0.727 GOPATH="/go"
[2021-04-01T19:44:26.093Z] #19 0.727 GOPRIVATE=""
[2021-04-01T19:44:26.093Z] #19 0.727 GOPROXY="mycompany.org"
[2021-04-01T19:44:26.093Z] #19 0.727 GOROOT="/usr/local/go"
[2021-04-01T19:44:26.093Z] #19 0.727 GOSUMDB="sum.golang.org"
[2021-04-01T19:44:26.093Z] #19 0.727 GOTMPDIR=""
[2021-04-01T19:44:26.093Z] #19 0.727 GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
[2021-04-01T19:44:26.093Z] #19 0.727 GOVCS=""
[2021-04-01T19:44:26.093Z] #19 0.727 GOVERSION="go1.16.2"
[2021-04-01T19:44:26.093Z] #19 0.727 GCCGO="gccgo"
[2021-04-01T19:44:26.093Z] #19 0.727 AR="ar"
[2021-04-01T19:44:26.093Z] #19 0.727 CC="gcc"
[2021-04-01T19:44:26.093Z] #19 0.727 CXX="g++"
[2021-04-01T19:44:26.093Z] #19 0.727 CGO_ENABLED="1"
[2021-04-01T19:44:26.093Z] #19 0.727 GOMOD="/dev/null"
[2021-04-01T19:44:26.093Z] #19 0.727 CGO_CFLAGS="-g -O2"
[2021-04-01T19:44:26.093Z] #19 0.727 CGO_CPPFLAGS=""
[2021-04-01T19:44:26.093Z] #19 0.727 CGO_CXXFLAGS="-g -O2"
[2021-04-01T19:44:26.093Z] #19 0.727 CGO_FFLAGS="-g -O2"
[2021-04-01T19:44:26.093Z] #19 0.727 CGO_LDFLAGS="-g -O2"
[2021-04-01T19:44:26.093Z] #19 0.727 PKG_CONFIG="pkg-config"
[2021-04-01T19:44:26.093Z] #19 0.727 GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build3087407697=/tmp/go-build -gno-record-gcc-switches"
What did you do?
We have vulnerability scanning on all Docker images as a part of our deployment pipeline, and even an image with no Go projects in it was flagged as being affected by the crypto/ssh vulnerability fixed in this commit. Here is the Snyk vulnerability page.
This is the flagged Docker image:
Dockerfile
FROM golang:1.16-alpine@sha256:3411aef9ae9cb0fe3534fe2a4d1a9745d952d9a5ed1e20a11ff10549731156e8 # Installing dependencies RUN apk upgrade --no-cache && \ apk add --no-cache \ bash \ # Install Git git \ nodejs \ npm \ make \ gcc musl-dev python3-dev libffi-dev openssl-dev \ python3 \ py3-pip && \ echo "*** setup python ***" && \ ln -sf python3 /usr/bin/python && \ pip install wheel && \ rm -rf /root/.cache/pip
As an aside, is there a way to force a Docker image to install a newer version of a built-in module? I tried doing a go get -u golang.org/x/crypto/ssh
, however it did not fix the problem 😞
Any help would be greatly appreciated! Just checking to make sure it's not because of something silly I've done 😄
Activity
seankhliao commentedon Apr 1, 2021
I don;t see this for either of the base images?
3411aef9ae9cb0fe3534fe2a4d1a9745d952d9a5ed1e20a11ff10549731156e8
52dbfc81ec12df22e2ab1e7c9c4f4ee3dff73514e56a54924714d29ac03ff791
or with your provided dockerfile either
Dockerfile
ruffoa commentedon Apr 1, 2021
Hmm, it's possible our vulnerability scanner logic in our builds is broken, unfortunately I'm unable to test it locally due to not having access to Snyk. Thanks for looking into this for me though, guess I'll have to go through our internal logic again 😆