pasBill pasGates a écrit 16057 commentaires

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é…

L’épisode est qu'il a décidé une fois pour toute que les voitures ne seraient pas autonomes avec 100 ou 200 ans, et rien ne le fera changer d'avis.

Quand il y a un bug sous Windows, tout le code de Windows est analysé, dans toutes les dll ?

Quand tu insères du code dans un binaire, ça décale tout le code de diffèrentes manières. Si qq'un rapporte un bug dans ce binaire, ou un binaire relatif, et qu'un développeur charge le schmilblick dans un debugger pour voir ce qu'il se passe, il verra que les lignes de code sont décalées par rapport à l'assembleur indiqué par le debugger, voire même le debugger lui dira directement que le binaire ne correspond pas aux symboles de debuggage si l'attaquant n'a pas fait l'effort/réussi à modifier les symboles de debuggage en même temps.

Et oui, ca n'a rien de spécifique à Windows, c'est vrai pour Linux aussi.

Et tout les développeurs ont systématiquement tout le code dans toutes les versions distribuées, qu'ils recompilent parallèlement entièrement ?
Compilent-ils tous sur exactement la même machine ? Avec un compilateur et une machine qui ont exactement le même état ?

Cela n'a rien à voir avec le problème. Le problème est la correspondance entre lignes de code (que les développeurs ont évidemment), et ce que les symboles de debug disent. Si ton debugger à un moment te dit qu'il y a un appel de fonction, et tu vois une ligne de code disant "int a = 4+20;", tu sais qu'il y a qqe chose qui foire.

Et tout ça c'est évidemment sans parler du fait que les binaires sont signés d'habitude(du moins pour Windows, Office et autres softs), faudrait que le gars arrive à faire son changement dans l'intervalle entre la génération des binaires et leur signature, sinon il devra poser lui même une requête de signature(ça demande typiquement 2-3 personnes, donc il devra avoir des complices déjà), et inutile de dire que ça va tout de suite alerter tout le monde. Ça va pas être du gâteau.

En ce qui concerne l'accès au code source: s'il est si restreint et contrôlé, cela pose les mêmes problèmes d'avoir un petit nombre de personne y ayant accès / contrôle (remplace "de haut niveau administratif" par "de haut niveau de contrôle de l'accès").

Non du tout, c'est très différent. Si tu prends le cas de Microsoft, ou Amazon, ou Google, … t'as des centaines et centaines (voire milliers selon les projets hein) de développeurs/testeurs, t'as quelque dizaines de managers de 1-2ème niveau, et au dessus c'est le "haut management".
Ces sociétés ont toutes des permissions sur leur code source, géré par groupe, avec un pare-feu humain pour joindre le groupe. Tu regardes typiquement qui est la personne, pour qui il bosse et quel est le titre de son job pour décider quand tu reçois la requête, il y a une automatisation pour expédier les requêtes ou c'est super évident (le gars est dans la hiérarchie du VP du bon groupe, son titre est développeur, …). Ça te dit si il bosse dans le bon département, si il est sensé avoir accès au code, … et il y a toujours le manager de la personne en CC: sur l'email histoire qu'il soit au courant. C'est au final très simple et une requète "bizarre" se voit très vite.

Façile ? Non justement. La force de la NSA ce sont ces informaticiens, leur spécialité est tout ce qui est technique. Des gars derrière leur écran, dans les bureaux de la NSA.

Se faire passer pour quelqu'un d'autre en public, mentir de manière efficace pendant des semaines et des mois, … devant des gens, c'est pas forcément leur spécialité.

Pas forcèment plus qu'en interne à la boite, car oh grande nouvelle, plusieurs personnes lisent le même code en interne aussi, et tout le monde n'est pas employé par la NSA.

Ben non, ca ne marche pas.

