L’annonce indique que les images macOS 26 et Xcode 27 doivent remplacer la commande openssl par défaut, auparavant issue d’OpenSSL 3.x, par celle d’OpenSSL 4.x. Le déploiement progressif est prévu du 2 au 8 novembre 2026. Ces dates et ces images délimitent le changement annoncé ; elles ne permettent pas d’affirmer que toute machine Mac ou toute image macOS est concernée. Pour les statuts effectifs, consultez l’annonce puis les publications d’images au moment où votre exécution a lieu.

L’annonce indique également que la version 3 reste accessible au moyen d’un chemin Homebrew versionné et recommande de sélectionner explicitement une version lorsque le workflow en dépend. Ce conseil concerne les pipelines concernés par ce changement ; il ne signifie pas que toutes les tâches échoueront après la mise à jour. Votre décision doit s’appuyer sur les appels et les résultats de votre propre pipeline. Les informations officielles sur le changement et la sélection de version sont le point de départ, pas un verdict de compatibilité.

Pour situer rapidement le risque, distinguez ces situations :

Déterminer si votre image figure dans le périmètre

Un libellé runs-on ne suffit pas à démontrer qu’une exécution a utilisé un contenu d’image précis. Examinez la définition du workflow, le journal de travail et l’image effectivement publiée. La syntaxe de sélection d’un runner figure dans la référence GitHub Actions à runs-on, tandis que la documentation sur les runners hébergés aide à comprendre les catégories de runners disponibles.

Ne transposez pas automatiquement la modification annoncée à un Mac auto-hébergé. Sa configuration dépend des outils installés et du PATH défini par votre système d’exploitation, votre compte d’exécution, votre agent ou le script de lancement. Une image Xcode, une image macOS d’un autre niveau et un hôte autogéré doivent être identifiés séparément.

Le premier piège consiste à vérifier que openssl existe, puis à conclure que le workflow utilise la version attendue. La présence du programme ne révèle ni son emplacement, ni sa version principale, ni la sélection faite dans chaque étape. De même, plusieurs installations peuvent coexister ; seule l’analyse de la commande effectivement résolue par le shell et par le processus de build permet de savoir laquelle intervient.

Comment savoir si le script utilise OpenSSL 3 ou OpenSSL 4 ? Ajoutez temporairement des contrôles au même endroit que la commande concernée, et non uniquement au début du workflow :

echo "PATH=$PATH"
command -v openssl
type -a openssl
openssl version -a
openssl version -d

command -v révèle la commande trouvée par le shell ; type -a permet de repérer plusieurs possibilités ; openssl version -a affiche les informations de version et de compilation. La documentation OpenSSL décrit les options de la commande openssl version. Gardez ces sorties dans le journal de diagnostic et comparez-les avec l’étape qui échoue.

Pour rendre le test reproductible, lancez les contrôles dans le même shell, le même travail et le même contexte que l’étape incriminée. Un changement de PATH entre deux étapes, un script qui ajuste son environnement ou un outil qui appelle son propre binaire peuvent invalider une vérification faite ailleurs. Si la commande est choisie par un script de construction, ajoutez un journal non sensible juste avant son invocation.

Dans un workflow, les commandes d’écriture de sortie ou de groupe de journalisation doivent respecter les mécanismes documentés par GitHub. Consultez la référence des commandes de workflow avant d’ajouter des marqueurs ou de transmettre une valeur entre étapes. Ne mettez pas de secret dans une sortie destinée au journal : masquez toute donnée sensible et ne consignez jamais une clé privée.

Une différence potentielle de comportement ne constitue pas la preuve qu’un certificat ou une clé est devenu incompatible. La bonne question est plus limitée : la commande et les options utilisées par votre procédure de signature produisent-elles encore le résultat attendu avec le binaire sélectionné ? Cette validation doit employer le processus de l’équipe, dans un travail isolé, sans exposer le matériel de signature.

Quelles étapes de certificat et de clé faut-il refaire après une bascule ? Rejouez les opérations que votre pipeline exécute réellement : lecture et inspection des certificats, traitement des clés, vérification des formats d’entrée et de sortie, puis étape de signature qui dépend de ces éléments. Relevez le code de retour, la sortie attendue et l’étape exacte du workflow. Les options utilisées doivent être confrontées aux commandes et au guide de migration OpenSSL, car une incompatibilité éventuelle dépend du couple version, option et format, pas seulement du nom de l’outil. Le guide officiel de migration OpenSSL est une référence pour examiner les changements pertinents.

