Certes, mais apparemment ils ont pas mal insisté pour l'obtenir.
Et comme OpenBSD semble contre le processus des embargo, les gens ne leur font plus assez confiance pour l'avenir d'où cette décision.
Un embargo n'a de sens que si les acteurs travaillent conjointement et sont d'accord avec ces règles.
ils n'ont pas besoin de trois ou quatre mois pour préparer un patch, 2h en l'occurrence pour adapter le patch fourni, donc c'est pas comme si ça va changer grand chose
Bah si, si OpenBSD délivre un correctif en lien avec la sécurité, des gens vont l'analyser si cela n'impacte pas d'autres systèmes et donc générer des attaques contre les dits systèmes qui n'ont pas encore corrigé la faille.
et de trois, attendre presque deux mois après que CERT et donc les agences gouvernementales soient au courant, ça montre un peu les limites de ce genre d'embargo à rallonge : de quoi laisser largement le temps à ceux qui voudraient en profiter parmi les nombreux acteurs au courant.
Oui, le méchant gouvernement est au courant donc ils vont profiter de l'embargo pour attaquer tous azimuts.
Déjà, la faille est surfaite, elle n'est pas si critique que présentée. En réalité si tu as un chiffrement applicatif, ce qui est de plus en plus le cas (HTTPS, chiffrement SMTP/IMAP, VPN, etc.) ces flux ne sont pas concernés. Et les actions possibles restent malgré tout assez limitée. Donc l'urgence selon moi n'était pas non plus de mise.
Trois mois (ou plus pour certains en fait), c'est pour les gros vendeurs, en particulier les négligents et paresseux, et pour assurer la médiatisation, ça n'a pas grand chose à voir avec la sécurité.
C'est vraiment naïf je pense de présenter cela ainsi.
Je ne dis pas que les 4 mois sont nécessaires, je n'en sais rien, mais cela ne demande pas deux jours non plus.
Car bon, le développeur OpenBSD qui fait son correctif à l'arrache en 4h n'a pas les mêmes contraintes (ni la même qualité de service) qu'une entreprise comme Microsoft, Samsung ou Apple. Ces entreprises ont souvent beaucoup de versions de leur logiciel à maintenir. Entre les différents Windows (3 sont encore maintenus), macOS, iOS, et pour Samsung c'est plusieurs versions d'Android et de Tizen à toucher pour des dizaines de périphériques (avec leur propre version du système).
Bref, les entreprises commerciales ont une certaine inertie pour ce genre de correctifs mais c'est justifié. Ils doivent reproduire le soucis, trouver le correctif adéquat, le tester sur tous les appareils concernés (quand tu as une vraie QA, cette étape prend du temps). Car bien entendu, on doit être sûr que la MaJ ne casse rien pour personne car ma grand mère ne va pas déboguer et faire un rapport de bogue pour sa machine auprès de ses entreprises (ce que l'utilisateur d'OpenBSD moyen saurait faire). Ensuite il faut générer la mise à jour et en faire la diffusion (et étant donné leur infra, cela ne se fait pas en une minute). Sans compter que comme les MaJ ça coûte à en faire, ils vont probablement intégrer ce changement avec d'autres qui étaient prévus. Ce qui ralenti le processus.
Donc bon, non ils ne sont pas fainéants, paresseux ou incompétents. Mais assurer une qualité de service pour des millions / milliards de produits diffusés dans le monde, utilisés par des non informaticiens, cela ne s'improvise pas. Même un changement banal nécessite de gros efforts pour éviter des problèmes. Du coup ils ne peuvent pas se permettre de faire comme OpenBSD ou Debian de faire un correctif rapidement et de le diffuser dans la foulée ou presque.
C'est difficile de concilier toutes ces contraintes à la fois.
[^] # Re: En parlant de lire ...
Posté par Renault (site web personnel) . En réponse au journal Alerte du 16 octobre en cours : wpa_supplicant souffre d'une faille de sécurité. Évalué à 10.
Certes, mais apparemment ils ont pas mal insisté pour l'obtenir.
Et comme OpenBSD semble contre le processus des embargo, les gens ne leur font plus assez confiance pour l'avenir d'où cette décision.
Un embargo n'a de sens que si les acteurs travaillent conjointement et sont d'accord avec ces règles.
Bah si, si OpenBSD délivre un correctif en lien avec la sécurité, des gens vont l'analyser si cela n'impacte pas d'autres systèmes et donc générer des attaques contre les dits systèmes qui n'ont pas encore corrigé la faille.
Oui, le méchant gouvernement est au courant donc ils vont profiter de l'embargo pour attaquer tous azimuts.
Déjà, la faille est surfaite, elle n'est pas si critique que présentée. En réalité si tu as un chiffrement applicatif, ce qui est de plus en plus le cas (HTTPS, chiffrement SMTP/IMAP, VPN, etc.) ces flux ne sont pas concernés. Et les actions possibles restent malgré tout assez limitée. Donc l'urgence selon moi n'était pas non plus de mise.
C'est vraiment naïf je pense de présenter cela ainsi.
Je ne dis pas que les 4 mois sont nécessaires, je n'en sais rien, mais cela ne demande pas deux jours non plus.
Car bon, le développeur OpenBSD qui fait son correctif à l'arrache en 4h n'a pas les mêmes contraintes (ni la même qualité de service) qu'une entreprise comme Microsoft, Samsung ou Apple. Ces entreprises ont souvent beaucoup de versions de leur logiciel à maintenir. Entre les différents Windows (3 sont encore maintenus), macOS, iOS, et pour Samsung c'est plusieurs versions d'Android et de Tizen à toucher pour des dizaines de périphériques (avec leur propre version du système).
Bref, les entreprises commerciales ont une certaine inertie pour ce genre de correctifs mais c'est justifié. Ils doivent reproduire le soucis, trouver le correctif adéquat, le tester sur tous les appareils concernés (quand tu as une vraie QA, cette étape prend du temps). Car bien entendu, on doit être sûr que la MaJ ne casse rien pour personne car ma grand mère ne va pas déboguer et faire un rapport de bogue pour sa machine auprès de ses entreprises (ce que l'utilisateur d'OpenBSD moyen saurait faire). Ensuite il faut générer la mise à jour et en faire la diffusion (et étant donné leur infra, cela ne se fait pas en une minute). Sans compter que comme les MaJ ça coûte à en faire, ils vont probablement intégrer ce changement avec d'autres qui étaient prévus. Ce qui ralenti le processus.
Donc bon, non ils ne sont pas fainéants, paresseux ou incompétents. Mais assurer une qualité de service pour des millions / milliards de produits diffusés dans le monde, utilisés par des non informaticiens, cela ne s'improvise pas. Même un changement banal nécessite de gros efforts pour éviter des problèmes. Du coup ils ne peuvent pas se permettre de faire comme OpenBSD ou Debian de faire un correctif rapidement et de le diffuser dans la foulée ou presque.
C'est difficile de concilier toutes ces contraintes à la fois.