Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Fermée
  • Quelque chose ne va pas ?
#46 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
68/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
github-actions, go
Domaine
build-system, cli, release

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.
Langage dominant
Go
Étoiles
1
Forks
1
Merge moyen
5 j 2 h
PR mergées (30 j)
3

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de TMHSDigital/subenum

Toutes les issues de TMHSDigital/subenum

Issues similaires

Plus d'issues Go

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.