pasBill pasGates a écrit 16060 commentaires

Je comprends bien, mais tu entends quoi par mises a jour critiques ? Parce que des patchs de securite il y en a plusieurs par mois.

Noyer le poisson ?

Tu me fais bien rire, vous n'avez toujours RIEN prouve quand a la responsabilite de MS la dedans.

Notamment etant donne que plusieurs constructeurs vendent des PCs avec Linux en ce moment.

Le but est pas de les mettre sur le meme plan, mais vous avez cette manie de prendre le passe de MS pour justifier vos attaques d'aujourd'hui, je vous rappelles simplement que certains de vos "copains" sont tres tres loin d'etre tout blanc et cela ne semble pas vous gener un poil.

Ouhais c'est un peu le meme principe ton truc. Si jamais tu as un patch qui fout la merde de facon individuel (naturellement il n'est pas exclu surtout avec microsoft que la combinaison des patchs posent probleme) c'est archement plus simple de le trouver lorsque tu appliques les yeux fermes un ensemble.

Si tu savais de quoi tu parles, ce qui n'est visiblement pas le cas du tout, tu saurais que c'est la methode preferee des entreprises.

Tout simplement car les problemes sont assez rares pour valoir cette approche :

On installe tous les patchs qu'on va installer au final sur nos machines, on regarde si il y a un probleme.
Si il y en a un, on enleve les patchs et on isole le patch fautif.

Mais bon, un jour peut-etre il te viendra a l'idee de t'informer avant de sortir des idioties sur un sujet auquel tu ne connais rien...

Justement, regrouper a la fin du mois n'est pas une bonne solution, parce qu'une fois le patch sorti, nos chers amis du cote obscur se mettent a regarder ce qui a cause le bug et voir ce qu'ils peuvent faire avec.

Faut pas oublier que l'enorme majorite des failles sont "secretes" jusqu'au moment de la publication des patchs, seul la personne qui a rapporte le bug et l'editeur la connaissent habituellement jusqu'a ce moment ce qui limite les risques(raison pour laquelle Mozilla/RH/... bloquent l'acces a ces bugs dans leur bugzilla jusqu'a la sortie du patch). Une fois le patch sorti par contre, c'est la course a celui qui cree l'exploit le plus vite possible.

Bref, je suis pas sur que tu aies envie d'attendre le 30 Juillet pour tester un patch sorti le 2 Juillet...

En voyant que les patchs sont separes, c'est pas un package de 200Mo, en voyant que chaque bulletin explique clairement les dependances/risques/....

Parce que faut etre un peu honnete aussi, quasiment aucun admin ne s'amuse a regarder le contenu du patch(code source), ils n'ont aucune idee des consequences du changement de code vu qu'ils ne connaissent pas le code.

Super \o/

Heureusement il n'y a que les proces pour abus de position dominante qui sont importants, ceux pour corruption ne comptent pas.

Ce qui n'a rien a voir avec le fait d'avoir un OS non-Windows, et tout a voir avec le fait d'utiliser un OS dont le nom ressemble a s'y meprendre avec Windows.

Bref, tu melanges tout.

Sinon, on peut toujours déposer une pêche par dessus…

J'imagines que ca ne se dit pas en France, mais evites de proposer de poser une peche sur un cake en Suisse, pas une bonne idee :+)

Tu t'auto-trolles je pense. Tu dis que Microsoft prend le temps de tester avant de sortir des updates. Or, tu sais très bien que le gros du business de Microsoft est l'OEM et ils n'auraient pas rencontré ces problèmes avant?

Justement non car cela depend des modeles. Les laptops AMD d'HP n'avaient pas de probleme par exemple car leur image etait bonne. Bref, fallait tomber sur le bon modele qui avait une image pourrie.

Et puis, si l'image était incorrecte, genre il manquait typiquement un module, non?

Non, HP avait specifie dans la base de registre qu'il fallait charger le driver de power management d'Intel, mais n'avait pas le driver sur le disque, donc sans SP pas de probleme.
Mais a l'installation du SP, l\installer en voyant cette entree a fait ce qu'il est sense faire : il a installe le driver.

On peut difficilement demander au service pack de faire autre chose que ce qu'il lui est dit de faire, il n'est pas sense deviner que HP lui ment et il n'est pas sense gerer l'infinie combinaison de configurations corrompues qu'il pourrait rencontrer, ca serait ingerable...

Si j'en crois les difficultes des developpeurs en general (libre/proprio/autres), c'est loin d'etre facile a eviter meme en ayant de la rigueur...

C'est effectivement cingle, ca a l'air d'etre un processus sacrement lourd pour generer ces patchs et j'ai du mal a imaginer que cela va tourner en qqe chose d'utilisable de maniere reguliere, mais on ne sait jamais...

Je trouve cet argumentation irrecevable. Il faut attendre que la faille soit ACTIVEMENT exploitée pour qu'elle soit patchée ? Il y a un vrai marché noir des exploits : un acheteur pourrait très bien demander l'exclusivité et l'utiliser pour des cibles précises. Bien sûr, la personne qui découvre la faille peut aussi choisir de ne pas la diffuser et l'exploiter pour sa pomme. Microsoft attend que suffisamment de sociétés soient impactées pour patcher ?

Non, mais tu veux pas non plus pousser les patchs dehors sans les tester, parce que les societes si elles voient regulierement des patchs qui foutent le bordel, elles se mettent a ne plus les installer (eh oui ca peut sembler dingue, mais bcp preferent stabilite a securite)

Pourquoi tu te focalises sur RedHat, tu as un dent contre eux ? Est-ce que RedHat entre en concurrence avec Microsoft, c'est pour ça qu'il faut absolument trouver les défauts de cet OS ?

