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.
Aller plus loin
- Annonce du projet (271 clics)
# Besoin de renfort, vraiment ?
Posté par Jean-Max Reymond (site web personnel) . É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 gnx . É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 isildur37 . É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 Didrik Pining . Évalué à 2.
[^] # Re: Besoin de renfort, vraiment ?
Posté par vv222 (site web personnel) . É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 Zenitram (site web personnel) . Évalué à -2. Dernière modification le 26 avril 2014 à 15:15.
Je cite la personne à laquelle tu réponds :
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 BAud (site web personnel) . Évalué à 3. Dernière modification le 26 avril 2014 à 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 Antoine . Évalué à 6.
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 vv222 (site web personnel) . É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 isildur37 . É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 ckyl . Évalué à 6. Dernière modification le 29 avril 2014 à 17:18.
Dans un autre siècle oui, maintenant ca semblerait plutôt être 20% après tes 100%.
[^] # Re: Besoin de renfort, vraiment ?
Posté par djano . Évalué à 1.
Aussi appelé le 120%.
[^] # Re: Besoin de renfort, vraiment ?
Posté par lasher . É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 netsurfeur . É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 vv222 (site web personnel) . É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 claudex . É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 vv222 (site web personnel) . É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 claudex . Évalué à 3.
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 vv222 (site web personnel) . Évalué à 1.
Bah, de toutes façons je pinaille gratuitement, hein ;)
L'important reste qu'on se comprenne !
PS : Elle vient d'où cette nimage ?
M'a bien fait rire en tous cas…
[^] # Re: Besoin de renfort, vraiment ?
Posté par claudex . Évalué à 3.
De http://www.metoogotmy.net/
« 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 vv222 (site web personnel) . Évalué à 1.
Merci !
[^] # Re: Besoin de renfort, vraiment ?
Posté par gnx . É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.
[^] # Re: Besoin de renfort, vraiment ?
Posté par Sytoka Modon (site web personnel) . Évalué à 10.
Je ne serais pas étonné que les dons en question soit dans le paquet 'optimisation fiscale'…
# On verra
Posté par gnx . Évalué à 10. Dernière modification le 25 avril 2014 à 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 Thomas Douillard . É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 vlamy (site web personnel) . Évalué à 9. Dernière modification le 26 avril 2014 à 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 Thomas Douillard . É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 Nicolas Boulay (site web personnel) . É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 Thomas Douillard . É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 vlamy (site web personnel) . Évalué à 2.
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 Thomas Douillard . É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 vlamy (site web personnel) . Évalué à 6. Dernière modification le 28 avril 2014 à 09:35.
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 :
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 :
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 Thomas Douillard . É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 vlamy (site web personnel) . É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 Thomas Douillard . É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 Nicolas Boulay (site web personnel) . É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 Thomas Douillard . É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 Nicolas Boulay (site web personnel) . É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 David Mentré (site web personnel) . Évalué à 1.
:-) 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.
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/
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 Nicolas Boulay (site web personnel) . É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 vlamy (site web personnel) . Évalué à 5. Dernière modification le 28 avril 2014 à 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 Thomas Douillard . É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 vlamy (site web personnel) . É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 Thomas Douillard . Évalué à 2.
Je parle pas vraiment de faire de la preuve de protocole, en fait, on dialogue de sourd.
[^] # Re: On verra
Posté par vlamy (site web personnel) . Évalué à 3.
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 Thomas Douillard . É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 Thomas Douillard . É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 gnx . Évalué à 2.
Une OPA sur systemd :-)
[^] # Re: On verra
Posté par claudex . É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 Thomas Douillard . Évalué à 2.
On peut imaginer plus, genre l'infrastructure de compilation sur les questions de sécurité.
[^] # Re: On verra
Posté par gnx . Évalué à 2.
Avec le Tout-PRISM aux manettes, il n'y aura plus de souci à se faire.
[^] # Re: On verra
Posté par Frédéric Massot (site web personnel) . Évalué à 4.
"Core infrastructure" ça a plus de gueule que "Plumbing infrastructure".
[^] # Re: On verra
Posté par Antoine . Évalué à 3.
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 David Mentré (site web personnel) . Évalué à 1.
Ben en fait, cette faille a été découverte par des gens qui veulent prouver formellement TLS : miTLS (http://www.mitls.org/) écrit en F# et spécifié en F7.
[^] # Re: On verra
Posté par Thomas Douillard . Évalué à 2.
Bonjour, le journal est un peu ancien, je te conseillerai d'en poster un nouveau sur le sujet avec des éclairages de quelqu'un qu'y s'y connait, ça aurait sans doute plus de visibilité :)
[^] # Re: On verra
Posté par Anonyme . É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 pasBill pasGates . É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 linette . É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 vincent LECOQ (site web personnel) . É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 flagos . É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 claudex . É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 Anonyme . Évalué à 10.
Il ont sans doute un interet à le faire, ils font pas ca juste pour rire.
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 pasBill pasGates . É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 Thomas Douillard . É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 pasBill pasGates . É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 gnx . É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 feth . É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 Antoine . Évalué à 4.
Microsoft n'a aucun serveur non-Windows ?
[^] # Re: C'est assez drole
Posté par pasBill pasGates . É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 Thomas Debesse (site web personnel) . É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 claudex . É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 pasBill pasGates . É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 LupusMic (site web personnel, Mastodon) . É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 claudex . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.