Gitea 28 elimina el prefijo 1.x y añade auditoría

Saber quién cambió qué en tu forge

En una instancia autoalojada, los logs normales ayudan a depurar errores, pero no responden bien a preguntas de control: quién cambió la visibilidad de un repositorio, quién creó un token o desde dónde se modificó un webhook. Gitea 28.0.0 incorpora un registro de auditoría separado de los logs de aplicación, router y acceso. Su objetivo es dejar una traza estructurada de cambios relevantes para seguridad y administración. (docs.gitea.com)

El cambio de versión también merece atención: Gitea abandona el prefijo histórico 1. y pasa de la serie 1.x a llamarse 28.0.0. No lo trataría como una actualización rutinaria solo porque el número parezca distinto; hay cambios de comportamiento que pueden afectar a integraciones, automatizaciones y políticas de red. (blog.gitea.com)

Activar la auditoría sin montar otro servicio

La auditoría está desactivada por defecto y se guarda en la base de datos cuando se habilita. Cada evento incluye, entre otros datos, una acción estable, el actor, el ámbito afectado, el origen, un mensaje y metadatos en JSON. En Docker se pueden usar las variables GITEA__audit__RECORD_OUTPUT y GITEA__audit__RETENTION_DAYS, que Gitea traslada a app.ini. (docs.gitea.com)

[audit]
RECORD_OUTPUT = database
RETENTION_DAYS = 30

Yo empezaría con una retención limitada y la ajustaría después de revisar cuánto crece la base de datos y qué necesidades reales tiene el equipo. Con RETENTION_DAYS = 0, los eventos se conservan indefinidamente. La limpieza la ejecuta la tarea programada cron.delete_old_audit_events mientras la grabación esté activa y exista una retención mayor que cero. (docs.gitea.com)

Un formato útil para revisar y exportar

Los administradores del sitio pueden filtrar eventos por actor, acción y origen, y exportar el resultado filtrado como JSONL desde la interfaz. Eso permite conservar una evidencia puntual, enviarla a otra herramienta o procesarla con scripts sin tener que interpretar texto libre de los logs. Los propietarios de organizaciones, administradores de repositorios y usuarios autenticados también disponen de vistas acotadas a su propio ámbito. (docs.gitea.com)

Para mí, el valor está en poder cruzar cambios administrativos con despliegues o tareas de automatización. El origen puede indicar si una acción llegó desde la interfaz, la API, la CLI o un proceso del sistema. Además, las tareas de Gitea Actions quedan identificadas como actor de sistema, algo práctico cuando una automatización toca secretos, webhooks o configuración del repositorio. (docs.gitea.com)

La actualización exige revisar más que el contenedor

Gitea 28 cambia las reglas de salida de red para migraciones, espejos, webhooks y OAuth2. Las operaciones Git de red pasan por un proxy interno y las listas de permitidos y bloqueados deben revisarse antes de actualizar. Si usas una política restrictiva, EGRESS_MODE = strict es la opción que mantiene una lista de permitidos exclusiva; sin ese modo, una configuración anterior puede no comportarse como esperabas. (blog.gitea.com)

También cambia la conservación de Gitea Actions: las ejecuciones completadas se eliminan tras 400 días por defecto, junto con sus trabajos, logs y artefactos. Si necesitas conservar ese historial sin caducidad, hay que definirlo antes de actualizar con RUN_RETENTION_DAYS = 0 en la sección [actions]. No dejaría esta decisión para después si tus ejecuciones contienen evidencias de CI, informes de pruebas o artefactos de entrega. (blog.gitea.com)

[actions]
RUN_RETENTION_DAYS = 0

El registro público también queda desactivado por defecto. Si tu instancia admite altas abiertas, debes declarar expresamente [service] DISABLE_REGISTRATION = false; confiar en el comportamiento previo ya no basta. Conviene revisar igualmente ROOT_URL, porque Gitea deja de usar [server] DOMAIN para determinar el dominio de la instancia y el dominio SSH por defecto. (blog.gitea.com)

La letra pequeña de la auditoría

La auditoría no sustituye al registro de acceso ni es una grabación completa de toda la actividad. No guarda lecturas como navegación, clonados, fetch o peticiones API GET, y tampoco registra inicios de sesión salvo fallos de segundo factor. Tampoco conserva valores de secretos o tokens, ni identifica qué clave SSH usó un usuario normal al hacer un push. (docs.gitea.com)

Hay otra limitación importante: si falla la escritura de un evento de auditoría, la operación original continúa y el error queda reflejado en los logs. Es una decisión razonable para no bloquear el trabajo, pero significa que el registro no debe tratarse como una garantía absoluta sin supervisar la salud de la base de datos y de los logs. Yo comprobaría alertas, copias de seguridad y capacidad antes de convertirlo en una pieza de cumplimiento interno. (docs.gitea.com)

Cómo plantearía el cambio

Haría copia de seguridad, probaría la actualización en una instancia de pruebas y revisaría primero las listas de egress y los flujos de Actions. Después activaría la auditoría con una retención corta, validaría que aparecen eventos útiles y decidiría qué exportaciones necesito conservar fuera de Gitea. Por último, comprobaría el registro público, ROOT_URL, la versión de Git y cualquier script que descargue binarios usando nombres antiguos. (blog.gitea.com)

Fuente: Self-Host Lab.

Anuncio oficial: Gitea 28.0.0 is released.

Documentación oficial: Audit Logging.