mORMot2 Daily

2026-10-13 — RSA adopte les témoins FIPS tandis que des défauts AES-GCM et SQL sont corrigés

Tue, 13 Oct 2026 07:00:00 +0000

Cette édition est dominée par une vaste série RSA de conformité, de correction et de performances : l'encodage à largeur fixe et des contrôles PKCS#1/PSS renforcés précèdent l'emploi d'un DRBG NIST et la sélection FIPS 186-5 des témoins Miller-Rabin. Elle corrige aussi les blocs partiels AES-GCM, la propagation de retenue x86, la validation des clés ECC, l'attente des timers et plusieurs cas limites PostgreSQL/SQLite. Les utilisateurs de l'API publique TBigInt doivent adapter une signature IsPrime et peuvent utiliser plusieurs nouvelles méthodes.

Adoptez le build 2.4.17586 pour bénéficier de toute la série de conformité et d'optimisation RSA.
TBigInt.IsPrime accepte désormais TAesPrngAbstract au lieu de PLecuyer ; les appels directs doivent migrer.
Les sorties RSA ont une largeur fixe et PKCS#1/PSS rejette les encodages non canoniques ou invalides.
AES-GCM gère correctement les blocs AVX partiels ainsi que les états clonés ou réinitialisés.
Les chaînes vides PostgreSQL, les lectures BOOLINT et la destruction des connexions thread-safe sont corrigées.

2026-10-12 — TTunnelLocal adopte AES-GCM authentifié avec des clés par direction

Mon, 12 Oct 2026 07:00:00 +0000

TTunnelLocal reçoit une réécriture de sécurité : AES-CTR est remplacé par des trames AES-GCM authentifiées, les clés d'envoi et de réception sont séparées, la session est authentifiée et les handshakes malformés sont rejetés plus tôt. La série corrige aussi les données associées GCM avec OpenSSL, une fuite des cookies binaires et l'analyse des cookies __Secure- précédés d'un espace. Delphi 2010 est protégé contre des inlinings non sûrs.

Utilisez le build 2.4.17551 ; la réécriture de sécurité TTunnelLocal reçoit trois durcissements immédiats.
Le trafic chiffré TTunnelLocal utilise AES-GCM avec des trames authentifiées et des clés d'envoi/réception séparées.
Le code utilisant tlmVersion1 doit migrer vers tlmVersion1_aesctr ou le nouvel identifiant tlmVersion2.
TAesGcmOsl authentifie désormais correctement les données associées AEAD.
La destruction de TBinaryCookieGenerator ne fuit plus l'état géré après invalidation.

2026-10-11 — Les limites de redirection s'uniformisent et l'attente POSIX revient sans délai

Sun, 11 Oct 2026 07:00:00 +0000

Les clients HTTP appliquent désormais RedirectMax de façon cohérente dans WinHTTP et libcurl, avec une politique WinHTTP plus stricte contre les rétrogradations et TLS 1.3 activé sur les versions Windows compatibles. RunRedirect sous POSIX n'attend plus tout son délai de sondage après la fermeture de stdout par l'enfant. Les utilisateurs ARM doivent aussi prendre le correctif de normalisation de DoubleToAscii.

Utilisez le build 2.4.17538 pour inclure tous les correctifs de redirection, TLS et DoubleToAscii.
TWinHttp et TCurlHttp appliquent désormais RedirectMax au lieu de l'utiliser comme simple interrupteur.
RunRedirect sous POSIX revient à la fin du processus enfant sans attendre le délai de lecture configuré.
WinHTTP propose TLS 1.3 sous Windows 11 et Windows Server 2022 ou ultérieur.

2026-10-10 — Les clients HTTP et WebSockets se stabilisent après une large optimisation ECC

Sat, 10 Oct 2026 07:00:00 +0000

Cette édition corrige plusieurs lacunes du cycle de vie des WebSockets HTTP.sys et le traitement des en-têtes de réponse pour WinINet, WinHTTP, le client HTTP de Delphi et libcurl. Le même lot réécrit de nombreux chemins arithmétiques ECC P-256 pour ARM, i386 et x86-64, tout en rétablissant la compilation avec Delphi 7/2007 et Delphi POSIX. Les utilisateurs Kerberos POSIX doivent aussi prendre en compte deux changements de signature publics liés aux keytabs.

Utilisez le build 2.4.17531 : il contient la série complète des en-têtes des clients HTTP et tous les correctifs de compatibilité.
Les builds 2.4.17513 à 2.4.17515 contiennent un token fixme isolé dans mormot.core.base et ne doivent pas être utilisés.
TServerSspiKeyTab.PrepareKeyTab renvoie désormais boolean et ServerForceKeytab accepte RawUtf8 au lieu de TFileName.
Le nettoyage, les callbacks idle, le suivi des ping et les échecs d'envoi des WebSockets HTTP.sys ont été revus sur sept commits.

2026-10-09 — Les atomiques FPC ARM retrouvent leur ordre pendant la refonte des WebSockets HTTP.sys

Fri, 09 Oct 2026 07:00:00 +0000

