zlib est l'un des rares morceaux de code C tiers présents dans sgcWebSockets. Il alimente l'extension WebSocket permessage-deflate, de sorte que chaque trame compressée que votre serveur envoie ou reçoit passe par lui, et il gère l'encodage de contenu HTTP. sgcOpenAPI partage les mêmes sources, il utilise donc la même copie. À partir de 2026.8.0, cette copie passe de zlib 1.2.12 à zlib 1.3.1.
Le changement est invisible dans l'API. Rien dans votre code n'a besoin d'être modifié, et le comportement de compression reste inchangé. Ce qui mérite une explication, c'est pourquoi la montée de version d'une petite bibliothèque C est plus qu'un simple remplacement de fichier, et ce que nous avons fait pour être sûrs qu'elle est sans risque sur chaque compilateur que nous prenons en charge.
Ce que corrige la 1.3.1, et pourquoi vous n'étiez pas exposé
Le correctif principal entre 1.2.12 et 1.3.1 est CVE-2022-37434, une lecture hors limites dans le tas au sein de inflate(). Il n'est atteignable que lorsque l'application appelante fournit à zlib un gz_header dont le champ extra pointe vers un tampon. zlib y copie alors le champ extra gzip, et en 1.2.12 cette copie ne comportait pas de contrôle de limites.
sgcWebSockets n'a jamais rempli cette condition. Il appelle inflateGetHeader uniquement avec un gz_header initialisé à zéro, et il n'affecte jamais head.extra, si bien que la branche concernée ne pouvait pas être atteinte. Nous l'avons vérifié dans les sources avant de décider quoi faire, et nous le disons clairement : les applications construites avec les versions antérieures n'étaient pas vulnérables par ce chemin.
Nous avons tout de même mis à jour. Ce que lisent les scanners automatisés et les questionnaires fournisseurs, ce sont les chaînes de version, pas les graphes d'appels, et un client qui lance une analyse de dépendances ne devrait pas avoir à reconstituer notre raisonnement pour clore un signalement. La mise à jour met fin à la discussion au lieu d'obliger à la répéter.
Pourquoi mettre à jour zlib n'est pas un simple remplacement de fichier
zlib est compilé dans votre exécutable plutôt que déployé sous forme de DLL, et c'est pourquoi une application sgcWebSockets n'a pas de zlib1.dll à côté d'elle. Cette liaison est réalisée avec des fichiers objets précompilés, et Delphi est exigeant sur leur format. Mettre à jour zlib signifie donc reconstruire ces objets, et il n'y en a pas un jeu mais trois.
| Utilisé par | Format | Construit avec |
|---|---|---|
| Delphi 7 à XE | OMF | bcc32, ZEXPORT=__fastcall |
| XE2 et ultérieurs, Win32 | OMF | bcc32, ZEXPORT=__cdecl |
| XE2 et ultérieurs, Win64 | COFF | MSVC cl |
Les deux jeux 32 bits diffèrent par la convention d'appel, car les compilateurs plus anciens lient zlib avec la convention de registre Delphi tandis que XE2 et les suivants utilisent cdecl. Le jeu 64 bits relève encore d'un format d'objet différent. Il est à noter que bcc64 ne peut pas le produire, car il émet des objets ELF alors que l'éditeur de liens Delphi Win64 attend du COFF, ce jeu est donc construit avec le compilateur Microsoft.
Rien de tout cela n'est visible pour vous. C'est simplement la raison pour laquelle une montée de version de zlib est un exercice de compilation plutôt qu'un téléchargement.
Vérifié sur chaque compilateur, pas seulement le plus récent
Des objets reconstruits peuvent se compiler proprement et rester erronés, un test d'édition de liens ne suffit donc pas à lui seul. Chaque compilateur pris en charge a servi à construire puis à exécuter un programme qui compresse un tampon, le décompresse, le compare octet par octet et vérifie que les objets liés rapportent la version attendue.
uses
sgcIdCTypes, sgcIdGlobal, sgcIdZLibHeaders;
var
vPackedLen: TIdC_ULONG;
begin
vPackedLen := SizeOf(vPacked);
if compress(PIdAnsiChar(@vPacked[0]), vPackedLen,
PIdAnsiChar(@vSrc[0]), SizeOf(vSrc)) <> 0 then
raise Exception.Create('compress failed');
WriteLn('zlib ', String(AnsiString(zlibVersion))); // zlib 1.3.1
end;Cela s'est exécuté sur Delphi 7, Delphi 2007, Delphi 2009 et RAD Studio XE6 jusqu'à 13, en Win32 et en Win64 là où la plateforme existe. Les 25 combinaisons passent toutes et rapportent 1.3.1.
Un bug 64 bits latent corrigé au passage
La matrice a mis au jour quelque chose qui n'avait rien à voir avec la nouvelle version. Sur Delphi 10 Seattle, les compilations 64 bits sélectionnaient les objets 32 bits, qui ne peuvent pas être liés dans un exécutable 64 bits et produisaient une erreur Bad object file format. La cause était une ancienne condition destinée à contourner un problème spécifique à Seattle, qui dirigeait cette seule combinaison vers le mauvais jeu d'objets. Seattle 64 bits utilise désormais les mêmes objets que toutes les autres cibles 64 bits, et compile.
sgcOpenAPI reçoit la même mise à jour
sgcOpenAPI partage ses sources avec sgcWebSockets, zlib compris, il passe donc à 1.3.1 dans la même version sans action séparée de votre part.
Ce que vous devez faire
Installez 2026.8.0 et recompilez vos projets. Il n'y a aucune propriété à régler, aucune unité à ajouter ou à supprimer, et aucun changement de déploiement, car zlib était déjà à l'intérieur de votre exécutable et y reste. Si vous tenez une nomenclature logicielle pour votre propre produit, mettez l'entrée zlib à 1.3.1 et vous pouvez retirer toute note CVE-2022-37434 que vous conserviez.