Docker Official Image packaging for golang
BSD 3-Clause "New" or "Revised" License

My company uses anonymous pulls from the Docker Hub registry and, unfortunately, regularly runs into the Docker Hub rate limit on pulls. Is there any chance that the golang image could be written also to another registry like so that all my Dockerfiles that start with

FROM golang:latest as builder

can be changed to point to Quay or whereever that doesn't such aggressive pull limits?

I like the small size of the Alpine image but within some project I really miss full blown features (like /dev/log for instance).

In my opinion a Debian Slim image could really by a useful midway between Alpine and full Debian, it would not diminish the right of existence for an Alpine image (can think of loads of uses there) however it would add uses for programs that are just a bit to intensive for the bare-bones Alpine installments but also don't justify a complete Debian installment either (scaling). I've looked up the base templates for the Debian setup and reiterated the request there as well: docker-library/buildpack-deps#99

Please consider adding a Debian like Slim package to the available Golang images. And of course, I do not mind contributing

I'm just wondering, maybe I'm missing something, but is using buildpack-deps actually a good idea?
I've done a short test to compare the image sizes of the official golang versus installing golang starting from plan debian and the difference is quite significant (756MB vs 460MB).
What also surprised me is that python is also installed - which is actually a dependency of mercurial. Is this actually necessary when running go? Is there a reasoning behind this?


We are using golang-1.19-buster image and there are couple of high security vulnerabilities reported.

We saw the first one was remediated on alpine in docker-library/official-images#12929

Is there a plan to do the same in case of buster also ?

I've copied this Dockerfile and customizing.
It worked last week. However it failed today on this line.

It seems that now alpine docker image has /etc/nsswitch.conf file.

If tha file dones't exist, it works.
However if it exist, test returns 1 and stop.

Can we rebuild golang on latest alpine 3.15.6, 3.16.2 to get CVE-2022-37434 addressed please?
. CVE-2022-37434 (Base Score: [9.8 CRITICAL]):

$ docker pull golang:1.19.0-alpine3.15
1.19.0-alpine3.15: Pulling from library/golang
no matching manifest for linux/amd64 in the manifest list entries

in Aqua security scan on golang:1.18.3-bullseye

it says Installed Resource: coreutils 1.8 is affected by this CVE.

It says this is the command bringing it in:

/bin/sh -c set -eux; 	arch="$(dpkg --print-architecture)"; arch="${arch##*-}"; 	url=; 	case "$arch" in 		'amd64') 			url=''; 			sha256='956f8507b302ab0bb747613695cdae10af99bbd39a90cae522b7c0302cc27245'; 			;; 		'armel') 			export GOARCH='arm' GOARM='5' GOOS='linux'; 			;; 		'armhf') 			url=''; 			sha256='b8f0b5db24114388d5dcba7ca0698510ea05228b0402fcbeb0881f74ae9cb83b'; 			;; 		'arm64') 			url=''; 			sha256='beacbe1441bee4d7978b900136d1d6a71d150f0a9bb77e9d50c822065623a35a'; 			;; 		'i386') 			url=''; 			sha256='72b73da021397a3a1ce182c19d2a890a5346bfe80885d9dd7d1ff04ce6597938'; 			;; 		'mips64el') 			export GOARCH='mips64le' GOOS='linux'; 			;; 		'ppc64el') 			url=''; 			sha256='5d42bd252e7af9f854df92e46bb2e88be7b2fb310cc937c0fe091afd8c4f2016'; 			;; 		's390x') 			url=''; 			sha256='ebb4efddec5bbd22bdd9c87137cb3dd59e874b5dfcf93d00bef351c60d2c7401'; 			;; 		*) echo >&2 "error: unsupported architecture '$arch' (likely packaging update needed)"; exit 1 ;; 	esac; 	build=; 	if [ -z "$url" ]; then 		build=1; 		url=''; 		sha256='0012386ddcbb5f3350e407c679923811dbd283fcdc421724931614a842ecbc2d'; 		echo >&2; 		echo >&2 "warning: current architecture ($arch) does not have a compatible Go binary release; will be building from source"; 		echo >&2; 	fi; 		wget -O go.tgz.asc "$url.asc"; 	wget -O go.tgz "$url" --progress=dot:giga; 	echo "$sha256 *go.tgz" | sha256sum -c -; 		GNUPGHOME="$(mktemp -d)"; export GNUPGHOME; 	gpg --batch --keyserver --recv-keys 'EB4C 1BFD 4F04 2F6D DDCC  EC91 7721 F63B D38B 4796'; 	gpg --batch --keyserver --recv-keys '2F52 8D36 D67B 69ED F998  D857 78BD 6547 3CB3 BD13'; 	gpg --batch --verify go.tgz.asc go.tgz; 	gpgconf --kill all; 	rm -rf "$GNUPGHOME" go.tgz.asc; 		tar -C /usr/local -xzf go.tgz; 	rm go.tgz; 		if [ -n "$build" ]; then 		savedAptMark="$(apt-mark showmanual)"; 		apt-get update; 		apt-get install -y --no-install-recommends golang-go; 				export GOCACHE='/tmp/gocache'; 				( 			cd /usr/local/go/src; 			export GOROOT_BOOTSTRAP="$(go env GOROOT)" GOHOSTOS="$GOOS" GOHOSTARCH="$GOARCH"; 			./make.bash; 		); 				apt-mark auto '.*' > /dev/null; 		apt-mark manual $savedAptMark > /dev/null; 		apt-get purge -y --auto-remove -o APT::AutoRemove::RecommendsImportant=false; 		rm -rf /var/lib/apt/lists/*; 				rm -rf 			/usr/local/go/pkg/*/cmd 			/usr/local/go/pkg/bootstrap 			/usr/local/go/pkg/obj 			/usr/local/go/pkg/tool/*/api 			/usr/local/go/pkg/tool/*/go_bootstrap 			/usr/local/go/src/cmd/dist/dist 			"$GOCACHE" 		; 	fi; 		go version