Cette édition répare les barrières mémoire absentes des verrous mORMot sous FPC ARM et AArch64, où les données protégées pouvaient encore subir des courses malgré le mot de verrouillage. Sous Windows, la gestion des requêtes et WebSockets HTTP.sys est largement refondue puis stabilisée sur le cycle de vie, les E/S overlapped, l’envoi, l’arrêt et le ping. Les utilisateurs directs des wrappers HTTP.sys bas niveau et des index de connexion THttpApiWebSocketServerProtocol doivent migrer leur code.

Les verrous FPC ARM et AArch64 appliquent désormais des barrières mémoire complètes ; l’ancien code pouvait perdre des mises à jour ou corrompre l’état partagé.
Le moteur HTTP.sys traite les corps chunked sans limite, déconnecte les échecs laissant un corps non lu et isole l’état par requête.
Les connexions WebSocket HTTP.sys utilisent maintenant des ID TLockedList, des structures overlapped séparées pour lecture/réveil et un arrêt protégé.
THttpServerRequest.FullUrl devient RawUtf8, HttpApiRequest est supprimé et plusieurs signatures HTTP.sys bas niveau changent.
optCleanMagicJson peut retirer JSON_BASE64_MAGIC des réponses SOA ; SetErrorText, HtmlEscapeShortVar et TLockedList.Find sont nouveaux.
Adoptez le build 2.4.17497 ; ne restez pas sur les builds de transition HTTP.sys 2.4.17464 à 2.4.17496.

2026-10-08 — Le routage proxy mûrit et un piège de sous-classe WebSocket est corrigé

Thu, 08 Oct 2026 07:00:00 +0000

Cette édition étend la détection et le contournement des proxy aux clients socket et REST, puis corrige le routage des redirections, les identifiants proxy, les couches socket et la validation des URI. Elle ajoute aussi des fabriques WebSocket sensibles aux options, le build final réparant une régression de sous-classe dans leurs anciennes surcharges. Les appels directs à GetProxyForUri doivent désormais fournir un TUri au lieu d’un RawUtf8.

GetProxyForUri accepte désormais TUri au lieu de RawUtf8 ; ses appels directs nécessitent une migration du code source.
HTTP_PROXY, HTTPS_PROXY, NO_PROXY, les listes de contournement Windows et REST ProxyName alimentent désormais le routage du client socket.
Les redirections cross-origin, changements d’identifiants proxy et reconnexions non-TCP choisissent maintenant le bon routage et la bonne couche socket.
Les nouvelles surcharges THttpClientWebSockets.WebSocketsConnect acceptent TUri et THttpRequestExtendedOptions ; le build 2.4.17462 corrige le dispatch des sous-classes via les anciennes surcharges.
RemoveMagicFromJson retire JSON_BASE64_MAGIC au début des chaînes JSON sans modifier les chaînes ordinaires.
Adoptez le build 2.4.17462 et évitez de rester sur les builds 2.4.17450 à 2.4.17461.

2026-10-07 — Les états HTTP se stabilisent et la fermeture Unix cesse de supprimer les sockets serveur

Wed, 07 Oct 2026 07:00:00 +0000

Cette édition très orientée réseau achève une vaste réécriture des clients HTTP et des délais, puis corrige les régressions de constructeurs, proxy, WebSocket et backends natifs apparues en chemin. Le framing HTTP distingue désormais la sémantique des réponses HEAD des corps de requête, HTTP.sys sous Windows accepte les uploads chunked et les en-têtes répétés d’authentification ou de cookie, et les clients POSIX ne suppriment plus le socket Unix du serveur à leur fermeture.

POSIX Unix-domain clients no longer unlink the server socket path when they close.
HTTP.sys now accepts chunked request bodies and preserves repeated Set-Cookie and authentication headers.
HEAD and OPTIONS handling now follows message framing; redirected 301 POST and 303 requests also discard their old bodies.
THttpRequestExtendedOptions.GetTimeouts is replaced by ComputeTimeouts, THttpRequest.InternalConnect loses its parameters, and TCrtSocket.ReOpen no longer accepts a timeout.
TRestHttpClientGeneric connection-definition parsing no longer risks an infinite loop.
Land on final build 2.4.17433 rather than an intermediate build from this refactor sequence.

2026-10-06 — L’arrêt asynchrone ferme les fuites et les délais HTTP se séparent par phase

Tue, 06 Oct 2026 07:00:00 +0000

Cette édition réseau a un impact élevé. Les serveurs asynchrones, les tunnels et RTSP-over-HTTP reçoivent une correction coordonnée de la propriété et de l’arrêt, tandis que TSynThreadPool ferme une course pouvant laisser du travail en file d’attente endormi. Les clients HTTP gagnent des délais distincts pour la connexion, l’envoi et la réception, et l’authentification Kerberos côté serveur est regroupée derrière un wrapper multiplateforme avec la suppression d’une méthode publique.

TSynThreadPool now clears a worker's processing state under the pending-queue lock, preventing a queued task from being stranded by a wake-up race.
Async socket, tunnel and RTSP-over-HTTP cleanup now closes file descriptors and transferred connections on failure and shutdown paths.
TCrtSocket and HTTP clients now expose separate connect, send and receive timeouts; use 0, not a negative value, when requesting legacy fallback on a live TCrtSocket.
TServerSspiKeyTab.ComputeServerHeader is removed; migrate direct callers to KerberosServerAuthHeader and prepare a POSIX keytab explicitly when required.
Delphi users should land on build 2.4.17398, which repairs compilation after the timeout constructor refactor.

