NumOpen a écrit 1047 commentaires

Exact. C'est pour cela qu'il faudrait légiférer pour que l'ouverture du code soit obligatoire dans le cas de son utilisation dans des systèmes critiques ou qui touchent à la vie privée (e-santé, voitures sans conducteurs avec géolocalisation…).
Il y a des normes qualité de toute sorte dans l'industrie qui imposent la transparence, dans tous les domaines, 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.

"En somme, tu dit qu'il est plus simple d'analyser qq centaines de milliers de lignes de code que de sortir tcpdump et voir ce qu'il sort de la machine?" : non, ce n'est pas ce que j'ai écris.

"C'est a l'editeur de prendre en charge ce cout en laissant la communaute relire le code?" : 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. On peut ainsi plus facilement faire auditer le code, trouver des failles et exiger de l'éditeur qu'il les corrige. Sinon, l'éditeur cache son mauvais travail en fermant le code (ils ne sont pas fous non plus), ce qui lui évite une conception trop onéreuse.

"tu crois reellement que mr machin, developeur lambda, va etre capable de donner le moindre patch/avis sur un systeme pareil?" : non, 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. Il existe aussi pleins d'outils d'audit de code qu'on peut utiliser lorsque le code source est disponible et l'ouverture des codes et le financement d'audits comme le fait la Communauté Européenne encourageraient le développement de ce genre d'outils et favoriserait l'utilisation de bonnes pratiques de codage et de sécurisation.

http://actualitedelhistoire.over-blog.com/article-attentats-du-11-septembre-partie-6-96145749.html

Tiens, un autre risque que je viens de voir : http://www.danger-sante.org/indication-pacemaker/

Le problème des sondes Pitot est mécanique/physique/thermique. Il est connu, maîtrisable et évitable. Pour les orages et le matériel électronique, c'est déjà plus complexe et aléatoire.

Un logiciel ne tombe pas en panne mais peut planter seul, on peut le faire planter ou on peut s'en servir pour voler des informations ou casser un système piloté par le logiciel. 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.

"qu'est ce qui te fait donc penser que si on publie le code utilise pour la defense nationale, il sera relu correctement?" : pour moi, c'est la condition de base pour qu'il soit auditable. Ensuite, il faut que des moyens financiers soient débloqués pour faire faire les audits.
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. Et ça permettrait de détecter de élèves doués et intéressés par le sujet, qui pourraient ensuite être embauchés.

"T'as deux options ici: tu n'en sais rien et fait juste un procès d'intention" : 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.

Non, ce n'est pas faux. Les avions sont plus fiables parce qu'il y a beaucoup plus d'argents investi dans la sécurité, y compris dans la partie électrique et électronique. Mais les États-Unis peuvent détourner à distance un avion en prenant le contrôle à distance des commandes de vol et rien n'indique que des terroristes peuvent faire de même. Cela n'était pas possible avant lorsque les commandes étaient mécaniques. Et les derniers accidents montrent que les commandes électroniques sont souvent perturbées par les orages.

L'analyse du trafic n'est pas une raison suffisante pour accepter l'utilisation de logiciels à code fermé. On doit pouvoir déjà auparavant avoir accès au code source pour détecter d'éventuels mouchards et compiler soi-même le logiciel. On ne peut pas faire confiance à du code compilé.
De plus, l'analyse du trafic n'est parfois pas suffisante, la transmission d'informations peut se faire d'une façon tout à fait normale et non détectable dans la masse des autres transmissions. Un des éditeurs chez lequel j'ai travaillé mettait un mouchard dans son logiciel, comme quasiment tous les autres éditeurs le font et ça n'avait jamais été détecté et ne le sera sans doute jamais.
Enfin, ce n'est pas à nous de devoir pallier au risque imposé par du code fermé mais à l'éditeur de prendre en charge ce coût, de nous prouver sa bonne foi en montrant patte blanche et en nous aidant à sécuriser le code en l'ouvrant. Utiliser des analyseurs de trafic suppose qu'on a déjà pris et accepté le risque d'utiliser des logiciels dont on ne sait pas ce qu'ils font. C'est inacceptable par exemple pour une centrale nucléaire où 100% des systèmes devraient être compilés à partir de code ouvert. Cela devrait devenir une exigence.

C'est différent dans le cas de la défense et dans d'autres secteurs sensibles (santé, énergie, objets connectés, voitures sans pilote…) car les conséquences en cas d'incident de sécurité peuvent être dramatique. C'est donc des secteurs où il ne faut plus laisser les éditeurs cacher leur incompétence ou/et leur faible investissement dans la sécurité, en cachant leur code source. Ils justifient cette pratique en la présentant comme une source de sécurité alors qu'au contraire, c'est une source d'insécurité et une façon pour eux de cacher leurs défauts.

Je pense que l'ouverture du code est une condition initiale indispensable à la sécurité, ne serait-ce déjà que pour s'assurer qu'il n'y a pas de mouchard dedans. À chaque fois que j'ai travaillé chez des éditeurs, ils inséraient dans leur logiciels quelques lignes de code pour remonter discrètement les configurations des ordinateurs sur lesquels étaient installés leurs logiciels et quelques autres informations au passage.
Ensuite, c'est en effet une question de moyens et de volonté.

