• [^] # Re: macOS ou quand la fin du support d’une version coïncide avec l’expiration d’un certificat racine

    Posté par (site web personnel, Mastodon) . En réponse au journal Certificat expiré. Évalué à 10.

    Quelques heures avant la fin du support, macOS ne parle déjà plus à la moitié d’Internet.

    En fait non, tu le dis toi-même :

    Bizarrement, Safari ne râle pas

    Tu confonds Web et Internet. 🤦‍♀️

    c’est tellement un enfer de travailler avec macOS que je préfère ne pas « changer une équipe qui gagne »

    Oui, c'est ce que se disent une tonne de gens et c'est bien ce qui pose des problèmes de sécurité plus tard (boom). Je note ta phrase pour si un jour tu conspues une entité pour ne pas avoir mis à jour ses outils et que ça t'a posé ensuite un problème.

    Parfois c’est assez incroyable de voir comment tu peux aller loin dans l’imaginaire.

    Je rappelle le contexte :

    • un système qui n’est prévu que pour faire le portage d’un logiciel vers macOS (machine de build) et qui accessoirement est devenu aussi l’environnement de compilation d’un autre logiciel pour macOS (machine de build), je l’ai précisé dans mon commentaire.
    • un système qui est à jour de macOS et de son environnement de développement spécifique (incluant le compilateur fourni par Apple ainsi que les bibliothèques et outils installés via Homebrew, ici), je l’ai précisé dans mon commentaire, et qui est même encore pris en charge au moment des faits, je l’ai précisé dans mon commentaire.
    • un système dont j’ai le contrôle (ça semble assez évident vu la façon dont j’ai tourné mon commentaire)

    Oui, c'est ce que se disent une tonne de gens et c'est bien ce qui pose des problèmes de sécurité plus tard (boom).

    Ici le système macOS a le rôle d’un docker qui est démarré pour faire un build et être éteint après, tu crois vraiment qu’il y a une « tonne de gens » qui « pensent ça dans un tel contexte et à qui « ça pose des problèmes de sécurité plus tard ». Tu n’as même aucune idée de l’isolement du système en question... Et pour rappel, les outils du système qui communiquent avec l’extérieur sont à jours, le seul truc pas à jour c’est un certificat racine que je peux ajouter.

    En fait je ne le précise pas mais depuis précisément le 30 septembre 2021, j’ai migré ce système depuis un bridge ouvert à mon LAN vers un réseau qui ne communique qu’entre ma machine principale et ce système de build et rien d’autre. La système ne sert à rien d’autre (pour tout dire, c’était peut-être la première fois en trois ans et depuis l’installation de macOS que j’utilisais le Safari que j’ai utilisé pour vérifier si le certificat fonctionnait). En dehors de deux dépôts (dont celui cité dans mon message initial) dont le clonage est réalisé par CMake, le clonage de dépôts (il y a peut-être une 20aine de dépôts) sont réalisés par la machine principale non-macOS qui orchestre les builds. En gross j’ai un script sous Linux que j’appelle en faisant quelque chose comme « ./do macos », et hop 95% des sources sont téléchargées sous Linux, le système macOS compile les sources (et clone lui-même deux dépôts qui font exception et dont un seul dépôt est un dépôt de code, hébergé par GNOME et dont je suis l’unique mainteneur de la branche utilisée), et hop ça recrache un build pour macOS.

    Je note ta phrase pour si un jour tu conspues une entité pour ne pas avoir mis à jour ses outils et que ça t'a posé ensuite un problème.

    Hors sujet, donc, puisque l’on parle de mes outils de ma propre entité. Tu imagines une situation fictive qui ne se produit pas.

    En fait, si tu veux me voir conspuer une entité pour ne pas avoir mis à jour ses outils et que ça m’a posé ensuite un problème, tu peux citer Apple et le fait de ne pas avoir mis à jour ses certificats racines pendant la durée de prise en charge de son système (haha).

    Bref, tu ne me connais pas, tu ne connais pas mes méthodes de travail, tu ne connais même pas mon opinion sur le sujet et tu n’as aucun moyen de le déduire de mon commentaire. Là je parle d’un cas très particulier d’un système dédié au build d’un logiciel qui est entretenu dans un environnement finement contrôlé. Tu ne peux rien déduire de ma politique dans d’autres situations. Dans d’autres contextes, je suis connu pour être l’ayatollah de la mise à jour et je peux pas te dire le nombre d’argumentaires que j’ai détruit de la part de personnes qui mettaient en danger des parcs informatiques entier, et je peux te dire que certains peuvent témoigner qu’il ne faut pas rigoler avec ça avec moi. Mais on n’est pas du tout dans ce contexte, c’est assez explicite normalement. C’est assez dingue comment tu te laisses dérouler ton imaginaire super loin en dehors du contexte en extrapolant de façon incroyable sur d’autres contextes qui sont de ta fabrication dans ta tête. En fait c’est normal d’explorer dans sa tête le champ des possibles, ce qui n’est pas normal, c’est de répondre non-pas au message et à la situation de ton interlocuteur, mais d’adresser à ton interlocuteur une réponse qui s’applique au monde que tu as créé dans ta tête, de faire subir aux autres tes réactions à des peurs correspondant à des situations fictives que tu as forgées dans ta tête.

    Tu aurais pu par exemple écrire (ça aurait été légitime) : « j’espère que tu n’appliques pas cette méthode dans d’autres contextes [...] » et de rappeler avec raison que dans d’autres contextes ceci cela patati patata... En plus tu n’aurais pas pris un ton de reproche, tu aurais laissé à l’autre la liberté de se corriger s’il était dans l’erreur, avec même la possibilité de ne pas seulement élever le débat mais peut-être même élever la personne, et tu aurais simplement enseigné au lieu de condamner.

    Si tu veux plus de contexte, Je travaille sur ce portage depuis 3 ans. J’ai installé le système macOS Mojave à cette intention, et tout le développement s’est fait sur ce système alors qu’il était officiellement maintenu, en faisant toutes les mises à jour, et comparant les comportements avec des snapshots réalisés avant mis à jour lorsque je rencontrais des problèmes après mis à jour, ce afin d’identifier les causes des régressions. Ce travail a été extrêmement douloureux pour diverses raisons que je ne peux pas décrire sans pondre un roman. Après trois ans, il ne me reste plus qu’un seul bug gênant qui m’empêche de publier la toute première version de l’histoire d’un éditeur de niveau entièrement compatible avec les technologies id Tech 3 et qui ne requiert pas XQuartz pour fonctionner. En fait, même la dernière version de MacRadiant qui doit dater de 2013 ou quelque chose comme ça nécessitait X11 sur macOS... Aucune autre alternative utilisant X11 n’est maintenue, et il n’existe pas d’alternative n’utilisant pas X11 qui soit complète (DarkRadiant ne gère toujours pas intégralement certains modes de projection de textures à la façon d’id Tech 3). Il s’agit pour moi de remplir un besoin qui n’est pas du tout satisfait, que j’ai fait uniquement par générosité parce que je pense que c’est important, qui plus est avec en face de moi une certaine ingratitude car les utilisateurs de macOS n’ont souvent pas idée du coût faramineux que peut impliquer un portage sur macOS, je dis bien peut car certains portages se font comme une lettre à la poste mais le cas que j’ai traité est probablement le plus incroyablement compliqué pour diverses raisons.

    Juste pour dresser un portrait vite-fait : Il y a 10 ans le logiciel utilisait GTK avec GtkGLExt, X11, OpenGL non-core et requiert de partager le contexte OpenGL entre plusieurs viewport, et ne gèrait évidemment pas le hiDPI à la sauce Apple. GTK2 est obsolète en général (GTK3 et GTK4 sont sortis), X11 est obsolète sur macOS d’Apple, OpenGL non-core est obsolète en général, OpenGL tout court est obsolète sur macOS d’Apple, GtkGLExt est obsolète (remplacé par GtkGLArea) mais il n’y a pas d’implémentation GtkGLExt pour macOS fonctionnelle sans X11 (elle n’a jamais été terminée), et il n’y a pas d’implémentation GtkGLArea pour OpenGL non-core dans GTK3 ni dans GTK4 pour maCOS d’Apple (donc si vous avez bien suivi, il n’y a officiellement aucune solution pour réaliser ce portage). Sous macOS avec ce logiciel la gestion du pointeur ne fonctionne pas correctement, ni le multi-écran, les surfaces OpenGL recouvertes par des surfaces non-OpenGL sont dessinées par dessus les surfaces non-OpenGL, et quand certains de ces problèmes ont des contournements. Et sous macOS le partage de contexte OpenGL n’est pas fonctionnel. Et pour Windows, le logiciel est même distribué avec une version de Mesa utilisable de manière optionnelle afin de contourner certains problèmes de drivers intégrés de Windows 10. Et aujourd’hui le code sait tourner sous Linux, Windows, macOS, FreeBSD et travailler avec GTK2, GTK3, GtkGLExt, GTKGLArea, OpenGL, X11 natif, Quartz natif, le-truc-de-windows natif, Wayland est en cours, implémente des contournement pour des bugs d’affichage dans Windows, implémente une palanquée d’autres contournements pour des bugs d’affichage dans macOS, des bugs de pointeurs dans macOS, sait travailler avec des contextes OpenGL partagés et non-partagés, et imite autant qu’il est raisonnable l’apparence native des applications du système Hôte (la version macOS respecte même la préférence d’environnement clair/foncé).

    Et bref, pour la première fois de l’histoire, après un travail de dingue de 3 ans et beaucoup d’arrachage de cheveux, je suis presque prêt à sortir pour macOS et de manière complètement bénévole la première version de l’histoire de ce logiciel. Le développement a duré toute la durée de vie de macOS Mojave. Alors oui, ça y est, Mojave est déprécié depuis hier venredi 1er octobre 2021 à ce que je crois, et bien tu sais quoi ? Il est complètement à jour à la date du 30 septembre 2021. Ce système est relativement isolé et ne sert qu’au build. Il est probable que je ne mette pas à jour macOS vers une version plus récente de Mojave avant la sortie de ce logiciel. Il n’y a plus qu’un bug gênant à résoudre et il sera prêt.

    Ce portage complètement bénévole m’a entre autre retardé dans la fusion d’un fork dont la masse accumulée (et qui continue de s’accumuler) de travail requise pour la fusion s’élève désormais à un nombre à 4 zéro si elle était évaluée en euro au salaire d’un développeur. Alors je veux terminer la version macOS d’abord, et je suis prêt à repousser un peu et sans rougir le moment où je devrais penser à l’après-Mojave.

    J’ai confirmation auprès d’utilisateur de macOS récents que la version compilée sous Mojave fonctionne sur les dernières versions de macOS. Alors tu sais quoi ? Je crois que d’ici à ce que je corrige ou contourne le dernier bug gênant, d’ici la publication de la note de version et la compilation finale du logiciel, je crois que je vais conserver mon système de build dans son environnement contrôlé et isolé et qui était à jour le 30 septembre 2021, vérifier moi-même les certificats si besoin un par un, publier cette première mondiale et de l’histoire, clore ce chapitre de douleur de trois ans, et peut-être, peut-être, envisager de tenter d’essayer de faire une mise à jour vers un macOS plus récent que Mojave et de voir si tout se passe bien. Après avoir publié le logiciel compilé sur un macOS à jour du 30 septembre 2021 et clôt un chapitre de 3 ans de souffrance, je pourrai peut-être envisager de prendre le risque d’ouvrir un nouveau chapitre de souffrance et de faire face à des problèmes dont la résolution est incertaine et implique une durée indéterminée de travail.

    Tu sais quoi ? à moins d’une découverte demain d’un exploit incroyable qui pourrait affecter de manière malicieuse la compilation d’un logiciel sur un environnement macOS à jour du 30 septembre 2021 de manière à véroler ce que produirait cet environnement de build, et/ou de briser au moins 3 pare-feux, et/ou de véroler le compilateur officiel d’Apple, soit en vérolant le source téléchargé via le dépôt de GNOME avec une communication vérifiée par un certificat Let's Encrypt dont j’ai validé l’autorité à la main, et/ou un accès physique en cassant le système de chiffrement de disque, je ne crois pas que je mettrais en danger qui que ce soit. En fait il serait peut-être plus raisonnable de penser à me menacer de me casser la gueule à grand coup de clé à molette (et même ça c’est pas sûr que ça marche), ou d’autres méthodes plus perverses. Il y a probablement plus de failles qui permettent de remonter jusqu’à ce système macOS ou de corrompre mes copies que de manière de faire produire du code vérolé par le compilateur d’Apple en faisant s’envoler un papillon. Par ailleurs le logiciel compilé ne fait aucune communication réseau donc je n’ai pas vraiment à m’inquiéter d’une faille dormante dans une bibliothèque de communication réseau par exemple. Une surface d’attaque réaliste serait par exemple une faille dans la libpng (ou autre format) pas encore découverte à la date du 30 septembre 2021, en supposant que quelqu’un arrive à refourguer une image vérolée (pour garder cet exemple) à un utilisateur du logiciel sous mac... Bref, le risque ne serait pas plus élevé qu’avec toute autre application publiée avant le 1er octobre 2021 même si compilée sur une version plus récente de macOS, tant que publié avant cette date.

    ce commentaire est sous licence cc by 4 et précédentes