golang¶
Limited security support¶
The Debian infrastructure currently doesn’t properly enable rebuilding packages that statically link parts of other packages on a large scale. Until buster that hasn’t been a problem in practice, but with the growth of the Go ecosystem it means that Go based packages won’t be covered by regular security support until the infrastructure is improved to deal with them maintainably.
If updates are warranted, they can only come via regular point releases, which may be slow in arriving.
Libraries written in Go are packaged for Debian with the only purpose of building other Go programs for Debian. They are specifically not available for users in their regular development workflow. For that, users should use go get.
Elements of decision/triage, considering the static linking issue:
If the reverse-dependencies are not rebuilt, it makes sense not to fix a CVE:
the vulnerability status would be wrong (marked as fixed, but affected in practice)
this would be a time bomb, as regressions may surface later e.g. if a reverse-dependency is rebuilt one year later for a different reason
considering the packagers view above, and the relatively fast evolution of the language, the Go toolchain in Debian is aimed at building Debian dependencies more than compiling user/third-party programs; LTS users may still use LTS golang to rebuild old custom programs though
If the go packagers themselves fixed a CVE through a DSA, it makes sense to follow suit, even if they didn’t rebuild reverse-dependencies
If a past suite (e.g. the previous LTS) fixed it, it makes sense to fix to avoid a regression
See also: stable update
Finding reverse build dependencies¶
Replace golang_binary_package with the package you want to find reverse build-dependencies for, e.g. golang-go or golang-github-prometheus-client-golang-dev
buster/stretch:
dose-ceve --deb-native-arch=amd64 -r $golang_binary_package -T debsrc \
debsrc:///var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_source_Sources \
deb:///var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_binary-amd64_Packages \
| grep-dctrl -n -s Package '' | sort -u
jessie:
dose-ceve --deb-native-arch=amd64 -r $golang_binary_package -T debsrc \
debsrc:///var/lib/apt/lists/XXX_debian_dists_jessie_main_source_Sources \
deb:///var/lib/apt/lists/XXX_debian_dists_jessie_main_binary-amd64_Packages \
| grep-dctrl -n -s Package '' | sort -u
See https://manpages.debian.org/stable/dose-extra/dose-ceve.1.en.html#EXAMPLES
Maintainer snippet: excludes source-only/arch-all packages, but misses some packages such as ‘aptly’ (missing/incomplete Built-Using field):
apt-cache dumpavail | \
grep-dctrl \
-F Built-Using 'golang-1.7' -a \
'(' --not -F Architecture all ')' \
-s Source,Package,Version
Example non-obvious affected packages (no Go dependencies in binary packages): heartbleader, toxiproxy
- Example reverse-dependencies rebuilds:
DLA-3455-1 for golang-go.crypto/buster, causing 18 rebuilds (source uploads)
Debian 10.3 rebuilds debos/1.0.0+git20190123.d6e16be-1+b1 for non-security issue (bin-nmu #946467)
DLA-2402-1 for golang-go.crypto/stretch, resulting in multiple subsequent DLAs: DLA-2442-1 (obfs4proxy), DLA-2453-1 (restic), DLA-2454-1 (rclone), DLA-2455-1 (packer), DLA-2527-1 (snapd)
Debian 9.13 includes numerous go-based packages rebuilds through binNMUs (not tracked in source package), e.g. heartbleeder/0.1.1-5+b3 and mongo-tools/3.2.11-1+b3
DLA-1664-1 for golang, causing heartbleeder/0.1.1-2+deb8u1 and aptly/0.8-3+deb8u1 (source uploads)
- Limitations / TODO:
How to find packages affected by a golang standard library, e.g. packages that use net/http or archive/zip and could be rebuilt following Debian 11.2/golang-1.15.
Building¶
Part of the golang-1.11 test suite requires the USER variable,
which is removed by debuild as part of environment sanitization.
If you use debuild, make sure you work-around using:
debuild -e USER ...
There’s a work-around in 1.11.6-1+deb10u5, and upstream fixed at 3a18f0ecb5 (go1.12), but this may still be needed when recompiling old versions.
ARM64, ARMHF: building golang-1.11 with schroot on the porter boxes
consistently triggers many errors in the test suites that never happen
in the buildds (notably os/signal and TestGdb* from runtime).
ARMHFonARM64: some armhf (32-bit) buildds are running on actual 64-bit host architecture, which may trigger additional build failures, especially when the test is built-and-run with an empty Go cache. Beware when attempting to reproduce issues. See DLA 3395-2.
Run test suite¶
Run/re-run full test suite:
debian/rules override_dh_auto_test-arch
debian/rules override_dh_auto_test RUN_TEST=true # jessie
Run a specific test:
debuild
# Simple case
cd src/pkg/net/url/
go test -v # default to '.'
go test -v -run '^TestParse$' .
# Clean-up
# - Test results:
go clean -testcache
# - Force rebuild:
go clean -cache
# - In doubt:
rm -rf ~/.cache/go-build/
# - Run without caching results (cf. 'go help test')
go test -count=1 ...
# More complex case
cd /.../debian-source-packages/golang-1.x/src/ # src/pkg/ for jessie
rm -rf ../pkg/linux_*/ # Go reuses the .a files there
GOROOT=/.../debian-source-packages/golang-1.x/ PATH=../bin:$PATH go test -v ./net/http/ # not 'net/http/', this would check the system install
GOROOT=/.../debian-source-packages/golang-1.x/ PATH=../bin:$PATH go test -v ./net/http/... # '...' means 'with subdirs'
GOROOT=/.../debian-source-packages/golang-1.x/ PATH=../bin:$PATH go test -v ./net/http/httputil/reverseproxy*.go
GOROOT=/.../debian-source-packages/golang-1.x/ PATH=../bin:$PATH go test -v -list '.*' ./net/http/
# Pass "tags"
GOROOT=/.../debian-source-packages/golang-1.x/ PATH=../bin:$PATH go test -v -tags=osusergo os/user
# Another way for internal test suites:
GOROOT=/usr/src/golang/golang-1.8-1.8.1/ PATH=../bin:$PATH go tool dist test -list
GOROOT=/usr/src/golang/golang-1.8-1.8.1/ PATH=../bin:$PATH go tool dist test -run go_test:cmd/go
# If errors don't make sense:
GOROOT=/usr/src/golang/golang-1.8-1.8.1/ PATH=../bin:$PATH go tool dist test -run go_test:net/http -rebuild
Rdeps availability on build¶
The buildds should pick your updated Go libraries from the security archive for LTS suite, so as soon they are “Installed” in the buildd status.