Au contraire, je considere que Redhat est celui qui fait le meilleur boulot du cote "linux professionel", c'est pour cela que je les prends eux, compare a ce qui selon moi se fait de mieux de l'autre cote.

Un étudiant motivé a réussi à tenir 2 ans sans rebooter tout en patchant son noyau (84% des patchs appliqués à chaud sans modif, et les autres avec modif). Il semble qu'une boîte ait été fondée autour de ce service qui se vend maintenant (tout en restant GPL).

Mais je connais tres bien ksplice, le probleme c'est que personne ne s'amuse a creer un patch de securite qui ne contient que le code du patch en question.
Tu regardes chez Redhat, tu verras que leurs patchs, c'est un ensemble de correctifs, pas juste une ligne qui corrige un buffer overflow.
On a exactement la meme techno que ksplice dans Windows depuis 2003, on a vu les limitations.

Je ne comprend pas en quoi c'est plus simple. Disons pour l'exemple qu'Ubuntu propose une mise à jour par jour et que Windows en propose 30 par mois (ce qui donne aussi 1 par jour). Bah si tu prends 3 jours pour étudier (tester/valider) une màj Ubuntu, tu seras exposé durant 3 jours à une faille donnée. Si tu prends 2 jours pour étudier les 30 màj Windows, tu seras exposé à 30 failles durant 2 jours. Je pense donc que Windows est plus longtemps exposés aux failles. J'ai pris des nombres un peu au pif juste pour illustrer mon idée.

C'est parce que tu ne regardes que du point de vue securite.

Je t'expose le cote de l'enterprise :

Ubuntu sort en moyenne un patch par semaine (disons, chiffre au pif).
L'entreprise peut soit :
a) Attendre un mois et tester les 4 patchs Ubuntu en meme temps, mais se retrouver avec une fenetre d'exposition d'un mois pour le 1er patch, 3 semaines pour le 2eme, ...
b) Tester les patchs quand ils sortent, vu qu'il n'y a pas d'annonce, c'est branle bas de combat a chaque fois, et c'est 2 jours de perdus chaque semaine en moyenne

Tu compares la solution MS :
Les patchs sortent un jour precis chaque mois --> On sait quand on va faire nos tests, ca prend 3 jours, pas 4x2 jours, et on est expose que ces 3 jours d'habitude.
Si qqe chose de super critique se produit (faille en exploitation active), le patch sort des que possible, sans attendre la date mensuelle, c'est rare donc ca prend peu de temps additionel au final.

Faut comprendre que MS faisait comme les distrib Linux avant, si on a change c'est notamment parce qu'on nous l'a demande...

Si c'est celui du 11 decembre non vu que je suis pas abonne, et j'ai rien vu de relatif au sujet dernierement, j'imagines qu'ils ont trouve un moyen tordu de supporter des changements plus serieux niveau hotpatching, lequel ?

Et tu as vu ou qu'ils exercent des menaces ?

Quelle importance ? Le meme gus va soudainement devenir un ange parce qu'il se met a vendre des services sur du LL plutot que sur IBM DB2 ?

Tout a fait, la question est donc : ou est le juste milieu ?

J'ai trouve un bug dans la recette, il y a un bugzilla ?

Et qu'est ce qui les en empeche ? Tu as deja vu ces patchs ? Il semble clair que non.

« vingt-huit failles ; vingt-sept en exécution de code à distance ; (...) vingt-cinq sont jugées critiques ; (...) ; une est gratifiée d'un exploit depuis août dernier... »

Ouaip, et ce dernier n'etait pas activement exploite, raison pour laquelle on a prefere tester le patch plus longtemps. C'est une approche, j'imagines que d'autres prefereraient qu'on sorte le patch de maniere urgente.

Et puis bon, sous Linux il est très rare d'avoir à rebooter un serveur pour appliquer un correctif de sécurité (même pour le noyau, on peut s'en passer !).

Et non, si tu regardes les patchs kernel de Redhat par exemple, tu noteras qu'il y a nombre de correctifs venant avec, qui vont certainement rendre le patch impossible a hotpatcher (changement de structure, ...)

Bref, dans la majorite des cas, impossible.

Sinon, la raison du groupement des patchs c'est justement que les entreprises le demandent, et cela pour une raisons simple :

A chaque patch elles doivent revalider leurs applications, il est plus simple pour elles de le faire une fois pour tous les patchs que tous les 5 jours.

Certainement, c'est un bug et il est pas beau.

Maintenant, est-ce qu'il rend toutes les machines inoperables ? Non, il cause des problemes dans des cas bien definis seulement et il ne plante pas le systeme.

Bref, qqe chose de bien plus difficile a attraper lors des tests que "j'installes le patch, la machine fonctionne plus".

Meme pas...

Les problemes du SP3 sur AMD etaient pour la plupart dus a une chose :

Des OEMs qui avaient une image Windows generee pour CPUs Intel qu'ils appliquaient sur leurs machines AMD.

Bref, les OEMs se sont mechamment plantes dans leur config, le SP3 lui-meme n'etait pas la cause du probleme, sur une installation correcte il s'installait sans probleme, et on ne peut evidemment pas garantir une installation correcte du SP sur une mauvaise image.

Et tu mets ou la barriere ?

Parce qu'evidemment plus tu testes, plus t'es sur de la qualite du bousin.

T'es pret a recevoir un patch totalement non teste ?

Ca serait drole si c'etait le vrai, le probleme c'est que pour les failles ultra-critiques on sort le patch des qu'on peut, mais on le teste un minimum avant quand meme, et il y a plein d'exemples qui sont la pour le montrer.

Ben en partie oui, tester un patch prend du temps.

Si tu veux sortir vite, t'as moins de temps --> moins de tests...

Si tu fais plus de tests -> plus de temps --> moins vite...