L'ouverture du code est une chose, les moyens de l'examiner en est une autre. C'est pour cela qu'il faut au préalable exiger de la transparence pour les applications critiques (défense nationale, santé, énergie…) et ensuite, mettre les moyens en face pour travailler sur le code, comme va le faire la commission Européenne. L'ouverture du code devrait être obligatoire dans ces domaines, je pense qu'il faudrait légiférer.

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.
On vient de m'installer un compteur d'eau communicant de marque américaine. Je voudrais le faire examiner pour savoir ce qu'il transmets (consommation en temps réel, habitudes d'utilisation de l'eau, absence du domicile…) mais le fabricant se garde bien de donner des informations, c'est sûr que sa sécurité est plus qu'aléatoire. Au fait, si des personnes sont intéressées pour m'aider à travailler sur ce sujet…

Si le code source n'avait pas été publié, personne n'aurait pu voir que ça avait été mal écrit.

Je confirme. Une des entreprises où j'ai travaillé a refusé de l'utiliser et continuait à transmettre les informations sensibles sur papier au lieu d'utiliser une boîte noire dont elle ne savait pas ce qu'elle faisait.

Les failles bash, heartbleed, debian openssl ont été détectées et corrigées. Si le code avait été fermé, elles n'auraient jamais été détectées ni corrigées.

Ce que j'essaie d'expliquer, c'est justement que la sécurité par l'obscurité est une erreur, surtout dans les secteurs sensibles, y compris la Défense nationale. Si tu veux renforcer la sécurité de tes logiciels, il faut en publier le code source et surtout demander l'aide de la communauté pour les tester et éventuellement les améliorer contre rémunération.
Par exemple, organiser régulièrement des challenges, des tests d'intrusion, faire faire des audits etc. est la meilleure façon de connaître les erreurs de conception.
Il faut développer en France l'esprit Hacker au lieu de sans cesse faire l'amalgame hacker=vilain pirate dans la presse et de condamner, museler les gens qui veulent améliorer les choses et qui osent (sacrilège) avertir lorsqu'il y a une mauvaise conception. Il ne faut plus que les éditeurs, les fabricants, les distributeurs… puissent étouffer ceux qui osent remettre en cause leur incompétence, surtout lorsque notre vie privée et notre sécurité sont en jeu. De toute façon, cette stratégie ne fonctionne plus avec Internet, ils auraient maintenant beaucoup plus à gagner en étant transparent. Cela les obligerait bien sûr à dépenser plus dans la sécurisation de leurs produits mais au final, tout le monde serait gagnant.

C'était la mise en garde réponse du chargé de mission de sécurité économique du HFDS.
Ce que j'essaie d'expliquer, c'est justement que la sécurité par l'obscurité est une erreur, surtout dans les secteurs sensibles, y compris la Défense nationale. Si tu veux renforcer la sécurité de tes logiciels, il faut en publier le code source et surtout demander l'aide de la communauté pour les tester et éventuellement les améliorer contre rémunération.
Par exemple, organiser régulièrement des challenges, des tests d'intrusion, faire faire des audits etc. est la meilleure façon de connaître les erreurs de conception.

Flûte, si quelqu'un peut corriger : perturbations électromécaniques -> perturbations électromagnétiques

un identifiant du créantier ->
un identifiant du créancier

C'est utilisable.

Ou https://kiwiirc.com en mode Web.

Justement, c'est l'occasion unique de sensibiliser une promotion sur la perte de contrôle sur ses données, les risques encourus pour sa vie privée etc. J'ai à l'esprit l'exemple d'un intervenant dans un collège qui citait une publicité aux USA pour une crème contre l’acné, avec la photographie d'un jeune utilisateur de Facebook bien boutonneux.
Il doit bien y avoir un journal des élèves, des panneaux d'affichage, des professeurs intéressés pour organiser un débat etc.
Un projet de communication utile à mener.

Il n'y a qu'à organiser un boycott de la messagerie jusqu'à ce que les données privées soient récupérées, hébergées et gérées dans les locaux de l'école.

Ah, tiens, Zenitram a encore frappé. Tout en finesse et en diplomatie.

De toute façon, faire une entreprise en France, quelle que soit sa forme, c'est suicidaire. On croule de suite sous la paperasse et les taxes sans même commencer à facturer un centime. Rien que pour acheter et vendre une clé USB, il faut payer une taxe et remplir de la paperasse : http://www.copiefrance.fr/fr/professionnels/exoneration-et-remboursement
Pou avoir un standard téléphonique, idem : http://www.lascpa.org
Tous les gouvernements nous gavent avec leur "simplification administrative" et s'empressent de voter de nouvelles lois encore plus destructives pour l'emploi pour récupérer un peu d'argent à droite et à gauche.
En Lorraine, plus personne ne crée de SSII, tout le monde va au Luxembourg. Même les personnes qui habitent dans les Vosges font un trajet de 200 km pour y aller créer leur structure ! C'est un exode de plus en plus visible, il y a 80 000 personnes qui passent la frontière chaque jour et il est prévu d'y en avoir le double dans quelques années. Les autoroutes sont saturées et la région a beau ajouter des TER, ça ne suffit plus.

Le domaine public implique surtout qu'il n'y a plus de droit du tout (y compris de droit patrimonial) et donc plus aucune protection de l'œuvre.
http://journeedudomainepublic.fr/le-domaine-public/