pasBill pasGates a écrit 16169 commentaires

Tu as fais la demande, et tu n'as pas encore les arguments pour le justifier ?

charrue, boeuf, toussa…

Le truc étant que Valve ne force pas à sortir sur les 3 plateformes.

Qu'on se comprenne, tu parlais de pression, moi je te dis que 1.16% des gens ne met aucune pression. Ensuite si des devs veulent développer pour Linux, c'est évidemment leur choix, et certains le font.

Tu appelles cela provocation et fanfaronnade, moi je vois les mots de qq'un qui a été grandement frustré et qui s'exprime.

Pour les développeurs, de nouveau, aucun ne va faire l'effort pour 1.16% des utilisateurs. Ils s'en foutent de ce que font les autres devs, ce qui intéresse un éditeur/développeur c'est le nombre de gens qui vont acheter son jeu.

Ben oui évidemment… un type qui quitte Linux, il a forcément mauvaise conscience… il ne peut pas avoir de bonnes raisons !

Bref, point positif, cette personne semble un peu sensibilisé à la question de la portabilité, sinon il ne tenterait même pas de se justifier.

Ou plutôt il a trouvé que l'effort n'en valait pas la peine…

Après, comme tous, je pense que c'est un mauvais choix pour un moteur de jeux d’abandonner Linux maintenant. La section Linux de steam s'étoffe de jeux que je ne m'attendais vraiment pas à retrouver sur mon OS favoris et avec steamOS la compatibilité Linux va être une demande de plus en plus fréquente chez les éditeurs.

Ben quand je vois les stats chez Steam : http://store.steampowered.com/hwsurvey Linux est a 1.16% , je doutes que ça force les éditeurs à quoi que ce soit.

Ils ne disent pas qu'il faut rendre l'entièreté du logiciel publique mais au moins les parties relatives à la sécurité. La très grande majorité des modules de sécurité sont réutilisables par d'autres logiciels et à grande échelle.

Oh mais je suis bien d'accord qu'en ce qui concerne des algo cryptographiques, c'est important de comprendre comment l'algo fonctionne. Parce que si tu n'as que le résultat de l'algo, une suite de bytes, ça ne dit strictement rien.

Ben non, lisez le reste de livre, explique clairement que c'est bien le code en plus de l'algo qu'il faut (Pour pleins de subtilités).

Le code joue un role en crypto parce que si t'as des conditions, etc… ça crée des side-channel et timing attacks. C'est ce que BEAST et autres sont par exemple, mais ça se trouve sans le code. Ensuite t'as le cas ou le code introduit une erreur comparé à l'algo (genre il affaiblit les exposants de RSA ou autre) et là cela serait problèmatique évidemment, mais le truc est qu'en réalité le code ctypto est tellement petit et 'simple' (operations maths) que tu peux facilement l'extraire de code binaire et le recomposer pour en tirer un pseudo-code C équivalent.

Documentez-vous avant de sortir des énormités basées sur des statistiques biaisées (genre <10 bugs qui ont fait le plaisir des médias).

T'es gentil, la securité software c'est mon boulot depuis plus de 10 ans. On va dire que je ne manque pas d'experience dans le domaine.

Du tout non. De Mon côté je dis simplement qu'ouvrir le code ne change rien à l'aspect sécurité. Ca ne veut certainement pas dire que je demande de fermer ce qui est ouvert, les développeurs font ce qu'ils veulent, c'est leur code, pas le mien.

Faut assumer mon chèr, quand tu postes des aneries de manière répetitive, tu te fais remettre en place.

De temps en temps, ca arrive à tout le monde hein, moi, Zenitram et autres compris. Mais ce n'est de loin pas la première fois que tu nous ressors ton histoire sur la securité et le LL ici, alors ques tes arguments ont déjà été demontré comment totalement sans fondement.