Alpine image version 3.16.1 has been released and it addresses 2 security vulnerabilities.
Hence, I request that the relevant go alpine 3.16 image also be upgraded.

golang:1.17.8-alpine came with the git executable - presumably to accommodate go get - but golang:1.18-alpine does not - presumably because of the breaking change to go get that accompanied the new version.

In line with the upstream supported versions policy, I would like to suggest adding a tag (that could e.g. be called prev or previous, but I'm open to other names as well) that would always identify the second-most recent minor release. This would complement the latest tag to allow CI pipelines to always test the two currently-supported go releases.

To give a concrete example, as of the day of writing the most recent go release (and the one identified by latest) is 1.17.1, and the proposed prev tag would identify go 1.16.8.

  • When 1.17.2 is released, prev would still identify 1.16.8
  • When 1.16.9 is released, prev would identify 1.16.9
  • When 1.18 is released, latest would identify 1.18 and prev would identify 1.17.x (where x would be the current 1.17 patch version at the time 1.18 comes out).

Outside of the scope of this issue, this could potentially be extended in the future with the next tag (to identify RCs) and tip (for the head of the go master branch), again for the sake of being able to have CI pipelines run against the most recent go RC or head, respectively.

I have an arm64 Ubuntu 18.04.3 LTS os, 4.15.0-70-generic #79-Ubuntu SMP Tue Nov 12 10:36:10 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux.
Run this script:

docker run -it golang:1.16-alpine3.14 sh -c '
apk add build-base binutils-gold
mkdir /plugin 
cd /plugin
cat > greeter.go <<'EOF'
package main

import (
        _ "plugin"

func main() {
        fmt.Println("Hello, world")

go mod init plugin-demo
echo run plugin demo=====; echo
go run greeter.go

In the command go run greeter.go, it only reports signal: segmentation fault (core dumped)

# sudo docker run -it --rm golang:latest 
root@a1b6bf79fa04:/go# go version
go version go1.17.5 linux/amd64

The alpine images come with 2.4 MB in /root/.cache/go-build:

$ docker run -it --rm golang:1.17-alpine du -d0 -h /root/.cache/go-build
2.4M	/root/.cache/go-build

The Debian images don't have this:

$ docker run -it --rm golang:1.17 du -d0 -h /root/.cache/go-build       
du: cannot access '/root/.cache/go-build': No such file or directory

Not sure if this is actually intended or if it is just unneeded weight in the alpine images.

When are the docker images for golang v1.17.9 expected to be released?

> docker run --rm golang:1-alpine go version
go version go1.17.5 linux/amd64
> docker image inspect golang:1-alpine --format "{{.ID}}"