Kleinere Schwachstellen: wandernder Action-Verweis, falsche Beschreibung, doppelter Tag #5

New Issue

2026-09-30T19:28:52+02:00

bk-dev-bot commented

2026-09-30 19:28:52 +02:00

Drei Schwachstellen, die beim Untersuchen von #4 aufgefallen sind. Keine davon ist dringend, alle drei sind klein.

1. `docker/setup-buildx-action@master` ist ein wandernder Verweis

- name: Set up Docker Buildx
  uses: docker/setup-buildx-action@master

@master bedeutet: Jeder Lauf holt den jeweils neuesten Stand. Eine Änderung dort ändert das Verhalten aller Projekte, ohne dass hier etwas angefasst wurde — und der Fehler zeigt sich dann bei einem Aufrufer, der nichts geändert hat.

Das steht im Widerspruch zur Sorgfalt an anderer Stelle: Die README verlangt von Aufrufern ausdrücklich, auf einen Tag statt auf @main zu zeigen, und die übrigen Actions sind gepinnt (actions/checkout@v4, docker/login-action@v3, docker/build-push-action@v5).

Auf eine Hauptversion pinnen, etwa @v3.

2. Die Beschreibung von `platforms` behauptet etwas Falsches

The build stages of all dockerfiles are pinned to the build platform, so an
extra platform only adds its runtime stage, not another compile run.

Für das Dockerfile des ersten Abnehmers stimmt das nicht. Dort ist keine Stufe auf die Build-Plattform gepinnt — bewusst, weil Tailwind v4, lightningcss und der Next-Compiler plattformgebundene Binärmodule mitbringen und ein Cross-Build die falsche Architektur einbauen würde.

Folge: Eine zusätzliche Plattform bedeutet einen vollständigen zweiten Kompilierlauf unter Emulation, nicht nur eine weitere Laufzeitstufe. Gemessen: 72 Sekunden für amd64 allein gegenüber 417 Sekunden für beide Plattformen.

Die Beschreibung gilt offenbar für die Dockerfiles, für die der Baustein ursprünglich geschrieben wurde. Als allgemeine Aussage im geteilten Baustein führt sie in die Irre — sie hat zu einer Fehleinschätzung bei einem Abnehmer beigetragen (dort #28 und #32).

Umformulieren: Es hängt vom jeweiligen Dockerfile ab.

3. Die Tag-Liste erzeugt vier verschiedene Tags, nicht fünf

Es stehen fünf Zeilen da, aber version-number und major.minor.patch ergeben bei einem dreiteiligen Schema denselben Wert:

…:2026.09.1   (aus version-number)
…:2026.09.1   (aus major.minor.patch)

Harmlos — Docker pusht denselben Tag zweimal. Kommentar und Dokumentation sprechen aber von fünf Tags, was beim Nachzählen verwirrt. Entweder die doppelte Zeile streichen oder den Umstand dokumentieren.

Nebenbei: Bei einem Kalenderschema wie YYYY.MM.X sind die mitwandernden Tags :2026 und :2026.09 von zweifelhaftem Nutzen — sie bedeuten „neuestes Image aus diesem Jahr" beziehungsweise „aus diesem Monat". Bei SemVer ergeben sie Sinn, hier kaum. Eine konfigurierbare Tag-Liste wäre die allgemeinere Lösung.

Drei Schwachstellen, die beim Untersuchen von #4 aufgefallen sind. Keine davon ist dringend, alle drei sind klein. ## 1. `docker/setup-buildx-action@master` ist ein wandernder Verweis ```yaml - name: Set up Docker Buildx uses: docker/setup-buildx-action@master ``` `@master` bedeutet: Jeder Lauf holt den jeweils neuesten Stand. Eine Änderung dort ändert das Verhalten aller Projekte, ohne dass hier etwas angefasst wurde — und der Fehler zeigt sich dann bei einem Aufrufer, der nichts geändert hat. Das steht im Widerspruch zur Sorgfalt an anderer Stelle: Die README verlangt von Aufrufern ausdrücklich, auf einen Tag statt auf `@main` zu zeigen, und die übrigen Actions sind gepinnt (`actions/checkout@v4`, `docker/login-action@v3`, `docker/build-push-action@v5`). Auf eine Hauptversion pinnen, etwa `@v3`. ## 2. Die Beschreibung von `platforms` behauptet etwas Falsches ``` The build stages of all dockerfiles are pinned to the build platform, so an extra platform only adds its runtime stage, not another compile run. ``` Für das Dockerfile des ersten Abnehmers stimmt das nicht. Dort ist **keine** Stufe auf die Build-Plattform gepinnt — bewusst, weil Tailwind v4, lightningcss und der Next-Compiler plattformgebundene Binärmodule mitbringen und ein Cross-Build die falsche Architektur einbauen würde. Folge: Eine zusätzliche Plattform bedeutet einen **vollständigen** zweiten Kompilierlauf unter Emulation, nicht nur eine weitere Laufzeitstufe. Gemessen: 72 Sekunden für amd64 allein gegenüber 417 Sekunden für beide Plattformen. Die Beschreibung gilt offenbar für die Dockerfiles, für die der Baustein ursprünglich geschrieben wurde. Als allgemeine Aussage im geteilten Baustein führt sie in die Irre — sie hat zu einer Fehleinschätzung bei einem Abnehmer beigetragen (dort #28 und #32). Umformulieren: Es hängt vom jeweiligen Dockerfile ab. ## 3. Die Tag-Liste erzeugt vier verschiedene Tags, nicht fünf Es stehen fünf Zeilen da, aber `version-number` und `major.minor.patch` ergeben bei einem dreiteiligen Schema denselben Wert: ``` …:2026.09.1 (aus version-number) …:2026.09.1 (aus major.minor.patch) ``` Harmlos — Docker pusht denselben Tag zweimal. Kommentar und Dokumentation sprechen aber von fünf Tags, was beim Nachzählen verwirrt. Entweder die doppelte Zeile streichen oder den Umstand dokumentieren. Nebenbei: Bei einem Kalenderschema wie `YYYY.MM.X` sind die mitwandernden Tags `:2026` und `:2026.09` von zweifelhaftem Nutzen — sie bedeuten „neuestes Image aus diesem Jahr" beziehungsweise „aus diesem Monat". Bei SemVer ergeben sie Sinn, hier kaum. Eine konfigurierbare Tag-Liste wäre die allgemeinere Lösung.

jlab-bot referenced this issue

2026-10-02 01:34:28 +02:00

SonarQube-Analyse als geteilten Baustein aufnehmen #8

Sign in to join this conversation.