Samedi Sécurité : mon nouveau Mac, contraint et forcé !, Réactions à la publication du 21/06/2025

[Benzebut]

Ils vont dire que la mise à jour du 26 est le 27, le 28 celle du 29 et le 29 maintenu jusqu'à la sortie du 32, ce qui fera bien 5 de suivi pour la machine

La bonne solution serait qu'à partir du moment où un OS n'est plus maintenu, les éditeurs soient obligés d'en publier le code source et que ce dernier tombe dans le domaine public

Non point. Puisque c'est la version de référence qui est suivie par la mise en conformité de la réglementation européenne, pas les mises à jour suivantes. Donc macOS 26 qui va sortir fin 2025 sera pris en charge jusqu'à la fin 2030. Quelque soit les prochaines générations de macOS ou leurs appellations.

Ensuite ce n'est pas la bonne solution, puisqu'une partie du code est toujours utilisée dans les générations suivantes. Cette possibilité pourrait l'être sur de très vieilles versions, mais alors il faudrait trouver le matériel compatible, ce qui va limiter encore plus l'usage. Sauf pour les nostalgiques...

S'ils ne veulent pas que le code tombe dans le domaine public, il leur faut juste continuer à le maintenir...

Et au passage, quand est signalée une faille de sécurité, il n'y a jamais moyen de savoir si les vieilles versions (n-3, n-4...) sont touchées ou pas

C'est justement ce qui est fait pendant 5 ans et plus généralement pendant 7 ans en cumulant les modalités. Donner le code n'est pas une obligation, c'est selon la volonté de chacun des inventeurs.

Concernant les failles de sécurité, cela dépend. Normalement, toutes les mises à jour corrigent l'intégralité des failles connues. Puis il s'agit souvent de failles générées par les "nouvelles" fonctions, donc pour les générations actuelles des logicielles. Si des failles sont plus enfouies dans le code, des mises à jour exceptionnelles sont fournies pour tous les appareils supportés, donc sur les anciennes versions des logiciels et cela désormais légalement pendant 5 ans.

Mais pas sur des versions plus anciennes et dans ce cas, cela devient plus aléatoire en fonction de la "faille". Les détails des problèmes sont fournis dans le code CVE...

[Paul Emploi]

Concernant les failles de sécurité, cela dépend. Normalement, toutes les mises à jour corrigent l'intégralité des failles connues.

Non, très loin de ça malheureusement!

[jeandemi]

Ensuite ce n'est pas la bonne solution, puisqu'une partie du code est toujours utilisée dans les générations suivantes. Cette possibilité pourrait l'être sur de très vieilles versions, mais alors il faudrait trouver le matériel compatible, ce qui va limiter encore plus l'usage. Sauf pour les nostalgiques... .

Cela permettrait à certains développeurs de faire des drivers ainsi que des mises à jours d'anciens systèmes très appréciés comme Snow Léopard pour qu'il tourne sur des ordinateurs plus récents.
J'imagine déjà la réactivité de Snow sur un ordi équipé des derniers processeurs Intel ou AMD!

Concernant les failles de sécurité, cela dépend. Normalement, toutes les mises à jour corrigent l'intégralité des failles connues. Puis il s'agit souvent de failles générées par les "nouvelles" fonctions, donc pour les générations actuelles des logicielles.

Donc celui qui tourne avec par exemple Mojave (ou même Monterey) a peu de risques car les nouvelles fonctions ne sont pas présentes...

[Paul Emploi]

Concernant les failles de sécurité, cela dépend. Normalement, toutes les mises à jour corrigent l'intégralité des failles connues. Puis il s'agit souvent de failles générées par les "nouvelles" fonctions, donc pour les générations actuelles des logicielles.

Donc celui qui tourne avec par exemple Mojave (ou même Monterey) a peu de risques car les nouvelles fonctions ne sont pas présentes...

C'est un poil plus compliqué.
Les failles de sécurité sont des bugs (en général...), la plupart des bugs ne créent pas de failles de sécurité, certaines si.

À chaque fois qu'on créé du code, on créé des bugs. C'est mécanique.
Ça dépends des technologies et processus employés, mais on peut tabler sur un minima de 10 bugs par millier de ligne de code.
Certaines pourront être des failles de sécurité. Ou rendre un avion mortel, ce qui est plus gênant (surtout si on est dedans).

Quand on modifie des logiciels, y-compris pour en enlever des bugs, on créé aussi des bugs, de nouvelles bugs.
C'est là aussi inévitable!
Mais usuellement on en enlève plus que ce qu'on en créé.

