un nombre conséquent de failles ne passent jamais dans le CVE et ne sont même pas corrigée comme étant liée à la sécurité (faut des fois avoir l'œil pour envisager comment ça peut produire une faille)
oui, c'est le point de vue de Linus et il a plutôt raison, contrairement à certaines personnes de la sécurité qui manquent de connaissances du processus de développement (pas tous hein... mais bon, spa leur métier non plus) : prendre en compte de nouvelles fonctionnalités c'est aussi fiabiliser la conception, refaire une passe sur le code permettant la prise en compte de failles dont l'ampleur n'aurait pas été précédemment couverte complètement.
Avoir une équipe pour scruter tous les commits de tous les projets pour vérifier si ça a un impact de sécurité et se débrouiller pour le backporter (ce qui n'est pas trivial non plus) est voué à l'échec.
moui, c'est un peu la conclusion de Debian, Firefox, du noyau Linux, de OpenJDK : avoir des sorties cadencées habitue les utilisateurs à faire des mises à jour régulières en amont (environnements dév/qualification...) et caler (lorsque possible) les mises en production sur les versions LTS.
Pour moi il faut distinguer le matériel et le logiciel,
Pour moi aussi, même si découpler la partie noyau de la partie logicielle n'est pas complètement fait par les distributions. Le noyau a néanmoins tendance à conserver des API utilisateurs stables et les rendre de plus en plus configurables (interactions avec DBus...). Les abstractions ont parfois du bon (l'empilement de couches un peu moins...).
[^] # Re: De l'obligation de mettre à jour son OS et son matériel
Posté par BAud (site web personnel) . En réponse au lien Linux becoming a Windows / OSX clone. Évalué à 3. Dernière modification le 22 novembre 2023 à 11:06.
oui, c'est le point de vue de Linus et il a plutôt raison, contrairement à certaines personnes de la sécurité qui manquent de connaissances du processus de développement (pas tous hein... mais bon, spa leur métier non plus) : prendre en compte de nouvelles fonctionnalités c'est aussi fiabiliser la conception, refaire une passe sur le code permettant la prise en compte de failles dont l'ampleur n'aurait pas été précédemment couverte complètement.
moui, c'est un peu la conclusion de Debian, Firefox, du noyau Linux, de OpenJDK : avoir des sorties cadencées habitue les utilisateurs à faire des mises à jour régulières en amont (environnements dév/qualification...) et caler (lorsque possible) les mises en production sur les versions LTS.
Pour moi aussi, même si découpler la partie noyau de la partie logicielle n'est pas complètement fait par les distributions. Le noyau a néanmoins tendance à conserver des API utilisateurs stables et les rendre de plus en plus configurables (interactions avec DBus...). Les abstractions ont parfois du bon (l'empilement de couches un peu moins...).