Verweise der Form #123 im folgenden Text beziehen sich auf die GitHub-Nummerierung, nicht auf die Nummern in diesem Repo. Geschlossene Issues wurden nicht mitgezogen und sind weiterhin nur auf GitHub lesbar.
minecraft-server fehlt weiterhin seccompProfile: RuntimeDefault im Pod-Kontext. Teilmenge von #84 — dort ist es einer der fünf verbliebenen Sonderfälle (neben matrix-synapse, paperless-ngx, samba, teamspeak-server). Dieses Issue existiert, weil das Chart durch die #99-Runde gerade in vier aufeinanderfolgenden Veröffentlichungen steht und der Punkt sonst zwischen ihnen verloren geht.
Stand
Der Trivy-Job meldet bei jedem PR unverändert AVD-KSV-0104 und AVD-KSV-0030. Der Job läuft im Berichtsmodus und wird trotzdem success — er blockiert also nichts und ist leicht zu übersehen.
Bewusst nicht in die #99-Runde mitgenommen: seccompProfile ist eine Laufzeitverhaltensänderung und gehört nicht in einen PR, der Null-Absicherung und Linienwahl nachzieht. Das war die richtige Entscheidung — sie hätte die Nachweise beider Themen vermischt.
Der Grund, warum es hier nicht trivial ist
Bei freesailarr musste der Filter mit echtem Tunnel belegt werden, weil gluetun als root mit NET_ADMIN ein tun-Gerät anlegt. minecraft-server hat eine andere, eigene Frage:
Das Image nutzt gosu, um von root auf uid 1000 herunterzufallen. Ob der Standard-Syscall-Filter das durchlässt, ist zu belegen, nicht anzunehmen.
Der Serverpack-Init-Container (curseforgeServerpack.enabled) läuft im selben Pod-Kontext und würde den Filter mit erben. Er wird von der CI-Fixture nicht gerendert (siehe unten), fällt also durch die Pipeline.
Die JVM selbst ist ein plausibler Kandidat für ungewöhnliche Syscalls.
Der Install-Test ist hier aussagekräftig — minecraft-server steht nicht in ci/excluded-charts.txt, der Server kommt im k3d wirklich hoch. Das deckt den Normalpfad ab.
Nicht abgedeckt bleibt der Init-Container:ci/minecraft-server/test-values.yaml setzt curseforgeServerpack nicht, der Container wird also nie gerendert. Wer den Filter dort belegen will, muss das von Hand tun oder die Fixture erweitern. (Die Fixture-Lücke selbst wurde bewusst nicht nachverfolgt.)
Reihenfolge
Nach dem Abschluss der #99-Runde über alle drei Linien. Sonst kollidiert es mit den laufenden Versionssprüngen, und der Nachweis würde sich mit denen der Linienwahl vermischen.
Und dann stellt sich dieselbe Frage wie in #158: Der Filter muss über alle drei Linien nachgezogen werden, sonst trägt ihn nur die Linie, die gerade im Verzeichnis liegt.
Version
Major — Laufzeitverhaltensänderung, wie bei allen bisherigen seccompProfile-PRs (apache-tika 9.1.0 → 10.0.0 und weitere).
> Migriert aus [`jk-cluster/helm-charts#161`](https://github.com/jk-cluster/helm-charts/issues/161) — urspruenglich angelegt von **MeepMr** am 2026-08-24.
>
> Verweise der Form `#123` im folgenden Text beziehen sich auf die **GitHub-Nummerierung**, nicht auf die Nummern in diesem Repo. Geschlossene Issues wurden nicht mitgezogen und sind weiterhin nur auf GitHub lesbar.
---
`minecraft-server` fehlt weiterhin `seccompProfile: RuntimeDefault` im Pod-Kontext. Teilmenge von #84 — dort ist es einer der fünf verbliebenen Sonderfälle (neben `matrix-synapse`, `paperless-ngx`, `samba`, `teamspeak-server`). Dieses Issue existiert, weil das Chart durch die #99-Runde gerade in vier aufeinanderfolgenden Veröffentlichungen steht und der Punkt sonst zwischen ihnen verloren geht.
## Stand
Der Trivy-Job meldet bei jedem PR unverändert `AVD-KSV-0104` und `AVD-KSV-0030`. Der Job läuft im Berichtsmodus und wird trotzdem `success` — er blockiert also nichts und ist leicht zu übersehen.
Bewusst **nicht** in die #99-Runde mitgenommen: `seccompProfile` ist eine Laufzeitverhaltensänderung und gehört nicht in einen PR, der Null-Absicherung und Linienwahl nachzieht. Das war die richtige Entscheidung — sie hätte die Nachweise beider Themen vermischt.
## Der Grund, warum es hier nicht trivial ist
Bei `freesailarr` musste der Filter mit echtem Tunnel belegt werden, weil gluetun als root mit `NET_ADMIN` ein tun-Gerät anlegt. `minecraft-server` hat eine andere, eigene Frage:
- Das Image nutzt **gosu**, um von root auf uid 1000 herunterzufallen. Ob der Standard-Syscall-Filter das durchlässt, ist zu belegen, nicht anzunehmen.
- Der **Serverpack-Init-Container** (`curseforgeServerpack.enabled`) läuft im selben Pod-Kontext und würde den Filter mit erben. Er wird von der CI-Fixture nicht gerendert (siehe unten), fällt also durch die Pipeline.
- Die JVM selbst ist ein plausibler Kandidat für ungewöhnliche Syscalls.
**Der Install-Test ist hier aussagekräftig** — `minecraft-server` steht nicht in `ci/excluded-charts.txt`, der Server kommt im k3d wirklich hoch. Das deckt den Normalpfad ab.
**Nicht abgedeckt bleibt der Init-Container:** `ci/minecraft-server/test-values.yaml` setzt `curseforgeServerpack` nicht, der Container wird also nie gerendert. Wer den Filter dort belegen will, muss das von Hand tun oder die Fixture erweitern. (Die Fixture-Lücke selbst wurde bewusst nicht nachverfolgt.)
## Reihenfolge
**Nach** dem Abschluss der #99-Runde über alle drei Linien. Sonst kollidiert es mit den laufenden Versionssprüngen, und der Nachweis würde sich mit denen der Linienwahl vermischen.
Und dann stellt sich dieselbe Frage wie in #158: **Der Filter muss über alle drei Linien nachgezogen werden**, sonst trägt ihn nur die Linie, die gerade im Verzeichnis liegt.
## Version
Major — Laufzeitverhaltensänderung, wie bei allen bisherigen `seccompProfile`-PRs (apache-tika 9.1.0 → 10.0.0 und weitere).
In minecraft-server/values.yaml kommt seccompProfilenicht vor. Der Pod-Sicherheitskontext trägt also kein RuntimeDefault, anders als in den Charts, die der Härtungsvorgabe folgen.
Zum Umfang, damit es bei der Umsetzung nicht überrascht: das Nachziehen ist eine Laufzeitverhaltens-Änderung und nach der Versionierungsregel dieses Repositories damit ein Major-Bump, keine Patch-Korrektur — dieselbe Einordnung wie bei den übrigen Härtungsrunden.
## Nachgeprüft am 2026-10-04: unverändert offen
In `minecraft-server/values.yaml` kommt `seccompProfile` **nicht vor**. Der Pod-Sicherheitskontext trägt also kein `RuntimeDefault`, anders als in den Charts, die der Härtungsvorgabe folgen.
Zum Umfang, damit es bei der Umsetzung nicht überrascht: das Nachziehen ist eine **Laufzeitverhaltens-Änderung** und nach der Versionierungsregel dieses Repositories damit ein **Major**-Bump, keine Patch-Korrektur — dieselbe Einordnung wie bei den übrigen Härtungsrunden.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
minecraft-serverfehlt weiterhinseccompProfile: RuntimeDefaultim Pod-Kontext. Teilmenge von #84 — dort ist es einer der fünf verbliebenen Sonderfälle (nebenmatrix-synapse,paperless-ngx,samba,teamspeak-server). Dieses Issue existiert, weil das Chart durch die #99-Runde gerade in vier aufeinanderfolgenden Veröffentlichungen steht und der Punkt sonst zwischen ihnen verloren geht.Stand
Der Trivy-Job meldet bei jedem PR unverändert
AVD-KSV-0104undAVD-KSV-0030. Der Job läuft im Berichtsmodus und wird trotzdemsuccess— er blockiert also nichts und ist leicht zu übersehen.Bewusst nicht in die #99-Runde mitgenommen:
seccompProfileist eine Laufzeitverhaltensänderung und gehört nicht in einen PR, der Null-Absicherung und Linienwahl nachzieht. Das war die richtige Entscheidung — sie hätte die Nachweise beider Themen vermischt.Der Grund, warum es hier nicht trivial ist
Bei
freesailarrmusste der Filter mit echtem Tunnel belegt werden, weil gluetun als root mitNET_ADMINein tun-Gerät anlegt.minecraft-serverhat eine andere, eigene Frage:curseforgeServerpack.enabled) läuft im selben Pod-Kontext und würde den Filter mit erben. Er wird von der CI-Fixture nicht gerendert (siehe unten), fällt also durch die Pipeline.Der Install-Test ist hier aussagekräftig —
minecraft-serversteht nicht inci/excluded-charts.txt, der Server kommt im k3d wirklich hoch. Das deckt den Normalpfad ab.Nicht abgedeckt bleibt der Init-Container:
ci/minecraft-server/test-values.yamlsetztcurseforgeServerpacknicht, der Container wird also nie gerendert. Wer den Filter dort belegen will, muss das von Hand tun oder die Fixture erweitern. (Die Fixture-Lücke selbst wurde bewusst nicht nachverfolgt.)Reihenfolge
Nach dem Abschluss der #99-Runde über alle drei Linien. Sonst kollidiert es mit den laufenden Versionssprüngen, und der Nachweis würde sich mit denen der Linienwahl vermischen.
Und dann stellt sich dieselbe Frage wie in #158: Der Filter muss über alle drei Linien nachgezogen werden, sonst trägt ihn nur die Linie, die gerade im Verzeichnis liegt.
Version
Major — Laufzeitverhaltensänderung, wie bei allen bisherigen
seccompProfile-PRs (apache-tika 9.1.0 → 10.0.0 und weitere).Nachgeprüft am 2026-10-04: unverändert offen
In
minecraft-server/values.yamlkommtseccompProfilenicht vor. Der Pod-Sicherheitskontext trägt also keinRuntimeDefault, anders als in den Charts, die der Härtungsvorgabe folgen.Zum Umfang, damit es bei der Umsetzung nicht überrascht: das Nachziehen ist eine Laufzeitverhaltens-Änderung und nach der Versionierungsregel dieses Repositories damit ein Major-Bump, keine Patch-Korrektur — dieselbe Einordnung wie bei den übrigen Härtungsrunden.