2026-10-05 — Les tests RTSP-over-HTTP ne partagent plus leurs ports d’écoute

Mon, 05 Oct 2026 07:00:00 +0000

Cette édition est calme et limitée aux tests. Les deux variantes de régression RTSP-over-HTTP reçoivent désormais des paires de ports RTSP et HTTP distinctes, sans changement des unités de production ni des API publiques.

RTSPOverHTTP utilise les ports 3997/3996, tandis que RTSPOverHTTPBufferedWrite conserve 3999/3998.
Le changement reste limité à test.net.proto et ne demande aucune modification des applications Delphi ou FPC.

2026-10-04 — Le binding des tableaux PostgreSQL et les attentes concurrentes sont réparés

Sun, 04 Oct 2026 07:00:00 +0000

Les batches PostgreSQL ne sérialisent plus la capacité inutilisée des tableaux et ne perdent plus les quotes finales, ce qui ferme un échec explicite et une altération silencieuse des valeurs. TPipeStream renvoie maintenant EOF à sa taille déclarée, tandis que le chemin POSIX poll final conserve les timeouts malgré les signaux et l’épuisement temporaire des ressources. Le comptage du thread pool devient atomique ; le reste du lot construit des helpers de task pool partagé et renforce les tests de concurrence.

Visez la build 2.4.17369 au commit 913a072a26c0305bc468a79b658137de5f7d124b.
Les tableaux liés PostgreSQL respectent maintenant ValuesCount et conservent les valeurs finissant par une ou plusieurs quotes.
TPipeStream.Read n’attend plus indéfiniment quand le dernier bloc finit exactement à la taille déclarée du stream.
Les retries POSIX poll conservent le timeout réel et traitent EINTR, EAGAIN et POLLNVAL de façon cohérente.
Le comptage des tâches pending de TSynThreadPool devient atomique, y compris après un échec IOCP et pour le wake-up des waiters.
De nouveaux helpers TSynThreadTasks et TSynTestCase simplifient les workers de test partagés et persistants.

2026-10-03 — L’authentification AES-GCM revient, Tunnel et les files sont reconstruits

Sat, 03 Oct 2026 07:00:00 +0000

Le correctif le plus urgent restaure la vérification GMAC dans le chemin AVX de déchiffrement AES-GCM, qui pouvait accepter un ciphertext, un tag ou des associated data falsifiés sur les systèmes x86-64 éligibles. Le cycle de vie, le handshake et l’arrêt de Tunnel sont reconstruits pour sortir les appels externes des verrous et donner au propriétaire un contrôle déterministe du thread. Les attentes des files et thread pools gagnent les futex OS et de nouvelles API, puis les correctifs requis pour Delphi, Win8+ et Linux.

Visez la build 2.4.17356 au commit 1f7febd219f9cb54175a1f87620e6862e4e670b8.
TAesGcmEngine.Decrypt vérifie désormais GMAC après le chemin AVX single-pass ; les tests rejettent ciphertext, tags et AAD falsifiés.
TTunnelLocal possède et joint son worker, transfère explicitement les sockets et exécute les callbacks de relay hors du state lock.
TSynQueue utilise les futex OS disponibles et ajoute WaitPopReset et Waiters ; les attentes comparées gardent leur polling.
TSynThreadTasks, PendingTasks et WaitFor ajoutent l’exécution gérée et l’attente de fin ; les correctifs finaux couvrent Delphi, Win8+ et Linux.
Les data descriptors ZIP en mémoire, la finalisation des callbacks REST WebSocket et le démarrage THttpApiServer sont réparés.

2026-10-02 — Les deadlocks WebSocket sont éliminés, TLS et les logs d’exception se stabilisent

Fri, 02 Oct 2026 07:00:00 +0000

Le broadcast WebSocket async et le forwarding RTSP n’envoient plus sous un read lock de connexion, supprimant un deadlock lorsqu’un échec d’écriture retire le peer. SChannel traite désormais une fermeture ordonnée pendant l’envoi comme une connexion close et complète la couverture de renégociation TLS 1.3. L’interception des exceptions est aussi corrigée entre threads, sous Delphi Win32 et Delphi POSIX, tandis que la détection AVX-512 vérifie que l’OS sauvegarde réellement l’état ZMM.

Visez la build 2.4.17324 au commit 05e40cd692d391efb62ed97f78f264867477e8e5.
TWebSocketAsyncServer.WebSocketBroadcast et TPostConnection.OnRead ne deadlockent plus lorsqu’un send défaillant supprime une connexion.
Les envois SChannel renvoient nrClosed lors d’une fermeture normale et la réception gère SEC_I_RENEGOTIATE sous TLS 1.3.
Les exceptions concurrentes ne disparaissent plus, les doublons Delphi Win32 sont supprimés et Delphi POSIX gagne l’interception.
IntelAvx512 devient une variable calculée au démarrage et filtrée par XCR0 ; cpuAVX512 identifie le support x86-64-v4 activé par l’OS.
Le test WebSocket http.sys Windows de l’issue #418 est désactivé car il reste instable sous Windows 11.

2026-10-01 — SChannel gagne le mTLS natif et les courses au démarrage serveur sont éliminées

Thu, 01 Oct 2026 07:00:00 +0000

