Core Infrastructure Initiative

Posté par (page perso) . Édité par Davy Defaud et Benoît Sibaud. Modéré par ZeroHeure. Licence CC by-sa
29
25
avr.
2014
Technologie

Après la réponse musclée d’OpenBSD face à la faille Heartbleed d’OpenSSL, la Fondation Linux a aussi une tentative de solution. C’est un groupe de plus d’une dizaine d’entreprises qui va fournir plusieurs millions de dollars pour financer des projets capitaux et libres dans le besoin.

Les financements pourront aller à des développeurs clefs pour qu’ils puissent travailler à plein temps sur leur projet, à des audits de sécurité, à de l’infrastructure de test ou de développement, à des voyages ou même à des réunions physiques. Ce projet sera administré par la Fondation Linux et les fonds seront attribués par un groupe composé des différents bailleurs de fonds, de développeurs de logiciels libres ou d’autres membres des entreprises impliquées dans le Libre.

Pour l’instant, les premières sociétés impliquées sont (par ordre alphabétique) : Amazon, Cisco, Dell, Facebook, Fujitsu, Google, IBM, Intel, Microsoft, NetApp, Qualcomm, Rackspace et VMWare. La fondation espère que d’autres rejoindront le mouvement.

Logo CII

  • # Besoin de renfort, vraiment ?

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

    Si on ne prend que Google ou Facebook, ce sont des dizaines de milliards d'euros de bénéfice chaque année alors effectivement, elles ont besoin du renfort d'autres sociétés pour financer quelques dizaines de personnes travaillant sur des couches logicielles fondamentales.

    • [^] # Re: Besoin de renfort, vraiment ?

      Posté par . Évalué à 8.

      Je vois deux avantages pour eux :

      • ils peuvent financer un coup par coup ; le jour où il n'ont plus besoin de l'organisation, ils coupent le robinet du jour au lendemain et démerdez-vous ; pas la peine de s'embêter à gérer ses salariés.

      • pas de responsabilité directe qui pourrait être impliquée en cas de bug/faille (ou backdoor) importants dans les logiciels produits.

    • [^] # Re: Besoin de renfort, vraiment ?

      Posté par . Évalué à 9.

      Vous gagnez 1000 fois le salaire d'un africain et vous vous plaignez de payer des impôts ? Vraiment ?

      Plis sérieusement, j'ai tout autant intérêt que Google et Microsoft a avoir un SSL qui tienne la route. Pourquoi ne serai ce qu'aux gros de payer. Jusqu'à présent, personne ne se précipitait pour ce projet. Et combien donnez vous personnellement aux projet open source? C'est toujours facile de demander plus quand l'argent sort de la poche des autres…

      • [^] # Re: Besoin de renfort, vraiment ?

        Posté par . Évalué à 2.

        C'est toujours facile de demander plus quand l'argent sort de la poche des autres…

        socialism

      • [^] # Re: Besoin de renfort, vraiment ?

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

        Comme toi, je préfère une biblio SSL sécurisée plutôt que trouée.
        Mais contrairement à Facebook et autres Google je ne gagne pas des milliards en utilisant cette biblio, alors je comprends parfaitement qu'on demande des dons plus facilement aux gros qu'à moi.

        Je donne peu et rarement aux projets libres, tout simplement parce que j'ai de petits moyens.
        Mais si les gros donnaient autant en proportion, je pense que ce projet n'aurait jamais eu de raison d'être.

        • [^] # Re: Besoin de renfort, vraiment ?

          Posté par (page perso) . Évalué à -2. Dernière modification le 26/04/14 à 15:15.

          Je donne peu et rarement aux projets libres, tout simplement parce que j'ai de petits moyens.

          Je cite la personne à laquelle tu réponds :

          Vous gagnez 1000 fois le salaire d'un africain et vous vous plaignez de payer des impôts ? Vraiment ?

          Une personne qui gagne moins de $1 par jour dirait exactement la même chose sur toi que ce que toi dit sur Google. Juste une question de proportions.

          Bref, c'est toujours la même façon de faire : que les autres payent, moi je suis pauvre (sic par rapport aux gens qui gagnent moins de $1 par jour) et j'ai une "bonne raison" pour garder mon fric pour moi en gros égoïste mais les autres sont des salauds de faire comme moi.

          Toujours aux autres de lacher le fric, toujours les autres les méchants. Ben non… ils sont tout simplement comme toi.

          • [^] # Re: Besoin de renfort, vraiment ?

            Posté par (page perso) . Évalué à 3. Dernière modification le 26/04/14 à 15:24.

            distrowatch indique les dons effectués au cours du temps, c'est une incitation régulière dans leurs nouvelles, par exemple :
            http://distrowatch.com/weekly.php?issue=20140106#donation

            perso, même si je touche 4x le smic, je suis un peu en dessous… :/ (200 à 510 dollars à chaque fois)
            On va dire que je « donne » un peu de mon temps au Libre :-) (est-ce suffisant ? Non je ne le pense pas).

          • [^] # Re: Besoin de renfort, vraiment ?

            Posté par . Évalué à 6.

            Une personne qui gagne moins de $1 par jour dirait exactement la même chose sur toi que ce que toi dit sur Google

            Chuis pas sûr qu'un audit d'OpenSSL soit la première de ses préoccupations.
            Mais bon, ce serait dommage de se priver d'un bel effet de manche…

          • [^] # Re: Besoin de renfort, vraiment ?

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

            Contrairement à toi je trouve normal que ce soit à ces grosses boîtes de payer et pas à moi petit utilisateur : elles se font des milliards en se basant sur ces technos libres, là où moi je n'y gagne pas un kopeck.

            Et si tu me relis bien, tu verras que je donne. Peu et rarement parce que je tiens à manger à la fin du mois, mais je donne quand même.
            À l'échelle de nos revenus respectifs, j'en donne une bien plus grande part au libre que ne le font ces entreprises blindées de pognon.

            • [^] # Re: Besoin de renfort, vraiment ?

              Posté par . Évalué à 0.

              Google laisse 20% de leur temps a ses devis sur des projets perso ou open source, et participe au financement d'un grand nombre de projets, voire détaché des devs dessus. Donc au final Google participe énormément au libre…

              • [^] # Re: Besoin de renfort, vraiment ?

                Posté par . Évalué à 6. Dernière modification le 29/04/14 à 17:18.

                Google laisse 20% de leur temps a ses devis sur des projets perso ou open source

                Dans un autre siècle oui, maintenant ca semblerait plutôt être 20% après tes 100%.

                • [^] # Re: Besoin de renfort, vraiment ?

                  Posté par . Évalué à 1.

                  Aussi appelé le 120%.

                • [^] # Re: Besoin de renfort, vraiment ?

                  Posté par . Évalué à 2.

                  Ca dépend d'ou tu bosses chez Google. J'ai des amis qui démentent complètement que les 20% ont disparu.

                  • [^] # Re: Besoin de renfort, vraiment ?

                    Posté par . Évalué à 4.

                    J'avais lu dans la presse il y a quelques temps que les 20% n'étaient pas supprimés mais recadrés.
                    Il fallait que le projet soit approuvé par le manager et qu'il présente un intérêt pour Google.

                    • [^] # Re: Besoin de renfort, vraiment ?

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

                      Dans ce cas on parle bien de travailler 80% du temps pour Google, et les 20% restants… aussi pour Google ?!

                      Bah quand je bossais à la Poste c'était pareil, 100% de mon temps de travail était passé à bosser pour mon employeur (un peu plus en réalité, semaine de 39h oblige).

                      Je n'ai pourtant jamais entendu dire que « la Poste participe énormément au libre »…

                      • [^] # Re: Besoin de renfort, vraiment ?

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

                        Ça dépend ce qu'il veulent dire par "présente un intérêt pour Google". Ça peut très bien être «  on ne veut que nos employés fassent des graphismes pour Xonotic mais on veut bien qu'ils bossent sur les drivers du noyau » ou « on ne veut pas qu'ils bossent sur telle fonction de la libc parce qu'on ne l'utilise pas ».

                        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                        • [^] # Re: Besoin de renfort, vraiment ?

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

                          Je pense comprendre ce que tu veux dire, mais dans ce cas ton exemple est mal choisi : tes deux exemples portent sur des fonctionnalités profitant directement à Google (sauf erreur de ma part, bosser sur les pilotes du noyau va aider au développement d'Android, non ?).

                          Quand je bosse sur un truc qui profite directement à ma boîte, je n'appelle pas ça un « projet personnel ».

                          Bah, on ne pourra pas en savoir plus à ce sujet à moins d'avoir une intervention de quelques personnes bossant chez Google.

                          • [^] # Re: Besoin de renfort, vraiment ?

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

                            (sauf erreur de ma part, bosser sur les pilotes du noyau va aider au développement d'Android, non ?).

                            Je n'y pensais pas. Mais pour l'instant, je ne crois pas qu'il y a d'appareil Android avec les pilotes du noyau à part Intel, et je ne crois pas qu'il y a ait des gens externes qui contribuent.

                            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Besoin de renfort, vraiment ?

      Posté par . Évalué à 10.

      Il est vrai que le coup de l'appel aux dons sur la page a un côté match de bienfaisance chez les footballeurs : on fait raquer 10 ou 20€ à 20000 personnes pour un match bidon alors qu'il suffirait que les gonzes sur la pelouse lâchent un jour de salaire pour réunir la même somme.

      Les boîtes en question ont fait plus de 80 milliards de dollars de bénéfice l'an dernier (et ce en hum… « optimisant » fiscalement par tous les moyens imaginables pour reverser le moins possibles au populo), la somme versée représente pour eux non pas une journée de salaire mais moins de 10 minutes de bénéfice, et elles demandent aux gens de donner à leurs côtés. Mouais.

  • # On verra

    Posté par . Évalué à 10. Dernière modification le 25/04/14 à 18:21.

    [fiction]
    Pour l'instant, ils ont commencé à réunir des millions de dollars et ils ont produit un logo. Ensuite il faudra créer des comités et nommer leurs membres afin que ces comités déterminent des projets pour lesquels il faudra créer des comités et nommer des membres (et créer des logos). 6 mois plus tard, et 250 000 $ cramés en sauteries diverses et autres jetons de présence, on aura peut-être une première livraison de centaines de pages de documents imbittables sur la route à suivre. Ensuite il faudra trouver des programmeurs pour déchiffrer ça.

    Hmmm, je me demande si, quand quelque chose d'utilisable sera produit, l'initiative OpenBSD n'aura pas déjà fini depuis un an, et n'aura pas été portée depuis 10 mois sur les autres systèmes.
    [/fiction]

    • [^] # Re: On verra

      Posté par . Évalué à 10.

      Fiction, ils vont sortir de leurs labos les Leslie Lamport et autres spécialistes des méthodes formelles de l'INRIA et ils vont pondre une infrastructure prouvée mathématiquement en formant quelques devs et ingés au passage.

      • [^] # Re: On verra

        Posté par (page perso) . Évalué à 9. Dernière modification le 26/04/14 à 13:41.

        Je confirme que c'est de la fiction, car les productions scientifiques de Lamport et/ou de l'INRIA ne sont pas libres et c'est la guerre entre les labos de recherche. Cela dit, quand l'un a pondu l'article du siècle c'est une avancée qui profite à tous ! D'ailleurs Lamport a déjà bien fait avancer les choses dans le domaine de formalisation des protocoles distribués.

        Pour ce qui est de la preuve, attention à ne pas confondre protocole et implémentation ! On peut très bien prouver plein de choses sur les protocoles SSL/TLS, ce qui n'empêchera pas leurs implémentations d'être buggées !

        Je veux dire par là que dans la preuve du protocole, on suppose que les méthodes « send(message) » et « receive(message) » sont fiables. Si ce n'est pas le cas (comme pour SSL d'après ce que j'ai compris) la preuve ne tient plus :(

        Je me rappelle avoir posé cette question à un chercheur dans le domaine de la vérification formelle : « What if the OS running your proved protocol didn't behave as expected ? Do you run your implementation on proved OS ? Do they run on proved CPU ?»

        Sa réponse :

        « Fuck ! »

        • [^] # Re: On verra

          Posté par . Évalué à 4.

          Ben je parlais ici de preuve de l'implémentation évidemment. Après c'est sur qu'il faut aussi que l'OS, le compilateur et le CPU soient prouvés, et tous ces chercheurs le savent.

          Mais au moins, pas de bug dans l'implémentation, c'est toujours ça de pris. Un buffer overflow en 2014 c'est à pleurer, quand même.

          • [^] # Re: On verra

            Posté par . Évalué à 4.

            Attention aux preuves. Il faut déjà être d'accord sur la spécification. C'est souvent beaucoup plus dur à définir qu'imaginer.

            Le cas typique est le comportement en cas d'erreur, qui peut devenir très complexe.

            "La première sécurité est la liberté"

            • [^] # Re: On verra

              Posté par . Évalué à 5.

              T'es en train de dire que faire une spécification correcte est plus dur que faire du code incorrect ? J'ai envie de dire que c'est un bon moyen de botter en touche. La gestion d'erreur, oui c'est pas ce qu'il y a de plus facile à coder c'est évident … Après de là à faire attention aux preuves j'ai envie de dire qu'avec des arguments pareils on bouge pas d'un pouce, wtf ?

              • [^] # Re: On verra

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

                T'es en train de dire que faire une spécification correcte est plus dur que faire du code incorrect ?

                Oui, je t'invite à lire Paxos de Lamport justement, c'est un bon exemple de la complexité qu'un protocole (resp. qu'une spec.) peut avoir.

                Attention, je ne dis pas qu'une implémentation est forcément simple, mais des fois (et c'est particulièrement vrai en algorithmique distribuée) la spécification est plus complexe que l'implémentation.

                • [^] # Re: On verra

                  Posté par . Évalué à 2.

                  C'est dur de prouver des systèmes distribués, certes, mais écrire du code correct et être sûr qu'il est correct c'est carrément ultra dur aussi. Il y a quand même des patterns connus pour prouver qu'un calcul distribué termine par exemple. On peut montrer aussi des propriétés d'autostabilisation ou des choses comme ça.

                  • [^] # Re: On verra

                    Posté par (page perso) . Évalué à 6. Dernière modification le 28/04/14 à 09:35.

                    Il y a quand même des patterns connus pour prouver qu'un calcul distribué termine par exemple. On peut montrer aussi des propriétés d'autostabilisation ou des choses comme ça.

                    Je pense que tu t'égares :)

                    Que cela soit en distribué ou pas, on a un système que l'on modélise, une spec, un programme et des outils de preuves pour montrer que le programme est conforme à la spec, étant donné le système considéré.

                    Pour du code, généralement le système est connu : selon le langage tu as un jeu d'instructions, un système de type (c'est encore plus facile à formaliser/prouver, si ton langage a du typage fort), tu peux éventuellement modéliser la mémoire pour certains langages bas niveau et mettre 2/3 contraintes de QoS (puissance CPU, etc.), mais globalement cela s'arrête là.

                    Pour un système distribué, en plus d'avoir les contraintes d'implémentations, tu as les contraintes de distributions et de sécurité (cf. fautes byzantines), qui ajoutent des problèmes au niveau spécification. De tels problèmes sont connus, il s'agit par exemple de consensus distribué, de synchronisation en environnement asynchrone, d'authentification forte,…etc

                    Ce sont deux domaines différents, qui ont tous les deux des cas d'usage difficiles à prouver, mais ce que je veux te montrer c'est que si tu apportes de la distribution, tu apportes de la complexité dans le système, donc tout devient plus difficile à commencer par la spécification.

                    Pour finir :

                    Il y a quand même des patterns connus pour prouver qu'un calcul distribué termine par exemple. On peut montrer aussi des propriétés d'autostabilisation ou des choses comme ça.

                    Avec une modélisation juste d'Internet, c'est-à-dire un système distribué asynchrone dans lequel on ne sait pas distinguer le cas où une machine est lente à répondre ou si elle est en panne, tes propos sont faux. C'est un résultat théorique très connu dans le domaine de l'algorithmique distribué, on le nomme « FLP », pour « Fischer, Lynch, Paterson » et il dit en termes simplifiés :

                    On ne peut pas réaliser un consensus dans un système distribué asynchrone (modèle message passing) , si on tolère au plus une panne (réseau ou machine).

                    Ce qui signifie que non : on ne peut pas montrer qu'un consensus se termine ou qu'un système distribué se stabilise, c'est impossible ! Il existe bien entendu des astuces (se reposer sur un serveur centralisé qui fait fois), mais formellement on ne peut pas prouver ce genre de chose si on prend les hypothèses d'un réseau de type WAN.

                    • [^] # Re: On verra

                      Posté par . Évalué à 1.

                      Pour revenir a des choses plus terre à terre, la faille qui a provoqué tout ça elle n'a pas un nombre arbitraire de pairs et il s'agissait juste d'une erreur de validation des IOs :) On peut prouver des choses rien qu'en bétonnant les IO, évidemment c'est plus compliqué de valider Internet dans sa globalité.

                      • [^] # Re: On verra

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

                        C'est tout le problème, tu mets le doigt dessus en plus.

                        Si tu réfléchis simplement au niveau IO, il te manque le contexte du protocole : tu prouves seulement qu'une réception, indépendamment des autres, se passe bien.

                        Si tu réfléchis au niveau du protocole (i.e. spec.) tu trouves des cas, comme celui que la faille exploite, qui mettent en jeu une séquence de requêtes plus ou moins complexe (et non une seule requête) et des individus byzantins, c'est-à-dire des individus qui pourront exploiter n'importe quelque comportement pour compromettre le système.

                        Le correctif se traduit évidemment par un patch au niveau du code, mais pour voir la faille il faut se placer au niveau du protocole.

                        • [^] # Re: On verra

                          Posté par . Évalué à 3.

                          Pas du tout, si j'ai bien compris le principe de la faille, elle permet d'accéder à une zone mémoire qui ne devrait tout simplement pas être accessible. C'est pas une bête histoire de borne ?

              • [^] # Re: On verra

                Posté par . Évalué à 2.

                Dans les faits, une spec ne couvre jamais entièrement tous les comportements, il y a toujours un paquet de troues que l'on voit (ou pas) lors d'une implémentation.

                Une preuve formelle automatique, a besoin d'avoir la spec entière, ce qui peut être plus difficile à faire qu'un code correct. Souvent, on a juste besoin que le code ne plante jamais (pas d'exception), ni que les données soient corrompues.

                "La première sécurité est la liberté"

                • [^] # Re: On verra

                  Posté par . Évalué à 4.

                  La spec, dans la méthode B, elle est haut niveau au début du developpement et elle se précise au fur et à mesure (c'est le raffinage) justqu'à devenir compilable. Les trous dans la spec tu les détectes parce que c'est impossible de montrer que ton raffinage est compatible avec ce que tu as écris avant. Ils mettent le processus de spec et de preuve au coeur du développement.

                  • [^] # Re: On verra

                    Posté par . Évalué à 3.

                    A part la ligne 14, ils l'ont utilisé ailleurs ?

                    Le ferroviaire aime bien le formel avec des produits de http://www.absint.com/ . Mais ils s'agit souvent de prouver "des théorèmes" et non des "spec complètes".

                    Dans l'aéronautique, ils n'aiment pas trop.

                    "La première sécurité est la liberté"

                    • [^] # Re: On verra

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

                      A part la ligne 14, ils l'ont utilisé ailleurs ?

                      :-) Pas mal oui : http://www.clearsy.com/wp-content/uploads/carte-monde-b-fr.jpg

                      Le KVB qui contrôle la vitesse des TGV est développé en B. Des gestions d'aiguillages d'Alstom sont développés en B. etc.

                      Le ferroviaire aime bien le formel avec des produits de http://www.absint.com/ . Mais ils s'agit souvent de prouver "des théorèmes" et non des "spec complètes".

                      Tu peux jeter un œil sur le travail fait par ClearSy pour le CBTC de Thales sur la Flushing Line de New York. Le but est bien de prouver des propriétés système (i.e. dans une spec complète).
                      http://www.tools.clearsy.com/resources/formal-proofs-for-the-nyct-line-7-modernization-project/

                      Dans l'aéronautique, ils n'aiment pas trop.

                      Assertion un peu gratuite. Le standard DO-178C permet justement d'utiliser des méthodes formelles pour remplacer des tests, ce que la version précédente (178B) ne permettait pas. Et il y a aussi le DO-333 ("Formal Methods Supplement to DO-178C and DO-278A").

                      Airbus est un gros consommateur de méthodes et outils formels : CAVEAT, FLUCTUAT, Astrée, SCADE, CompCert, Frama-C, …

                      • [^] # Re: On verra

                        Posté par . Évalué à 2.

                        Pour info, je bosse pour Esterel. Si tu inclus SCADE dans les outils formels, je comprends ton point de vue. Mais cela ne fait pas de vérification formelle à part le bloc DV qui n'est pas utilisable en DO-178.

                        "La première sécurité est la liberté"

                  • [^] # Re: On verra

                    Posté par (page perso) . Évalué à 5. Dernière modification le 28/04/14 à 09:44.

                    Effectivement l'avantage de la méthode B est de couvrir tout le processus de réalisation (de la spec. à l'implémentation) d'un système. Cela dit, elle a ses propres limites, que je ne connais pas dans le détail et qui résident dans le nombre de fonctionnalités qu'elles propose (ce qui va se réduire au jeu d'instructions du langage d'implémentation à un moment de la méthode).

                    Ce dont je suis sûr, pour en avoir discuté avec un des pères de la méthode B, c'est que cette méthode ne permet pas la communication par message. En gros elle fonctionne sur un système fermé, type ligne 14 ou système bancaire clos (domaine dans lequel elle est aussi utilisée). C'est tout à fait normal, car un système distribué est plus complexe à modéliser et on ne sait pas encore faire des outils type « méthode B » qui intègrent toutes les hypothèses d'un système distribué.

                    Donc pour en revenir au journal, non on ne peut pas utiliser B pour SSL !

                    • [^] # Re: On verra

                      Posté par . Évalué à 2.

                      Bien sur que si, déja si on peut garantir qu'il n'y a pas de bug d'implémentation type heartbleed c'est pas mal. Ça démontrera pas la totale correction du protocole c'est sur. À part ça, j'ai vu passer un récent ajout de modélisation système pour la méthode B sur l'article Wikipédia, je sais pas ce que ça recouvre et j'ai pas investigué, mais si ça se trouve ils s'intéressent à certaines problématiques de distribution.

                      • [^] # Re: On verra

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

                        Le problème c'est que ce n'est pas l'objectif de la méthode B ! Si une méthode ou un langage était le meilleur dans tous les domaines de l'informatique ça se saurait. Mais non, on préfère faire des outils spécialisés car les problématiques sont aussi différentes que complexes et que si l'on veut des choses très fiables (i.e. prouvées formellement) il faut se concentrer sur des domaines précis, dans un premier temps.

                        Je ne pense pas que « B » ait vocation à faire de la preuve de protocole, ce qui ne signifie pas que c'est un mauvais outil, au contraire !

                        • [^] # Re: On verra

                          Posté par . Évalué à 2.

                          Je parle pas vraiment de faire de la preuve de protocole, en fait, on dialogue de sourd.

                          • [^] # Re: On verra

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

                            Je parle pas vraiment de faire de la preuve de protocole

                            Tout à fait, et moi je dis que faire la preuve du protocole c'est l'approche de la méthode B, qui de mon point de vue n'est pas idéale, bien que sûrement pas inutile ici :)

                            • [^] # Re: On verra

                              Posté par . Évalué à 2.

                              Oui et non, l'approche de la méthode B c'est d'écrire des specs et de vérifier que l'implémentation respecte bien les specs, et au passage qu'il n'y a pas de bug à la con comme des buffer overflow. Après comme toujours les specs ont des limites, on peut pas vérifier la cohérence d'un protocole cryptographique si on code seulement un client et un serveur indépendament en B. Ni que la précondition P=NP qui serait l'hypothétique garantie de la sécurité du protocole en question, mais on c'est pas parce qu'on fait du B qu'on est obligé d'essayer :) ~~~~

        • [^] # Re: On verra

          Posté par . Évalué à 2.

          Par ailleurs (je repond un commentaire, peux plus éditer), le nom du projet "Core infrastructure" est un peu énigmatique et laisse présager un projet ambitieux. Dans quel sens ? C'est toute la question mais j'ai tendance qu'ils sont partis pour prendre le problème globalement.

          • [^] # Re: On verra

            Posté par . Évalué à 2.

            Une OPA sur systemd :-)

          • [^] # Re: On verra

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

            J'imagine qu'avec le nom, ils veulent englober tous les projets qu'on retrouve dans une installation classique d'une distribution Linux. Par exemple : OpenSSL, OpenSSH, Bash, Perl, coreutils, systemd…

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: On verra

              Posté par . Évalué à 2.

              On peut imaginer plus, genre l'infrastructure de compilation sur les questions de sécurité.

              • [^] # Re: On verra

                Posté par . Évalué à 2.

                Avec le Tout-PRISM aux manettes, il n'y aura plus de souci à se faire.

          • [^] # Re: On verra

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

            "Core infrastructure" ça a plus de gueule que "Plumbing infrastructure".

        • [^] # Re: On verra

          Posté par . Évalué à 3.

          On peut très bien prouver plein de choses sur les protocoles SSL/TLS, ce qui n'empêchera pas leurs implémentations d'être buggées !

          Par ailleurs il semblerait que les preuves faites sur le protocole TLS ne couvrent pas tous les cas possibles ; je conseille l'article suivant, qui est très intéressant (une vulnérabilité trouvée récemment dans le protocole lui-même) :
          http://blog.cryptographyengineering.com/2014/04/attack-of-week-triple-handshakes-3shake.html

    • [^] # Re: On verra

      Posté par . Évalué à 5.

      Avoir réussis à convaincre ces societés et annoncer ca tout juste 2 semaines après Heartbleed, moi je trouve qu'ils sont plutot réactifs.

      Et meme si ca prenait 6 mois pour commencer à financer réellement OpenSSL, ca ne me semblerait pas non plus incroyablement long.

      Tu t'attendais à quoi, que l'argent soit deja sur le compte des dev OpenSSL depuis une semaine, qu'un nouvel audit soit terminé ?

  • # C'est assez drole

    Posté par . Évalué à 3.

    Microsoft paie pour securiser Linux, alors qu'ils n'etaient pas affectes par la faille OpenSSL vu qu'ils ne l'utilisent pas…

    Faudrait que certains ici pensent a aller leur payer une biere plutot que leur casser du sucre sur le dos constamment !

    • [^] # Re: C'est assez drole

      Posté par . Évalué à 3.

      Peut etre car le prochain telephone Nokia (qui appartient a microsoft maintenant) aura un style windows phone mais tournera sous android par exemple… Donc de la a leur payer une biere…

    • [^] # Re: C'est assez drole

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

      si ils financent ça avec leurs revenus acquis honnetement grâce à leur taxe sur android, ce ne sera qu'il juste retour des choses non ?

    • [^] # Re: C'est assez drole

      Posté par . Évalué à 10.

      C'est bon, j'ai déjà donne quand on m'a impose de prendre leur licence.

    • [^] # Re: C'est assez drole

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

      Le projet ne vise pas qu'à financer OpenSSL.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: C'est assez drole

      Posté par . Évalué à 10.

      Microsoft paie pour securiser Linux, alors qu'ils n'etaient pas affectes par la faille OpenSSL vu qu'ils ne l'utilisent pas…

      Il ont sans doute un interet à le faire, ils font pas ca juste pour rire.

      Faudrait que certains ici pensent a aller leur payer une biere plutot que leur casser du sucre sur le dos constamment !

      Ben non, c'est pas par ce qu'une societé fait des trucs bien dans certains cas qu'il faut s'interdire de la critiquer sur d'autres sujets.

      Par exemple: c'est pas par ce que Google organise le Google Summer of Code qu'on doit s'empecher de critiquer certaines actions de Google.

      Ca serait trop facile, tu paies $100k et tu fais tout ce que tu veux, on a plus le droit de te critiquer.

      • [^] # Re: C'est assez drole

        Posté par . Évalué à 2.

        Oh tout a fait, c'est bien pour ca que je dis que dans ce cas la, c'est une biere, je sais bien que vous n'allez pas vous arreter de critiquer :)

    • [^] # Re: C'est assez drole

      Posté par . Évalué à 4.

      Ben c'est peut être en train de changer, mais cette culture coopérative, travailler avec d'autres pour reverser le travail de manière à ce que tout le monde en profite, c'est un peu la stratégie inverse de ce que Microsoft faisait traditionnellement depuis plusieurs années.

      Évidemment il le font très probablement plutôt par culture open source et parce qu'ils y ont quelque chose à gagner, que la compétition sur le domaine de la sécurité n'est pas forcément un truc qui tourne énormément le grand public, qu'ils sont en retard sur certaines choses et qu'ils ont plutôt intérêt à récupérer ce qui se fait collaborativement plutôt que de joueur les égoïste sur ce point.

      N'empêche que voilà, on peut avoir l'impression qu'ils ont été poussés dans leur retranchement et qu'ils sont allés au bout des logiques de lobbying sur le BSA pour protéger leurs acquis avant de penser à joueur le jeu autrement.

      • [^] # Re: C'est assez drole

        Posté par . Évalué à 1.

        Que MS est dans une position de faiblesse en ce moment oui sur certains marches.

        Maintenant, que cette action la soit en rapport avec ca, j'en doutes fort. J'ai passe les 2 dernieres annees dans le team qui a organise ca (Trustworthy Computing), et les ventes de Windows (phone) ils s'en foutent pas mal, leur objectif venant d'en haut est tout autre et sans rapport direct.

        Non, le truc qui vient a retour a MS ici, c'est :
        - benefice d'image
        - ameliorations des relations avec certaines entites sur le meme modele que HackerOne
        - augmentation de la securite sur le net en general (MS en beneficie evidemment)

    • [^] # Re: C'est assez drole

      Posté par . Évalué à 7.

      Ce que Microsoft paye, c'est moins de 3 minutes de ses bénéfices de l'an dernier. Si je leur file 3 minutes de mes bénéfices de l'an dernier, ils ne risquent pas le coma alcoolique.

    • [^] # Re: C'est assez drole

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

      Si je pouvais avoir une bière par machine achetée sous windows pour ne même pas booter ce système et pas me faire rembourser parce que c'est long et que je suis professionnel, ou par lobbyiste de microsoft USA qui rédige des documents à la place des incompétents (corrompus ?) de Bruxelles, ma santé serait en danger.

    • [^] # Re: C'est assez drole

      Posté par . Évalué à 4.

      Microsoft paie pour securiser Linux, alors qu'ils n'etaient pas affectes par la faille OpenSSL vu qu'ils ne l'utilisent pas…

      Microsoft n'a aucun serveur non-Windows ?

      • [^] # Re: C'est assez drole

        Posté par . Évalué à 6.

        Que eux maintiennent (= c'est pas Akamai) il y a un Vax je crois encore pour leur ERP, mais ils pensaient le remplacer par Microsoft Dynamics.

        Sinon, tous les systemes internes que je connais, toutes les plateformes tournent sous Windows.

        Dans la boite ils ont des machines non-Windows evidemment (developpement sous Mac & Android, tests d'interop avec Windows ,…) mais c'est tout il me semble.

        • [^] # Re: C'est assez drole

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

          Est ce que ce VAX émule une calculette quatre opération ?

          ce commentaire est sous licence cc by 4 et précédentes

        • [^] # Re: C'est assez drole

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

          Même pas quelques trucs chez Azure ?

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: C'est assez drole

            Posté par . Évalué à 4.

            Non, c'est les clients qui font tourner Linux dans leurs VMs si ils veulent, la plateforme est 100% Windows.

            • [^] # Re: C'est assez drole

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

              Du coup MS a quand même intérêt à ce que les VM ne fassent pas tourner des logiciels troués. Mais c'est appréciable d'avoir vu MS évoluer sur ces questions.

  • # Ça commence

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

    Les premiers financements arrivent. Un audit sera financé pour OpenSSL et deux développeurs vont être payés à plein temps. OpenSSH et NTP ont aussi été sélectionné pour recevoir des fonds mais il n'y a encore aucune annonce sur la manière dont ça va être fait (peut-être que les discussions sont en cours avec les projets pour déterminer ce qu'il y a besoin dans ces projets).

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

Suivre le flux des commentaires

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