a) Les critiques ou on essaie de sortir le patch le plus vite possible sans attendre le mois prochain
b) Les non-critiques ou la c'est pas vraiment un probleme d'attendre le mois prochain
Bref, la sortie mensuelle n'affecte en rien la fenetre d'exposition aux failles critiques, car pour celles la on sort le patch aussi vite que possible lorsqu'elles sont publiques et/ou exploitees.
Note que tu peux non seulement le bloquer, mais aussi decider de la periode a laquelle il apparait, il serait probablement plus utile d'allonger la periode d'alerte plutot que l'enlever completement, genre pour etre sur que tu n'oublies pas pendant 3 semaines...
Ca n'a rien a voir avec nous, vu qu'on nous l'a demande.
Les admins ne peuvent pas les garder dans le pipe et les appliquer une fois par mois, parce que si on sort un patch le 5 Mars et que les admins font leurs tests le 30 du mois, ca fait 25 jours d'exposition.
Avec une date constante, les departements IT mettent leur phase de test le jour d'apres car la date est connue, et ils peuvent les deployer en qqe jours a chaque fois.
Start / Run / gpedit.msc / Local Computer Policy / Computer Configuration / Administrative Templates / Windows Components / Windows Update / Re-prompt for restart with scheduled installations
a) Tu racontes n'importe quoi. Le fait que les failles ne sont pas connues est identique partout, jettes un oeil au bugzilla de Mozilla, tu verras que les failles de securite sont inaccessible jusqu'a la release, idem chez les distributions.
Les failles ou les gens sont au courant et qui sont activement exploitees, on les corrige le plus vite possible sans attendre le mois qui suit comme je l'ai dit, donc pas de probleme.
b) Demandes aux entreprises si elles preferent tester les patchs tous les 5 jours ou une fois par mois t'auras la reponse.
Sinon, non tu peux pas faire pareil sous Linux, car les patchs etant publies aleatoirement, si tu attends la fin du mois, tu crees une fenetre d'exposition a la vulnerabilite
c) Oui ils sont potentiels et reels, mais a choisir mieux vaut n'avoir a le faire qu'une fois ou deux par an plutot que chaque mois.
Pour les accents, faudra t'y habituer, ca fait depuis 2001 que mes posts sont sans accents, personne n'en est encore mort...
a) Super, donc tout le monde est au courant des failles pendant le mois et peut essayer d'en tirer parti, a comparer avec le cas MS ou la faille n'est le plus souvent connue que de MS et du chercheur jusqu'a la release
b) Tout a fait, mais vu qu'elles arrivent toutes en meme temps, a une date connue d'avance, il est tres simple de prevoir le reboot a ce moment
c) Vu que cela arrive tres rarement c'est pas vraiment un probleme
Oui mais sous Linux on peut choisir quand redémarrer pour utiliser la version patchée et on est pas vulnérable pendant le mois en entier si la faille a été découverte le 2e jour du mois !
a) On regarde les 5 updates du mois passe pour Ubuntu, faut redemarrer si tu veux le code update.
b) Personne ne t'oblige a rebooter sous Windows apres avoir installe les updates, tu peux continuer a utiliser le systeme pendant 6 mois si ca te chante
c) Si la faille est activement exploitee, on sort le patch des que possible, donc c'est pas un probleme
Ni sous Windows ni sous MacOS tu n'es obliges de redemarrer apres une mise a jour.
Mais sous Windows, Linux ou MacOS, si tu ne redemarres pas les softs touches par l'update(soit parce qu'ils chargent la librairie updatee, soit parce qu'ils ont ete eux meme update), tu continueras a utiliser le vieux code.
Pour les mises a jours non-securite c'est pas un probleme, pour celles de securite c'est bcp plus problematique.
Sachant que seul un developpeur stupide debuggerait un probleme de perf dans son soft en lisant les sources de l'OS(que ce soit sous Windows ou Linux), certainement pas.
C'est plutot le besoin regulier de certains de sortir leurs frustrations (valides ou non) envers MS/le proprio/... d'une maniere totalement hors sujet qui cause la reaction epidermique.
Tu charges une librairie dynamiquement(pas par link dynamique, mais avec dlopen), la dependance est presente nulle part dans le package.
Resultat, faut passer tous les processus et lister les librairies chargees pour savoir si le processus doit etre redemarre ou pas.
Ensuite faut avoir la methode de redemarrage pour chaque processus, faut savoir que l'utilisateur est d'accord de le redemarrer, etc...
Ton PC du boulot s'en porterait plus mal si c'est ton departement IT qui se charge des updates.
Il leur faudrait tester les updates plusieurs fois par mois, ils ont probablement pas le temps et le budget pour.
Alors soit tu devrais attendre ton patch alors que tout le monde est au courant, soit tu le recevrais non teste avec les applis metier.
C'est pour ca qu'on les sort une fois par mois, pas pour eviter les reboot.
La principale demande pour cela c'etait pas les reboots.
C'est le fait que les entreprises avant d'installer un patch doivent le tester avec leurs applications metier, ca leur prend bcp de temps, et ca coute.
Le faire 1 fois par mois pour tous les patchs en meme temps leur facilite enormement la vie, ils savent quand ca arrive, savent que c'est 1 fois par mois seulement sauf probleme vraiment grave.
Devoir le faire 5 fois par mois, de maniere totalement inattendue lorsque un patch sort, ca fout une merde pas croyable dans leur departements IT.
<iTout simplement parce que le temps de chargement n'est pas du tout pareil, d'autant que tout est déjà dans le cache quand tu te reconnectes. C'est sûr, tu dois tout fermer mais de toute façon quand tu reviens le matin, tu prends un peu de temps à tout te faire revenir en tête. Si on devait suivre ta logique au bout, on ne rentrerait pas le soir chez soi.
C'est quoi la difference ? 30 secondes ? Ce temps est negligeable, le principal probleme est de devoir tout fermer et sauver, parce que ca empeche les departements IT de faire les updates de maniere transparente, les utilisateurs doivent essayer de retrouver ou est ce fichier sur lequel ils bossaient depuis 5 jours et dont ils ne souviennent plus ou ils l'ont sauve, etc...
Pour l'histoire du DM qui demande à être relancé, j'utilise Debian testing, donc j'en vois passer des mises à jour, et je peux te dire que je ne ferme jamais ma session suite à une mise à jour et je n'ai jamais de problème.
Normal vu que le probleme est invisible a l'oeil nu, le probleme que ca cause est que ta librairie qui contient le patch ne remplacera la librairie vulnerable(qui est en ce momemt chargee en memoire) que lorsque le processus est relance. Alors tu ne verras rien a l'oeil nu, ca continue a marcher, mais tu restes vulnerable. Si tu ne redemarres pas ta session autant ne pas installer le patch, c'est le meme resultat.
Ce que tu veux eviter : devoir arreter ce que tu fais, tout sauver, devoir relancer tous tes softs apres, etc...
Que ce soit un reboot ou un redemarrage de session, sur un desktop c'est le meme resultat. Que l'OS se decharge en memoire et se recharge importe peu, ce qui compte c'est l'impact sur l'utilisation. Si l'OS pouvait se decharger et se recharger sans que l'utilisateur s'en rende compte, personne ne serait emmerde par les reboots.
Si j'en crois les enterprises c'est absolument oui. C'est elles qui nous ont demande de changer notre systeme de release, avant on faisait comme Ubuntu: le patch sortait quand il etait pret.
Ces 30 derniers jours ca fait 5 updates affectant Ubuntu 8.04 et 8.10 qui demandent soit un reboot, soit un redemarrage de la session, ce qui signifie que tous tes softs doivent etre fermes, bref pour un desktop c'est equivalent a un reboot.
Ces updates sont sorties le 30 mars, 7 avril, 15 avril et 27 avril.
4 jours ou il faut tout fermer et redemarrer son OS/sa session
Car si on arrive à une stagnation de la création de nouvelle applications de l'informatique, cela risque de laisser le temps à Microsoft de stabiliser et de sécuriser ses produits, leur permettant de devenir réellement concurrentiel par rapport à Linux ou à d'autre OS libre (BSD, OpenSolaris...).
Ca c'est deja fait depuis un petit moment, donc c'est pas vraiment le probleme.
Ben justement, il est tres facile de definir les methode set/get sur ces objets directement, tu rajoutes une methode "Generate" qui te genere le buffer final (en concatenant les buffers des objets fils pour les containers, en gerant little/big endian et l'encodage pour les strings pour les autres objets, en compressant le contenu pour les objets s'occupant de compression, calculant les checksums, ...) et c'est regle.
Une fois cela fait, tu peux lire tes structs, et tu peux les generer en y mettant les valeurs que tu veux et t'as meme pas besoin de t'occuper de rafraichir les champs de longueur/checksum/compression ... quand tu changes les donnees avec un systeme pareil, l'appel a Generate sur l'objet pere se charge de tout.
[^] # Re: Encourageant mais...
Posté par pasBill pasGates . En réponse au journal Le mal qui ronge Microsoft: The Good Enough revolution. Évalué à 1.
[^] # Re: Encourageant mais...
Posté par pasBill pasGates . En réponse au journal Le mal qui ronge Microsoft: The Good Enough revolution. Évalué à 1.
a) Les critiques ou on essaie de sortir le patch le plus vite possible sans attendre le mois prochain
b) Les non-critiques ou la c'est pas vraiment un probleme d'attendre le mois prochain
Bref, la sortie mensuelle n'affecte en rien la fenetre d'exposition aux failles critiques, car pour celles la on sort le patch aussi vite que possible lorsqu'elles sont publiques et/ou exploitees.
[^] # Re: Encourageant mais...
Posté par pasBill pasGates . En réponse au journal Le mal qui ronge Microsoft: The Good Enough revolution. Évalué à 0.
Et pour les millions de gens qui restent a part elle, je fais comment ?
[^] # Re: Encourageant mais...
Posté par pasBill pasGates . En réponse au journal Le mal qui ronge Microsoft: The Good Enough revolution. Évalué à -2.
Faille publiee : Tout le monde est au courant et peut l'exploiter
Voila la difference
[^] # Re: Encourageant mais...
Posté par pasBill pasGates . En réponse au journal Le mal qui ronge Microsoft: The Good Enough revolution. Évalué à 1.
[^] # Re: Encourageant mais...
Posté par pasBill pasGates . En réponse au journal Le mal qui ronge Microsoft: The Good Enough revolution. Évalué à 0.
Les admins ne peuvent pas les garder dans le pipe et les appliquer une fois par mois, parce que si on sort un patch le 5 Mars et que les admins font leurs tests le 30 du mois, ca fait 25 jours d'exposition.
Avec une date constante, les departements IT mettent leur phase de test le jour d'apres car la date est connue, et ils peuvent les deployer en qqe jours a chaque fois.
[^] # Re: Encourageant mais...
Posté par pasBill pasGates . En réponse au journal Le mal qui ronge Microsoft: The Good Enough revolution. Évalué à 2.
[^] # Re: Encourageant mais...
Posté par pasBill pasGates . En réponse au journal Le mal qui ronge Microsoft: The Good Enough revolution. Évalué à 1.
Les failles ou les gens sont au courant et qui sont activement exploitees, on les corrige le plus vite possible sans attendre le mois qui suit comme je l'ai dit, donc pas de probleme.
b) Demandes aux entreprises si elles preferent tester les patchs tous les 5 jours ou une fois par mois t'auras la reponse.
Sinon, non tu peux pas faire pareil sous Linux, car les patchs etant publies aleatoirement, si tu attends la fin du mois, tu crees une fenetre d'exposition a la vulnerabilite
c) Oui ils sont potentiels et reels, mais a choisir mieux vaut n'avoir a le faire qu'une fois ou deux par an plutot que chaque mois.
Pour les accents, faudra t'y habituer, ca fait depuis 2001 que mes posts sont sans accents, personne n'en est encore mort...
[^] # Re: Encourageant mais...
Posté par pasBill pasGates . En réponse au journal Le mal qui ronge Microsoft: The Good Enough revolution. Évalué à 0.
b) Tout a fait, mais vu qu'elles arrivent toutes en meme temps, a une date connue d'avance, il est tres simple de prevoir le reboot a ce moment
c) Vu que cela arrive tres rarement c'est pas vraiment un probleme
[^] # Re: Encourageant mais...
Posté par pasBill pasGates . En réponse au journal Le mal qui ronge Microsoft: The Good Enough revolution. Évalué à 1.
a) On regarde les 5 updates du mois passe pour Ubuntu, faut redemarrer si tu veux le code update.
b) Personne ne t'oblige a rebooter sous Windows apres avoir installe les updates, tu peux continuer a utiliser le systeme pendant 6 mois si ca te chante
c) Si la faille est activement exploitee, on sort le patch des que possible, donc c'est pas un probleme
[^] # Re: Encourageant mais...
Posté par pasBill pasGates . En réponse au journal Le mal qui ronge Microsoft: The Good Enough revolution. Évalué à 1.
Mais sous Windows, Linux ou MacOS, si tu ne redemarres pas les softs touches par l'update(soit parce qu'ils chargent la librairie updatee, soit parce qu'ils ont ete eux meme update), tu continueras a utiliser le vieux code.
Pour les mises a jours non-securite c'est pas un probleme, pour celles de securite c'est bcp plus problematique.
[^] # Re: Encourageant mais...
Posté par pasBill pasGates . En réponse au journal Le mal qui ronge Microsoft: The Good Enough revolution. Évalué à -4.
C'est plutot le besoin regulier de certains de sortir leurs frustrations (valides ou non) envers MS/le proprio/... d'une maniere totalement hors sujet qui cause la reaction epidermique.
[^] # Re: Encourageant mais...
Posté par pasBill pasGates . En réponse au journal Le mal qui ronge Microsoft: The Good Enough revolution. Évalué à -1.
Le probleme c'est que ma fiancee par exemple, ne sait absolument pas que ca existe, tout comme une grande partie de la population.
[^] # Re: Encourageant mais...
Posté par pasBill pasGates . En réponse au journal Le mal qui ronge Microsoft: The Good Enough revolution. Évalué à 4.
Resultat, faut passer tous les processus et lister les librairies chargees pour savoir si le processus doit etre redemarre ou pas.
Ensuite faut avoir la methode de redemarrage pour chaque processus, faut savoir que l'utilisateur est d'accord de le redemarrer, etc...
C'est loin d'etre aussi simple que ca en a l'air.
[^] # Re: Encourageant mais...
Posté par pasBill pasGates . En réponse au journal Le mal qui ronge Microsoft: The Good Enough revolution. Évalué à 3.
Voila tous les softs qui dependent d'openssl, il y a KDE, Gnome, des softs en ligne de commande uniquement, des services, ...
Ils devraient tous etre redemarre, t'imagines le bordel pour trouver lesquels et tous les redemarrer, dans ce cas un reboot est plus simple.
[^] # Re: Encourageant mais...
Posté par pasBill pasGates . En réponse au journal Le mal qui ronge Microsoft: The Good Enough revolution. Évalué à 1.
Il leur faudrait tester les updates plusieurs fois par mois, ils ont probablement pas le temps et le budget pour.
Alors soit tu devrais attendre ton patch alors que tout le monde est au courant, soit tu le recevrais non teste avec les applis metier.
C'est pour ca qu'on les sort une fois par mois, pas pour eviter les reboot.
[^] # Re: Encourageant mais...
Posté par pasBill pasGates . En réponse au journal Le mal qui ronge Microsoft: The Good Enough revolution. Évalué à 2.
C'est le fait que les entreprises avant d'installer un patch doivent le tester avec leurs applications metier, ca leur prend bcp de temps, et ca coute.
Le faire 1 fois par mois pour tous les patchs en meme temps leur facilite enormement la vie, ils savent quand ca arrive, savent que c'est 1 fois par mois seulement sauf probleme vraiment grave.
Devoir le faire 5 fois par mois, de maniere totalement inattendue lorsque un patch sort, ca fout une merde pas croyable dans leur departements IT.
[^] # Re: Encourageant mais...
Posté par pasBill pasGates . En réponse au journal Le mal qui ronge Microsoft: The Good Enough revolution. Évalué à -1.
C'est quoi la difference ? 30 secondes ? Ce temps est negligeable, le principal probleme est de devoir tout fermer et sauver, parce que ca empeche les departements IT de faire les updates de maniere transparente, les utilisateurs doivent essayer de retrouver ou est ce fichier sur lequel ils bossaient depuis 5 jours et dont ils ne souviennent plus ou ils l'ont sauve, etc...
Pour l'histoire du DM qui demande à être relancé, j'utilise Debian testing, donc j'en vois passer des mises à jour, et je peux te dire que je ne ferme jamais ma session suite à une mise à jour et je n'ai jamais de problème.
Normal vu que le probleme est invisible a l'oeil nu, le probleme que ca cause est que ta librairie qui contient le patch ne remplacera la librairie vulnerable(qui est en ce momemt chargee en memoire) que lorsque le processus est relance. Alors tu ne verras rien a l'oeil nu, ca continue a marcher, mais tu restes vulnerable. Si tu ne redemarres pas ta session autant ne pas installer le patch, c'est le meme resultat.
[^] # Re: Encourageant mais...
Posté par pasBill pasGates . En réponse au journal Le mal qui ronge Microsoft: The Good Enough revolution. Évalué à 6.
Ce que tu veux eviter : devoir arreter ce que tu fais, tout sauver, devoir relancer tous tes softs apres, etc...
Que ce soit un reboot ou un redemarrage de session, sur un desktop c'est le meme resultat. Que l'OS se decharge en memoire et se recharge importe peu, ce qui compte c'est l'impact sur l'utilisation. Si l'OS pouvait se decharger et se recharger sans que l'utilisateur s'en rende compte, personne ne serait emmerde par les reboots.
[^] # Re: Encourageant mais...
Posté par pasBill pasGates . En réponse au journal Le mal qui ronge Microsoft: The Good Enough revolution. Évalué à 1.
[^] # Re: Encourageant mais...
Posté par pasBill pasGates . En réponse au journal Le mal qui ronge Microsoft: The Good Enough revolution. Évalué à -6.
[^] # Re: Encourageant mais...
Posté par pasBill pasGates . En réponse au journal Le mal qui ronge Microsoft: The Good Enough revolution. Évalué à 2.
http://www.ubuntu.com/usn/USN-749-1
http://www.ubuntu.com/usn/usn-751-1
http://www.ubuntu.com/usn/USN-767-1
http://www.ubuntu.com/usn/usn-758-1
Ces 30 derniers jours ca fait 5 updates affectant Ubuntu 8.04 et 8.10 qui demandent soit un reboot, soit un redemarrage de la session, ce qui signifie que tous tes softs doivent etre fermes, bref pour un desktop c'est equivalent a un reboot.
Ces updates sont sorties le 30 mars, 7 avril, 15 avril et 27 avril.
4 jours ou il faut tout fermer et redemarrer son OS/sa session
[^] # Re: Encourageant mais...
Posté par pasBill pasGates . En réponse au journal Le mal qui ronge Microsoft: The Good Enough revolution. Évalué à 1.
[^] # Re: Encourageant mais...
Posté par pasBill pasGates . En réponse au journal Le mal qui ronge Microsoft: The Good Enough revolution. Évalué à -1.
Ca c'est deja fait depuis un petit moment, donc c'est pas vraiment le probleme.
[^] # Re: Mini-framework
Posté par pasBill pasGates . En réponse au message Manipulation rapide et légère de données structurées binaires. Évalué à 1.
Une fois cela fait, tu peux lire tes structs, et tu peux les generer en y mettant les valeurs que tu veux et t'as meme pas besoin de t'occuper de rafraichir les champs de longueur/checksum/compression ... quand tu changes les donnees avec un systeme pareil, l'appel a Generate sur l'objet pere se charge de tout.