Gitea saute de 1.27 à 28.0 et durcit l’autorisation des dépôts
Gitea abandonne le préfixe « 1. » et publie la 28.0.0, une version majeure qui change la sortie réseau des opérations Git et corrige plusieurs failles d’autorisation. Une montée de version à planifier, pas à appliquer à l’aveugle.
30 septembre 2026. Gitea publie la version 28.0.0, et abandonne au passage le préfixe historique « 1. » de sa numérotation : la version qui aurait dû s’appeler 1.28.0 devient 28.0.0, à la manière du passage de Java à la version 9 en 2017. 30 septembre 2026. La montée de version majeure embarque cinq changements cassants, dont le routage des opérations réseau Git à travers un proxy interne avec de nouvelles règles d’égrès. 30 septembre 2026. Le changelog liste plusieurs correctifs de sécurité, mais Gitea en réserve les détails pendant environ une semaine pour laisser le temps de mettre à niveau. Pourquoi c’est important : pour qui autohéberge Gitea et s’appuie sur son runner d’Actions, c’est une mise à niveau à lire avant de déployer, pas à appliquer d’une traite.
Un numéro de version qui dit quelque chose
Le saut de 1.27.3 à 28.0.0 n’est pas cosmétique : il traduit une décision de numérotation. Gitea retranche le « 1. » historique qui ne portait plus d’information, exactement comme Java l’avait fait en passant de 1.8 à 9. La conséquence pratique est immédiate : une version majeure signale des ruptures de compatibilité, et celle-ci en compte cinq. Un administrateur qui met à niveau sans les lire court au-devant d’une instance qui ne démarre pas ou qui change silencieusement de comportement.
La liste des changements cassants mérite une lecture attentive, car elle touche des points de configuration que beaucoup d’instances ont déjà personnalisés. Le premier concerne les opérations réseau Git — migrations, miroirs et autres appels sortants — qui transitent désormais par un proxy interne appliquant les réglages d’égrès aux connexions directes (le changement #39426). Le préréglage « externe » disparaît, et pour une politique de refus par défaut, il faut désormais poser EGRESS_MODE = strict et lister explicitement les hôtes autorisés. En mode strict, une entrée sans port n’autorise que les ports 80 et 443. En mode laxiste, ALLOWED_HOST_LIST ne restreint plus les hôtes publics, et les entrées en adresse IP n’acceptent plus les jokers — * n’est plus une valeur valide. Les anciennes clés ALLOWED_DOMAINS, BLOCKED_DOMAINS et ALLOW_LOCALNETWORKS sont dépréciées au profit de ALLOWED_HOST_LIST et BLOCKED_HOST_LIST, et une entrée invalide de BLOCKED_HOST_LIST empêche désormais Gitea de démarrer.
Cinq ruptures, et leurs conséquences
Le deuxième changement cassant touche les Actions. Les exécutions terminées sont désormais supprimées après 400 jours par défaut, avec leurs tâches, journaux et artefacts, via une nouvelle tâche cron cleanup_action_runs (#38855). Pour conserver tout, il faut poser [actions] RUN_RETENTION_DAYS = 0 avant de monter de version — la valeur 0 signifiant désormais « conserver pour toujours » pour les trois réglages de rétention. C’est à la fois un nettoyage bienvenu et un piège pour qui comptait sur des journaux anciens.
Le troisième est une exigence de Git 2.25.0 minimum (#39131) : Gitea refuse de démarrer avec un Git plus ancien, un point à vérifier sur les distributions qui n’installent pas Git via les dépôts officiels. Le quatrième désactive l’auto-inscription par défaut (#39400) — il faut désormais poser explicitement [service] DISABLE_REGISTRATION = false — et fait migrer le domaine de l’instance vers ROOT_URL, [server] DOMAIN n’étant plus lu. Le cinquième durcit l’évaluation des workflows : le if: de niveau job est évalué avant l’expansion de la matrice, le fail-fast de la matrice est appliqué, et les dépôts publics ne peuvent plus appeler de workflows réutilisables depuis des dépôts privés (#39358).
À cela s’ajoute un détail opérationnel : les binaires de la 28.0.0 n’incluent plus les builds x86 32 bits ni gogit, et le Snap n’est plus compilé pour armhf. Les noms de fichiers perdent aussi leur suffixe de version d’OS. Si un script de téléchargement se fiait à l’ancien format gitea-28.0.0-windows-amd64.exe, il faut le mettre à jour.
Une vague de durcissement de l’autorisation
La 28.0.0 est également une version de sécurité, même si Gitea joue la prudence : le billet de blog annonce que les détails seront ajoutés « dans environ une semaine » pour laisser le temps de patcher. Le changelog du dépôt liste néanmoins les correctifs, et plusieurs méritent l’attention d’un exploitant.
Le plus structurant est le renforcement de l’autorisation par dépôt pour l’accès des équipes, la suppression et le délien des paquets (#39063). En clair, Gitea s’assure que les droits accordés à une équipe sur un dépôt restent bornés au périmètre de ce dépôt, au lieu de pouvoir déborder vers d’autres ressources — une correction qui réduit la surface d’une escalade de privilèges via un compte compromis.
Deux correctifs durcissent le transport Git lui-même. Le premier fait rejeter les objets Git invalides ou dupliqués lors d’un push (#39472), fermant une classe d’attaques où un dépôt malformé servait de vecteur. Le second identifie les clés publiques présentées par empreinte plutôt que par un identifiant ambigu (#39423), ce qui rend l’authentification SSH plus robuste. Enfin, la mise à jour de golang.org/x/crypto comble une faille de déni de service dans le paquet SSH (#39219), et les exécutions de pull requests de forks annulées ou non approuvées restent derrière la barrière d’approbation (#39399).
Ce que la 28.0.0 ajoute au quotidien
Au-delà de la sécurité, la 28.0.0 embarque des fonctionnalités qui parlent directement à un opérateur autohébergé. L’audit logging (#38189) — désactivé par défaut, activable via [audit] RECORD_OUTPUT = database, avec une rétention de 30 jours par défaut — permet de tracer qui a fait quoi sur l’instance, et de l’exporter en JSONL. C’est un manque criant que la forge comblait jusqu’ici par des journaux applicatifs peu exploitables.
La gestion des comptes de bots depuis l’interface d’administration, l’API et la CLI (#38966) remplace un bricolage répandu — créer un compte « robot » aux droits faits main — par un objet de première classe. L’usurpation d’identité par un administrateur (#38614) affiche un bandeau marquant la session et relie les actions aux deux comptes quand l’audit est actif, ce qui facilite le support sans casser la traçabilité. Les jetons de déploiement HTTPS et les règles d’approbation des code-owners viennent compléter un tableau déjà fourni.
Côté Actions, les nouveautés suivent le même fil : une vue de file d’attente des builds, le support du préfixe $/ et de self: dans les workflows réutilisables, une API de force-cancel, et le rafraîchissement adaptatif de la liste des exécutions. Pour une équipe qui a fait de Gitea Actions son CI/CD interne, c’est autant de petites frictions en moins — à condition de digérer d’abord les cinq changements cassants.
Verdict
Si vous autohébergez Gitea en production, ne mettez pas à niveau à l’aveugle : lisez les cinq changements cassants, en particulier le passage de l’égrès en EGRESS_MODE = strict et RUN_RETENTION_DAYS = 0 si vous voulez conserver vos journaux, puis testez sur une instance de staging avant de toucher la production. Si vous gérez des accès par équipe, les correctifs d’autorisation par dépôt (#39063) et de rejet des objets invalides (#39472) justifient à eux seuls une montée de version rapide. Si vous restez sur 1.27.x à court terme, vérifiez au minimum votre version de Git et la faille de déni de service SSH corrigée dans x/crypto, et planifiez la migration — les correctifs de sécurité ne redescendront pas sous forme de simple patch sur la branche 1.x.