GoReleaser version floats on "~> v2" in the job that signs releases

Offen Anfängerfreundlich
  • Stimmt etwas nicht?
#324 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
2/5
Geschätzter Aufwand
1-3 Stunden
Anfängerfreundlichkeit
66/100
Issue-Typ
Refactoring
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
github-actions, go, yaml
Bereich
ci-cd, release

Rechercherichtung

Beginne in .github/workflows/go.yml: Die Schritte goreleaser/goreleaser-action in Zeile 249 (snapshot) und Zeile 331 (release) verwenden version: "~> v2", und die Berechtigungen des Release-Jobs stehen etwa in den Zeilen 286-289. Wähle eine genaue GoReleaser-Version und prüfe im Release-Log, auf welche Version sie aktuell aufgelöst wird. Fertig ist, wenn beide Schritte diese Version nennen, das Repository dokumentiert, wie sie angehoben wird, und der Checkout des Release-Jobs persist-credentials: false setzt. Die Methode zum Anheben ist eine Entscheidung der Maintainer, also bestätige sie vor dem Bearbeiten.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

area: release dependencies good first issue severity: low

Summary

Every action and build tool in the workflows is pinned except GoReleaser itself, which resolves to the newest 2.x at run time in both the snapshot and the release job.

Where

  • .github/workflows/go.yml:331
  • .github/workflows/go.yml:249
  • .github/workflows/go.yml:286

Details

Every action is pinned to a commit SHA, and golangci-lint (v2.15.0, go.yml:117), govulncheck (@v1.9.0, go.yml:123), syft and cosign (fixed by their pinned installer actions; the log shows syft v1.54.0) are fixed versions. GoReleaser itself is not: goreleaser/goreleaser-action@a4f02ab... # v7.3.0 is given version: "~> v2" at go.yml:249 (snapshot) and go.yml:331 (release). The release-snapshot log of run 43648865601 shows it resolved at run time: Downloading https://github.com/goreleaser/goreleaser/releases/download/v2.20.2/goreleaser_Linux_x86_64.tar.gz, checked only against checksums.txt from the same release. The release job holds contents: write, id-token: write and attestations: write (go.yml:286-289).

Impact

Whatever GoReleaser v2.x is newest on the day of a tag builds, signs and uploads the release, with nothing reviewed and no Dependabot PR. A new minor that changes or deprecates a config key fails or alters a release that the snapshot run on the previous push passed, and a compromised upstream release would run with the signing identity. It is the one build tool in the release path that is not reproducible from the repository.

Steps to reproduce

Compare go.yml:331 with the Downloading .../goreleaser/releases/download/v2.20.2/... line in job 132612931653's log.

Suggested fix

Pin an exact version (version: v2.20.2) in both steps, and keep it current by hand or with a Dependabot-visible form (a tools go.mod or a comment-driven updater such as Renovate's regex manager; Dependabot's github-actions ecosystem does not read with: version).

Notes

While here: the release job's checkout can set persist-credentials: false; GoReleaser and gh take the token from the environment.

Acceptance criteria

  • Both jobs name an exact GoReleaser version
  • There is a documented way to bump it
  • The release job's checkout does not persist credentials

Getting started

  • Relevant files: .github/workflows/go.yml
  • How to run tests: make test (or go test ./...). Tests must stay hermetic: use -simulate, -simulate-zone or the local DNS test server, never a live domain.
  • Related docs: docs/DEVELOPER_GUIDE.md, docs/ARCHITECTURE.md

Filed by repo-audit/full-audit at d0c56f0. Severity: low. Effort: S. audit-key: dependencies|.github/workflows/go.yml|goreleaser-action.version

Vorherrschende Sprache
Go
Sterne
1
Forks
1
Ø Merge
6 Std. 42 Min.
Gemergte PRs (30 T.)
7

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.