Les serveurs Windows peuvent désormais exiger et valider les certificats clients avec SChannel, via les stores de confiance et callbacks existants de TNetTlsContext. Une seconde série corrige la construction des serveurs HTTP et async afin que leurs threads principaux ne démarrent pas avant les sockets, workers et références croisées. Les équipes utilisant le mTLS Windows ou créant des serveurs sous charge doivent viser la build finale.

Visez la build 2.4.17294 au commit de8d47ea7122b30aa81296a1e5e899a3909e34b1.
Les serveurs SChannel implémentent le mTLS via ClientCertificateAuthentication, CACertificatesFile, CASystemStores, CACertificatesRaw, OnEachPeerVerify et OnAfterPeerValidate.
Les threads des serveurs HTTP et async restent suspendus jusqu’à l’initialisation des sockets, workers et liens d’ownership.
Mettez à niveau pour le chargement de CACertificatesRaw, les erreurs explicites de certificat client absent et les corrections finales SChannel.
Les ajouts publics comprennent acoCreateSuspended, ConsoleLock/ConsoleUnLock et WinCryptTextToBinary.

2026-09-30 — Windows CNG et PKCS#11 progressent tandis que des défauts JSON et socket sont corrigés

Wed, 30 Sep 2026 07:00:00 +0000

Cette édition largement consacrée à la cryptographie introduit un backend de certificats Windows CNG, complète le déchiffrement d’enveloppes RSA via CNG et PKCS#11 et répare une longue séquence d’import/signature PKCS#11. Elle corrige aussi une lecture JSON hors limites dans les logs, borne une boucle socket, fiabilise le cookie de session derrière proxy et sépare les timeouts HTTP de connexion, d’envoi et de réception.

Visez la build 2.4.17268 au commit 80bc2689df777dadbe1f8af745096eeb13205ef7.
Ajoutez mormot.crypt.win aux uses si le code référence TAesAbstractApi ou ses descendants CryptoAPI AES, déplacés depuis mormot.crypt.core.
Windows reçoit TCryptCertAlgoCng, ICryptCertCng et TCryptCertCng.LoadPkcs12 pour les stores, cartes/KSP et identités PFX transitoires.
PKCS#11 reçoit le déchiffrement RSA envelope et davantage de signatures, mais TPkcs11 n’est plus thread-safe ; protégez le catalogue avec TCryptCertAlgoPkcs11.Lock/UnLock.
Mettez à niveau pour la lecture hors limites de TJsonWriter.AddEscapeBuffer, la boucle infinie de TCrtSocket.TrySockRecv, les GPF CNG/PKCS#11 et les corrections ABI OpenSSL.
THttpClientSocket.SetTimeouts sépare les budgets connect, send et receive ; TRestHttpClientSocket applique les trois.

2026-09-29 — SChannel active TLS 1.3 tandis que le support Windows CNG se consolide

Tue, 29 Sep 2026 07:00:00 +0000

Cette série centrée sur Windows modifie la politique protocolaire SChannel par défaut, partage les credentials serveur entre connexions HTTPS acceptées et ajoute un support important de CNG, des certificate stores et de msLAPS. Les derniers commits corrigent aussi les compilations Delphi 7 et Delphi 13, évitent les stubs CNG de Wine et réparent l’ownership des clés privées.

Visez la build 2.4.17208 au commit 18e7d88c0083b279402c59019c030abdfe39e3e1.
SChannelEnableTls13 vaut désormais true par défaut sur Windows 11 et Windows Server 2022 ou plus récent ; passez-le à false avant l’initialisation si ce déploiement n’est pas voulu.
Les serveurs HTTPS SChannel acquièrent un credential serveur partagé, conservé jusqu’à la libération du dernier contexte TLS accepté.
TNetTlsContext peut fournir à SChannel un PCCERT_CONTEXT ou un PFX protégé, et ReleaseBuffers libère maintenant les buffers SChannel inactifs.
Les wrappers TNCrypt, TWinCertStore et TWinCertCngKey exposent clés CNG, certificate stores, signature, unprotection de secrets et déchiffrement msLAPS.
Wine évite sa couche CNG incomplète, tandis que Delphi 7 et Delphi 13 reçoivent des correctifs de compilation explicites.

2026-09-28 — L’expiration des moteurs de script conserve toute sa plage

Mon, 28 Sep 2026 07:00:00 +0000

Un correctif arithmétique d’une ligne empêche les grandes valeurs de TThreadSafeManager.EngineExpireTimeOutMinutes de déborder lors de leur conversion en millisecondes. Les serveurs Windows SChannel incluent aussi l’erreur système dans l’exception levée lorsqu’aucun certificat ne peut être sélectionné dans le store. Les pools de moteurs configurés avec une longue durée de vie devraient prendre le premier correctif ; le changement TLS est seulement diagnostique.

Visez le head 5a1509b805bcdc7f239c683bd0e68ab9700c1247, build 2.4.17189.
EngineExpireTimeOutMinutes multiplie désormais les minutes en millisecondes avec Int64, sans débordement 32-bit pour les grandes valeurs.
Un échec de recherche de certificat SChannel lève désormais ESChannel avec le texte et le code Windows au lieu d’un message générique.