Maintenant, si tu préfères évidemment précher dans un bocal où tout le monde pense comme toi, fais seulement, mais ça ne te fera certainement pas avancer, ça te fera juste continuer à garder la tête dans le sable et te demander pourquoi le reste du monde ne suit pas à la lettre tes idées.

LOL merci pour ce grand moment d'humour !

T'as oublié de nous mettre aussi une press release de Laurent Blanc disant que le PSG est la meilleure équipe du monde et une autre de José Mourihno disant que c'est Chelsea.

Je n'ai jamais compris pourquoi en informatique on accepte la vente de systèmes opaques qui empêchent l'amélioration de la qualité et de la sécurité et pourquoi on punit les personnes qui luttent contre cela.

Parce que les gens en charge ont, contrairement à toi, compris que ce que tu racontes ne tient pas debout et que faire ce que tu dis ne changerait en rien la qualité ou la securité.

Mais au moins, il a été possible de le voir et de le corriger. Après, c'est une question de moyens et de volonté. Mais sans au préalable une ouverture du code source, c'est mort d'avance.

Le fait qu'aucune de ces failles n'ait été trouvée grâce au code contredit totalement ce que tu racontes. Avoir les sources ouvertes clairement n'a pas aidé, et cela prouve aussi qu'on peut trouver les failles sans les sources.

Et il y a plein de petites boites software ou les devs aiment eux aussi le travail bien fait…

On peut aussi envisager par exemple que certaines écoles d'informatique proposent des projets d'étude pour analyser des codes et trouver des failles de conception ou d'écriture. Ce serait de bons sujets bien plus intéressant que des projets montés de toute pièce.

Merci de confirmer ce que je pensais depuis le début, tu ne connais absolument rien à ce sujet.

oui, et j'en ai parfaitement le droit lorsque ma sécurité ou ma vie privée est en jeu ou celle de nombreuses personnes. Et lorsqu'on lit tous les jours les attaques réussies sur des systèmes opaques et qu'on en voit les conséquences désastreuses, on ne peut plus accepter ce risque.

Marrant, parce que les conséquences sont tout aussi désastreuses du coté du LL, il n'y a pas moins de problèmes, mais pourtant tu ne te focalises que sur un coté, en sortant l'idiotie que les convertir en projets de l'autre coté va miraculeusement résoudre le problème alors que les LL existants sont toujours aussi troués.

Non vraiment, tout ce que tu fais c'est du délit de sale gueule informatique, tu n'as absolument aucune connaissance du sujet, les faits vont à l'encontre de ce que tu racontes, et pourtant tu t'obstines.

Et tu crois que c'est different pour le LL hors les gros projets ? Tu crois que des experts s'amusent a aller revoir le code de projets obscurs ?

c'est à l'éditeur d'ouvrir le code afin qu'on s'assure qu'il a bien mis les moyens financiers pour le sécuriser correctement.

Ah la belle connerie ! On a bien vu avec OpenSSL que les gens se contre-foutent de vérifier, et qu'être en libre ne change rien à l'affaire.

mais l'ouverture du code doit être exigée pour vérifier que les éditeurs ont bien fait leur travail en payant des gens compétents et non en confiant l'écriture du code à des stagiaires ou à des intervenants successifs qui ont chacun à leur tour fait leur soupe. Ça, ça se détecte assez vite. Et un mouchard aussi.

Sérieusement, arrêtes de parler d'un sujet auquel tu ne connais visiblement rien du tout. Un mouchard ça se cache facilement même dans du code ouvert.

Mais quelles conneries tu nous sors… ça te tenterait d’arrêter de parler de ce que tu ne connais pas ?

Les boites proprios les plus grosses mettent certainement plus de moyens que les projets OSS les plus gros (MS, Google, Apple), elles ont des dizaines d'experts payés pour et n'hésitent pas à engager des boites spécialisées quand le besoin se fait sentir.

Les petites boites proprios, elles n'en font pas bcp, mais inutile de dire que c'est la même chose pour les petits projets libres.

