--- title: "Gitea 28.0: Abschied von 1.x, Audit-Logs und Bot-Accounts" date: 2026-10-01T02:11:13+02:00 modified: 2026-10-01T02:11:13+02:00 category: docker type: news author: Marcel Schönfelder canonical: https://s-edv.com/news/gitea-28-audit-logs-bot-accounts-versionsschema keywords: - Gitea - Docker - Selfhosting - Git - Audit-Log - Update reading_time: 4 --- # Gitea 28.0: Abschied von 1.x, Audit-Logs und Bot-Accounts Gitea hat am 30. September 2026 Version 28.0.0 veröffentlicht und dabei das historische Präfix „1.“ aus der Versionsnummer gestrichen: Auf 1.27 folgt nicht 1.28, sondern 28.0. Neu sind ein eingebautes Audit-Log, eigene Bot-Accounts, Admin-Impersonation und HTTPS-Deploy-Tokens pro Repository. Das Release enthält außerdem Sicherheitskorrekturen, deren Details das Projekt erst in etwa einer Woche nachreicht. Relevant ist das für alle, die Gitea selbst betreiben, besonders per Docker. Wer das Image über `gitea/gitea:1` oder `:1.27` bezieht, bekommt das neue Release nicht automatisch, sondern bleibt auf 1.27.3 stehen. Wer `:latest` nutzt, ist dagegen seit dem 30. September bereits auf 28.0.0 gelandet, samt Breaking Changes. Akuter Handlungsbedarf besteht heute vor allem darin, den eigenen Tag zu prüfen; das eigentliche Upgrade gehört in ein geplantes Wartungsfenster mit Backup. ## Was ist passiert? Das GitHub-Release v28.0.0 ist auf den 29. September 2026 datiert, der Blogbeitrag des Projekts auf den 30. September. Die wichtigsten Neuerungen laut Release-Ankündigung: - **Audit-Logging:** Sicherheitsrelevante Ereignisse werden in Admin-, Organisations-, Repository- und Benutzereinstellungen angezeigt, filterbar nach Actor, Action und Origin, exportierbar als JSONL. Standardmäßig aus, Aufbewahrung 30 Tage. - **Bot-Accounts:** Konten für Automatisierung, die sich nur per Access Token anmelden, keinen interaktiven Login haben und keine Benachrichtigungen oder Mails erhalten. Bestehende lokale Konten lassen sich in Bots umwandeln. - **Admin-Impersonation:** Admins sehen Gitea aus Sicht eines bestimmten Benutzers, ohne dessen Passwort. Bei aktivem Audit-Log werden beide Konten protokolliert. - **Deploy-Tokens:** HTTPS-Gegenstück zu SSH-Deploy-Keys, je Repository mit Lese- oder Lese-Schreib-Recht, auch für LFS. ## Für wen ist das relevant? Betroffen sind alle selbst betriebenen Gitea-Instanzen, die auf 28.0 wechseln oder per `:latest` bereits gewechselt haben. Laut Docker Hub zeigen `28`, `28.0`, `28.0.0` und `latest` auf dasselbe Image, `1` und `1.27` dagegen weiterhin auf 1.27.3. Gleiches gilt für die Rootless-Varianten `28-rootless` und `1-rootless`. Nicht direkt betroffen sind Instanzen mit festem 1.27er-Pin, solange niemand den Tag ändert. Wer Binaries per Skript lädt, muss Download-Skripte anpassen: Dateinamen tragen kein OS-Versionssuffix mehr, 32-Bit-x86- und gogit-Builds entfallen. ## Wie kritisch ist das? Das Update ist kein Notfall-Patch, aber auch kein reines Funktionsrelease. Die Breaking Changes können eine Instanz nach dem Upgrade am Start hindern oder still das Verhalten ändern: - Gitea startet nicht mehr mit Git älter als 2.25.0. Ungültige Einträge in `[migrations] BLOCKED_HOST_LIST` verhindern ebenfalls den Start. - Migrationen und Mirrors laufen über einen internen Proxy mit neuen Egress-Regeln. Im Standardmodus `lax` beschränkt `[security] ALLOWED_HOST_LIST` öffentliche Hosts nicht mehr; als exklusive Allowlist wirkt sie nur mit `EGRESS_MODE = strict`. - `[server] DOMAIN` wird ignoriert, die Domain kommt aus `ROOT_URL`. Die Selbstregistrierung ist ohne ausdrückliches `DISABLE_REGISTRATION = false` abgeschaltet. - Abgeschlossene Actions-Läufe samt Logs und Artefakten werden nach 400 Tagen gelöscht, außer `[actions] RUN_RETENTION_DAYS = 0` ist gesetzt. - Live-Benachrichtigungen nutzen WebSockets unter `/-/ws`. Ohne weitergeleitete Upgrade-Header am Reverse Proxy fallen Zähler auf Polling zurück. Welche Schwachstellen die Sicherheitskorrekturen schließen und wie schwer sie wiegen, ist noch nicht veröffentlicht. Der Changelog nennt unter anderem Fixes für Push-Prüfungen, SSH-Schlüsselzuordnung und Team-Berechtigungen. ## Was sollten Admins jetzt tun? - Image-Tag und laufende Version prüfen, etwa mit `docker compose images` und `docker exec gitea --version`. Wer unbeabsichtigt per `:latest` auf 28.0.0 gewechselt hat, sollte die Breaking Changes sofort gegenprüfen. - Update-Automatik anpassen: Watchtower oder ähnliche Werkzeuge auf `:1` holen 28.0 nie. In Renovate erscheint der Wechsel von 1.27.3 auf 28.0.0 als Versionssprung, der bewusst freigegeben werden sollte. - Vor dem Upgrade ein vollständiges Backup mit `gitea dump` plus Datenbank- und Volume-Sicherung anlegen, wie es auch das Projekt empfiehlt. - `app.ini` auf `DOMAIN`, Egress-Listen, Registrierung und Actions-Aufbewahrung durchsehen, dann gezielt auf `gitea/gitea:28` wechseln. - Audit-Log mit `[audit] RECORD_OUTPUT = database` aktivieren und `RETENTION_DAYS` passend zur eigenen Aufbewahrungsrichtlinie setzen. - Service-User für CI und Skripte schrittweise durch Bot-Accounts oder Deploy-Tokens ersetzen. ## Einordnung für Unternehmen Für kleinere Teams schließt Gitea 28 zwei Lücken, die bisher oft mit Workarounds überbrückt wurden: Ein nachvollziehbares Audit-Log erleichtert Nachweise bei Rechteänderungen, und Bot-Accounts ersetzen geteilte Service-User mit Passwort und Postfach. Der Versionssprung selbst ändert technisch wenig, wirkt aber auf jede Update-Automatik, die auf das Major-Tag `1` vertraut. Die Instanz bleibt dann ohne Warnung auf 1.27 stehen. Wie lange 1.27 noch Sicherheitsupdates erhält, geht aus den Quellen nicht hervor. Wer zuletzt wegen [CVE-2026-60004](https://s-edv.com/news/gitea-cve-2026-60004-kritische-rce-wird-aktiv-ausgenutzt) kurzfristig patchen musste, weiß, wie wichtig ein bewusst gewählter Update-Kanal ist. ## Passende Anleitungen auf S-EDV - [Gitea als Self-Hosted Git-Server mit Docker](https://s-edv.com/anleitungen/gitea-self-hosted-git-server-docker): Installation, Backup per gitea dump und Updates. - [Renovate für Docker-Abhängigkeiten](https://s-edv.com/anleitungen/renovate-docker-dependency-updater): Image-Updates kontrolliert per Pull Request freigeben. - [Container-Updates mit Watchtower-Nachfolgern](https://s-edv.com/anleitungen/docker-container-updates-watchtower-nachfolger-diun-wud): Update-Benachrichtigung statt blinder Automatik. ## Quellen - [Gitea-Blog: Ankündigung von Gitea 28.0.0 mit Breaking Changes (30.09.2026)](https://blog.gitea.com/release-of-28.0.0/) - [GitHub: Release v28.0.0 von go-gitea/gitea mit vollständigem Changelog](https://github.com/go-gitea/gitea/releases/tag/v28.0.0) - [Docker Hub: Image-Tags von gitea/gitea (abgerufen am 01.10.2026)](https://hub.docker.com/r/gitea/gitea/tags) - [Linuxiac: Bericht zu Gitea 28.0, Audit-Logs und Bot-Accounts (30.09.2026)](https://linuxiac.com/gitea-28-0-drops-1-x-versioning-adds-audit-logs-and-bot-accounts/)