Gzip 1.15 corrige une course qui supprimait le mauvais fichier

Gzip 1.15 est sorti le 20 septembre 2026 et corrige un défaut qui pouvait amener gzip à supprimer le mauvais fichier. Jim Meyering a annoncé la version sur la liste de diffusion GNU info-gnu. La plupart des défauts corrigés sont présents dans gzip depuis ses débuts. Des scripts tournent donc dessus depuis des décennies.

Gzip est le programme de compression derrière les fichiers .gz livrés avec presque tous les systèmes Linux et Unix. Il est intégré aux gestionnaires de paquets, aux sauvegardes et à la rotation des journaux. Un défaut y touche bien plus de machines que sa discrétion ne le laisse croire.

Cette version rassemble 119 commits écrits sur 75 semaines. Paul Eggert en a signé 88 et Meyering 24, avec des apports plus modestes de Mark Adler, Bruno Haible et Collin Funk. La version précédente, gzip 1.14, date d'avril 2025 selon Phoronix.

Ce que faisait le défaut de suppression

Gzip compresse normalement un fichier puis supprime l'original. C'est dans la détermination du fichier à supprimer que se logeait ce défaut.

L'annonce énonce clairement le correctif : « gzip ne peut plus supprimer par erreur le mauvais fichier si un autre processus renomme simultanément un répertoire ancêtre de la destination de gzip ». Un ancêtre désigne ici tout répertoire situé au-dessus du fichier visé.

Le danger apparaît donc quand deux choses se produisent en même temps. Gzip est au milieu de son travail, et un autre processus renomme un dossier du chemin. Gzip résout alors le chemin à nouveau et peut aboutir à un autre fichier que celui de départ.

Il s'agit d'une situation de compétition, ou race condition. Le résultat dépend donc du calendrier de deux programmes distincts. Ce concours de circonstances étant nécessaire, le cas est rare. Sur un serveur chargé de tâches automatiques, rare n'équivaut pourtant pas à jamais.

Un second problème de verrouillage est aussi corrigé. La synchronisation pouvait échouer sur les systèmes gérant les drapeaux de fichier O_PATH ou O_SEARCH. Celui-ci est plus récent que les autres : il est arrivé avec gzip 1.7.

Trois corrections dans le décodage .lzh

Gzip lit toujours les fichiers .lzh, un ancien format de compression très répandu au Japon. Trois correctifs concernent ce décodeur.

L'un porte sur la sûreté mémoire. L'annonce indique qu'« un dépassement de tampon a été corrigé lors de la décompression d'un fichier .lzh après la décompression d'un fichier .Z ». Un dépassement de tampon signifie que le programme écrit au-delà de la mémoire qu'il a réservée.

Les deux autres produisent une sortie erronée plutôt qu'un plantage. Décompresser un fichier .lzh juste après un autre pouvait corrompre le résultat, car la table de décodage du fichier précédent restait en place. La sortie pouvait aussi être corrompue lorsqu'un tampon de bits interne n'était pas correctement vidé.

La version corrige par ailleurs « une utilisation de mémoire non initialisée sur certaines entrées mal formées ». Il s'agit de mémoire lue avant que quoi que ce soit n'y ait été écrit.

L'annonce ne cite aucun identifiant CVE pour ces points.

Ce qui change par ailleurs

Certains changements modifient le comportement au lieu de corriger un défaut, et quelques anciennes plateformes disparaissent.

Changement	Signification
Gestion de la locale	Gzip suit la locale de l'environnement au lieu de supposer la locale C
Taux des fichiers vides	Un fichier vide affiche désormais -Inf% au lieu de 0.0%
znew -P	L'option est ignorée et déclenche un avertissement
Diagnostics	Les noms de fichiers aux caractères inhabituels sont mis entre guillemets
Flux PKZIP	gzip -d accepte les signatures PKZIP, en-têtes locaux et descripteurs de données
Plateformes retirées	FreeBSD 4.11 et antérieurs, HP-UX 11.00, Minix 3.1.8, Windows 8.1 via MinGW sans UCRT

Les courses sur fichiers temporaires dans les scripts gzexe, zdiff et znew sont également corrigées.

Ce que cela signifie pour les développeurs

Traitez cette version comme une mise à jour de sécurité, même sans CVE. Deux des correctifs portent sur la sûreté mémoire du décodeur. Si l'un de vos services passe à gzip des archives fournies par des tiers, ce décodeur est accessible depuis l'extérieur. Il mérite alors une place en tête de votre file de correctifs. Rustls a illustré le même point en corrigeant une faille TLS 1.3 ouverte depuis 2024 : l'ancienneté ne prouve pas qu'un défaut est inoffensif.

Vérifiez deux points précis dans vos scripts avant de mettre à jour. Si quelque chose analyse le taux de compression de gzip, le cas du fichier vide affiche maintenant -Inf% et un analyseur attendant un simple nombre échouera. Si quelque chose suppose que gzip trie ou affiche les noms de fichiers de façon identique partout, le changement de locale peut décaler ce résultat d'une machine à l'autre.

La course à la suppression mérite un examen si gzip s'exécute là où des répertoires sont renommés sous lui. Les scripts de déploiement qui permutent un dossier de version en sont la forme courante. La fenêtre est étroite, mais le coût d'un mauvais fichier perdu ne l'est pas.

Vérifiez enfin les plateformes retirées avant de mettre à jour une image de compilation. Si vous compilez encore pour HP-UX 11.00 ou pour Windows 8.1 via MinGW sans UCRT, gzip 1.15 marque la fin de ce chemin.