From 3f5da21f3e485fbc5ebe5e55ff7bc4a74a78c8a9 Mon Sep 17 00:00:00 2001 From: Thore Cimbal Date: Wed, 19 Aug 2026 12:00:00 +0000 Subject: [PATCH] docs(issues): close #0084 - the token exists and is proven to work sorb created the project access token with exactly what the job needs: Maintainer, because main is protected with push=Maintainers, and write_repository only, because the job pushes and never calls the API. Checked through the API without touching the value. Proven rather than assumed: a throwaway job pushed a ref with that token and removed it again, leaving main untouched and no branch behind. So the value reaches the job - protected variable on a protected branch - and it may write. The first real test is the rotation on 2026-09-01. Recorded as a future silent failure: the token expires 2027-08-19, and because the job runs green while idle, nobody would notice until the next real rotation after that date. Exactly the #0104 class, so it belongs in a calendar rather than in hope. Co-Authored-By: Claude Opus 5 --- STATUS.md | 5 +-- ...nonize-token-fuer-die-automatische-turn.md | 38 ++++++++++++++++++- 2 files changed, 39 insertions(+), 4 deletions(-) diff --git a/STATUS.md b/STATUS.md index 9c0a3a5..6e2f8bc 100644 --- a/STATUS.md +++ b/STATUS.md @@ -2,9 +2,9 @@ -## Issues (64 open, 35 closed) +## Issues (63 open, 36 closed) -Verteilung: M1 17 · M2 17 · M3 4 · M4 11 · M5 15 +Verteilung: M1 16 · M2 17 · M3 4 · M4 11 · M5 15 | Issue | Status | Meilenstein | Priorität | Title | |---|---|---|---|---| @@ -52,7 +52,6 @@ Verteilung: M1 17 · M2 17 · M3 4 · M4 11 · M5 15 | [0081](docs/issues/0081-gitops-48-gaeste-invite-workflow-per-bot-3-tage-account.md) | open | M3 | medium | Gäste-Invite-Workflow per Bot (3-Tage-Accounts, Admin-Freischaltung, begrenzte Reaktivierung) | | [0082](docs/issues/0082-gitops-49-cve-alarme-eine-matrix-nachricht-pro-cve-flut.md) | open | M1 | high | CVE-Alarme: eine Matrix-Nachricht pro CVE flutet den Security-Raum -- Zustellung derzeit stumm | | [0083](docs/issues/0083-gitops-50-monitoring-deploy-geaenderte-configs-greifen.md) | open | M1 | medium | Monitoring-Deploy: geaenderte Configs greifen nicht ohne --force-recreate (Inode-Falle bei Einzeldatei-Mounts) | -| [0084](docs/issues/0084-gitops-51-ci-canonize-token-fuer-die-automatische-turn.md) | next | M1 | medium | CI: CANONIZE_TOKEN für die automatische TURN-Rotation hinterlegen | | [0085](docs/issues/0085-gitops-52-docs-traegt-zwei-altbestaende-abgeschlossener.md) | open | M2 | low | docs/ trägt zwei Altbestände abgeschlossener Umzüge: TASKS.md und oldwiki/ | | [0086](docs/issues/0086-gitops-53-k8s-ressourcen-heissen-noch-element-web-docs.md) | open | M4 | low | k8s-Ressourcen heißen noch element-web-docs (Rest des ThreadNet-Rebrands) | | [0087](docs/issues/0087-gitops-55-logo-fuer-die-authentik-anmeldemaske-entwerfe.md) | waiting | M4 | low | Logo für die Authentik-Anmeldemaske entwerfen (Querformat/SVG) | diff --git a/docs/issues/0084-gitops-51-ci-canonize-token-fuer-die-automatische-turn.md b/docs/issues/0084-gitops-51-ci-canonize-token-fuer-die-automatische-turn.md index fcaada9..0395170 100644 --- a/docs/issues/0084-gitops-51-ci-canonize-token-fuer-die-automatische-turn.md +++ b/docs/issues/0084-gitops-51-ci-canonize-token-fuer-die-automatische-turn.md @@ -1,7 +1,7 @@ --- type: issue id: "0084" -status: next +status: done created: 2026-08-02 milestone: M1 priority: medium @@ -43,3 +43,39 @@ Der Rotations-CronJob läuft im Cluster und erreicht git.lab nicht; er pusht sei Bis dahin ist nichts kaputt: Ohne offene Rotation läuft der Job grün durch. Erst wenn am 01.09. wirklich rotiert wird und das Token fehlt, bricht er ab — laut und sichtbar, statt still das Falsche zu tun. Nebenbei aufgefallen: Der Branch `turn-secret-rotation-20260728-192656` liegt auf git.lab und Gitea, steckt aber längst in `main` — eine Karteileiche vom Juli. Kann weg, ist aber harmlos. + +## Erledigt 2026-08-19 — Token angelegt und nachweislich wirksam + +sorb hat den Project Access Token angelegt; die Eigenschaften stimmen mit dem überein, +was der Job braucht (per API geprüft, ohne den Wert anzufassen): + +| | | +|---|---| +| Name | `canonize-rotation` | +| Rolle | **Maintainer** — nötig, weil `main` mit `push = Maintainers` geschützt ist | +| Scopes | **nur `write_repository`** — der Job pusht, er ruft keine API auf | +| CI-Variable | `CANONIZE_TOKEN`, maskiert **und** geschützt | +| Ablauf | **2027-08-19** | + +**Wirksamkeit belegt, nicht angenommen** (Pipeline 521, Wegwerf-Job, `main` unberührt): + +``` +Sichtbar: CANONIZE_TOKEN ist im Job gesetzt. +SCHREIBEN OK: Zweig canonize-token-probe-521 angelegt. +Aufgeraeumt: canonize-token-probe-521 wieder entfernt. +``` + +Der Job hat einen Wegwerf-Zweig angelegt und wieder gelöscht — damit ist gezeigt, dass +der Wert im Job ankommt (geschützte Variable auf geschütztem Branch) **und** dass er +schreiben darf. Der Prüf-Job ist danach wieder entfernt worden; es blieb kein Zweig +liegen. Der erste echte Ernstfall ist die Rotation am **2026-09-01**. + +⚠️ **Ein Ablaufdatum ist ein stiller Ausfall in der Zukunft.** Am **2027-08-19** hört der +Token auf zu gelten. Der Job läuft im Leerlauf trotzdem grün durch — auffallen würde es +erst bei der nächsten echten Rotation danach, also frühestens am 2027-09-01. Genau die +Klasse aus #0104. Gehört in den Kalender, nicht in die Hoffnung. + +**Zwei Fallen beim Prüfen**, hier notiert weil sie beim nächsten Mal Zeit kosten würden: +Eine per API ausgelöste Pipeline hat die Quelle `api`, **nicht** `web` — die erste +Fassung der Regel übersprang den Job deshalb wortlos. Und dieses Repo kennt keine Stage +`pruefen` (das ist management); GitLab wies die Pipeline dafür komplett ab.