Ne testez pas une chaîne de signature en copiant un certificat privé ou une clé dans un nouveau journal, un artefact partagé ou un script temporaire. Utilisez le mécanisme de secrets déjà approuvé par l’organisation et limitez l’accès au travail de validation. Conservez la preuve fonctionnelle — tâche réussie, résultat attendu et identité de la version — sans conserver le contenu secret. Si vous ne pouvez pas exécuter la signature en sécurité dans un environnement isolé, la validation n’est pas suffisante pour autoriser la bascule.

Scénario d’équipe : un build de test réussit après la modification du runner, mais l’étape de signature n’a pas été exécutée, car la branche de validation ne publie pas d’application. Ce résultat confirme uniquement le build couvert par ce travail. Il ne démontre ni la compatibilité des certificats ni le fonctionnement de la publication. Dans ce cas, gardez la version actuelle pour le parcours de diffusion et ajoutez un test de signature contrôlé avant de déclarer le changement accepté.

Un test de connexion peut échouer à cause de la commande cliente, mais aussi d’un endpoint, d’un certificat distant, d’identifiants, d’un proxy ou d’une politique réseau. Attribuer immédiatement un échec TLS à OpenSSL 4 risque de masquer la véritable cause. Commencez par relever l’hôte visé, le moment de l’échec, le code de retour et le texte non sensible du journal, puis comparez l’exécution avec la version explicitement choisie.

Comment traiter une assertion de script qui ne passe plus ? Recherchez dans le dépôt les appels à openssl, puis repérez les scripts qui analysent sa sortie, ses options ou ses valeurs par défaut. Une assertion fondée sur une ligne de texte exacte est fragile : elle peut échouer sans que la négociation TLS soit invalide. Comparez d’abord la sortie observée avec la sortie attendue et localisez la commande à l’origine de cette différence.

Pour reproduire uniquement le contrôle TLS concerné, s_client permet d’examiner une connexion client, mais les options et les résultats doivent être interprétés en fonction de votre endpoint et de votre configuration. Référez-vous à la documentation OpenSSL de s_client. N’ajoutez pas de paramètres de diagnostic qui désactivent une vérification de certificat dans le chemin de production : un test permissif peut sembler réussi tout en supprimant précisément le contrôle que vous devez valider.

Consignez séparément les observations suivantes :

• Résolution et accès réseau : l’hôte est-il joignable depuis ce runner, avec le proxy et le réseau attendus ?
• Identité et confiance : le certificat présenté et la chaîne de confiance correspondent-ils à l’attente de l’équipe ?
• Appel de commande : quel binaire et quelles options ont été utilisés, et quel résultat ont-ils renvoyé ?
• Assertion du script : vérifie-t-elle un résultat fonctionnel ou une représentation textuelle trop précise ?

Une différence de sortie ou d’option mérite une investigation. Elle n’établit pas, à elle seule, une panne de TLS ni une incompatibilité générale.

Un paquet installé ne garantit pas que le compilateur, une liaison de langage ou un script de construction le sélectionne. Un projet peut trouver un exécutable dans un chemin et charger une bibliothèque depuis un autre ; un script peut aussi s’appuyer sur une valeur par défaut qui varie avec l’environnement. Il faut donc traiter séparément le binaire de ligne de commande, la configuration de compilation et la liaison utilisée au moment de l’exécution.

Comment relier un échec de dépendance à la version OpenSSL ? Reproduisez le build sur le même commit, dans un travail isolé, puis comparez les journaux de configuration, de compilation et de liaison. Relevez les chemins de recherche des en-têtes et des bibliothèques, la commande d’édition de liens et les tests exécutés après le build. La liste des commandes OpenSSL 4 permet de contrôler les commandes disponibles, tandis que le guide de migration aide à examiner une différence de comportement documentée.

Si votre projet utilise une variable de configuration ou un chemin explicite, faites-le apparaître dans le journal sans y inclure de secret. Évitez de conclure à partir du seul résultat de openssl version : ce contrôle décrit le programme lancé par le shell, pas nécessairement la bibliothèque chargée par chaque dépendance. Comparez le résultat de compilation, l’inspection des liaisons adaptée à l’outil utilisé et les tests qui sollicitent réellement cette dépendance.

Pour localiser l’appel, recherchez les mots openssl, les noms de bibliothèques et les paramètres de configuration dans les scripts de build, les fichiers de dépendances et les étapes du workflow. Un échec qui apparaît uniquement après changement de version peut être corrélé au changement ; il ne devient une preuve causale que si un essai comparatif contrôlé sur le même commit reproduit la différence.