2026-09-26 — Les redirects URI se stabilisent, heartbeat et sessions se rétablissent

Sat, 26 Sep 2026 07:00:00 +0000

La pile URI est réécrite selon RFC 3986 avec résolution des Location relatives, puis stabilisée jusqu’à la build 2.4.17187 avant son adoption par les redirects HTTP. Les utilisateurs en production reçoivent aussi le correctif successeur des heartbeats WebSocket async désactivés, des timeouts Signed URI et REST corrigés, un proxy cache plus sûr au démarrage et à l’arrêt, et les écritures IOCP directes optionnelles sous Windows. Les appels externes à ESynSspi.RaiseLastOSError doivent migrer.

Visez le head 215c7bbd240419735ad7e89f5d35ddc9cfeb8b4d, build 2.4.17187, pour la séquence URI et redirect complète.
La build 2.4.17171 rétablit les callbacks heartbeat WebSocket async désactivés par la comparaison idle précédente.
L’ordre des timestamps Signed URI et le calcul du timeout REST sont corrigés pour les services longs et le rollover 32-bit.
Les proxy caches Windows peuvent écrire directement via IOCP et évitent des races de démarrage et suppression.
Remplacez les appels externes ESynSspi.RaiseLastOSError par ESynSspi.RaiseSspiError.
Évitez 2.4.17162–2.4.17170 pour heartbeat et 2.4.17176–2.4.17186 pour la séquence URI incomplète.

2026-09-25 — SChannel et les caches HTTP se stabilisent, mais les heartbeats régressent

Fri, 25 Sep 2026 07:00:00 +0000

Windows SChannel reçoit des corrections de concurrence, handshake, renégociation et mémoire, tandis que les clients HTTP gagnent des restrictions de redirection optionnelles et que les deux proxy caches corrigent les statuts. Le timing heartbeat WebSocket async passe à HeartbeatDelay, mais deux retouches laissent une comparaison finale qui désactive ces callbacks après le seuil mémoire par défaut. Les implémentations INetTls externes et le code utilisant LastOperationIdleSeconds doivent aussi migrer.

Visez le head c94dba6c18f6a0c5b225734af210da678cc59167, build 2.4.17161, pour les correctifs SChannel, redirect et cache terminés.
Les callbacks heartbeat WebSocket async sont désactivés après le seuil mémoire par défaut ; mettez LastOperationReleaseMemorySeconds à 0 en attendant la correction.
Les implémentations INetTls externes doivent ajouter ReleaseBuffers et LastOperationIdleSeconds doit migrer vers GetLastOperationIdleSeconds.
THttpRequestExtendedOptions.RedirectOptions ajoute purge cross-origin et rejet de redirects en gardant le comportement libre par défaut.
Le proxy cache refuse les statuts GET invalides, interrompt les lecteurs progressifs en erreur et vérifie la taille finale.
Évitez 2.4.17143 et les builds redirect incomplètes 2.4.17159–2.4.17160.

2026-09-24 — Les backends TLS se stabilisent après une réparation complète

Thu, 24 Sep 2026 07:00:00 +0000

OpenSSL et Windows SChannel reçoivent une large série de corrections pour les callbacks, la policy certificat, les I/O asynchrones, le shutdown et les erreurs. Les insertions ORM externes s’arrêtent si SELECT max(ID) échoue au lieu de reprendre les ID à un, et l’allocateur SQLite restaure l’alignement requis sur Android ARM64. Ce lot touche la production : prenez le head final, pas une build TLS intermédiaire.

Visez le head 34c5672df4ab31378524d2868b8482b408eafbdd, build 2.4.17135.
Un échec max-ID ORM retourne 0 et bloque l’insertion au lieu d’essayer des ID dupliqués depuis un.
OpenSSL reçoit des correctifs liés pour callbacks, autorités mTLS, retries async, passwords, SNI et shutdown.
SChannel est réécrit pour les I/O async bufferisées puis corrigé pour handshake, TLS 1.3, shutdown, ClientHello et erreurs finales.
L’allocateur SQLite de secours utilise un header de 16 octets pour aligner Android ARM64.
Évitez 2.4.17117 et les séquences OpenSSL 2.4.17083–2.4.17113 et SChannel 2.4.17119–2.4.17134.

2026-09-23 — L’historique des exceptions est reconstruit et OpenSSL reçoit un nouveau correctif I/O

Wed, 23 Sep 2026 07:00:00 +0000

Le chemin d’interception des exceptions est largement reconstruit après l’identification d’un GPF aléatoire et d’un modèle mémoire/threading non sûr dans l’ancien stockage des dernières exceptions. La séquence se termine par une récupération newest-first correcte et une stack bornée par exception. Les retries Send/Receive et le reporting des erreurs de configuration OpenSSL reçoivent deux correctifs finaux, tandis que FPC gagne une meilleure capture de stack et une réparation du seed déterministe ARM32.

Visez la build 2.4.17082 au commit 03ab5c85c4b2982c96b7f38d683dbff85e016f77.
GetLastException et GetLastExceptions utilisent un ring verrouillé de 16 entrées avec une copie privée de stack par exception.
OpenSSL ne retente que WANT_READ/WANT_WRITE, impose cinq secondes et rapporte les erreurs de setup sans détourner SSL_get_error.
La méthode de classe publique TDebugFile.AddLog est supprimée ; les appelants doivent migrer vers les API de location ou StackTrace restantes.
KEEP_STACKFRAMES conserve les réglages de stack frames du projet, surtout pour le debug FPC POSIX, avec un coût de performance documenté.
FPC Windows consomme la stack capturée par le RTL et FPC ARM32 stabilise le QWord de TLecuyer.SeedGenerator.

