Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Release linux/amd64 binary is dynamically linked, contradicting the "single static binary" claim

Geschlossen
  • Stimmt etwas nicht?
#46 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
68/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
github-actions, go
Bereich
build-system, cli, release

Rechercherichtung

Start with the release build matrix in .github/workflows/go.yml, especially the build step around line 192, and inspect how its Linux legs compile and name their assets. Check the resulting Linux binaries with file and add a CI assertion that verifies they are statically linked. Done means Linux release assets meet the issue's stated static/stripped criteria and CI catches regressions.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

area: release bug ci priority: high

Why it matters

The repo description, README and site all promise a "single static Go binary". The v0.8.0 subenum-linux-amd64 release asset is actually dynamically linked against glibc (file reports dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2 ... not stripped). It will not run on Alpine/musl, in scratch/distroless images, or on older glibc hosts, which are common pentest/CI environments. Oddly the cross-compiled linux-arm64 asset is static, so behaviour differs by arch.

Evidence

  • .github/workflows/go.yml:192 — the release matrix builds with
    go build -v -buildvcs=false -ldflags "-X main.Version=..." and no CGO_ENABLED=0. The linux/amd64 leg compiles natively on ubuntu-latest, so cgo is on and net links the cgo resolver.
  • No -trimpath and no -s -w, so binaries embed local paths and debug info (larger, not reproducible).
  • -buildvcs=false strips VCS info, so go version -m subenum shows nothing useful for provenance.

Suggested approach

  • Set CGO_ENABLED: 0 in the build step env for all legs.
  • Build with -trimpath -ldflags "-s -w -X main.Version=..."; drop -buildvcs=false in CI (keep it only where .git is absent, e.g. Docker).
  • Add a CI assertion on Linux legs: file subenum-linux-* | grep -q 'statically linked'.
  • (Covered more broadly by the GoReleaser issue, but this one-line fix should ship as a patch release now.)

Done when

  • All Linux release assets report statically linked, are stripped, and CI fails if that regresses.
  • A v0.8.1 patch release replaces the dynamic binary.
Vorherrschende Sprache
Go
Sterne
1
Forks
1
Ø Merge
5 T. 2 Std.
Gemergte PRs (30 T.)
3

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus TMHSDigital/subenum

Alle Issues in TMHSDigital/subenum

Ähnliche Issues

Weitere Issues zu Go

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.