Parce que le jour ou un bug est rapporté, les développeurs chargent le binaire publié, et se rendent très vite compte que le code (et les symboles de débuggage si l'effort est fait de les modifier aussi) ne correspondent pas au code qu'ils ont.

Sans parler du fait qu'être placé très haut ne signifie pas que la personne a accès aux machines.

Tu peux être sur que les VPs et autres de Windows n'avaient pas accès aux machines de build et aux dépots de code source par exemple, car tout le monde doit faire la demande. Et une demande de leur part d'avoir un accès, surtout en écriture, vu leur job, aurait été vue avec énormement de suspicion par les gens en charge d'autoriser la requète.

Tout a fait, c'est possible, c'est par contre légèrement plus complique que ce que tu écris :

• Faut qu'il y ait un poste disponible la ou tu veux mettre la backdoor. Te faire engager dans le team marketing ou vente ça va pas aider
• Faut que tu passes l'interview quand même
• Faudra que tu insères la backdoor dans la partie de code qui t'es assignée point de vue boulot, sinon ça va amener des questions…
• T'as typiquement un background check dans nombre de boites, et ça force le fait que la personne qui est engagée soit un développeur, tu peux pas envoyer n'importe quel agent de terrain. En remote c'est évidemment plus facile car pas d'interactions face à face et 8h par jour.

Bref, la barre est quand même plus élevée qu'apparaître de nulle part et envoyer des patchs à un projet.

http://en.wikipedia.org/wiki/Entertainment_Computer_System

Hardware
- ECS EXEC/BASIC ROM, containing the built-in BASIC programming language and additional BIOS routines to handle the added hardware features
- additional 2kB of system RAM (supposedly, the system could be further expanded to as much as 64kB with add-on memory modules, but no such modules ever made it to production)
- additional AY-3-8910 sound chip (this was the same sound chip used in the Intellivision)
- a cassette recorder/printer interface (used the same peripherals as the Mattel Aquarius)
- two additional input ports for the alphanumeric Computer Keyboard, the Music Synthesizer keyboard, or two additional Intellivision Game Controllers.

Probablement. Richard de la NSA fera ça car Michael de la NSA est déjà occupé à faire de même avec Redhat.

Un code open source ne veut pas dire que tu dois accepter du code de n'importe qui. Ou meme en accepter tout cours.

Un code proprio ne veut pas dire que tu vas mettre des backdoors dedans.

Mais bien sur que si qu'il y a une difference. On ne peut jamais avoir une garantie à 100%, ca ne veut pas dire qu'il n'y a pas de difference.

C'est quoi la différence alors ? Faire un code open source sans accepter de changement ? Ca laisse toujours la porte ouverte à l'auteur d'y insèrer ses backdoors, comme un auteur proprio.

Et en pratique, dans la vraie vie, combien de projets ayant une valeur sont dans ce cas ? Linux ? Apache ? OpenOffice ? KDE ? Gnome ? … Ah oui, aucun.

"beaucoup plus complique" ?

Vraiment ?

Si moi demain, je veux insérer une backdoor dans Linux, je peux. J'envoies qqe patches qui sont bien, je gagnes la confiance, et au bout d'un moment j'insères ma backdoor discrètement. Au pire, les gens la verront, croiront que c'est un bug innocent, je réessaierai un peu plus tard et je finirai par y arriver.

Si je veux aller insèrer une backdoor dans iOS ou Windows par contre, ah ben merde, j'ai pas accès… Seule la société elle-même peut le faire.

Ces 2 phrases sont vraies pour n'importe qui. Moi, toi, TImaniac, ta grand-mère, …

Eh oui, il n'est pas si évident que ce soit plus simple d'un coté que de l'autre.

Ben oui, avoir et pouvoir lire les sources c'est une sacrée garantie qu'il n'y a pas de failles/backdoors.

Shellshock et Heartbleed l'ont très bien montré.

T'auras du mal, bcp de mal, à faire mieux que les gros providers de "cloud computing" en terme de fiabilité et étiquette environnement vu qu'ils optimisent un max l'utilisation de leurs ressources (pour raisons monétaires), ce qui permet justement de limiter le nombre de systèmes consommant au maximum en placant de manière optimisée les VMs sur les serveurs, alors que toi, au final ta machine continuera de bouffer de l'énergie alors que tu ne l'utiliseras probablement que très rarement.