2026-09-22 — Vérification TLS, formatage sûr et réseau mobile Delphi arrivent ensemble

Tue, 22 Sep 2026 07:00:00 +0000

Les utilisateurs OpenSSL doivent prendre toute la séquence transport : retries socket croisés, vérification hostname par défaut et purge de la file d’erreurs sous OpenSSL 1.x/3.x. Une régression d’une build dans FormatAdder pouvait écrire via une destination invalide pour une sortie vide. Delphi Android/iOS gagnent des backends HTTP System.Net, Delphi ARMv7 devient utilisable et TXmlParser accepte les DOCTYPE simples sans charger les entités DTD.

Visez la build 2.4.17065 au commit 743a53fd4cb3af700463b0d143581ce17c6c8b31.
Les clients OpenSSL vérifient ServerAddress quand HostNamesCsv est vide ; OpenSSL 1.x/3.x purge les erreurs avant connect, accept, read et write.
Évitez 2.4.17025–2.4.17063 pour la séquence OpenSSL incomplète et 2.4.17047 pour le chemin d’overflow de FormatAdder avec sortie vide.
Delphi Android et iOS peuvent utiliser TDelphiNetHttp, TRestHttpClientDelphiNet et TSqlDBDelphiNetConnectionProperties via le TLS de l’OS.
Delphi Android ARMv7 reçoit les stubs ABI, le JSON aligné pour les packed fields et le support des appels variadiques.
TXmlParser ignore les DOCTYPE externes simples par défaut ; utilisez xpoRejectDocType pour les rejeter, les subsets internes restant non pris en charge.

2026-09-21 — OpenSSL async réessaie correctement et TSynLog réduit son verrou d’écriture

Mon, 21 Sep 2026 07:00:00 +0000

Les clients et serveurs non bloquants utilisant OpenSSL réessaient maintenant SSL_connect et SSL_accept après WANT_READ ou WANT_WRITE au lieu de les traiter comme fatals. Le commit final conserve le premier résultat SSL_get_error afin de signaler la vraie cause d’un échec. TSynLog déplace aussi la collecte de stack trace et d’informations système hors de son verrou writer, avec moins de contention mais un état par thread plus grand et des suffixes bornés.

Visez la build 2.4.17024 au commit 13c7b4dd94b23c25d51e5b0ab9b6e207cb039207.
Les handshakes TLS OpenSSL sur sockets async réessaient WANT_READ et WANT_WRITE pendant cinq secondes au maximum.
Évitez les builds 2.4.17020 à 2.4.17023 : la nouvelle boucle relit SSL_get_error lors d’un échec final ; 2.4.17024 transmet le code déjà capturé.
TSynLog pré-rend les stack traces et informations système configurées avant de prendre son verrou par writer.
Le record thread TSynLog grandit de 320 octets ; les suffixes stack trace sont limités à 255 octets et les informations système à 63.
AppendSysInfo est un nouveau helper public qui ajoute les informations système sans vider la ShortString existante.

2026-09-20 — L’inspection des logs préserve les fichiers MAB et gagne le traçage des appelants

Sun, 20 Sep 2026 07:00:00 +0000

Cette édition renforce surtout les outils autour de TSynLog sans modifier les protocoles backend. Les lecteurs de logs ne plantent plus sur des données de profiler vides ou des sélections de texte brut, et TDebugFile ne supprime plus un fichier .mab externe illisible. FreeBSD, FPC et Android reçoivent des corrections socket et POSIX, tandis que la découverte du symbole appelant passe désormais par TDebugFile sur tous les compilateurs pris en charge.

Visez la build 2.4.17019 au commit fc996116ae8a2534c5e763ac180649cdb78013ab.
TDebugFile.Create ne supprime plus un fichier .mab externe illisible fourni via aExeName.
TSynLogFile et TSynLogFileView gèrent sans plantage les logs sans sllEnter, les lignes texte brut copiées et un filtre de niveaux vide.
Le dimensionnement des sockets UNIX FreeBSD et les corrections de compilation FPC, BSD et Android sont complets dans la build finale.
TDebugFile.AppendCallerShort est nouveau ; TSynLog.Enter ou Log sans texte résout aussi l’appelant sous FPC, comme sous Delphi.
Le package Lazarus conserve maintenant mormot.crypt.pkcs11 lorsqu’il régénère mormot2.pas.

2026-09-19 — Les sockets POSIX survivent aux signaux tandis que TSynLog change son ABI de format

Sat, 19 Sep 2026 07:00:00 +0000

Cette série cross-platform est volumineuse. Les attentes, accept et I/O socket POSIX reprennent après EINTR sans allonger les deadlines, tandis que Delphi AArch64 gagne le dispatch d’interfaces, les variants late-bound et un cache temporel bien aligné. TSynLog remplace volontairement PUtf8Char par RawUtf8 dans ses API formatées et pré-rend hors verrou ; prenez les correctifs finaux car la build 2.4.16999 peut dépasser son buffer stack de 4 Ko.