Au bout d'un grand nombre de cycle d'utilisation, de remontée de bugs, et de chasse aux bugs, la stabilité est excellente, le logiciel alors très solide.
C'est généralement le moment choisi pour ne plus l'utiliser...

Le fond du problème c'est que nous, collectivement, ne sachions pas nous satisfaire de ce qui marche très bien, qui a été épuré et stabilisé sur des années ou des décennies.
Il faut toujours plus, toujours plus beau, toujours plus gros au passage et plus lourd.

bash tourne bien, zsh ça semble être le cas, il faut alors qu'un génie se dise qu'il va remplacer les deux premiers par un nouveau shell écrit en Rust, et qu'un encore plus grand génie se dise qu'on va foutre ça dans des distros Linux...
J'ai très hâte de voir ce que ça va donner, mais pas sur un de mes ordinateurs, de loin!

[Mac Arthur]

Concernant les failles de sécurité, cela dépend. Normalement, toutes les mises à jour corrigent l'intégralité des failles connues. Puis il s'agit souvent de failles générées par les "nouvelles" fonctions, donc pour les générations actuelles des logicielles.

Donc celui qui tourne avec par exemple Mojave (ou même Monterey) a peu de risques car les nouvelles fonctions ne sont pas présentes...

C'est généralement le moment choisi pour ne plus l'utiliser…

Le fond du problème, c'est que nous, collectivement, ne sachions pas nous satisfaire de ce qui marche très bien, qui a été épuré et stabilisé sur des années ou des décennies.
Il faut toujours plus, toujours plus beau, toujours plus gros au passage et plus lourd.

Je pense qu'à la place du "on" (nous), il faudrait plutôt dire "ils" (les éditeurs). Ce sont eux qui conduisent la course à l'échalote.
Même si j'aime bien des choses nouvelles, sinon je te testerais pas Tahoe, ce qui est robuste me va également très bien.
Eux, ils ont intérêt à raccourcir le cycle du produit. C'est aussi mécanique, et donc au bout du bout les "vieilles" versions ne sont plus maintenues, ce qui accélère la vitesse de switch. Suivez mon regard du côté de la Pomme…

[Benzebut]

Non, très loin de ça malheureusement!

Simple question de point de vue. Car comme l'intervention suivante l'indique, les codes actuels sont rarement stabilisés et que les mises à jour s'appliquent sur du code qui vient d'être créé, donc contenant son lot de problèmes non encore identifiés. Surtout si des nouvelles fonctionnalités sont ajoutées au dernier moment...
Néanmoins, l'idée reste que les failles de sécurité connues sont bouchées lors des nouvelles versions dans la mesure du possible.

[Benzebut]

Cela permettrait à certains développeurs de faire des drivers ainsi que des mises à jours d'anciens systèmes très appréciés comme Snow Léopard pour qu'il tourne sur des ordinateurs plus récents.
J'imagine déjà la réactivité de Snow sur un ordi équipé des derniers processeurs Intel ou AMD!

Dans le cas présent, cela serait juste impossible. Le code de Snow Leopard ne connait même pas l'architecture des derniers Intel et encore moins celle ARM ! Il faudrait recompiler tout le code avec les nouveaux langages, reprendre tous les appels, intégrer les protocoles actuels et écrire des bibliothèques complètes pour un résultat peu satisfaisant. Par contre, cette version de macOS pourrait tourner sous un émulateur (qui lui ferait la liaison entre l'ancien code), mais avec des fortes pertes de performances et pas du tout l'ergonomie attendue...

Donc celui qui tourne avec par exemple Mojave (ou même Monterey) a peu de risques car les nouvelles fonctions ne sont pas présentes...

Comme indiqué dans ma réponse et comme l'a justement rappelé Paul Emploi, cela dépend.
Pour les nouvelles fonctions liées à la nouvelle version de macOS, pas de risques. Mais si ces failles sont plus anciennes et bien présentes dans le cœur de macOS et qu'elles ont été révélées par les dernières fonctions, alors ces versions de macOS seront concernées comme les autres par le problème. Sans corrections de proposées, car les 5 années fatidiques seront passées.

Le véritable problème pour moi, est l'inutile volonté d'avoir des mises à jour trop fréquentes qui empêchent de stabiliser le code et de le pérenniser. Ce qui ne peut qu'entrainer l'explosion des failles, puisque l'optimisation du code n'est plus faite...

