Journal meme pas un mois...

Posté par .
Tags : aucun
8
16
nov.
2009
Cela n'a vraiment pas pris longtemps pour avoir un trou de securite exploitable sous Seven. Le plus amusant et la reponse de la compagnie produisant cet OS...

Microsoft said it may patch the problem, but didn't spell out a timetable or commit to an out-of-cycle update before the next regularly-scheduled Patch Tuesday of December 8. Instead, the company suggested users block TCP ports 139 and 445 at the firewall.

Il se pourrait eventuellement que un jour si l'age du capitaine et le vent tourne bien que l'on se bouge les fesses et corrige ce probleme de securite.

En attendant avec Seven vous pouvez oublier vous servir de samba pour quelques temps.

Precision smbv1 et v2 sont touches donc pas de roue de secours sauf downgrade vers une version precedente des OS redmondien ou mieux Linux!

http://computerworld.co.nz/news.nsf/scrt/E9592E1A9719742ACC2(...)
  • # Comme d'hab

    Posté par . Évalué à 8.

    Ben on a l'habitude que MS se foute un peu de certaines failles.

    Mais là si je comprends bien, ils ne disent pas qu'ils ne vont rien faire, juste qu'il ne vont sans doute rien faire avant le 8 décembre.

    Reste que "z'avez qu'à bloquer les ports!", c'est vrai que c'est un peu fort de café pour les entreprises/administrations où c'est "fort déployé".

    3 semaines mini, ça va être très très long quand même!
    • [^] # Re: Comme d'hab

      Posté par . Évalué à 8.

      d'autant que si je ne me trompe pas, les port 139 et 445 sont les ports pour le protocole SMB

      ca va etre pratique de bloquer les port 139/445 sur les machines clientes en entreprises
      quand elles ont un serveur de fichier (windows ou linux/samba)
      • [^] # Re: Comme d'hab

        Posté par (page perso) . Évalué à 6.

        D'autant plus qu'il me semble que pour fonctionner même sans partage de fichier, Active Directory nécessite d'avoir le service smb d'activé… (c'est vrai que c'est indispensable!!)
      • [^] # Re: Comme d'hab

        Posté par . Évalué à 9.

        J'ai envie de dire que si des entreprises ont déjà déployé Windows 7, "tant pis pour leur gueule"...
        • [^] # Re: Comme d'hab

          Posté par (page perso) . Évalué à 9.

          Cette faille ne touche pas que Windows Seven mais aussi Windows Server 2008 R2. Et cette version de l'OS est bien plus déployée que Seven. (tant pis pour leur gueule quand même)
          • [^] # Re: Comme d'hab

            Posté par (page perso) . Évalué à 10.

            J'ai envie de dire que si des entreprises ont déjà déployé Windows, "tant pis pour leur gueule"...
          • [^] # Re: Comme d'hab

            Posté par . Évalué à 0.

            C'est tres exactement l'inverse.

            Windows Seven est enormement plus deploye que la version serveur, la version client est toujours bcp plus en avance que les serveurs.
            • [^] # Re: Comme d'hab

              Posté par . Évalué à 3.

              En comptant les Seven liés aux machines grands publics ou dans les entreprises également?

              Parce que autant comme on disait, Mme Michu qui voit son PC planter, elle se dira que c'est pas la fin du monde, et des Mme Michu, y'en a beaucoup ; autant l'admin sys qui a un utilisateur au téléphone toutes les minutes à cause de plantages intempestifs, c'est plus gênant.
      • [^] # Re: Comme d'hab

        Posté par . Évalué à 2.

        En même temps, une entreprise qui laisse un partage CIFS (ex SMB) accessible de l'extérieur... L'attaquant doit donc être déjà dans le réseau local de l'entreprise.

        Il faut également rappeler que W7 n'est pas un OS serveur (limitation du nombre de connexion, etc). C'est Windows Server 2010 qui sera la version serveur basée sur W7.
        • [^] # Re: Comme d'hab

          Posté par (page perso) . Évalué à 4.

          Une appliquette Java exécutée depuis une page web anodine, ça fonctionne très bien :-)
          Et c'est utilisé en vrai.
        • [^] # Re: Comme d'hab

          Posté par (page perso) . Évalué à 6.

          En même temps, une entreprise qui laisse un partage CIFS (ex SMB) accessible de l'extérieur... L'attaquant doit donc être déjà dans le réseau local de l'entreprise.

          Parmi les cas très classiques d'infection, il y a le portable pro de l'employé utilisé pour terminer un rapport pendant le WE, et utilisé pour surfer sur le web (éventuellement à titre professionnel, par exemple pour faire des recherche). Le portable se prend un virus à ce moment-là, et le ramène tranquillement dans le réseau de l'entreprise, le lundi matin...

          Le routeur/firewall/proxy de la boîte est ainsi complètement contourné, et le virus peut ainsi se farcir tout le joli réseau interne en 192.168.x.y/10.x.y.y, avant éventuellement de se lancer à des connexions externes.
        • [^] # Re: Comme d'hab

          Posté par . Évalué à 4.

          Malheureusement, c'est une erreur très courante de se croire protégé dans un réseau local dernière un par-feu. Il y a 1000 et une possibilités permettant d'exécuter cette attaque sans se prendre la tête avec le par-feu. Sans parler que dans la pratique un nombre non négligeable d'attaques viennent plus ou moins directement de l'intérieur.
        • [^] # Re: Comme d'hab

          Posté par . Évalué à 0.

          C'est Windows Server 2010 qui sera la version serveur basée sur W7.

          Euh non, c'est Windows Server 2008 R2, qui est sorti en meme temps que Win7
          • [^] # Re: Comme d'hab

            Posté par . Évalué à 4.

            ah tiens c'est marrant ça...

            Donc si je comprends bien :

            si la version grand public de windows seven avait été appelée Windows vista R2, cela aurait été un flop commercial dû à la mauvaise image qu'a vista ; donc pour se refaire une virginité il a été renommé en Windows Seven.

            si la version serveur de windows seven s'appelle 2008 R2, moi ce que je comprends c'est que les changements liés à seven ne sont pas si profonds et/ou nombreux que ça.

            Ils sont forts en marketing $krosoft !

            Enfin bon je dis ça mais je poste depuis un vista (qui marche très bien).
    • [^] # Re: Comme d'hab

      Posté par (page perso) . Évalué à 9.

      >>> Reste que "z'avez qu'à bloquer les ports!", c'est vrai que c'est un peu fort de café pour les entreprises/administrations où c'est "fort déployé".

      Je pense qu'à ce stade il doit y avoir fort peu d'administrations ou d'entreprises qui utilisent Seven (il est sorti il n'y a pas longtemps).
      Peut-être que Microsoft se dit que ça n'urge pas quand ce sont des particuliers qui sont impactés ?
      • [^] # Re: Comme d'hab

        Posté par . Évalué à 1.

        Peut-être que Microsoft se dit que ça n'urge pas quand ce sont des particuliers qui sont impactés ?

        a) On ne s'est jamais dit que ca n'urge pas
        b) Sortir un patch ca prend du temps si on veut faire les choses correctement, t'as pas envie de sortir un patch qui corrige le probleme et qui casse le protocole en retour, ou cree un memory leak, ou autre, resultat faut le tester et ca prend du temps.
      • [^] # Re: Comme d'hab

        Posté par . Évalué à -1.

        Raaah, clicke sur envoyer trop vite...

        c) Ce bug c'est un DoS, pas un EoP, alors oui ca peut un peu emmerder les societes, mais au final c'est pas un truc qui va les mettre serieusement en danger, le jour ou un laptop debarque dans la societe il fera tomber qqe serveurs, il sera vite localise et ca sera regle. C'est chiant, ca a un impact, mais c'est pas un _vrai_ danger vu que c'est pas qqe chose d'expose a internet (e-business toussa).
        • [^] # Re: Comme d'hab

          Posté par (page perso) . Évalué à 7.

          Bon ok, c'est vrai quoi juste quelques serveurs qui tombent, c'est pas un danger. J'ai souvenir qu'Exchange a un peu de peine avec les arrêts brutaux (je sais pas si ça a changé depuis).
          Il est possible que certaines applications ne supportent pas les arrêts brutaux sans risque de corruption de données, c'est pour ça, notamment, qu'on met des ups aux serveurs.

          C'est clair que ce n'est pas la fin du monde, mais c'est déjà très problématique. Un serveur qui démarre c'est quoi, 10-20 minutes. Après un arrêt un peu brutal tu fais quand même un petit scandisk, serveur de fichiers (dans un pme) 500Go, c'est pas fait en trois secondes.

          Donc je dirais 30 minutes d'interruption (et c'est court encore). Tu as 20 employés que tu paies disons 4000.-/mois (c'est pas mirobolant), donc 250.- de perdu. 50 employés, 650.- de perdu. Durant le mois ça peut arriver plusieurs fois. Ce qui qui paie ? Microsoft ?

          Le partage de fichier est quand même une fonction de base d'un serveur. Si celle-ci est défectueuse au point de pouvoir empêcher l'entreprise de fonctionner de manière aléatoire durant une demi-heure, c'est un problème.
          Une vrai réponse de Microsoft aurait été un patch disponible rapidement mais pas super-testé et tout. Après l'administrateur décide si ce patch est nécessaire ou pas, c'est le minimum.

          Microsoft n'est pas à la hauteur en terme de réactivité depuis toujours et ce n'est pas prêt de changer.

          "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

          • [^] # Re: Comme d'hab

            Posté par . Évalué à 0.

            Le partage de fichier est quand même une fonction de base d'un serveur. Si celle-ci est défectueuse au point de pouvoir empêcher l'entreprise de fonctionner de manière aléatoire durant une demi-heure, c'est un problème.

            Tout a fait, mais ce n'est pas le cas, faut que tu sois attaque pour que ce soit le cas.
            Si demain on voit que les attaques se multiplient, on sortira le patch en le testant moins, mais jusqu'a aujourd'hui il n'y a aucune raison de couper les tests.

            Une vrai réponse de Microsoft aurait été un patch disponible rapidement mais pas super-testé et tout. Après l'administrateur décide si ce patch est nécessaire ou pas, c'est le minimum.

            Non pas du tout, car nombre de gens utilisent les updates automatiques, leur balancer un patch pas teste pourrait leur crasher leur systeme si il y a un probleme, pas vraiment une bonne idee.

            La vraie reponse c'est de voir ce qui se passe dans le monde reel, tu regardes autour de toi, tu verras que cette vulnerabilite n'est pas exploitee activement, personne n'est sous un deluge d'attaques ou autre, donc aucune raison de sortir un patch bacle.

            Microsoft n'est pas à la hauteur en terme de réactivité depuis toujours et ce n'est pas prêt de changer.

            Au contraire, entre un patch teste et un patch non teste, j'ai tres tres vite fait mon choix, surtout dans ce cas ou ce n'est visiblement pas exploite activement.
            Faut que vous sortiez un peu de votre petit monde et vous rendiez compte que sortir un patch pour des millions de systemes utilises dans un tas de configs differentes par des gens souvent pas competents, c'est pas aussi simple qu'ecrire 3 lignes de code, compiler et jeter ca sur le net.
            • [^] # Re: Comme d'hab

              Posté par (page perso) . Évalué à 4.

              Non pas du tout, car nombre de gens utilisent les updates automatiques, leur balancer un patch pas teste pourrait leur crasher leur systeme si il y a un probleme, pas vraiment une bonne idee.

              Mais j'ai parlé du système de mise à jour ? Un exe qu'on puisse aller télécharger sur le site. Simplement.

              Faut que vous sortiez un peu de votre petit monde et vous rendiez compte que sortir un patch pour des millions de systemes utilises dans un tas de configs differentes par des gens souvent pas competents, c'est pas aussi simple qu'ecrire 3 lignes de code, compiler et jeter ca sur le net.

              Toi sors de ton monde. Il y a des administrateurs très capables qui sont prêt à mettre en patch qui demande de redémarrer le serveur en fin de journée si cela permet de ne pas risquer de faire perdre de l'argent (et donc sa place) à son patron.

              Tu as déjà bossé dans du service ? Le serveur il doit jamais planter, faire le café au boss, trouver les clés de la voiture, ... bref résoudre tous les problèmes.
              Le fournisseur d'accès se broute et la connexion internet est perdue : "dring ... Allo ? Internet marche pas, il faut réparer. Mais c'est votre fournisseur d'accès qui a un problème. M'en fout, vous venez me réparer ça tout de suite ... tut tut tut"

              Facile tes quelques millions de couillons, mais sors des labs de Microsoft et va dans une vrai PME (ce qui reste le gros du marché de Microsoft) et viens ensuite nous parler des tes problèmes de patch pas iso-machin-chose.

              Il faut des solutions (des workarounds) dans les 5 minutes. C'est pas parfait, mais ça permet d'éviter le pire et pour un truc tip-top pile-poil, ça peut attendre.

              C'est pour ça que mettre Microsoft dans une PME c'est de la connerie pur et simple.

              "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

              • [^] # Re: Comme d'hab

                Posté par . Évalué à -1.

                Mais j'ai parlé du système de mise à jour ? Un exe qu'on puisse aller télécharger sur le site. Simplement.

                Ca ne regle qu'une partie du probleme, ca laisse ces PMEs qui comptaient sur les updates automatiques dans la mouise, ca nous oblige a tester un truc 2x alors que rien ne presse vraiment pour le moment ce qui nous fait perdre du temps, ...

                Toi sors de ton monde. Il y a des administrateurs très capables qui sont prêt à mettre en patch qui demande de redémarrer le serveur en fin de journée si cela permet de ne pas risquer de faire perdre de l'argent (et donc sa place) à son patron.

                Tout a fait, il y en a. Il en y a aussi enormement parmis eux qui vont faire la chose suivante :
                - Attendre qu'on sorte le patch teste, car ils ne sont pas attaques

                La plupart suivent les mailing-lists de securite et regardent si la vulnerabilite est activement exploitee pour decider si ils doivent sortir de leur cycle de patch ou pas, dans le cas present la reponse est toute claire : non

                Tu as déjà bossé dans du service ? Le serveur il doit jamais planter, faire le café au boss, trouver les clés de la voiture, ... bref résoudre tous les problèmes.
                Le fournisseur d'accès se broute et la connexion internet est perdue : "dring ... Allo ? Internet marche pas, il faut réparer. Mais c'est votre fournisseur d'accès qui a un problème. M'en fout, vous venez me réparer ça tout de suite ... tut tut tut"


                Le truc que malheureusement tu ne comprends pas, c'est qu'avant, on sortait les patchs a peu pres comme tu le demandais, et on a change... Pourquoi ? Parce que les entreprises nous l'ont demande...

                Facile tes quelques millions de couillons, mais sors des labs de Microsoft et va dans une vrai PME (ce qui reste le gros du marché de Microsoft) et viens ensuite nous parler des tes problèmes de patch pas iso-machin-chose.

                Justement, la methode qu'on applique, elle vient de nos clients.

                Il faut des solutions (des workarounds) dans les 5 minutes. C'est pas parfait, mais ça permet d'éviter le pire et pour un truc tip-top pile-poil, ça peut attendre.

                Tout a fait, c'est pour ca que dans nos advisories on donne les workarounds quand il y en a. Mais le patch lui, si il peut attendre d'etre teste, on ne le sortira que teste.
                • [^] # Re: Comme d'hab

                  Posté par (page perso) . Évalué à 3.

                  Mais n'importe quoi. Je dis pas de revenir à l'ancienne méthode (dont on parlera plus loin), mais dans certains cas, et celui-ci en ai un, préparer un workaround disponible ne casse pas le système de mise à jour et permet à ceux qui le juge nécessaire. On parle quand même de pouvoir éteindre un serveur à distance. Ce n'est pas rien.

                  Ensuite ce n'est pas à Microsoft de décider si c'est exploitable ou pas. Si j'en parle à mon apprenti de ce problème, ben tu peux être certain qu'au cours il va bien s'amuser avec les serveurs de l'école. Donc avoir le choix de pouvoir appliquer un patch risquer ou attendre la version finale, c'est un choix qu'un administrateur devrait pouvoir faire (et si je serais dans une école, par exemple, je choisirais le patch moisi). Mais comme vous prenez tous vos clients pour des cons, c'est clair que vous faites vous ce choix.

                  Le système de diffusion des patchs étaient décriés parce qu'il redémarrait le serveur automatiquement (même si c'était un patch qui changeait le fond d'écran). Donc les entreprises en avaient un peu plein l'os de voir leurs serveurs redémarrer de manière aléatoire. Donc oui, c'est insupportable de vivre avec une épée de Microsoft au-dessus de la tête ("Mon serveur redémarrera aujourd'hui ?").
                  Donc il faut arrêter de mettre la faute sur vos clients, vos clients ont choisi entre :
                  1) Redémarrage aléatoire automatique, mais toujours la dernière mise à jour
                  2) Un mois d'exposition mais on sait qu'on redémarre un jeudi par mois.
                  C'est un choix fantastique que Microsoft propose ... Vraiment ...

                  Finalement à vous cachez derrière "on doit tester pour que ce soit super parfait", montres bien que vous avez préférez protéger la campagne de marketing au lieu de la sécurité, un patch critique en période de lancement aurait fait trop de vagues.
                  Microsoft n'est pas un partenaire efficace quand on parle de sécurité, c'est connu et reconnu pas par hasard.

                  "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                  • [^] # Re: Comme d'hab

                    Posté par . Évalué à -1.

                    Mais n'importe quoi. Je dis pas de revenir à l'ancienne méthode (dont on parlera plus loin), mais dans certains cas, et celui-ci en ai un, préparer un workaround disponible ne casse pas le système de mise à jour et permet à ceux qui le juge nécessaire. On parle quand même de pouvoir éteindre un serveur à distance. Ce n'est pas rien.

                    Non ce n'est pas rien, mais ce n'est pas la fin du monde non plus.

                    Ensuite ce n'est pas à Microsoft de décider si c'est exploitable ou pas. Si j'en parle à mon apprenti de ce problème, ben tu peux être certain qu'au cours il va bien s'amuser avec les serveurs de l'école. Donc avoir le choix de pouvoir appliquer un patch risquer ou attendre la version finale, c'est un choix qu'un administrateur devrait pouvoir faire (et si je serais dans une école, par exemple, je choisirais le patch moisi). Mais comme vous prenez tous vos clients pour des cons, c'est clair que vous faites vous ce choix.

                    Ben oui evidemment qu'on prend tous nos clients pour des cons...

                    Le système de diffusion des patchs étaient décriés parce qu'il redémarrait le serveur automatiquement (même si c'était un patch qui changeait le fond d'écran). Donc les entreprises en avaient un peu plein l'os de voir leurs serveurs redémarrer de manière aléatoire. Donc oui, c'est insupportable de vivre avec une épée de Microsoft au-dessus de la tête ("Mon serveur redémarrera aujourd'hui ?").

                    Notre systeme n'a _jamais_ redemarre un serveur automatiquement, tu racontes n'importe quoi.

                    C'est un choix fantastique que Microsoft propose ... Vraiment ...

                    Visiblement tu n'as rien compris au systeme d'update de MS, heureusement que tu n'es pas mon admin.

                    Finalement à vous cachez derrière "on doit tester pour que ce soit super parfait", montres bien que vous avez préférez protéger la campagne de marketing au lieu de la sécurité, un patch critique en période de lancement aurait fait trop de vagues.

                    Oui bien sur, ca montre bien a quel point tu ne sais pas de quoi tu parles. On a deja sorti des patchs de securite pour Win7 depuis Octobre.

                    Microsoft n'est pas un partenaire efficace quand on parle de sécurité, c'est connu et reconnu pas par hasard.

                    Malheureusement pour toi c'est exactement l'inverse, MS est reconnu pour etre maintenant a l'avant-garde de ce cote dans le monde de la securite apres s'etre pris une claque qu'on pourrait qualifier d'enorme en 2002-2003.
                    Si tu demandes a des boites genre IOActive, Leviathan ou autre quelle boite il faut copier niveau securite, un des premiers noms que tu entendras est MS. C'est pas par hasard que Mozilla est alle chercher sa directeur de securite chez nous hein(Window Snyder, qui est partie de Mozilla depuis).
                    • [^] # Re: Comme d'hab

                      Posté par (page perso) . Évalué à 2.

                      Non ce n'est pas rien, mais ce n'est pas la fin du monde non plus.

                      Mais c'est ça que je critique. Ce n'est pas à vous de juger de la gravité de la situation. Celui qui a des apprentis informaticiens entre 16 et 18 ans et qui a des serveurs Windows 2008 R2, je penses qu'il doit trembler actuellement. C'est un exemple concret.
                      Et il y a bien d'autres situations (ou pas, je n'ai pas pensé à toutes les situations) où l'administrateur voudrait pouvoir patcher ça au plus vite.

                      Notre systeme n'a _jamais_ redemarre un serveur automatiquement, tu racontes n'importe quoi.

                      J'ai souvenir d'une boîte de dialogue qui venait tout les X temps et laissait X minutes avant de redémarrer automatiquement.

                      Visiblement tu n'as rien compris au systeme d'update de MS, heureusement que tu n'es pas mon admin.

                      Non, c'est toi qui ne connaît pas bien l'histoire de ta boîte je crois. Par contre les licences j'y ai jamais, au grand jamais, rien compris ... Mais t'inquiète pas, je ne fais plus de Microsoft maintenant ... Je ressasse seulement mes souvenirs.

                      une claque qu'on pourrait qualifier d'enorme en 2002-2003
                      Tu voulais dire 1975-2003 ?
                      Sinon je penses bien que vous débauchez les meilleures. Mais ça veut pas dire que votre système est le meilleure (c'est pas parce que Ian Murdock est chez OpenSolaris que ce système va être aussi bon que Debian (en terme de distribution)).

                      "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                      • [^] # Re: Comme d'hab

                        Posté par . Évalué à -1.

                        Mais c'est ça que je critique. Ce n'est pas à vous de juger de la gravité de la situation.

                        Alors on fait quoi ? On sort 300 patchs par jour car pour chacun d'eux il cree une situation critique pour quelqu'un quelque part sur la planete ? C'est irrealiste, il faut donc qu'on fasse un jugement sur la gravite du probleme.

                        J'ai souvenir d'une boîte de dialogue qui venait tout les X temps et laissait X minutes avant de redémarrer automatiquement.

                        Et si tu lisais la doc, tu saurais comment l'eviter.

                        Non, c'est toi qui ne connaît pas bien l'histoire de ta boîte je crois. Par contre les licences j'y ai jamais, au grand jamais, rien compris ... Mais t'inquiète pas, je ne fais plus de Microsoft maintenant ... Je ressasse seulement mes souvenirs.

                        Voyons voir, ca fait 9 ans que je bosses sur les patchs de Windows chez MS, marrant, mais j'ai comme la drole d'impression que je sais 10x mieux de quoi je parles que toi.

                        Tu voulais dire 1975-2003 ?
                        Sinon je penses bien que vous débauchez les meilleures. Mais ça veut pas dire que votre système est le meilleure (c'est pas parce que Ian Murdock est chez OpenSolaris que ce système va être aussi bon que Debian (en terme de distribution)).


                        Mais mon cher, les boites de securite, elles basent pas leur jugement sur qui on embauche, elles basent leur jugements sur nos produits et nos processus.

                        Snyder elle etait chez nous pendant plusieurs annees, c'est la ou elle s'est fait un nom en bonne partie, si le resultat de son boulot avait ete de la merde, crois-moi ca se saurait dans les milieux specialises
                        • [^] # Re: Comme d'hab

                          Posté par (page perso) . Évalué à 3.

                          Alors on fait quoi ? On sort 300 patchs par jour car pour chacun d'eux il cree une situation critique pour quelqu'un quelque part sur la planete ? C'est irrealiste, il faut donc qu'on fasse un jugement sur la gravite du probleme.

                          Rooh, sois sérieux, éteindre un serveur à distance il me semble que c'est grave. Suffisamment pour avoir un patch critique,

                          mais j'ai comme la drole d'impression que je sais 10x mieux de quoi je parles que toi.

                          Expliques au lieu de simplement nier (avec des sources, si possible, car tu ne mets jamais de source, c'est lourd à la fin).

                          "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                          • [^] # Re: Comme d'hab

                            Posté par . Évalué à -1.

                            Rooh, sois sérieux, éteindre un serveur à distance il me semble que c'est grave. Suffisamment pour avoir un patch critique

                            C'est grave oui,au point de sortir un patch oui, au point de sortir le patch dans les 30 secondes sans le tester correctement, non.

                            Expliques au lieu de simplement nier (avec des sources, si possible, car tu ne mets jamais de source, c'est lourd à la fin).

                            Tu veux que je t'expliques quoi ? Que notre systeme ne reboote pas les serveurs automatiquement ?

                            http://blogs.technet.com/mu/archive/2008/10/02/windows-updat(...)

                            Le systeme te demande ce que tu veux faire au setup, si tu decides de les installer automatiquement, alors il y aura reboot avec le pop-up et t'as des options pour le delai de reboot, ne pas rebooter si qq'un est logge, ..., si tu decides de download et laisse l'utilisateur decider, alors elles s'installeront quand tu le voudras, si tu decides de rien faire, alors il ne fera rien.
                            • [^] # Re: Comme d'hab

                              Posté par (page perso) . Évalué à 4.

                              Oui, donc soit tu utilises les mises à jour automatique et ton serveur redémarre automatiquement, soit tu n'utilises pas les mise à jour automatique. Super comme choix.

                              Debian tu peux, par exemple, faire les mises à jour de tout, sauf ce qui nécessite un redémarrage. Prenez-en de la graine.

                              "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                              • [^] # Re: Comme d'hab

                                Posté par . Évalué à 1.

                                Ben faut etre coherent aussi et arreter de gueuler pour n'importe quoi, soit c'est automatique, soit c'est manuel.

                                Installer la mise a jour automatiquement et redemarrer manuellement, c'est strictement identique a downloader la mise a jour automatiquement et l'installer+rebooter manuellement, vu que l'install sans reboot ne sert pas a grand chose.
                                • [^] # Re: Comme d'hab

                                  Posté par (page perso) . Évalué à 3.

                                  Non je serais cohérent si je continuais à dire que c'est un scandale que Microsoft ne sorte pas un patch pour le trou smb1 et 2, mais je crois que le débat à glisser un peu parce que Microsoft a décidé que ce n'est pas grave. Donc ce n'est pas grave.

                                  Sinon pour les mises à jour (puisqu'on est sur le sujet), il y a moyen de faire plus précis que "auto / pas auto" (ça c'est Microsoft).

                                  vu que l'install sans reboot ne sert pas a grand chose.

                                  Oui dans le cas de Windows, mais dans les autres systèmes (je dirais presque tous les autres), il y a possibilité de mettre à jour des parties du système pouvant être rechargée sans nécessité un redémarrage complet de la machine. En fait on redémarre uniquement quand on met à jour le noyau Linux.

                                  "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                                  • [^] # Re: Comme d'hab

                                    Posté par . Évalué à -1.

                                    Non je serais cohérent si je continuais à dire que c'est un scandale que Microsoft ne sorte pas un patch pour le trou smb1 et 2, mais je crois que le débat à glisser un peu parce que Microsoft a décidé que ce n'est pas grave. Donc ce n'est pas grave.

                                    On a dit qu'on sortirait pas de patch ? Non.

                                    Enfin bon, desole de faire les choses proprement plutot que sortir un truc en 30s qui se refera trouer en 2 jours et qui risque de tout casser. Visiblement depuis l'annonce tu as eu tous tes serveurs qui ont ete attaques.

                                    Sinon pour les mises à jour (puisqu'on est sur le sujet), il y a moyen de faire plus précis que "auto / pas auto" (ça c'est Microsoft).

                                    Et hop, on ressort les petites phrases la con sur MS.

                                    Tu remarqueras que c'est plus que auto / pas auto , il peut toutes les installer et retarder le reboot, ne pas rebooter si qq'un est logge, etc... mais visiblement cette partie de la phrase tu l'as ratee.

                                    Oui dans le cas de Windows, mais dans les autres systèmes (je dirais presque tous les autres), il y a possibilité de mettre à jour des parties du système pouvant être rechargée sans nécessité un redémarrage complet de la machine. En fait on redémarre uniquement quand on met à jour le noyau Linux.

                                    En pratique sous Linux tu dois rebooter au moins une fois par mois vu le nombre d'updates du kernel, sous Windows c'est idem.
                                    • [^] # Re: Comme d'hab

                                      Posté par (page perso) . Évalué à 2.

                                      <i>En pratique</i>

                                      Désolé, c'est moi qui suit du côté pratique, tu ne peux pas utiliser ce mot ...

                                      <i>sous Linux tu dois rebooter au moins une fois par mois vu le nombre d'updates du kernel, sous Windows c'est idem.</i>

                                      ... surtout quand c'est complètement à côté. Depuis le début de l'année, 8 redémarrages, dont 2 redémarrage d'affilé (2 jours d'intervalle).

                                      "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                                      • [^] # Re: Comme d'hab

                                        Posté par . Évalué à 0.

                                        Désolé, c'est moi qui suit du côté pratique, tu ne peux pas utiliser ce mot ...

                                        Dis nous alors, tes machines ont ete attaquees ? Tu as des elements montrant que c'est utilise activement ?

                                        ... surtout quand c'est complètement à côté. Depuis le début de l'année, 8 redémarrages, dont 2 redémarrage d'affilé (2 jours d'intervalle).

                                        Tu vas chez Redhat, tu comptes le nombre de patchs de securite du kernel, cette annee ils en sont a 8, l'annee passee a 10.

                                        Sur les serveurs, tu peux rajouter les libs genre openssl vu le nombre de softs qui les utilisent (tu peux t'amuser a aller sur chaque machine, trouver les softs les utilisant, trouver comment les arreter un par un et etre bien sur que t'en as pas oublie mais un reboot sera bien plus simple et sur), sur les clients les libs KDE et Gnome.

                                        Au final, t'arrives a environ un mois voire plus
                                    • [^] # Re: Comme d'hab

                                      Posté par . Évalué à 2.

                                      On pourra mettre toutes les possibilités imaginables sur le redemarrage lors de l'install des mises à jour, ça change pas le problème de base. Pourquoi faut il systematiquement redemarrer un serveur pour n'importe quelle mise à jour ? D'après la philosophie microsoft, une MAJ IE8 requiert le redemarrage du serveur (J'ai eu l'exemple hier soir sur un 2003 server).
                                      Honnetement, j'aurai moins la haine envers les serveurs microsoft si côté MAJ, c'etait aussi bien geré qu'une debian par exemple.


                                      "En pratique sous Linux tu dois rebooter au moins une fois par mois vu le nombre d'updates du kernel, sous Windows c'est idem."

                                      En pratique, j'ai compté 7 mises à jour du noyau sous debian depuis Janvier 2009, donc ceux qui ont redemarré pour charger le nouveau noyau ont quand même eu des uptimes plus long qu'un mois (http://www.debian.org/security/2009/).
                                      En pratique pour avoir du microsoft en serveur depuis avril, c'est rare quand l'uptime depasse 1 mois.

                                      Encore pratique, dans un réseau d'entreprise, un linux non mis à jour peut tenir plusieurs années sans poser de problème en terme de piratage ou attaque de virus (c'est du vecu).
                                      Un windows non mis à jour risque de tenir moins longtemps si les utilisateurs ont moyen, sans le vouloir, de faire rentrer virus, vers et compagnie par la "porte de derriere".
                                      En ce qui me concerne, je met à jour mes serveurs debian par choix (parce qu'on ne sait jamais) et mes serveurs windows par obligation (parce que sans les MAJ, ils vont se faire "demonter" un jour ou l'autre les pauvres).
                                      • [^] # Re: Comme d'hab

                                        Posté par . Évalué à -1.

                                        On pourra mettre toutes les possibilités imaginables sur le redemarrage lors de l'install des mises à jour, ça change pas le problème de base. Pourquoi faut il systematiquement redemarrer un serveur pour n'importe quelle mise à jour ?

                                        C'est du a la maniere dont Windows gere les dlls et exe (tu peux pas remplacer un dll ou exe pendant qu'il est utilise).

                                        En pratique, j'ai compté 7 mises à jour du noyau sous debian depuis Janvier 2009, donc ceux qui ont redemarré pour charger le nouveau noyau ont quand même eu des uptimes plus long qu'un mois (http://www.debian.org/security/2009/).

                                        Et lors des updates a openssl et autres, tu as parcouru la liste de tous les softs l'utilisant et les a tous redemarres ? Sur toutes tes machines ? Ca a du etre drole a faire.

                                        En pratique pour avoir du microsoft en serveur depuis avril, c'est rare quand l'uptime depasse 1 mois.

                                        Logique vu qu'on sort nos patchs chaque mois.

                                        Encore pratique, dans un réseau d'entreprise, un linux non mis à jour peut tenir plusieurs années sans poser de problème en terme de piratage ou attaque de virus (c'est du vecu).

                                        Mets moi dans ton reseau d'entreprise, tu commenceras tres vite a avoir des sueurs froides.

                                        Ce n'est pas parce que les gens ne le font pas que ce n'est pas faisable.

                                        Choix au hasard :
                                        - http://www.samba.org/samba/security/CVE-2009-0022.html
                                        - http://www.vupen.com/english/advisories/2009/0029
                                        - http://www.samba.org/samba/security/CVE-2008-1105.html
                                        • [^] # Re: Comme d'hab

                                          Posté par (page perso) . Évalué à 4.

                                          C'est du a la maniere dont Windows gere les dlls et exe (tu peux pas remplacer un dll ou exe pendant qu'il est utilise).

                                          Ce que fait le dpkg dans ce cas là, il arrête le service utilisant la bibliothèque, remplace le fichier et démarre le service.

                                          Et lors des updates a openssl et autres, tu as parcouru la liste de tous les softs l'utilisant et les a tous redemarres

                                          Debian gère ça automatiquement. Lorsque tu mets à jour une bibliothèque genre openssl, il te mets la liste de tous les services devant être redémarrés. Tu peux décider de ne pas redémarrer un en le supprimant de la liste.

                                          "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                                          • [^] # Re: Comme d'hab

                                            Posté par . Évalué à 1.

                                            Ton dpkg il inclut tous ces softs metiers et autres qui ne sont pas livres en tant que .deb ? Il est baleze dis donc.

                                            Parce que le gros probleme c'est bien ca, le systeme de packaging il ne couvre pas tout, surtout lorsque il s'agit de logiciels proprio et dieu sait si les entreprises en utilisent.
                                            • [^] # Re: Comme d'hab

                                              Posté par (page perso) . Évalué à 3.

                                              Si l'admin a prévu le coup il a fait un paquet qui permet de "caler" ton logiciel dans le système de paquet. C'est un paquet qui ne fait rien d'autre que de te garantir les dépendances et tout et tout durant les mises à jour. Le paquet en lui même ne met pas de fichier.

                                              Donc la réponse est oui. dpkg te gère tout. Mais dans certain cas tu dois prévoir manuellement la possibilité X ou Y (les cas où tu ne reçois pas de .deb tout bien fait).

                                              Et tu peux même faire plus que ça, tu peux gérer ta configuration avec, tu peux prévoir de faire des retours en arrière automatique en cas de mise à jour foireuse (ce qui n'arrive jamais, mais ça m'avait été demandé de prévoir un cas comme ça pour une certification ISO-1664).

                                              Debian a un système de gestion de paquets connu et reconnu, ce n'est pas un hasard, c'est un outil qui a été développé par une communauté qui fait tourner le monde des serveurs depuis longtemps et ça se ressent à l'utilisation, c'est un vrai régal.

                                              "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                                              • [^] # Re: Comme d'hab

                                                Posté par . Évalué à -1.

                                                Si l'admin a prévu le coup il a fait un paquet qui permet de "caler" ton logiciel dans le système de paquet. C'est un paquet qui ne fait rien d'autre que de te garantir les dépendances et tout et tout durant les mises à jour. Le paquet en lui même ne met pas de fichier.

                                                Ben ca va etre drole a faire quand tu te rendras compte que le soft il loade des librairies a la demande plutot qu'en etant linke directement a elles(sans parler que ca va etre rigolo de faire cette liste des libs linkees, car faut la refaire a chaque update du soft en question, pour chaque soft au cas ou ca change, et il faut trouver les binaires de chaque soft, nombre qui peut augmenter a chaque release / update).

                                                Eh oui pas de chance, marche pas non plus.

                                                Debian a un système de gestion de paquets connu et reconnu, ce n'est pas un hasard, c'est un outil qui a été développé par une communauté qui fait tourner le monde des serveurs depuis longtemps et ça se ressent à l'utilisation, c'est un vrai régal.

                                                Ce systeme de gestion de paquets ne resoud rien car il ne represente pas l'entier du systeme et ses dependances.
                                                • [^] # Re: Comme d'hab

                                                  Posté par (page perso) . Évalué à 3.

                                                  Si il charge les librairies à la demande, il n'y a rien à faire, je vois pas où tu veux en venir, là ...

                                                  Sinon quand tu prends un logiciel, tu dois toute façon savoir quelles librairies (autres que celle qu'il amène lui-même) tu dois avoir sur ton système et ton logiciel tu vas l'installer dans un répertoire bien délimiter pour que tu puisses voir l'entier du truc sans te prendre la tête.

                                                  Enfin je me demande un truc : tu as déjà installé un logiciel ? Parce que j'ai des doutes, t'es un peu à côté de la plaque là.

                                                  Ce systeme de gestion de paquets ne resoud rien car il ne represente pas l'entier du systeme et ses dependances.

                                                  Si justement c'est une vue de tout ton système et toutes le dépendances

                                                  "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                                                  • [^] # Re: Comme d'hab

                                                    Posté par . Évalué à 0.

                                                    Si il charge les librairies à la demande, il n'y a rien à faire, je vois pas où tu veux en venir, là ...

                                                    Vraiment ?

                                                    Le soft X charge a la demande OpenSSL, un patch pour OpenSSL surgit.

                                                    Tu l'installes, tu redemarres tous les softs, sauf le soft X car tu ne sais pas qu'il utilise OpenSSL, ce soft reste vulnerable.

                                                    Sinon quand tu prends un logiciel, tu dois toute façon savoir quelles librairies (autres que celle qu'il amène lui-même) tu dois avoir sur ton système et ton logiciel tu vas l'installer dans un répertoire bien délimiter pour que tu puisses voir l'entier du truc sans te prendre la tête.

                                                    Quand le soft depend de librairies qui sont quasiment toujours presentes et que l'editeur ne te donne pas l'info (souvent il ne l'a pas d'ailleurs ce qui est drole), tu fais comment ?

                                                    Si justement c'est une vue de tout ton système et toutes le dépendances

                                                    Je viens de te demontrer par A+B que non, car il ne gere pas les softs non-packages, et qu'il n'est pas possible de creer ces packages soi-meme de maniere sure et complete.
                                                    • [^] # Re: Comme d'hab

                                                      Posté par (page perso) . Évalué à 3.

                                                      Je viens de te demontrer par A+B que non, car il ne gere pas les softs non-packages, et qu'il n'est pas possible de creer ces packages soi-meme de maniere sure et complete.

                                                      Si c'est possible, ça demande du temps. Après tu pèses le pour et le contre. Perso je me prends pas la tête, les softs proprios je les redémarre quand je fais une mise à jour.
                                                      Mais il est possible de d'automatiser cette tâche de détection de librairie. Je n'ai jamais essayé, mais vu que tu arrives à isoler tous les fichiers, tu peux facilement faire un script qui va te donner la liste de toutes les librairies nécessaires puis lister les paquets contenant ces librairies (le gestionnaire de paquet de Debian te permet de savoir à quel paquet un fichier appartient).
                                                      De la magie personne ne peut en faire. Ni Microsoft, ni Debian, ni Apple. Mais actuellement le seul système qui s'approche de la perfection en terme de gestion des mises à jour reste Debian et je crois pas que Microsoft s'approche de ça.

                                                      "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                                                      • [^] # Re: Comme d'hab

                                                        Posté par . Évalué à -1.

                                                        Si c'est possible, ça demande du temps. Après tu pèses le pour et le contre. Perso je me prends pas la tête, les softs proprios je les redémarre quand je fais une mise à jour.
                                                        Mais il est possible de d'automatiser cette tâche de détection de librairie. Je n'ai jamais essayé, mais vu que tu arrives à isoler tous les fichiers, tu peux facilement faire un script qui va te donner la liste de toutes les librairies nécessaires puis lister les paquets contenant ces librairies (le gestionnaire de paquet de Debian te permet de savoir à quel paquet un fichier appartient).


                                                        Non tu ne peux pas le faire. Tu ne sais pas quand et sous quelles conditions le soft va decider de charger la librairie, si tu fais tourner ton script hors de cette condition, tu ne verras pas la librairie.

                                                        Quand a ne pas te prendre la tete, c'est justement la bonne solution, parce que c'est la seule qui soit sure.
                                                        Maintenant quand tu deploies ton patch et que tu dois redemarrer tous ces softs sur X machines differentes, faut savoir comment le faire sur chaque machine, garder la chose a jour, etc... un vrai bordel compare a "je me prends pas la tete" comme tu le dis qui est de redemarrer le systeme.

                                                        De la magie personne ne peut en faire. Ni Microsoft, ni Debian, ni Apple. Mais actuellement le seul système qui s'approche de la perfection en terme de gestion des mises à jour reste Debian et je crois pas que Microsoft s'approche de ça.

                                                        Que Microsoft ne soit pas parfait je n'en doutes pas une seconde, que Debian en soit proche sur ce point, permet moi de rire, c'est le genre de systeme ou soit tu y arrives completement, soit tu n'y arrives pas, il y a pas de milieu, car le milieu signifie que tu restes vulnerable sans le savoir, et Debian n'y arrives pas completement, bref, il est exactement au meme stade que MS.
                                                        Que les gens ne s'en rendent pas compte et suivent aveuglement le troupeau ne signifie pas que le troupeau a raison.
                                        • [^] # Re: Comme d'hab

                                          Posté par . Évalué à 1.

                                          Et lors des updates a openssl et autres, tu as parcouru la liste de tous les softs l'utilisant et les a tous redemarres ? Sur toutes tes machines ? Ca a du etre drole a faire.

                                          Ah oui, quand on ne sais pas se servir d'un gestionnaire de paquet, on peut imaginer que c'est difficile. Alors, pour obtenir la liste des paquets installes sur la machine, c'est une ligne de shell, pour savoir quels sont les paquets qui utilisent openssl, c'est une autre ligne de shell, reste ensuite a croiser les deux liste, ce qui doit se faire avec une troisieme ligne de shell (j'ai meme pas chercher à savoir s'il y avait une commande qui faisait déjà les trois opérations).

                                          Et je doute que distribuer ca sur une liste de machines avec ssh ca soit vraiment plus compliqué...

                                          Mais bon, je te comprends, tu n'as pas l'habitude...
                                          • [^] # Re: Comme d'hab

                                            Posté par (page perso) . Évalué à 3.

                                            Tu devrais passer sur Debian, c'est déjà gérer.

                                            "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                                            • [^] # Re: Comme d'hab

                                              Posté par . Évalué à 2.

                                              Ben, j'utilise déjà Debian, et depuis longtemps...

                                              En fait, j'ai répondu directement a la question de pBpG, a savoir comment on fait pour trouver la liste des packages qui utilisent openssl, et je ne me suis pas soucié de savoir si le gestionnaire de paquet (qui connait bien sur cette info) s'en servait pour redémarrer automatiquement les services concernés... mais bon, evidemment, j'aurais pu me douter qu'il le faisait, parce qu'il le peut et que c'est super utile.

                                              Bref, faut que je révise mon gestionnaire de paquet, il est encore plus puissant que je ne l'imaginais.
                                          • [^] # Re: Comme d'hab

                                            Posté par . Évalué à -1.

                                            Ben non c'est incomplet, nombre de softs proprio ne sont pas disponibles dans le packaging de la distribution.

                                            Ton systeme ne fonctionne pas et est dangereux pour le systeme.

                                            Mais bon, je te comprends, tu n'as pas l'habitude...

                                            Au contraire, j'ai l'habitude, la preuve.
                                            • [^] # Re: Comme d'hab

                                              Posté par (page perso) . Évalué à 2.

                                              J'ai répondu en haut pour la gestion des softs proprios ... Et j'en fait tourner (pas le choix, mea culpa).

                                              Et tu sais, Windows c'est incomplet, nombre de soft qui ne sont pas disponible du tout (et qui font parties des softs métiers).

                                              "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                                              • [^] # Re: Comme d'hab

                                                Posté par . Évalué à -1.

                                                Rien j'est jamais complet, mais il est assez evident que niveau softs dispos Linux a qqe trains de retard
                                            • [^] # Re: Comme d'hab

                                              Posté par . Évalué à 2.

                                              Mmh.... Tu as demandé comment on faisait pour connaitre tous les logiciels qui utilisent openssl, en sous-entendant que ce n'était pas facile.
                                              J'ai donné une méthode manuelle en trois ligne de shell, et Etienne a précisé que le gestionnaire de paquet utilisait déja cette fonctionnalité pour les mises à jour.
                                              Ensuite, au lieu de reconnaitre la puissance du gestionnaire de paquet, tu dévie la question sur les logiciels propriétaires qui ne rentrent pas dans le moule. Je te remercie de nous montrer la supériorité du libre sur le propriétaire, mais ca on le savait déjà. Et je te retourne la question : sur Windows, comment on fait pour identifier tous les logiciels qui dépendent d'une bibliothèque ?

                                              Pour revenir au sujet :
                                              - Si la machine ne comporte que des logiciels packagés, alors je peux laisser le gestionnaire de paquet gérer les dépendances, c'est son boulot.
                                              - Si elle héberge en plus des logiciels non packagés (propriétaires ou pas), on sait reconnaitre ces logiciels et les redémarrer, parce qu'on s'est donné la peine de les installer avec un peu de méthode. Si on ne veut pas se prendre
                                              la tête, on redémarre systématiquement ces logiciels en cas de mise à jour.
                                              - Et on a même la possibilité de créer des paquets "fictifs" pour que le gestionnaire de paquets prenne en charge les logiciels externes.

                                              J'aimerais que tu nous explique quel sont les cas qui ne sont pas pris en compte par les trois points ci-dessus, et surtout comment on peut faire la meme chose sous Windows.
                                              • [^] # Re: Comme d'hab

                                                Posté par . Évalué à -1.

                                                Ensuite, au lieu de reconnaitre la puissance du gestionnaire de paquet, tu dévie la question sur les logiciels propriétaires qui ne rentrent pas dans le moule. Je te remercie de nous montrer la supériorité du libre sur le propriétaire, mais ca on le savait déjà. Et je te retourne la question : sur Windows, comment on fait pour identifier tous les logiciels qui dépendent d'une bibliothèque ?

                                                Tu me fais rire, je te demandes un truc, tu me donnes une solution qui ne marche qu'a 50%
                                                La superiorite du libre sur le proprio elle est tres drole et n'a rien a voir la dedans, c'est le fait que le soft ne soit pas package qui est le point faible.

                                                Et je te retourne la question : sur Windows, comment on fait pour identifier tous les logiciels qui dépendent d'une bibliothèque ?

                                                Inutile de me retourner la question, la reponse est que c'est une chose impossible a faire quel que soit le systeme.

                                                Pour revenir au sujet :
                                                - Si la machine ne comporte que des logiciels packagés, alors je peux laisser le gestionnaire de paquet gérer les dépendances, c'est son boulot.
                                                - Si elle héberge en plus des logiciels non packagés (propriétaires ou pas), on sait reconnaitre ces logiciels et les redémarrer, parce qu'on s'est donné la peine de les installer avec un peu de méthode. Si on ne veut pas se prendre
                                                la tête, on redémarre systématiquement ces logiciels en cas de mise à jour.


                                                a) Oui, mais c'est plutot utopique
                                                b) Oui, idem sous Windows en fait

                                                J'aimerais que tu nous explique quel sont les cas qui ne sont pas pris en compte par les trois points ci-dessus, et surtout comment on peut faire la meme chose sous Windows.

                                                Il y a un truc qui s'appelle MSI sous Windows, tu devrais chercher ce qu'il fait, ca t'apprendrais des trucs je pense.
                                                • [^] # Re: Comme d'hab

                                                  Posté par . Évalué à 2.

                                                  Tu me fais rire, je te demandes un truc, tu me donnes une solution qui ne marche qu'a 50%

                                                  Content de te faire rire, sache que toi aussi tu m'amuses beaucoup.

                                                  La superiorite du libre sur le proprio elle est tres drole et n'a rien a voir la dedans, c'est le fait que le soft ne soit pas package qui est le point faible.
                                                  Donc, la solution que je donne marche a 100% lorsque tous les softs sont packagés, merci de le démontrer. Et sans trop de difficultés, on peut toujours faire un pseudo-package autour d'un soft non-packagé, juste pour l'inscrire dans le gestionnaire de paquet.
                                                  Maintenant, le libre a effectivement quelque chose a voir la dedans, parce que les softs libres sont presque toujours packagés, contrairement au softs proprios.

                                                  Inutile de me retourner la question, la reponse est que c'est une chose impossible a faire quel que soit le systeme.

                                                  Magnifique. Tu ne sais pas le faire sur le systeme commercialisé par ton employeur, donc tu généralise à tous les systemes existants, alors qu'on vient de te donner au moins un exemple du contraire. Quelle belle démonstration !

                                                  a) Oui, mais c'est plutot utopique
                                                  b) Oui, idem sous Windows en fait


                                                  Ben oui, quand on ne sais pas faire a), on fait systematiquement b), mais c'est pas glorieux.

                                                  Il y a un truc qui s'appelle MSI sous Windows, tu devrais chercher ce qu'il fait, ca t'apprendrais des trucs je pense.

                                                  Oui, je vais aller voir, parce que je n'ai pas la prétention de tout connaitre. Mais d'après ton discours, j'ai bien peur que ce machin ne sache pas gérer les dépendances, alors je ne m'attends pas à une révélation.

                                                  Et puis... tu sais, il y a un truc qui s'appelle dpkg sous Debian, tu devrais chercher ce qu'il fait, ca t'apprendrais des trucs je pense.
                                                  • [^] # Re: Comme d'hab

                                                    Posté par . Évalué à -1.

                                                    Donc, la solution que je donne marche a 100% lorsque tous les softs sont packagés, merci de le démontrer. Et sans trop de difficultés, on peut toujours faire un pseudo-package autour d'un soft non-packagé, juste pour l'inscrire dans le gestionnaire de paquet.

                                                    Moi je t'ai demande une solution qui marche a 100% dans la realite, pas une solution qui marche a 100% dans un monde hypothetique.

                                                    Quand a faire un pseudo-package, j'ai demontre plus haut que non, ce n'est pas faisable pour bon nombre de softs.

                                                    Maintenant, le libre a effectivement quelque chose a voir la dedans, parce que les softs libres sont presque toujours packagés, contrairement au softs proprios.

                                                    Eh oui... "presque toujours", enfin bon, sauf dans les cas ou la version qu'on veut est plus recente que la distrib, car la le package fourni met un merdier pas possible dans les dependances, sauf dans le cas ou le soft n'est pas fourni par la distrib, ...
                                                    Et chacun de ces cas constitue un trou dans ta solution qui garderait ton systeme vulnerable.

                                                    Magnifique. Tu ne sais pas le faire sur le systeme commercialisé par ton employeur, donc tu généralise à tous les systemes existants, alors qu'on vient de te donner au moins un exemple du contraire. Quelle belle démonstration !

                                                    C'est triste que tu ne saches pas de quoi tu parles.

                                                    Oui, je vais aller voir, parce que je n'ai pas la prétention de tout connaitre. Mais d'après ton discours, j'ai bien peur que ce machin ne sache pas gérer les dépendances, alors je ne m'attends pas à une révélation.

                                                    C'est bien ca le probleme, tu parles de ce que tu ne connais pas. MSI gere les dependances, il est capable de te trouver tous les packages dependant du binaire X, il est aussi capable de te dire comment arreter / redemarrer les services dependants.

                                                    Mais rien de tout cela ne resoud le probleme.
                                                    • [^] # Re: Comme d'hab

                                                      Posté par (page perso) . Évalué à 2.

                                                      Il est toujours vivant ce troll ?

                                                      Quand a faire un pseudo-package, j'ai demontre plus haut que non, ce n'est pas faisable pour bon nombre de softs.

                                                      Faire des pseudo-paquets est faisable moyennant un peu de temps pour le faire. Peu importe la méthode que le logiciel utilise. Tu peux toujours savoir quelle librairies un logiciel charge.

                                                      Eh oui... "presque toujours", enfin bon, sauf dans les cas ou la version qu'on veut est plus recente que la distrib, car la le package fourni met un merdier pas possible dans les dependances, sauf dans le cas ou le soft n'est pas fourni par la distrib, ...

                                                      Je suis pas certain de comprendre ta phrase, mais je crois en comprendre l'essence. C'est très simple d'installer un logiciel non-empaqueté ou empaqueté pour une autre distribution. Installer un des ces logiciels et ses dépendances ne met pas en danger le système de paquet puisque les systèmes de paquets respectes la "Filesystem Hierarchy Standard".

                                                      C'est triste que tu ne saches pas de quoi tu parles.

                                                      Je crois qu'il sait de quoi il parle, tu dois te tromper.


                                                      C'est bien ca le probleme, tu parles de ce que tu ne connais pas. MSI gere les dependances, il est capable de te trouver tous les packages dependant du binaire X, il est aussi capable de te dire comment arreter / redemarrer les services dependants.

                                                      Mais rien de tout cela ne resoud le probleme.


                                                      MSI n'est pas la panacée, loin de là. Et ça fait pas longtemps que MS Office peut-être installé en silencieux (ce qui est normalement requis pour les paquets MSI). Le problème de MSI c'est que Microsoft n'a pas joué le jeu avec MS Office (pas de mode silencieux), donc d'autres ont fait pareil. Le produit a été gâché. Dommage.

                                                      "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                                                      • [^] # Re: Comme d'hab

                                                        Posté par . Évalué à 0.

                                                        Faire des pseudo-paquets est faisable moyennant un peu de temps pour le faire. Peu importe la méthode que le logiciel utilise. Tu peux toujours savoir quelle librairies un logiciel charge.

                                                        Tu peux savoir a l'instant T quelle librairie il a charge, je te mets au defi de me donner une methode qui permet de garantir que tu sauras quelle librairie il *peut* charger. Hors, c'est ce qu'il faut pour pouvoir generer un paquet complet, sinon quand tu fais ta query pour savoir quels paquets dependent de la lib X, tu auras faux.

                                                        Je suis pas certain de comprendre ta phrase, mais je crois en comprendre l'essence. C'est très simple d'installer un logiciel non-empaqueté ou empaqueté pour une autre distribution. Installer un des ces logiciels et ses dépendances ne met pas en danger le système de paquet puisque les systèmes de paquets respectes la "Filesystem Hierarchy Standard".

                                                        Non ca ne met pas le systeme de dependances en danger, mais dieu sait si ca installe un merdier enorme sur le systeme(ben oui, parce que cette nouvelle version du paquet, elle depend des nouvelles versions des dependances, et faut tout ramener), resultat c'est absolument deconseille.

                                                        Je crois qu'il sait de quoi il parle, tu dois te tromper.

                                                        Clairement non vu qu'il ne sais meme pas que MSI gere les dependances.

                                                        MSI n'est pas la panacée, loin de là. Et ça fait pas longtemps que MS Office peut-être installé en silencieux (ce qui est normalement requis pour les paquets MSI). Le problème de MSI c'est que Microsoft n'a pas joué le jeu avec MS Office (pas de mode silencieux), donc d'autres ont fait pareil. Le produit a été gâché. Dommage.

                                                        Non MSI n'est pas la panacee, tout comme .deb n'est pas la panacee non plus, ni .rpm d'ailleurs. La panacee ca n'existe pas.
                                                        Le probleme de MSI est le meme que .deb : ils ne couvrent pas tous les softs, les paquets ne sont pas tous detailles completement, ...
                                                        • [^] # Re: Comme d'hab

                                                          Posté par (page perso) . Évalué à 2.

                                                          Tu peux savoir a l'instant T quelle librairie il a charge, je te mets au defi de me donner une methode qui permet de garantir que tu sauras quelle librairie il *peut* charger. Hors, c'est ce qu'il faut pour pouvoir generer un paquet complet, sinon quand tu fais ta query pour savoir quels paquets dependent de la lib X, tu auras faux.

                                                          Tu peux mettre à jour tes dépendances au moment même où le logiciel va charger la librairie (enfin quelque ms plus tard). Et en prenant plus de temps, tu peux savoir avant l'exécution du programme quelle librairie il va charger.

                                                          resultat c'est absolument deconseille.

                                                          Non, c'est pas déconseillé bien au contraire puisque les outils pour gérer des logiciels hors système de paquets sont fourni par le système de paquets.

                                                          Clairement non

                                                          Par contre toi tu ne sais pas de quoi tu parles et ça c'est certain.

                                                          Le probleme de MSI est le meme que .deb : ils ne couvrent pas tous les softs, les paquets ne sont pas tous detailles completement, ...

                                                          Non le problème est différent. MSI a été créé par Microsoft et les premiers à ne pas avoir respecter ce système de paquet, c'est Microsoft. Donc crédibilité zéro. Debian respecte les règles définies par le projet. Et ça c'est une _énorme_ différence sur un serveur.

                                                          "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                                                          • [^] # Re: Comme d'hab

                                                            Posté par . Évalué à 0.

                                                            Tu peux mettre à jour tes dépendances au moment même où le logiciel va charger la librairie (enfin quelque ms plus tard). Et en prenant plus de temps, tu peux savoir avant l'exécution du programme quelle librairie il va charger.

                                                            J'attends que tu me montres comment tu fais cela

                                                            Non, c'est pas déconseillé bien au contraire puisque les outils pour gérer des logiciels hors système de paquets sont fourni par le système de paquets.

                                                            Au jour d'aujourd'hui, tu fais quoi ? Tu redemarres tes softs proprios constamment, visiblement tu ne le fais pas. Pourquoi ? Ben oui, trop complexe a mettre a oeuvre.

                                                            Par contre toi tu ne sais pas de quoi tu parles et ça c'est certain.

                                                            Moi j'attends toujours que tu m'expliques _COMMENT_ faire, pas que tu me dises que tu peux.

                                                            Non le problème est différent. MSI a été créé par Microsoft et les premiers à ne pas avoir respecter ce système de paquet, c'est Microsoft. Donc crédibilité zéro. Debian respecte les règles définies par le projet. Et ça c'est une _énorme_ différence sur un serveur.

                                                            Non le probleme est identique, d'un point de vue technologique, MSI c'est .deb , les 2 ont le meme probleme : des softs ne rentrent pas dans le moule pour diverses raisons.
                                                            • [^] # Re: Comme d'hab

                                                              Posté par (page perso) . Évalué à 2.

                                                              Tu modifies les appelles aux fonctions de chargement des librairies de manière à ce qu'à chaque appelle, le système de paquet soit mise à jour en conséquence.

                                                              Tu peux sûrement passer par un module noyau qui intercepte les chargements de librairies et transmet ça à un daemon qui s'occupe de mettre à jour le système de paquet.

                                                              Avec des outils d'analyse d'exécutable tu peux savoir si le logiciel fait appel à des fonctions de chargement de librairies et donc tu peux savoir quel librairie est appelée.

                                                              Tu peux décompiler le logiciel et le comprendre.

                                                              Au jour d'aujourd'hui, tu fais quoi ? Tu redemarres tes softs proprios constamment, visiblement tu ne le fais pas. Pourquoi ? Ben oui, trop complexe a mettre a oeuvre.

                                                              ??? Redémarrer un logiciel c'est compliqué ? Houlà mais attends, on parle de logiciel, pas de centrales nucléaires ... Tu veux pas une aspirine par hasard ?

                                                              "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                                                              • [^] # Re: Comme d'hab

                                                                Posté par . Évalué à 0.

                                                                Tu modifies les appelles aux fonctions de chargement des librairies de manière à ce qu'à chaque appelle, le système de paquet soit mise à jour en conséquence.

                                                                Tu peux sûrement passer par un module noyau qui intercepte les chargements de librairies et transmet ça à un daemon qui s'occupe de mettre à jour le système de paquet.


                                                                C'est tres propre ca, comme ca tu apprendras que Firefox depend de 5235 packages differents(tu sais, tous ces plugins), ce qui est faux.

                                                                Tu peux décompiler le logiciel et le comprendre.

                                                                Super ca, va t'amuser a decompiler Oracle qu'on rigole, surtout lorsqu il generera le nom des libs a charger dynamiquement.
                                                        • [^] # Re: Comme d'hab

                                                          Posté par . Évalué à 1.

                                                          Clairement non vu qu'il ne sais meme pas que MSI gere les dependances.

                                                          Je n'ai jamais prétendu connaitre MSI, relis bien ce que j'ai écrit. J'ai juste déclaré avoir compris, d'après la description que tu en donnais, que MSI ne devait pas gérer les dépendances. Parce que s'il était capable de le faire, il devrait pouvoir s'en servir intelligemment (ne pas redemarrer si necessaire).

                                                          MSI gere les dependances, il est capable de te trouver tous les packages dependant du binaire X,

                                                          Ah, fantastique, MSI est capable de faire "une chose impossible a faire quel que soit le systeme", selon tes propres termes. J'espère que c'est breveté, au moins.

                                                          Mais bon, je ne sais pas de quoi je parle, alors je vais te laisser dans tes certitudes, tu a forcément raison.
                                                          • [^] # Re: Comme d'hab

                                                            Posté par . Évalué à 0.

                                                            Parce que s'il était capable de le faire, il devrait pouvoir s'en servir intelligemment (ne pas redemarrer si necessaire).

                                                            Il le fait jusqu'a un point, comme .deb, c'est pas une methode sure a 100%

                                                            Ah, fantastique, MSI est capable de faire "une chose impossible a faire quel que soit le systeme", selon tes propres termes. J'espère que c'est breveté, au moins.

                                                            MSI fait la meme chose que .deb : il regarde sans sa base de donnees pour un fichier X, et sait quel package est marque comme dependant de X, ca veut pas dire que cette methode est suffisante et infaillible.

                                                            Mais bon, je ne sais pas de quoi je parle, alors je vais te laisser dans tes certitudes, tu a forcément raison.

                                                            Clairement, parce que tu n'arrives pas a faire la difference entre la description d'un package et la realite, c'est pas forcement la meme chose.
                                                            • [^] # Re: Comme d'hab

                                                              Posté par . Évalué à 1.

                                                              MSI fait la meme chose que .deb : il regarde sans sa base de donnees pour un fichier X, et sait quel package est marque comme dependant de X, ca veut pas dire que cette methode est suffisante et infaillible.

                                                              Fantastique, j'espere que c'est breveté. Plaisanterie mise à part, si MSI est capable de faire ceci, pourquoi ne pas laisser le choix a l'admin : lui proposer le reboot systématique (finfaillible) ou seulement d'après le calcul de dépendances de MSI (avec une fiabilité non garantie) ?

                                                              Clairement, parce que tu n'arrives pas a faire la difference entre la description d'un package et la realite, c'est pas forcement la meme chose.

                                                              Oui, tu as absolument raison, la description d'un package peut etre differente de la realité. Dans ce cas, la description est erronée, c'est un bug, on demande a ce que cela soit corrigé, ou on le corrige soit meme.

                                                              Si les logiciels ne sont pas correctement intégrés à la plateforme, ou si les administrateurs travaillent comme des pieds, alors le systeme de gestion de paquet n'est pas fiable. On est bien avancé, là, c'est pas la peine d'aller plus loin, on le savait dès le départ.

                                                              Maintenant, pose toi la question de savoir pourquoi tu supposes être dans cette situation, alors que je fais exactement la supposition inverse ? Indice: les mauvaises habitudes d'administration et de développement propagées par un certain OS depuis des années.
                                                              • [^] # Re: Comme d'hab

                                                                Posté par . Évalué à 0.

                                                                Plaisanterie mise à part, si MSI est capable de faire ceci, pourquoi ne pas laisser le choix a l'admin : lui proposer le reboot systématique (finfaillible) ou seulement d'après le calcul de dépendances de MSI (avec une fiabilité non garantie) ?

                                                                Parce que c'est un choix de merde, pourquoi donc proposer :
                                                                a) Ca marche a coup sur
                                                                b) On a aucune idee de si ca marche, et si ca marche pas tu ne le sauras pas

                                                                b) est extremement dangereux a proposer, partant de la, c'est un choix de merde.

                                                                Oui, tu as absolument raison, la description d'un package peut etre differente de la realité. Dans ce cas, la description est erronée, c'est un bug, on demande a ce que cela soit corrigé, ou on le corrige soit meme.

                                                                Non, je t'ai donne l'exemple plus bas d'un plugin externe charge par un soft, ce plugin est externe au soft, il n'est donc pas reference par le package de ce soft. C'est au contraire le package du plugin qui reference le soft.

                                                                Si les logiciels ne sont pas correctement intégrés à la plateforme, ou si les administrateurs travaillent comme des pieds, alors le systeme de gestion de paquet n'est pas fiable. On est bien avancé, là, c'est pas la peine d'aller plus loin, on le savait dès le départ.

                                                                Maintenant, pose toi la question de savoir pourquoi tu supposes être dans cette situation, alors que je fais exactement la supposition inverse ? Indice: les mauvaises habitudes d'administration et de développement propagées par un certain OS depuis des années.


                                                                Oh mais la reponse a la question est tres simple : J'ai raison et toi non, car plutot que partir sur l'idee que tout est parfait sous Linux je regardes la realite. Les logiciels sous Linux ne sont pas tous integres a la plateforme, et nombre d'admins travaillent comme des pieds. Et cela n'a bien entendu rien a voir avec Windows, c'est un probleme general.
                                                                • [^] # Re: Comme d'hab

                                                                  Posté par . Évalué à 1.

                                                                  Ah, voui, le choix b) est dangereux, alors c'est de la merde, alors on ne le propose pas...

                                                                  ce plugin est externe au soft, il n'est donc pas reference par le package de ce soft. C'est au contraire le package du plugin qui reference le soft.

                                                                  Il est ou le probleme, la ? Le plugin référence le soft, le plugin est mis a jour, le plugin dit coucou au soft, tu redemarres s'il te plait ?
                                                                  Tu es vraiment sur de savoir de quoi tu parles ?

                                                                  Oh mais la reponse a la question est tres simple : J'ai raison et toi non, car plutot que partir sur l'idee que tout est parfait sous Linux je regardes la realite. Les logiciels sous Linux ne sont pas tous integres a la plateforme, et nombre d'admins travaillent comme des pieds.

                                                                  Ah oui, tu as raison et moi non, ca c'est de l'argumentation béton, heureusement qu'on est vendredi.
                                                                  Effectivement, nombre d'admins travaillent comme des pieds, mais c'est pas une raison pour empecher les bons admins de travailler correctement.

                                                                  Je te laisse répondre une dernière fois, parce que j'ai l'impression qu'on va diminuer ton bonus si tu n'as pas le dernier mot sur chaque fil, mais après, j'arrête, ta mauvaise fois me fatigue.
                                                    • [^] # Re: Comme d'hab

                                                      Posté par . Évalué à 1.

                                                      Eh oui... "presque toujours", enfin bon, sauf dans les cas ou la version qu'on veut est plus recente que la distrib, car la le package fourni met un merdier pas possible dans les dependances, sauf dans le cas ou le soft n'est pas fourni par la distrib, ...

                                                      Oui, si on fout le merdier intentionnellement, apres ca marche moins bien. Dis moi quelque chose que je ne sais pas, s'il te plait.
                                                      • [^] # Re: Comme d'hab

                                                        Posté par . Évalué à 0.

                                                        Ah ben oui, installer un soft c'est mettre le merdier j'oubliais !

                                                        C'est ca la beaute du systeme de packaging sous Linux, il garde tout propre, sauf si tu decides d'installer un soft qui n'etait pas prevu.

                                                        C'est sympa quand tu veux la derniere version d'un soft ca.
                                                        • [^] # Re: Comme d'hab

                                                          Posté par . Évalué à 1.

                                                          C'est ca la beaute du systeme de packaging sous Linux, il garde tout propre, sauf si tu decides d'installer un soft qui n'etait pas prevu.

                                                          Et quand c'est pas prévu, on t'a déja donné la solution, plusieurs fois. Mais bon, il semble que tu ne veux pas comprendre.

                                                          Tiens, tu as parlé de Oracle plus haut... La version Express 10g est disponible sous forme de paquets .rpm et .deb ... Comme quoi, il suffit que les editeurs s'y mettent.
                                                          • [^] # Re: Comme d'hab

                                                            Posté par . Évalué à -1.

                                                            Ah oui le packaging Oracle...

                                                            Dis-moi, quand ton Oracle il charge un plugin externe sous forme de librairies dynamique, tu le sais comment ?

                                                            Le systeme de packaging ne reference pas le .so dans le paquet Oracle vu que c'est un plugin externe a Oracle, tu n'as aucun moyen de savoir qu'Oracle l'a charge.

                                                            Tu pourrais t'amuser a trouver tous les packages dependant d'Oracle, mais la encore, ca ne te dit rien sur le fait que la lib est chargee ou pas en ce moment par un des executables Oracle, ...

                                                            Faut vous reveiller, le systeme de packaging il est la pour une chose : decider de quelles binaires sont necessaires au fonctionnement d'un soft et etre capable de les updater. Il est pas la pour gerer le redemarrage de softs lors d'une update, il n'en est tout simplement pas capable.
                                                            • [^] # Re: Comme d'hab

                                                              Posté par (page perso) . Évalué à 2.

                                                              Tu fais exprès là ? Le système de paquets est fait pour la gestion de dépendance. Savoir où vont les fichiers c'est un simple tar, si l'on fait des paquets c'est pour avoir une gestion des dépendances, c'est même l'utilité première.

                                                              Je supposes qu'Oracle a pris le temps de faire un vrai paquet qui indique les dépendances, parce que sinon c'est sympa, t'installes le paquet d'Oracle, tu démarres, ça ne marche pas parce qu'il manque la lib XYZ. Tu installes la lib XYZ, tu démarres, ça marche pas parce qu'il manque la lib ABC, ... Je penses pas qu'Oracle souhaite passer pour une bande de charlot ? Donc ils auront certainement mis les bonnes dépendances pour que lors de l'installation du paquet, le système de gestion aille chercher toutes les dépendances nécessaires et lorsque tu démarres, ça fonctionne.

                                                              Mais je peux me tromper, Oracle est peut-être une bande de charlot.

                                                              "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                                                              • [^] # Re: Comme d'hab

                                                                Posté par . Évalué à 1.

                                                                Tu fais exprès là ?

                                                                Oui, je pense qu'il le fait exprès. Et tout son discours semble basé sur le fait que le vendeur d'un logiciel (par exemple Oracle) a un interêt quelconque a ne pas donner dans les informations du paquet les informations nécessaires a son bon fonctionnement. Je pense personnellement que ca doit venir d'une déformation professionnelle de sa part...
                                                              • [^] # Re: Comme d'hab

                                                                Posté par . Évalué à 0.

                                                                Je supposes qu'Oracle a pris le temps de faire un vrai paquet qui indique les dépendances, parce que sinon c'est sympa, t'installes le paquet d'Oracle, tu démarres, ça ne marche pas parce qu'il manque la lib XYZ. Tu installes la lib XYZ, tu démarres, ça marche pas parce qu'il manque la lib ABC, ... Je penses pas qu'Oracle souhaite passer pour une bande de charlot ?

                                                                Un plugin externe est par definition qqe chose qui n'est pas necessaire au fonctionnement, c'est un plugin.
                                                                Le fait qu'il soit externe signifie que Oracle ne connait peut-etre meme pas son existence.

                                                                Ca ne rend pas moins probable le fait que ce plugin soit charge par Oracle.
                                                                • [^] # Re: Comme d'hab

                                                                  Posté par (page perso) . Évalué à 2.

                                                                  Hallucinant. Donc tu dis que les entreprises vendant du logiciel ne savent pas ce qu'elles mettent dans leurs produits ?
                                                                  Je comprends mieux pourquoi Windows est une bouse sans nom. Je comprends mieux pourquoi je ne fais pas confiance au logiciel propriétaire.

                                                                  "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                                                                  • [^] # Re: Comme d'hab

                                                                    Posté par . Évalué à 0.

                                                                    A toi de me le dire, tu crois que la MoFo connait toutes les extensions existantes pour Firefox ?

                                                                    Je me demandes, tu comprends ce qu'est un plugin ?
                                                                    • [^] # Re: Comme d'hab

                                                                      Posté par (page perso) . Évalué à 2.

                                                                      Donc dans ce cas là je ne vois pas la problème avec le système de gestion de paquet. Les extensions de logiciel sont des paquets séparés dans le gestionnaire de paquet, donc il n'y pas de problème la non plus.

                                                                      "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                                                                      • [^] # Re: Comme d'hab

                                                                        Posté par . Évalué à 0.

                                                                        Je vais t'expliquer le probleme, histoire que tu comprennes la difference entre dependances et utilisation.

                                                                        Plugin X pour Firefox utilises disons Nautilus pour afficher qqe chose quand tu cliques sur un lien.

                                                                        Partant de la, le package du plugin a au moins 2 dependances :
                                                                        - Firefox
                                                                        - Nautilus

                                                                        et il n'y a aucune difference dans la definition de la dependance entre ces 2, car le systeme de dependance de .deb est basique : il te permet de dire de quel package ton package depend, et si ce package est necessaire, optionel, recommande, ...

                                                                        L'enorme difference avec l'utilisation est que le plugin qui est une librairie est charge dans l'espace d'addresse de Firefox, mais pas dans Nautilus, c'est la librairie qui lance Nautilus.

                                                                        Resultat, si tu updates ce plugin, il faut redemarrer Firefox, mais pas Nautilus, et le systeme de packaging n'a _aucun_ moyen de savoir la difference.
                                                                        Alors soit il se mettra a redemarrer des trucs non-necessaire, avec le potentiel de redemarrages en cascade a cause des dependances, soit il ne fait rien.
                                                                        • [^] # Re: Comme d'hab

                                                                          Posté par (page perso) . Évalué à 2.

                                                                          Intéressant. On parle risque de sécurité sur les serveur tu me parles de Nautilus et Firefox. Non mais déjà un serveur, on ne lui installe pas une interface graphique, ça sert à rien et encore moins d'environnement de bureau Gnome.
                                                                          L'art de dire n'importe quoi afin de noyer le poisson dans l'eau.

                                                                          "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                                                                          • [^] # Re: Comme d'hab

                                                                            Posté par . Évalué à 0.

                                                                            Moi je crois plutot que c'est toi qui essaie de noyer le poisson.

                                                                            Firefox et Nautilus etaient pris comme exemples pour illustrer le fait que le systeme de dependances n'est pas capable de gerer les redemarrages.

                                                                            Tu peux les remplacer par des softs serveurs, ca revient au meme.
                                                                            • [^] # Re: Comme d'hab

                                                                              Posté par (page perso) . Évalué à 2.

                                                                              Moi je crois plutot que c'est toi qui essaie de noyer le poisson.

                                                                              Oui en trouvant toujours une solution au problème que tu essaies de faire exister.

                                                                              Bon je vais être bref parce que j'en ai un peu marre. Chaque fois qu'un logiciel charge un plugin, il y a moyen de le savoir puisque cela passe par diverse appelle dans les librairies de base du système et par le noyau du système. Celui qui veut faire le système tip-top nikel chrome il peut exploiter cette information et tenir à jour la liste des dépendances.

                                                                              Ensuite les plugins sont souvent ajouté par l'administrateur donc celui-ci sait ce qu'il fait ou alors documenter par le fabricant du logiciel. On est pas chez Microsoft là, les logiciels qu'on installe sur des serveurs on lit la documentation avant et on a généralement une documentation assez complète et suffisante pour faire une intégration correcte.

                                                                              Ce que tu essaies de prouver c'est qu'un système qui ne redémarre que quand c'est nécessaire lors des mises à jour n'existe pas. Moi je te dis il existe. Et toutes les théories que tu avances sont anéantis par le simple fait que j'ai des serveurs qui ne redémarrent seulement quand il y a mis à jour du noyau, ceux-ci font le partage des données (samba), la gestion des comptes utilisateurs (LDAP et tout), partage d'impression, réseau (dhcp, dns, ...), mail (Exim, dovecot), calendrier (caldav), agenda (LDAP). C'est déjà une bonne partie de l'infrastructure nécessaire en entreprise et c'est même la seule partie nécessaire dans la plus part des PME. Et ça ce n'est pas faisable sur le système de ton boss parce que c'est plus simple de forcer à tous redémarrer que de documenter une fois pour toute et de manière ouverte le système complet.

                                                                              "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                                                                              • [^] # Re: Comme d'hab

                                                                                Posté par . Évalué à 0.

                                                                                Bon je vais être bref parce que j'en ai un peu marre. Chaque fois qu'un logiciel charge un plugin, il y a moyen de le savoir puisque cela passe par diverse appelle dans les librairies de base du système et par le noyau du système. Celui qui veut faire le système tip-top nikel chrome il peut exploiter cette information et tenir à jour la liste des dépendances.

                                                                                Oh ben bien sur qu'il y a moyen de le savoir. Mais ce n'est pas le systeme de dependances.

                                                                                Maintenant dis-moi, tu connais qq'un qui utilise ce systeme ? Tu me trouves un lien sur ce systeme pour que je puisse l'utiliser demain ?

                                                                                Non, il n'existe pas, pour une raison bien simple: si tu fais cela tu pourris la base de donnees des dependances avec des infos qui sont _fausses_ , un plugin n'est pas une dependance dans le sens Soft -> plugin mais dans l'autre sens.

                                                                                Ensuite les plugins sont souvent ajouté par l'administrateur donc celui-ci sait ce qu'il fait ou alors documenter par le fabricant du logiciel. On est pas chez Microsoft là, les logiciels qu'on installe sur des serveurs on lit la documentation avant et on a généralement une documentation assez complète et suffisante pour faire une intégration correcte.

                                                                                Oh joli la petite pique, mais sois honnete plutot que sortir des aneries sur MS. Que le plugin soit installe oui, mais ca ne veut pas dire qu'il est charge.

                                                                                Ce que tu essaies de prouver c'est qu'un système qui ne redémarre que quand c'est nécessaire lors des mises à jour n'existe pas. Moi je te dis il existe. Et toutes les théories que tu avances sont anéantis par le simple fait que j'ai des serveurs qui ne redémarrent seulement quand il y a mis à jour du noyau, ceux-ci font le partage des données (samba), la gestion des comptes utilisateurs (LDAP et tout), partage d'impression, réseau (dhcp, dns, ...), mail (Exim, dovecot), calendrier (caldav), agenda (LDAP). C'est déjà une bonne partie de l'infrastructure nécessaire en entreprise et c'est même la seule partie nécessaire dans la plus part des PME. Et ça ce n'est pas faisable sur le système de ton boss parce que c'est plus simple de forcer à tous redémarrer que de documenter une fois pour toute et de manière ouverte le système complet.

                                                                                Ce qui est triste, ce que tu ne comprends meme pas le sujet dont tu parles.

                                                                                Oui ton systeme il ne reboote pas, ca ne veut pas dire qu'il a ete patche correctement !

                                                                                Moi j'attends que tu m'expliques comment ton dpkg il regle le probleme que j'ai donne plus haut, et je veux la maniere de le regler en pratique, pas en theorie, si demain tu dois le faire, quelles commandes tu tapes, quel soft tu lances, parce que je suis sur a 100% que tu n'appliques pas cette technique d'interception de syscalls pour trouver les dependances, et que personne ne le fait.
                                                                              • [^] # Re: Comme d'hab

                                                                                Posté par . Évalué à 1.

                                                                                Tu devrais laisser tomber, parce que tu perds ton temps. Il veut absolument gérer le problème de manière technique (interception de syscall, etc.), et il refuse de comprendre qu'une solution déclarative puisse marcher. Bref, c'est sans espoir.

                                                                                Et puis, surtout, n'oublie pas que nous ne savons pas de quoi nous parlons, contrairement à lui, qui affirme, je cite : le systeme de dependance de .deb est basique.

                                                                                On devrait lui suggérer de faire une recherche sur les mots-clefs dpkg triggers, ca pourrait peut-être lui apprendre quelque-chose.

                                                                                Mais quel clown...
                                                                                • [^] # Re: Comme d'hab

                                                                                  Posté par . Évalué à 0.

                                                                                  Sachant que la solution declarative _ne fonctionne pas_ effectivement je refuse decomprendre qu'elle puisse marcher.

                                                                                  Mais je serais ravi que tu m'expliques comment ton adorable dpkg resoud le probleme que j'ai donne plus haut, et je veux un exemple pratique de resolution qui puisse s'appliquer de maniere generale, pas un hack qui marche dans 1 cas et pas l'autre.
                                                                                  • [^] # Re: Comme d'hab

                                                                                    Posté par (page perso) . Évalué à 2.

                                                                                    Il m'affiche la liste des logiciels qu'il va redémarrer, dans cette liste il y a les deux logiciels (nautilus et firefox) et moi j'enlève celui qu'il n'y pas besoin de redémarrer ou je redémarre les deux logiciels, mais ma machine n'a pas été redémarrer et les utilisateurs ont senti un petit temps de latence, mais pas trop grave comparé au 30 minutes (et ça c'est sans serveur Exchange) de latences (s'il redémarre, ce qui est moins certain avec Exchange qui a la manie de vite corrompre ça base à l'extinction (pour rajouter un peu de fun dans l'opération)) que des solutions concurrentes proposent.

                                                                                    PS: Tu noteras que j'ai une haine particulière envers Exchange, mais c'est le résultat de longues nuits blanches.

                                                                                    "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                                                                                    • [^] # Re: Comme d'hab

                                                                                      Posté par . Évalué à -1.

                                                                                      La tu me donnes de la theorie de nouveau.

                                                                                      En _pratique_ (donc si je voulais le faire demain, comment je ferais), tu fais comment pour :
                                                                                      a) Avoir les bonnes dependances et ne pas en rater y compris avec des softs non-packages originellement
                                                                                      b) T'assurer que ton systeme de dependances ne te sort pas 2353 softs qui n'ont rien a voir , parce qu'un plugin comme je te l'ai demontre ,ca peut dependre de tout un tas de trucs ayant un executable ou daemon parmis eux sans etre forcement charge dans leur espace d'addresse.

                                                                                      Quelles sont les commandes que tu utilises pour faire a) et b) de maniere efficace (c'est a dire que ca marche 99% du temps, par opposition a un hack qui marche 20-30% du temps)
                                                                                      • [^] # Re: Comme d'hab

                                                                                        Posté par (page perso) . Évalué à 2.

                                                                                        Tu n'utilises pas un système Microsoft.

                                                                                        "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                                                                                        • [^] # Re: Comme d'hab

                                                                                          Posté par . Évalué à -1.

                                                                                          C'est drole comme tu evites de repondre, a croire que tu n'as pas la reponse.
                                                                                          • [^] # Re: Comme d'hab

                                                                                            Posté par (page perso) . Évalué à 4.

                                                                                            J'ai répondu quatre cent fois en long en large et en travers, sauf que j'ai l'impression de parler a un mur qui ne comprend pas un mot de ce que je dis ... J'en ai juste plein l'os de répété les même mots, ça me donne l'impression d'être dans une cage.
                                                                                            Je te laisses relire la discussion en entier si tu la veux ta réponse, mais moi c'est mon dernier poste sur ce sujet.

                                                                                            "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                                                                                            • [^] # Re: Comme d'hab

                                                                                              Posté par . Évalué à -1.

                                                                                              Non tu n'as rien donne, tu donne des "il suffit de xxx" qui ne tiennent pas debout et que personne ne fait.

                                                                                              Par exemple ton idee d'utiliser strace qui finirait par donner des centaines de dependances a un soft (car sa lib charge une autre lib, qui en charge une autre, etc...), qui a un impact reel sur ses perfs et qui donc empeche son utilisation sur machines de prod, etc...

                                                                                              Tu sais parfaitement que personne n'utilise les techniques que tu as donnees, car elles ne fonctionnent pas dans la vraie vie.
                                        • [^] # Re: Comme d'hab

                                          Posté par . Évalué à 3.

                                          "Mets moi dans ton reseau d'entreprise, tu commenceras tres vite a avoir des sueurs froides."

                                          Le fait même qu'une personne malveillante puisse rentrer dans les locaux et reussir à se plugger sur le reseau sans que cela ne derange personne est déjà un gros problème de securité.
                                          La securité informatiqye ne s'arrête pas au système d'exploitation...
  • # Ah bin zut alors

    Posté par . Évalué à 10.

    Va falloir installer OpenOffice pour pouvoir filtrer les ports.
    Heureusement dans Windows (after)Eight, on aura une commande pour savoir qui a le droit de le faire.
    Ouf, sauvés.
  • # super

    Posté par (page perso) . Évalué à -10.

    Oué super, en même temps combien de machines potentiellement vulnérables ?

    - Madame Michu sur son 7 Home Premium a le firewall avec ces ports de bloqué par défaut sur sa connexion internet.
    - Une entreprise utilise un firewall qui bloque déjà ces ports vers l'extérieur de l'entreprise.

    En gros, 99,9% des utilisateurs s'en foutent.

    En attendant avec Seven vous pouvez oublier vous servir de samba pour quelques temps
    Bah oué, moi je m'en sers et cette faille ne m'inquiète absoluement pas, dingue n'est ce pas ?
    • [^] # Re: super

      Posté par . Évalué à 2.

      C'est pas une raison pour que microsoft ne prenne pas cette vulnerabilité au serieux...
      ça me fait d'ailleurs penser à conficker qui utilise aussi en partie une vulnerabilité netbios des windows 2000 à vista (je suppose, pas le 7) dont le patch existe depuis un moment.
      Il s'est pas glissé de l'exterieur, mais bel et bien de l'interieur et pas que chez Mme Michu...à son travail aussi (comme par hasard ^^).
      • [^] # Re: super

        Posté par (page perso) . Évalué à -1.

        C'est pas une question de sérieux, c'est une question de criticité : Microsoft précise explicitement qu'ils travaillent à la réalisation d'un correctif (cf FAQ), la question réside uniquement dans le moment où il sera dispo : correctifs mensuels ou correctif "urgent". Pour l'instant la faille n'est pas exploitée malgré le fait que le code soit dispo pour le faire.
        Et pour cause, à part un admin boulet en entreprise qui aurait ouvert _volontairement_ les ports SMB vers l'extérieur, la menace ne peut que venir d'un intranet. Un ver peut bien sûr être un vecteur, m'enfin bon l'intérêt de faire un DoS depuis l'intérieur d'une entreprise, voilà quoi.

        Pour l'instant à part 01Net, personne ne juge cette faille critique.
        Suffit de voir le bulletin sur secunia : http://secunia.com/advisories/37347/

        Franchement c'est juste bon pour la presse people informatique et notre cher Albert, trop fier d'annoncer une faille dans Windows 7.
        • [^] # Re: super

          Posté par . Évalué à 6.

        • [^] # Re: super

          Posté par . Évalué à 2.

          "Un ver peut bien sûr être un vecteur, m'enfin bon l'intérêt de faire un DoS depuis l'intérieur d'une entreprise, voilà quoi."


          Re-exemple avec conficker. ce dernier n'avait pas pour but de foutre le "brin" dans les reseaux d'entreprise...N'empêche qu'il a fait plus ou moins de degât. Ok pas de pertes d'infos, mais de ce que j'ai pu lire et voir, ça pouvait aller d'une hausse de l'activité réseau à la desactivation de comptes utilisateurs selon la strategie utilisée par l'entreprise en passant par la perte des partages de fichiers pour le serveurs non patchés.
          • [^] # Re: super

            Posté par (page perso) . Évalué à -2.

            Dans tous les cas, je vois mal un ver qui s'amuse à ouvrir le port 80 pour héberger une page web qui sera visiter par un autre membre de l'entreprise (par hasard bien entendu, y'en a qui tape des IP au pif toute la journée dans leur navigateur) qui, au pire, risque juste de devoir rebooter sa machine.
            • [^] # Re: super

              Posté par . Évalué à 2.

              Bah, avec les mises à jour du DNS poussées par les clients, il peut suffire de s'arranger pour l'adresse IP en question ait un nom sympathique associé, non?
              • [^] # Re: super

                Posté par (page perso) . Évalué à 9.

                Oui, enfin là, vous êtes tous entrain de vous liguer pour rendre cette faille problématique.
                J'aurais tendance à penser comme Timaniac :
                1/ C'est une faille
                2/ Elle est exploitable
                3/ Elle m'empêche pas de dormir pour autant, vues les conditions d'exploitation.

                Et aussi, les "ça fait même pas un mois", ça me lourde.
                Comme si toutes les failles des LL mettaient 10 ans avant d'être découvertes…
                Sans parler des failles dans le noyau linux qui touchent une branche entière… Mais dans ce cas là, non, on félicite plutôt le modèle de développement du LL…

                Proprio ou libre, des bugs, y en a dans tous les logiciels, alors arrêtez de jouer à qui pisse le plus loin, car vous n'aurez pas toujours le vent dans le dos…

                Puis bon, attendre la prochaine update avec le firewall en attendant, ça vaut bien attendre la prochaine update sans la 3D en attendant, hein !
                • [^] # Re: super

                  Posté par . Évalué à 8.

                  Me rappelle que - de 24h avant la decouverte d'une faille de noyau (parmis d'autres), debian (je prend l'exemple de ma distrib) nous sortait un noyau patché dans ses depots. Les mecs ont pas attendu une semaine, un mois ou la saint glin glin.
                  Je me ligue pas contre leur faille mais contre leur politique à traiter le problème...Surtout quand leur pub de ***** met en avant un système "plus securisé"...
                  • [^] # Re: super

                    Posté par . Évalué à -2.

                    C'est super 24h, ca montre tres tres clairement qu'ils n'ont pas teste le patch, et qu'ils n'ont pas passe une minute a chercher si il y avait d'autres failles du meme type, si j'etais toi j'eviterais de l'installer sur mes serveurs.
                    • [^] # Re: super

                      Posté par . Évalué à 8.

                      J'ai confiance en ma distrib, c'est pour ça que je l'utilise. Autant dire que le jour où je fais plus confiance en debian...me restera plus que BSD ^^
                • [^] # Re: super

                  Posté par . Évalué à 2.

                  Oui, enfin là, vous êtes tous entrain de vous liguer pour rendre cette faille problématique.

                  D'un autre côté, le mec qui va vouloir exploiter cette faille risque de faire de même. Sinon, effectivement, le danger sera très limité.

                  Si tous les malfaisants de la planète avaient ton attitude ("moué, bof") face à une faille, on dormirait TOUS beaucoup plus tranquilles ;)
      • [^] # Re: super

        Posté par . Évalué à -1.

        C'est pas une raison pour que microsoft ne prenne pas cette vulnerabilité au serieux...

        Faudrait arreter de prendre les conneries d'Albert pour des realites hein, personne n'a dit qu'on ne prenait pas cette vulnerabilite au serieux.
    • [^] # Re: super

      Posté par . Évalué à 3.

      Donc si l'on suit ton raisonnement c'est pas tres grave qu'une troisieme faille assez critique sur le protocole SMB soit trouve en quelques mois sur les differentes versions windows. De plus tu sembles ne pas avoir tout lu dans le lien, et cela n'est pas bien si l'on veut troller correctement, car il est bien indique que Windows Server 2008 est aussi touche. Maintenant peut etre va tu pretendre que cet OS n'est pas encore present en entreprise?
      • [^] # Re: super

        Posté par (page perso) . Évalué à 1.

        car il est bien indique que Windows Server 2008 est aussi touche. Maintenant peut etre va tu pretendre que cet OS n'est pas encore present en entreprise?
        Remplace "Windows 7" par "Windows Server 2008" dans ma phrase, ça ne change strictement rien à mes propos : en entreprise la vulnérabilité ne peut être exploitée que si une seule condition est réunie : l'admin est un gros boulet, qui :
        - a ouvert _volontairement_ les ports SMB vers l'extérieur
        - navigue sur internet depuis le serveur SMB.
        Sauf si t'es admin, la probabilité que la faille soit exploitée est très faible.
        Bref tout le monde s'en fou, sauf toi bien sûr.
        • [^] # Re: super

          Posté par . Évalué à 8.

          C'est pas comme si les administrateurs n'étaient effectivement pas des gros boulets, sous-formés ce qui justifie leur bas salaires et permet au passage à Microsoft de prétendre derrière que Windows à un CTO inférieur à GNU/linux.
          Effectivement, tout va bien sous le Soleil.
          • [^] # Re: super

            Posté par . Évalué à 5.

            > sous le Soleil

            exactement
        • [^] # Re: super

          Posté par . Évalué à -2.

          Moi je pense que une entreprise qui sort un OS en ayant connaissance d'un probleme de securite public est serieuse? Ca m'etonne pas vraiment pas les problemes sous votre OS...
          • [^] # Re: super

            Posté par (page perso) . Évalué à 4.

            Gros malin : celui qui a découvert la faille indique avoir contacter Microsoft le 8 novembre.
            Comme qui dirait Windows 7 est sorti avant.
      • [^] # Re: super

        Posté par . Évalué à 0.

        car il est bien indique que Windows Server 2008 est aussi touche. Maintenant peut etre va tu pretendre que cet OS n'est pas encore present en entreprise?

        WS08 R2 n'est pas WS08, c'est la version serveur de Win7, apprends a lire.
        • [^] # Re: super

          Posté par . Évalué à 4.

          ah oui, le coup du R2, un coup on le met un coup on le met pas, très pratique pour avoir des dates de sortie, enfin des anciennetés, à géométrie variable.

          c'est un peu comme le SP2 ou le SP3 de XP, si tu veux dire que XP a 8 ans tu ne comptes pas les services pack dedans, mais si tu veux dire qu'il est encore tout frais tu parles de XP SP2 ou XP SP3 et ça nous donne 5 ans ou même seulement 18 mois \o/

          à ce compte-là, Windows 2000 SP4etcetc n'a que 4 ans, mais c'est étonnant tu préfères ne parler que de Windows 2000 tout court puisque c'est à chaque fois pour ne plus avoir à supporter cet OS de trop^W^W^W^W^W fustiger son ancienneté et son horrible obsolescence technique, alors qu'à un an près...
          • [^] # Re: super

            Posté par . Évalué à -1.

            Les changements dans R2 n'ont rien mais alors rien a voir avec un SP.

            - Enlevement du dispatch lock
            - RDP avec remoting de DirectX et video
            - DirectAccess
            - Live Migration pour HV
            - Passage de HV a 64 CPUs
            - DNSSEC
            - BranchCache
            ...

            Jamais un service pack n'a eu de features pareilles, et de loin
            • [^] # Re: super

              Posté par (page perso) . Évalué à 4.

              amais un service pack n'a eu de features pareilles
              Je dirais même: jamais un Windows n'a eu de features pareilles :-)
            • [^] # Re: super

              Posté par . Évalué à 4.

              Question bete, c'est quoi le besoin de remoting de directX sur un os serveur?
              Histoire de profiter du compositing sur le bureau, malgre l'absence de carte 3d decente sur ledit serveur?

              Pour la video par contre, je seche.

              Ou alors c'est juste parce que ca vient du devleoppement pour la version client de l'os et que tant qu'a faire, vous l'avez pousse sur le serveur, histoire d'avoir une base de code commune?
              • [^] # Re: super

                Posté par . Évalué à -1.

                Ben justement, peu importe la carte graphique sur le serveur, ton client sur connecte sur le serveur Terminal Services, il ecrit son document Word a la con, trouve son boulot chiant et il veut voir une anim Direct3D, les instructions D3D seront executees en local sur le client, en tirant partie de la carte graphique du client. Resultat le serveur n'est pas charge par tout ce bordel et c'est plus fluide pour l'utilisateur qu'avoir simplement le buffer de l'anim qui passe.

                Idem pour la video(faut que ca passe par DirectShow je crois)
                • [^] # Re: super

                  Posté par . Évalué à 0.

                  ok, j'avais effectivement pas pense au cas terminal server et voyait ca plutot dans l'optique admin studieux et barbu, avec son pitit gilet contre la clim se connectant a son gentil serveur en remote.
    • [^] # Re: super

      Posté par . Évalué à 6.

      - Une entreprise utilise un firewall qui bloque déjà ces ports vers l'extérieur de l'entreprise.

      Et tu fais comment pour te protéger de l'intérieur? Pour une PME avec trois pecnots dans un bureau ce n'est peut-être pas un problème. Quand tu as plusieurs milliers d'utilisateurs dans ton domaine, déjà c'est plus ennuyeux. Bref cette vulnérabilité est très critique.
  • # même pas un jour

    Posté par (page perso) . Évalué à 3.

    En fait c'est la faille dont je parlais déjà avant la sortie officielle de windows 7 (https://linuxfr.org/~hugoroy/28917.html )

    Donc il faudrait retitrer ça : même pas une seconde :)
    Ce qui est vraiment inadmissible c'est que Microsoft ait mis plus d'un mois à communiquer officiellement autour de cette faille....
    • [^] # Re: même pas un jour

      Posté par . Évalué à 3.

      Ah tiens je n'avais pas fait le rapprochement mais bon les memes qui criait au complot (Timaniac pour ne pas le nommer et un des porte parole "officieux" de MS sur dlfp) vient de nous dire que ce n'etait pas grave. Manque plus que ceux qui criait au FUD viennent nous expliquer que c'est en fait un probleme du a du logiciel GPL qu'une boite de sous traitant a utilise sans que Redmond soit au courrant :)
  • # 7

    Posté par . Évalué à 1.

    Pourquoi "Seven" ? A-t-on dit "Noytifaife" ? Ou encore "Fripauille Touane" ? :-)

    Je crois qu'on dit simplement "Sept".

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.