Visez la build 2.4.17002 au commit 4ef9dc663bbf00ad1920c83a7274e3676610b37f.
Ne déployez pas la build 2.4.16999 : un log formaté proche de 4 Ko avec instance peut dépasser le buffer stack TSynLog.
Migrez les paramètres de format TSynLogProc, Log, DoLog, Enter, EnterLocal et ManualEnter de PUtf8Char vers const RawUtf8.
Les I/O socket POSIX, poll, epoll et accept reprennent après EINTR en conservant les deadlines ; prenez la séquence complète plutôt que les builds 2.4.16947 à 2.4.16964.
Delphi AArch64 gagne DispInvoke et les appels d’interface sur Android/iOS, avec correction de l’alignement du verrou GlobalTime.
Delphi POSIX corrige le blocage des ressources ordinales au démarrage et le décodage inversé des resourcestring courtes/longues.

2026-09-18 — Les verrous par writer arrivent avec des réparations de fallback indispensables

Fri, 18 Sep 2026 07:00:00 +0000

TSynLog remplace son verrou d’écriture global au processus par un verrou par writer, réduisant la contention mais révélant aussi des chemins d’échec réparés plus tard dans la même série. Les utilisateurs directs de TX64CpuFeatures doivent supprimer les références à cpuSSSE3, tandis que les cibles x86-64 compatibles sélectionnent désormais automatiquement le parser SSSE3 des nombres JSON. Les viewers de logs, les outils de diagnostic et les appelants de AppendShortByteHex reçoivent aussi des améliorations concrètes de correction et d’API.

Visez la build 2.4.16943 au commit 0b26918230d72e33b79365a79c1bc444ec3029b1 ; évitez la séquence TSynLog incomplète des builds 2.4.16937 à 2.4.16941.
TSynLog sérialise maintenant les écritures par logger plutôt qu’avec un verrou d’écriture global, réduisant la contention entre logs indépendants.
La build 2.4.16942 répare les chemins d’échec de Enter, EnterLocal et ManualEnter introduits par le refactoring des verrous.
TX64CpuFeatures.cpuSSSE3 est supprimé ; utilisez cfSSSE3 dans CpuFeatures pour détecter cette capacité.
Les cibles Delphi et FPC x86-64 non-PIC compatibles sélectionnent désormais automatiquement GetNumericVariantSsse3 pour les nombres JSON.
La recherche dans les fichiers TSynLogFile en texte brut fonctionne à nouveau, et AppendShortByteHex accepte sans débordement les PtrUInt supérieurs à 255.

2026-09-17 — Le deadlock au démarrage des logs est corrigé, avec TLS 1.3 et POSIX stabilisés

Thu, 17 Sep 2026 07:00:00 +0000

L’échec de création d’un fichier de log pouvait relancer la journalisation via un writer non initialisé et laisser SynLogGlobalLock verrouillé, bloquant ensuite tous les threads de log. Cette édition complète aussi la configuration des suites TLS 1.3, corrige les retours Currency via la répartition d’interfaces sous FPC POSIX et supprime une boucle active avec /dev/null sous systemd. Les appelants POSIX qui utilisent directement WaitReadPending doivent s’adapter à son nouveau résultat entier, et les appelants bas niveau du parser numérique x86-64 doivent vérifier les points d’entrée SSSE3 renommés.

Visez la build 2.4.16922 au commit cdb7dad52a6989d41ce8405a15d26928e0829ca2 ; elle inclut les corrections finales des logs et de l’arrêt Linux.
TSynLog ne bloque plus tous les threads de log quand la création du fichier échoue avec la journalisation des exceptions activée.
Les backends OpenSSL configurent maintenant TLS 1.3 via TNetTlsContext.CipherSuites et SSL_CTX_set_ciphersuites.
La répartition d’interfaces FPC POSIX renvoie maintenant Currency via le chemin x87 FP0 au lieu de le traiter comme un résultat binary64.
WaitReadPending renvoie désormais -1, 0 ou 1 sous POSIX ; les appelants directs doivent remplacer l’usage booléen par une comparaison explicite.
Les instances THttpRequestContext réutilisées effacent maintenant AcceptEncoding, évitant de transmettre les préférences de compression à la requête suivante.

2026-09-16 — Le parsing numérique SSSE3 arrive sous Delphi et FPC, avec des corrections de limites

Wed, 16 Sep 2026 07:00:00 +0000

Le changement principal est un chemin assembleur x86-64 partagé pour GetExtended et GetNumericVariantFromJson sur les cibles Delphi et FPC compatibles SSSE3, avec des fallbacks scalaires et une matrice de régression élargie. Des corrections ultérieures réparent le parsing de MIN_INT64 avec fraction et la cohérence FP80. Le reporting de version macOS prend aussi en charge Golden Gate, mais sa première correspondance de kernel est corrigée plus tard dans cette même édition ; les utilisateurs en production doivent donc viser la build 2.4.16897 plutôt qu’une build intermédiaire.

