curl 8.23.0 est sorti : vérifier l’installation utilisée et les dépendances SMB

curl 8.23.0 est sorti le 14.10.2026. Un curl à jour dans le terminal ne prouve pas que la bibliothèque libcurl d’une application métier a aussi été actualisée. Les petites équipes informatiques qui gèrent scripts, conteneurs et applications de fournisseurs doivent identifier la copie utilisée, son fournisseur et les critères de recette. Autre question concrète : une tâche dépend-elle encore de SMB ?

Ce qui est confirmé le 14 octobre

Le tableau des versions indique 8.23.0 daté du 14.10.2026 et la page de téléchargement propose ses archives sources. [1][2] La formulation antérieure sur une sortie prévue est donc dépassée ; 8.23.0-rc3 n’est pas la version normale. Des sources disponibles ne prouvent ni la disponibilité dans votre canal de paquets ni la mise à jour d’une bibliothèque embarquée. Le numéro de version ne suffit pas non plus à évaluer les correctifs rétroportés d’une distribution. Le journal des modifications indique la suppression du support SMB. [3] Les tâches utilisant smb:// ou smbs:// nécessitent un inventaire ciblé et une recette avant migration. Cela concerne curl, pas automatiquement le SMB du système d’exploitation.

Prérequis et limites

Il faut un accès en lecture à l’inventaire logiciel et aux tâches planifiées, un responsable applicatif et un environnement de test séparé avec des données non confidentielles. L’inventaire ne nécessite aucune installation administrateur ni remplacement de fichiers système. Les mises à jour ultérieures doivent suivre le canal pris en charge. Une libcurl livrée avec une application n’est pas forcément celle de l’outil en ligne de commande. [4] Ne copiez pas de binaires ou de DLL provenant d’autres sources dans les répertoires applicatifs.

Cinq étapes pour préparer le changement

  1. Inventoriez les usages, pas seulement les versions. Pour chaque tâche importante, notez application, contexte d’exécution, chemin, fournisseur du paquet, responsable et finalité métier. Distinguez services, tâches planifiées, agents CI et conteneurs. Le chemin trouvé dans votre terminal personnel ne prouve pas ce qu’un service lance. Pour un logiciel d’éditeur, demandez la liste des composants ou une confirmation du fournisseur ; un nom de fichier ne suffit pas.
  2. Identifiez l’exécutable effectivement utilisé. Sous Windows, la requête PowerShell en lecture seule Get-Command curl.exe -All aide à trouver les exécutables ; sous Linux/macOS, command -v curl affiche la résolution du shell actuel. Lancez le binaire approuvé et fiable par son chemin complet avec --version. curl --version fournit notamment les bibliothèques, protocoles et fonctionnalités. [5] Relevez aussi le moteur TLS et l’architecture. Cette requête n’inventorie ni les autres processus ni les bibliothèques incorporées séparément. command -v peut aussi renvoyer une fonction du shell ou un alias. Avant de consulter la version, vérifiez que le chemin consigné désigne bien le fichier exécutable approuvé.
  3. Attribuez un circuit de mise à jour à chaque installation. Paquets système, images de base, outils autonomes et applications d’éditeurs ont chacun besoin d’un responsable. Les distributeurs peuvent rétroporter des correctifs ; le numéro upstream seul ne prouve donc pas l’état des correctifs. Le jour de la sortie, comparez avis du fournisseur, révision du paquet et disponibilité réelle. Ne remplacez pas vous-même libcurl dans une application d’éditeur inchangée. Documentez les validations manquantes avec un responsable et une date de réexamen. [7]
  4. Préparez une petite matrice de tests métier. Choisissez un téléchargement autorisé, un cas nécessaire de proxy/authentification et une réponse d’erreur contrôlée dans l’environnement de test. Définissez auparavant statut HTTP, contenu attendu et code de sortie : un processus réussi ne garantit pas un résultat métier correct. Testez uniquement les protocoles nécessaires, sans interroger des destinations de production arbitraires. Aucun secret dans les lignes de commande ou journaux partagés. Comparez avant et après avec la même configuration. Nouveau pour 8.23.0 : recherchez smb:// et smbs:// dans les scripts et configurations autorisés, sans copier les identifiants. Une occurrence est une dépendance potentielle, pas une preuve d’usage actif. Consignez la tâche, la copie réelle de curl et le responsable. Si SMB disparaît de la liste des protocoles après migration, il s’agit d’un changement documenté, pas d’une erreur TLS. Convenez avec le responsable applicatif d’un client SMB pris en charge ou d’un autre transfert adapté ; ne changez pas de protocole à l’aveugle. La recette exige que le même scénario autorisé fournisse les données et la gestion des erreurs attendues via la nouvelle solution. [3]
  5. Planifiez le changement seulement après validation. Prévoyez un paquet stable pris en charge, une sauvegarde de configuration, un créneau de maintenance et un retour arrière vérifié. Réservez les préversions aux essais de compatibilité facultatifs et isolés. Modifiez d’abord une tâche représentative, puis vérifiez chemin, bibliothèque et résultat dans le contexte réel du service ou du conteneur. Étendez seulement après recette. Un ancien conteneur ou processus persistant peut encore utiliser l’ancienne version ; planifiez les redémarrages nécessaires.

Diagnostiquer sans désactiver les contrôles TLS

Si la vérification des certificats échoue après le changement, comparez horloge, nom du serveur, chaîne de certificats, moteur TLS et magasin de confiance. Des compilations différentes peuvent utiliser des magasins d’AC différents. Ne masquez pas l’erreur avec --insecure ou -k : curl vérifie les certificats par défaut. [6] Obtenez les certificats d’AC internes uniquement par le circuit autorisé de l’entreprise. En cas d’authentification ou de redirection inattendue, arrêtez, conservez un constat expurgé et contactez l’exploitant responsable.

Validation et retour arrière

Le changement est terminé lorsque la tâche de production utilise de manière démontrable l’installation approuvée, passe la matrice et conserve une supervision ainsi qu’une gestion des erreurs opérationnelles. Consignez révision du paquet, heure d’exécution et validation. En cas de régression, utilisez le retour arrière documenté du paquet ou de l’application, sans échanger des bibliothèques isolées. Revenir à une version vulnérable n’est pas une solution durable : suspendez le flux si nécessaire et convenez d’une mesure limitée dans le temps avec la sécurité. Les traitements modifiant des données nécessitent aussi une restauration cohérente de celles-ci. Modèle de journal, pas un test réalisé : « tâche ; compte de service/conteneur ; chemin complet ; révision du paquet/fournisseur ; dépendance de protocole ; contenu/code de sortie attendus ; résultat ; validation ; retour arrière ». Sans options adaptées, une réponse HTTP d’erreur ne produit pas automatiquement un code d’erreur curl ; contrôlez séparément statut, contenu et code de sortie. [5]

Date et sources

État au 16.10.2026. Guide rédactionnel fondé sur les sources, sans test de compatibilité ou de sécurité réalisé par nos soins. Aucun essor spécifique des recherches sur curl 8.23.0 ou SMB n’est affirmé ; aucun lien d’affiliation. Vérifiez séparément la sortie du projet et la disponibilité locale des paquets ; canal pris en charge et autorisation restent nécessaires.