• Diff for "LTS/TestSuites/golang"

Limited security support

https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#golang-static-linking
https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#golang-static-linking

• 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.

https://go-team.pages.debian.net/packaging.html#_library_or_binary_library_packages

• 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 suite, 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: Teams/DebianGoTeam/2020/GoEcosystemIssues#stable_updates_.28through_security_update_or_point_release.29

Finding reverse build dependencies

(stretch or later)

stretch:

dose-ceve --deb-native-arch=amd64 -r golang-go -T debsrc \
    debsrc:///var/lib/apt/lists/XXX_debian_dists_stretch_main_source_Sources \
       deb:///var/lib/apt/lists/XXX_debian_dists_stretch_main_binary-amd64_Packages \
  | grep-dctrl -n -s Package '' | sort -u

jessie:

dose-ceve --deb-native-arch=amd64 -r golang-go -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-1664-1 causing heartbleeder/0.1.1-2+deb8u1 and aptly/0.8-3+deb8u1 (source uploads)

• Debian 9.13 includes numerous go-based packages rebuilds through binNMUs (not visible in source package), e.g. heartbleeder/0.1.1-5+b3 and mongo-tools/3.2.11-1+b3

• Debian 10.3 rebuilds debos/1.0.0+git20190123.d6e16be-1+b1 for non-security issue (bin-nmu 946467)

• CVE-2020-9283 resulting in DLA-2402-1 (golang-go.crypto), DLA-2453-1 (restic), DLA-2454-1 (rclone) and DLA-2455-1 (packer)

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.

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$' .

# 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

# 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