La fixation de version réduit la dépendance à une valeur par défaut d’image, mais elle n’est utile que si vous vérifiez le chemin réellement exécuté. L’annonce de runner-images indique qu’OpenSSL 3 reste disponible par un chemin Homebrew versionné ; vérifiez le chemin présent dans l’image utilisée et sélectionnez-le explicitement selon les instructions de l’annonce. Ne recopiez pas un chemin supposé sans le vérifier dans les journaux de votre runner.

Pour obtenir une comparaison interprétable :

• Choisissez le même commit et les mêmes entrées de pipeline.
• Lancez une exécution avec la version que le workflow utilisait avant le changement, puis une autre avec la version que vous évaluez.
• Ajoutez les contrôles de chemin et de version dans chaque tâche concernée, plutôt qu’en un seul point éloigné.
• Comparez les étapes de certificats, clés, TLS et dépendances, ainsi que les sorties attendues et les codes de retour.
• Gardez les secrets hors des journaux et des artefacts ; documentez seulement la procédure, la version résolue et le résultat.

Ces contrôles ne doivent pas transformer une annonce de changement en calendrier présumé pour toutes vos machines. Sur un runner hébergé, identifiez l’image correspondant au workflow et vérifiez les publications. Sur un hôte autogéré, inspectez l’installation locale, le PATH du compte d’exécution et la configuration de l’agent. Si l’exécution choisit un outil intégré à une dépendance, documentez aussi cette source au lieu de supposer que le programme système est utilisé.

La décision dépend de la couverture de vos tests et de la capacité à revenir à l’état précédent. Un travail réussi qui vérifie seulement la compilation ne couvre pas automatiquement la signature, les appels TLS ou les dépendances natives. De même, un hôte en ligne n’est pas une preuve de réussite de pipeline, et la réussite d’une étape ne vaut pas validation de publication.

Critères d’acceptation pour le responsable technique

Avant d’autoriser l’image ou la configuration candidate, demandez une preuve pour chaque flux critique : build principal, traitement des certificats et clés, signature, connexion TLS pertinente, construction des dépendances et test après liaison. Chaque preuve doit associer le commit testé, le runner utilisé, le chemin d’openssl, sa version déclarée et le résultat observé. Les journaux doivent être suffisamment détaillés pour diagnostiquer l’étape, mais ne doivent pas divulguer les clés, les mots de passe ou les jetons.

Prévoyez un retour à la version explicitement sélectionnée si un flux critique échoue ou si sa cause demeure indéterminée. Le retour n’est pas une reconnaissance que tout le changement est incompatible ; c’est une mesure de maîtrise du risque tant que l’équipe ne dispose pas d’une comparaison concluante. À l’inverse, ne retirez pas le mécanisme de fixation au seul motif que le workflow a réussi une fois : vérifiez que la sélection est documentée et reproductible au prochain renouvellement d’image.

Pour une équipe qui répartit ses tâches sur un environnement Mac distant, la machine doit être considérée comme un support d’exécution, pas comme une preuve de compatibilité OpenSSL. KVMNODE peut être une option à examiner si vous avez besoin d’un nœud Mac distinct pour reproduire un parcours de CI ou isoler des essais de signature. Vous pouvez consulter les informations KVMNODE sur les environnements Mac, puis vérifier les conditions correspondant au Mac mini proposé à la commande. Ne présumez pas qu’une version OpenSSL, un runner hébergé ou un niveau de service précis est inclus sans le confirmer pour l’environnement concerné.

Un Mac local ou acheté peut être préférable si votre équipe a besoin d’interfaces physiques, d’un contrôle matériel continu ou d’une charge soutenue et prévisible. Un environnement distant dédié peut être pertinent pour isoler un test, mais il ne dispense pas de vérifier l’accès, les outils installés, le compte d’exécution et la politique de secrets. Dans les deux cas, séparez trois validations : l’hôte est disponible, le travail CI passe, et le processus complet de publication est autorisé.

Quand vous aurez les preuves des tâches critiques, gardez une version explicite tant que la comparaison ne couvre pas la signature et les dépendances, ou adoptez la nouvelle version si tous les contrôles ciblés passent et que le retour est maîtrisé. Pour choisir un nœud Mac distant, partez de votre charge et de vos exigences d’accès ; ne déduisez pas sa compatibilité OpenSSL d’une annonce concernant les images GitHub-hosted.