[jeandemi]

Donc un nouvel OS est aussi dangereux qu'un ancien, mais pas sur les mêmes choses

Il me semble que c'était ça qu'avait apporté Snow par rapport aux précédentes versions : une correction maximale des bugs, ce qui en a fait une des versions les plus stables de MacOS et une des plus appréciées.

Et si Snow n'est pas optimisé pour les dernières fonctions du matériel (instructions AVX par exemple) il tournerait très bien car plus léger que les nouvelles versions... À condition d'y développer des drivers (kext) pour le nouveau matériel

[Paul Emploi]

Donc un nouvel OS est aussi dangereux qu'un ancien, mais pas sur les mêmes choses

Je pense que ça résume bien le problème!

[Benzebut]

Donc un nouvel OS est aussi dangereux qu'un ancien, mais pas sur les mêmes choses

Il me semble que c'était ça qu'avait apporté Snow par rapport aux précédentes versions : une correction maximale des bugs, ce qui en a fait une des versions les plus stables de MacOS et une des plus appréciées.

Et si Snow n'est pas optimisé pour les dernières fonctions du matériel (instructions AVX par exemple) il tournerait très bien car plus léger que les nouvelles versions... À condition d'y développer des drivers (kext) pour le nouveau matériel

Tel est hélas la triste conclusion de trop de mises à jour sur les OS et les applications...

Et la version 10.6 (Snow Léopard) de macOS avait été effectivement lancée pour stabiliser le code et optimiser l'existant. En faisant une "pause" dans les nouvelles fonctionnalités de macOS. Autre époque...

Cette version de macOS Snow Léopard ne tournerait pas sur les machines récentes, car en plus des extensions à développer pour profiter du nouveau matériel, encore une fois il faudrait écrire entièrement le code du noyau pour être utilisé sur les nouvelles architectures (bien plus que les instructions AVX). Et encore, sans garantie que cette version fonctionne correctement, car trop de changements dans les protocoles...

[jeandemi]

Les processeurs plus récents (disons jusqu'à la 14th gen) sont compatibles avec les logiciels écrits anciennement, juste que ces derniers ne sont pas optimisés. Ils ne peuvent pas profiter des nouvelles instructions ajoutées (AVX sur les Sandy Bridge, AVX-2 sur les Haswell...) mais du moment qu'il y a des drivers pour le chipset de la carte mère et de la carte graphique, des puces USB etc. il n'y a pas de raison que ça ne tourne pas.

On peut faire tourner MS DOS 6.1 sur un Core2 Quad (à condition de ne pas avoir plus de 640 Mo de RAM), mais il n'utilisera qu'un cœur sur les 4...

[Benzebut]

Les processeurs plus récents (disons jusqu'à la 14th gen) sont compatibles avec les logiciels écrits anciennement, juste que ces derniers ne sont pas optimisés. Ils ne peuvent pas profiter des nouvelles instructions ajoutées (AVX sur les Sandy Bridge, AVX-2 sur les Haswell...) mais du moment qu'il y a des drivers pour le chipset de la carte mère et de la carte graphique, des puces USB etc. il n'y a pas de raison que ça ne tourne pas.

On peut faire tourner MS DOS 6.1 sur un Core2 Quad (à condition de ne pas avoir plus de 640 Mo de RAM), mais il n'utilisera qu'un cœur sur les 4...

Il y a rétrocompatibilité partielle sur les processeurs d'une même famille. Partiellement car encore une fois, en plus des nouvelles instructions ou bibliothèques, le noyau n'est pas compatible avec l'architecture et va demander un émulateur pour gérer les jeux d'instructions. Ce font Rosetta et consorts.

Est-ce que MS DOS fonctionne sur l'architecture ARM ? Est-ce OS9 fonctionne sous Apple Silicon ?... Seul Doom continue de fonctionner sur tout un tas d'appareils modernes

[jeandemi]

Est-ce que MS DOS fonctionne sur l'architecture ARM ? Est-ce OS9 fonctionne sous Apple Silicon ?... Seul Doom continue de fonctionner sur tout un tas d'appareils modernes

Ce n'est pas ça que j'imagine, juste Snow sur un Intel récent, un i9-14900K par exemple

[MacAvantIOS]

Seul Doom continue de fonctionner sur tout un tas d'appareils modernes

Avec, il faut le dire, des efforts de portage qui forcent le respect!

[macfredx]

(…)
Seul Doom continue de fonctionner sur tout un tas d'appareils modernes

Et Myst.