Passez à la build 2.4.16897 ; la série assembleur numérique reçoit des corrections MIN_INT64 et FP80 avant le head final.
GetExtended et GetNumericVariantFromJson utilisent désormais l’assembleur SSSE3 sur les cibles Delphi Win64 et FPC Win64/Linux x86-64 compatibles.
La build 2.4.16888 corrige le parsing de -9223372036854775808.0 dans les chemins Pascal et assembleur x86-64.
Le chemin FP80 dédié conserve la précision de mantisse 64 bits et la build 2.4.16891 harmonise les résultats signés hors plage.
MacKernel et les métadonnées Golden Gate sont des ajouts publics ; les builds 2.4.16892–2.4.16895 utilisent une correspondance Darwin incorrecte corrigée en 16896.
GetInteger et GetCardinal consomment maintenant deux chiffres par boucle sans changer leurs signatures publiques.

2026-09-15 — Les parseurs numériques Pascal sont réécrits autour de chemins entiers plus rapides

Tue, 15 Sep 2026 07:00:00 +0000

Les implémentations Pascal derrière GetExtended et GetNumericVariantFromJson maintiennent désormais les entiers courants et les décimaux courts dans des boucles plus resserrées, tout en conservant des contrôles pour les longues mantisses, les exposants et les limites Int64. Les tests GetExtended rendent aussi explicites la normalisation du signe de zéro et plusieurs fractions de 18 à 20 chiffres. Aucune migration de signature n’est requise, mais les applications dépendant du type numérique exact des variants ou de cas limites flottants doivent valider la build 2.4.16865.

Passez à la build 2.4.16865 et retestez les conversions numériques qui dépendent du type variant exact ou de l’arrondi aux limites.
Le chemin Pascal hors Win32 de GetExtended a été simplifié deux fois, avec des boucles distinctes pour les 18 premiers chiffres, la suite contrôlée contre les débordements, les fractions et les exposants.
GetExtended normalise maintenant volontairement -0 et -0e400 en zéro numérique sur son chemin Pascal, conformément au comportement fixé par les nouveaux tests.
GetNumericVariantFromJson déroule ses premiers chiffres et réécrit la sélection Int64, Currency et Double sans modifier sa signature publique.
mormot.core.base ajoute la constante publique MIN_INT64 et le membre overlay TSynVarData.VPtrInt.

2026-09-14 — La propriété des requêtes DHCP et le parsing numérique court sont corrigés

Mon, 14 Sep 2026 07:00:00 +0000

Les serveurs DHCP suivent maintenant plus fidèlement l’état du client et les règles de sélection du serveur : les trames NAK sont nettoyées, les requêtes désignant un autre serveur sont ignorées et les anciennes adresses statiques sont rejetées. Une correction ultérieure empêche les options d’adresse mal formées d’être prises pour de vraies valeurs IPv4. Par ailleurs, GetExtended ne lit plus quatre octets depuis une entrée invalide d’un ou deux caractères ; les services qui analysent du texte numérique non fiable doivent donc prendre cette édition.

Passez à la build 2.4.16861 ; les builds 2.4.16857 à 2.4.16859 peuvent interpréter à tort les options DHCP 50 ou 54 mal formées comme de vraies adresses.
GetExtended rejette maintenant les tokens invalides courts avant son contrôle NAN/INF sur quatre octets, évitant une lecture potentielle au-delà du texte fourni.
Une requête DHCP dont server-identifier désigne un autre serveur est ignorée et comptée par la nouvelle métrique dsmDroppedOtherServer.
Un client qui demande explicitement une adresse ne correspondant plus à sa réservation statique reçoit maintenant un NAK au lieu d’un ACK de renouvellement.
Les trames DHCPNAK omettent les options de bail, réseau, boot et rule, conservent le chaddr du paquet et sont diffusées en broadcast en l’absence de relais.
DhcpIP4 renvoie maintenant zéro pour les options de quatre octets absentes ou mal formées, achevant les nouveaux contrôles REQUEST sans faux NAK ni abandon.

2026-09-13 — Le parsing décimal atteint l’arrondi IEEE exact après une régression sur zéro

Sun, 13 Sep 2026 07:00:00 +0000

Cette édition poursuit la stabilisation des conversions numériques avec des corrections de précision visibles en production dans les deux sens. DoubleToAscii gère maintenant correctement la notation scientifique et l’arrondi du sticky bit sur 64 bits, tandis que GetExtended accepte les exposants limites et arrondit les fractions décimales courantes vers le double IEEE le plus proche. GetNumericVariantFromJson rétablit aussi le traitement numérique de 0.0 ; les backends qui échangent des nombres JSON ou persistent des flottants en texte doivent donc prendre la série complète.

Passez au commit c9eff241 de la build 2.4.16851 ; il inclut le merge final sur l’arrondi décimal après la dernière incrémentation de version.
GetNumericVariantFromJson analyse de nouveau 0.0 et les formes fractionnaires entièrement nulles comme un zéro numérique au lieu d’échouer la conversion.
GetExtended et GetNumericVariantFromJson renvoient maintenant le double IEEE le plus proche pour des fractions courantes comme 1.2, au lieu d’une valeur supérieure d’un ULP.
DoubleToAscii corrige la ponctuation de la notation scientifique et applique l’arrondi sticky bit sur CPU64, améliorant les allers-retours exacts entre flottants et texte.
Le chemin GetExtended hors WIN32DELPHI traite maintenant les limites du plus petit subnormal et du plus grand double fini sans échec prématuré.