Heartbleed : https://www.youtube.com/watch?v=ezjRv_7iZZM --> analyse de traffic reseau resultant de tests de fuzzing
Shellshock : http://www.openwall.com/lists/oss-security/2014/10/08/17 " I did not find it by
looking at bash's code either."

Quand a corriger le bug, tu me fais bien rire. Et tu le testes comment le code ? Et tu l'integres comment ? Et tu maintiens ton fork comment ?

C'est irrealisable sur le long terme de faire son propre patch pour 99% de la planete, c'est le groupe maintenant le composant qui doit le faire.

Les problèmes de sécurité informatique ne sont bien sûr pas les mêmes qu'en mécanique et qu'en électronique mais ce sont aussi des problèmes de sécurité et ils sont complexes et coûteux à résoudre, bien plus qu'en mécanique et qu'en électronique.

Oui oui bien sur ! Dis moi donc combien couterait la correction d'une faille HW dans un CPU Intel que je rigole.

Grosse connerie, aucun, je dis bien AUCUN de ces bugs n'a été trouvé en lisant le code.

Ah oui ? Comment oses-tu dés lors dire que les logiciels propriétaires sont mal écrits ?

Bof… Johnny Halliday qui exprime une opinion lui aussi a un effet sur une partie des gens… c'est triste, mais c'est comme ca…

Depuis quand l'Église est invité à émettre son avis sur un mariage civil qui est détaché de toute religion ?

Je ne vois aucun problème à ce qu'ils émettent un avis.

Je veux dire, même mon chien coin peut le faire, ça veut pas dire pour autant qu'on va l'écouter. Le seul truc qu'il ne faut pas faire, c'est leur donner un pouvoir de décision.

A Seattle c'est la même chose, et non c'est pas mieux. Tu veux vivre dans un était policier ? Alors oui c'est mieux, mais à part ça ils ont ici une manière de faire qui antagonise la population contre la police, qui se retourne en devenant plus violente, ce qui antagonise encore plus la population, etc…

Non vraiment, la France c'est peut-être pas parfait, mais je suggères d'éviter le modèle US…

Si je modifie la dll "machin.dll", et qu'il y a un bug dans la dll "truc.dll", comment "truc.dll" peut-il être décalé ? comment le débugage de truc.dll m'informe du contenu de machin.dll ?

Faut comprendre que quand tu debug un probleme, en faisant du step-by-step dans un debugger, tu passes frequemment d'un dll a un autre au fil des fonctions.

1) le débuggeur, sans symbole de débuggage, n'est pas capable de retrouver la ligne.

T'imagines bien que MS génère et garde les symboles de debuggage pour tous les binaires qu'il publie, c'est impossible de properement debugger un problème sans ça.

Évidemment, la plupart des employés ne sont pas informé de ce workflow, tout comme les employés ne sont pas informé des fraudes fiscales prévues dans le workflow dans certaines entreprises.

La différence est que dans le cas financier, c'est au final la tête qui regroupe les résultats de différents groupes qui n'ont pas accès à tout, ils ne peuvent pas voir si il y a eu magouille car leurs chiffres personnels ne peuvent pas être directement reliés.

Avec du code, l'origine du code dans un module est clair : c'est tel groupe de 3-4 développeurs. Lorsque ils debuggent un problème et voient que le binaire ne correspond pas au code, ou voient que le code dans le dépot a changé et ils ne reconnaissent pas le changement, c'est immédiatement visible. A moins d'avoir tous les développeurs et testeurs de ce module dans la poche, ça va être dur de faire passer en douce un changement. Totalement impossible ? Non, mais c'est pas mal plus dur que trouver une faille dans le code que ces développeurs ont écrit par exemple je dirais.

Transports en commun sous-développés ? Je t'invites à venir visiter les USA mon cher, tu verras à quel point la France est bien de ce côté…