Konvention: was ein "plain app-version bump" ist - ein Patch hat eine Sicherheitsvorgabe gekippt #128
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: jlab-cluster/helm-charts#128
Reference in new issue
Block a user
Ein als „plain app-version bump" eingestufter Patch hat bei
sonarreine sicherheitsrelevante Vorgabe still gekippt. Niemand hat es gesehen, und das ist kein Versehen einer Person: unsere Konventionen sagen dem Prüfer ausdrücklich, dass bei so einem Bump nichts zu prüfen ist.Der Vorfall, gemessen
sonarrvertraut den Forwarded-Headern des Ingress-Controllers nicht mehr, und zwar seit einem früheren reinen App-Bump, nicht seit einer Chart-Änderung.Upstream hat die fünf fest verdrahteten privaten Netze aus
Startup.csdurch eine Einstellung mit leerer Vorgabe ersetzt:v2.5.2.5491(prowlarr, alt)v2.6.5.5623(prowlarr, neu)ForwardedHeadersConfigurator.csStartup.csKnownNetworks.Add(10/8,172.16/12,192.168/16,fc00::/7,fe80::/10)TrustedNetworksGetValue("TrustedNetworks", string.Empty)Der neue Code liest den Wert und kehrt bei leerem Wert vorzeitig zurück, registriert also kein einziges Netz. Bei
sonarrwar das inv4.0.19.3011— der Version, die im Cluster lief — schon der Fall: Konfigurator vorhanden,grep -c KnownNetworksinStartup.cs→ 0.Folge: echte Client-IP verloren, Schema hinter TLS-terminierendem Ingress als
httpgesehen, und beiAuthenticationRequiredType.DisabledForLocalAddressesändert sich das Authentifizierungsverhalten, weil eine Anfrage nur noch ohneX-Forwarded-Forals „local" gilt.Behoben ist es mit #121 (
freesailarr 4.0.0+up1.0.0,trustedNetworksfür prowlarr, radarr und sonarr). Aufgefallen ist es nur, weil der Plan das Lesen der Release-Notes für die beiden Minor-Sprünge verlangte — prowlarr2.5.2→2.6.5und radarr6.3.0→6.4.4wären Fall zwei und drei gewesen. Die fünf Patch-Sprünge derselben Runde (bazarr, qbittorrent, sonarr, flaresolverr, recyclarr) trugen nichts dergleichen; die Regel ist also nicht „jeder Bump ist gefährlich".Warum es niemand gesehen hat — die Diagnose ist nicht „Automerge ist ungesichert"
Das wäre die naheliegende Erklärung und sie ist falsch. Gemessen in
renovate.json5:automerge: true(Zeile 55),automergeType: "pr",platformAutomerge: truematchUpdateTypes: ["patch", "minor", "digest"](Zeilen 125–126) — Majors haben keinen, sie werden laut Zeile 122 „at the review" gehaltenseparateMultipleMajor: true(Zeile 68)Und auf
mainist die erforderliche Review aktiv: Auto-Merge greift nur bei grünen Checks und vorhandener Review. Es ist also nichts ohne menschliche Zustimmung durchgelaufen.Der Defekt sitzt darin, was unsere Konventionen dem Prüfer als Prüfpflicht nennen. Zwei Stellen sagen zusammen, dass es nichts zu lesen gibt:
CLAUDE.md, „The wiki": „What does not oblige an edit: a plain app-version bump. Renovate automerges those continuously and never touches the wiki."CLAUDE.md, „Versioning scheme": „Patch: bug fixes without behavior or values-schema change; plain app-version updates."Beide sind für den Normalfall richtig und beide definieren „plain" nirgends. Ein Bump ist also so lange „plain", wie niemand nachsieht — und genau das ist die Lücke: die Einstufung, die das Lesen erspart, wird getroffen, bevor gelesen wurde.
Zu entscheiden
Nicht von vornherein klar, und es ist eine Verfahrens- und keine reine Chart-Frage:
a) „plain" an der Sprungweite festmachen. Patch innerhalb einer Minor-Linie gilt als plain; Minor und Major verlangen das Lesen der Release-Notes auf Werte- und Verhaltensänderungen, mit dem Ergebnis im PR — auch wenn es „nichts gefunden" lautet. Das ist die Regel, die diesen Vorfall gefangen hätte, und sie kostet Aufwand nur bei Minors und Majors. Nachteil:
sonarrkam über einen Patch herein (4.0.19 → 4.0.20war harmlos, der Schaden lag in einem früheren Sprung) — die Regel hätte den Vorfall also erst beim nächsten Minor gefangen, nicht bei seinem Ursprung.b) Den Drei-Tage-Riegel um eine Leseauflage ergänzen statt um Zeit: ein Label oder ein PR-Rumpf-Abschnitt, in dem der Prüfer bestätigt, welche Upstream-Notizen er gesehen hat. Erfasst alle Sprungweiten, kostet bei jedem Bump etwas.
c) Die Wiki-Ausnahme präzisieren statt die Einstufung. „Plain" bleibt wie es ist, aber die Ausnahme in der Tabelle gilt nur, nachdem festgestellt wurde, dass sich keine Vorgabe geändert hat — also eine Umkehr der Beweislast, ohne neue Pflichten für den Normalfall.
d) Nichts ändern und den Vorfall als Einzelfall führen. Dann gehört in
Lessons-Learned, dass die Ausnahme diesen Preis hat — dort steht er inzwischen, aber ohne Regel, die daraus folgt.Was schon getan ist
In
Lessons-Learnedsteht der Vorfall als „The security default that a patch bump switched off", mit allen drei übertragbaren Teilen — einschließlich der Methode: ein geratener Tag, der 404 liefert, ist von „nicht betroffen" nicht zu unterscheiden, und genau so kam diesonarr-Prüfung zuerst falsch heraus.Was dort nicht steht, ist eine Regel. Der Entwicklungs-Agent von #121 hatte die ausdrückliche Auflage, keine Konventionsänderung vorzuschlagen, weil das eine eigene Entscheidung ist und kein Anhängsel eines Versions-PRs. Dieses Issue ist diese Entscheidung.
Umfang, wenn entschieden ist
CLAUDE.md— die bindende Kopie, beide genannten Stellen.README.md— die code-seitige Kopie der Konventionen.Workflowund, falls der Riegel oder ein Label dazukommt,Renovate.renovate.json5nur, falls die Entscheidung eine Konfigurationsänderung verlangt (b oder eine Einschränkung vonautomergenachmatchUpdateTypes).Nicht in diesem Umfang
Die drei
trustedNetworks-Werte selbst — die sind mit #121 geliefert und im Cluster gesetzt (10.42.0.0/16, von jeder der drei Apps im eigenen Protokoll bestätigt).Genehmigte Entscheidung: der Chart-Sprung folgt dem App-Sprung
Der Maintainer hat entschieden. Die Regel lautet:
Das ist keine neue Regel, sondern eine vollendete
ci/renovate-bump-chart.shdokumentiert in seinem Kopf schon:App-Major → Chart-Major gilt also bereits. Es fehlt genau die Mitte, und dort sitzt der Vorfall: ein App-Minor fällt heute auf einen Chart-Patch zusammen.
Vier Festlegungen
1. Maximum, nicht Ersatz. Der Chart-Sprung ist das Größere aus chart-eigener Einstufung und App-Sprung. Ein Wert, der verpflichtend wird, bleibt ein Chart-Major, auch wenn der App-Sprung ein Patch ist. Die Chart-Version darf nicht aufhören, chart-eigene Brüche zu melden.
2. Die Sprungweite kommt von Renovate, nicht aus einem
appVersion-Vergleich. Das ist der Teil, ohne den die Regel den auslösenden Vorfall nicht gefangen hätte, und README sagt den Grund selbst (Zeile 270):freesailarrhatappVersion: "1.0.0"als handgepflegten Marker für zehn Upstreams; er bewegt sich nie. prowlarrs2.5.2 → 2.6.5war ein Image-Tag in dervalues.yaml. Eine Regel, dieappVersionvergleicht, ist für genau diesen Fall blind.Renovate hat den Update-Typ bereits klassifiziert. Er wird als zweites Argument an den Hook übergeben (
{{{updateType}}}inpostUpgradeTasks.commands), und das Skript entscheidet danach statt selbst zu parsen. DassupdateTypeden Hook erreicht, ist per Dry-Run zu belegen, nicht anzunehmen — so wie #121 es für die Gruppierungsregel gemacht hat.3. Non-Semver-App-Versionen bleiben beim Patch, mit begründeter Ausnahme. Sieben Charts betrifft das:
2026-09-30(rss-bridge),2026.8.3,2026.9.13-3b8009065,2026.8.2-java25,3.3.1.0-full,6.0.0-beta13.1,9.1.2-alpine. Bei CalVer und Datums-Tags trägt die Positionsstelle keine Aussage über die Sprungweite — ein Monatswechsel würde jeden Monat einen Chart-Minor auslösen, der nichts über das Risiko sagt. Die Ausnahme gehört mit diesem Grund in die Konvention, nicht als Fußnote.4. Keine Leseauflage — ausdrücklich entschieden, und das ist eine Grenze, keine Lücke.
Der Maintainer hat die Variante „Chart-Minor/Major aus App-Bump verlangt das Lesen der Release-Notes" abgelehnt. Die Folge gehört klar hingeschrieben: dieses Issue wird damit beantwortet, aber der Vorfall aus seinem Rumpf bleibt wiederholbar. Die Einstufung hört auf, die Sprungweite zu untertreiben; niemand ist verpflichtet nachzusehen, was der Sprung enthält.
Was die Zahl trotzdem leistet, und das ist nicht kosmetisch — README Zeile 587:
Ein Minor ist dort sichtbar, wo ein Patch es nicht ist, und kann in
cluster-configeigene Riegel auslösen (Altersgrenze, Gruppierung, Automerge-Regeln). Ob dort tatsächlich nach Update-Typ unterschieden wird, ist von hier aus nicht prüfbar und gehört nicht in den Umfang — aber es ist der Mechanismus, der „nur die Nummer" wirksam macht, und er gehört benannt.Umfang
Code und Konfiguration
ci/renovate-bump-chart.sh— Update-Typ als Argument, Minor umsetzen, Maximum-Regel, Non-Semver-Rückfall, Kopfkommentar (Zeilen 17–18) nachziehen. Das Skript wird damit von einer Rechenhilfe zu entscheidender Logik.ci/istrun-<ding>-test.shdie etablierte Form. Mindestens: App-Major/Minor/Patch, die vier Non-Semver-Gestalten, die Maximum-Fälle (Chart-Major bei App-Patch), ein fehlender und ein unbekannter Update-Typ, und ein neuer Chart auf dem Branch (den das Skript heute ausdrücklich in Ruhe lässt).renovate.json5—{{{updateType}}}übergeben, mit Begründung im Kommentar.Konventionstexte, alle in derselben PR
CLAUDE.md:99undREADME.md:375— „Patch: … plain app-version updates" ist die Zeile, die fällt.CLAUDE.md:51— „What does not oblige an edit: a plain app-version bump". Die Wiki-Ausnahme bleibt (keine Leseauflage), aber „plain" ist jetzt mechanisch definiert statt unbestimmt. Der Satz muss das sagen.README.md:270–272— der dort als offen protokollierte Punkt wird zur Entscheidung. Die abgelehnte Variante und ihr Preis gehören erhalten, nicht ersetzt.CLAUDE.md:120undREADME.md:587— beide nennen das Sicherheitsnetz als „bumps the chart patch"; das stimmt dann nicht mehr.Wiki
Workflow(Versionskonvention),Renovate(der Hook und das neue Argument),Lessons-Learned— dort steht der Vorfall als „The security default that a patch bump switched off"; er bekommt die getroffene Entscheidung und ihre Grenze: die Zahl wurde ehrlich gemacht, die Leseauflage bewusst nicht eingeführt.Keine Chart-Version ändert sich
Die PR berührt
ci/,renovate.json5, README,CLAUDE.mdund das Wiki — kein Chart-Verzeichnis, also wird nichts veröffentlicht und nichts bekommt einen Versionsschritt. Die Regel wirkt auf den nächsten Renovate-Lauf.Schlüsselwort
Fixes #128— die Entscheidung, nach der dieses Issue fragt, ist getroffen und umgesetzt. Dass sie den Vorfall nicht ausschließt, ist Teil der Entscheidung und steht in der Dokumentation, nicht als Restarbeit.