Journal Les lois françaises favorisent-elles l’insécurité informatique ?

Posté par (page perso) . Licence CC by-sa
15
11
jan.
2015

Un système mécanique, par exemple dans une voiture, est relativement facile à sécuriser :

  • Le nombre de pièces et leurs interactions est relativement limité donc le risque de panne aussi ;
  • On peut calculer la résistance de chaque pièce mécanique et prévoir sa fiabilité (MTBF), quelles que soient les contraintes : efforts mécaniques exercés sur la pièce, fatigue et usure, vibrations, chaleur, réactions chimiques, corrosion ;
  • On a accès à chaque pièce pour faire un diagnostic ou une expertise et prévoir une panne ou en connaître les causes.

Un système électronique est déjà beaucoup plus difficile à sécuriser :

  • Le nombre de pièces (plusieurs milliards de composants dans les derniers microprocesseurs) et leurs interactions est extrêmement élevé donc le risque de panne aussi ;
  • On peut calculer globalement la résistance d’un système électronique et prévoir sa fiabilité mais elles sont généralement plus faibles que celles d’un système mécanique. Les systèmes électroniques sont plus sensibles aux contraintes extérieures : perturbations électromagnétiques, chaleur, surtensions…
  • On n’a pas accès à chaque composant, les diagnostics sont plus difficiles, on se contente simplement de changer tout un bloc.

Un système informatique est extrêmement difficile à sécuriser :

  • Le nombre d’instructions dans un code informatique complexe (plusieurs millions de lignes de code dans le noyau Linux) et leurs interactions est très élevé.
  • Il est difficile de mesurer la sécurité d’un système informatique, chaque instruction et chaque donnée extérieure traitée par le système pouvant être un paramètre.
  • On n’a généralement pas accès au code source des logiciels, ce qui rend impossibles son étude et les corrections des failles de sécurité.
  • La mise en réseau des systèmes informatiques les mets instantanément à la portée de tous les malfrats du monde (mondialisation des risques).

Lorsqu’on ajoute de l’électronique dans un système mécanique, sa sécurisation devient compliquée. Lorsqu’on y ajoute aussi de l’informatique, cela devient un véritable défi. Et ce défi va devoir être relevé de plus en plus souvent avec l’arrivée massive des objets connectés, la collecte de nos données privées (Big Data), leur transmission et leur stockage, surtout dans le domaine médical.

La sécurité informatique induit une durée de conception plus longue et plus coûteuse, elle nécessite d’embaucher du personnel plus qualifié et elle induit des frais supplémentaires et imprévisibles lorsque des défauts de sécurité sont découverts, pendant toute la durée de vie des systèmes.
Les fabricants ne veulent pas payer ce surcoût et préfèrent pratiquer la sécurité par l’obscurité. Il est plus économique de cacher la poussière sous le tapis. Le code source des logiciels n’est pas rendu public afin qu’on n’en voit pas les horreurs de conception et les publicités vantent une parfaite sécurité des systèmes, à grand renfort de termes techniques incompréhensibles pour les profanes. Et si quelqu’un de sérieux découvre des failles de sécurité et demande à ce qu’elles soient corrigées, les fabricants ont a leur disposition les lois nécessaires pour le réduire au silence et dissuader d’autres personnes de faire de même. Peut-être arriverez-vous à vous en sortir en essayant de prouver que vous agissiez pour un motif légitime de recherche ou de sécurité informatique ? Bon courage !

Malheureusement pour les éditeurs et les fabricants, internet n’est pas encore trop censuré :

Pour les technologies utilisées dans les secteurs sensibles (défense nationale, énergie), la gestion de la sécurité informatique est encore plus problématique. Des enjeux plus grands et le culte du secret rendent les utilisateurs des systèmes informatiques complètement paranoïaques, empêchent toute discussion ou remise en question. Et la lecture du Code de la Défense dissuade définitivement quiconque de s’intéresser à la sécurité des systèmes utilisés dans ces secteurs. Cela est pourtant indispensable si on veut suivre l’évolution des risques et prendre conscience de ses défauts. C’est sans doute une des raisons pour lesquelles le choc a été aussi violent lors des révélations d’Edward SNOWDEN.

En 2011, nous étions invités à faire une conférence sur la sécurité informatique dans les PME. Lors des échanges préparatoires et peu de temps après l’attaque du ver Stuxnet, j’avais demandé si l’utilisation de systèmes GNU/Linux et de logiciels libres était à l’étude dans des lieux sensibles comme les centrales nucléaires. C’est ce qu’à fait la gendarmerie, rendant ainsi son système d’information indépendant, mieux sécurisé et plus économique. La réponse m’a frappé : les courriels et le téléphone étaient sur écoute à la préfecture et il ne fallait pas aborder ce sujet pour ne pas avoir d’ennuis. Je n’ai pas insisté, ayant l’impression d’être à ce moment-là en Corée du Nord ou en Birmanie.

Si les codes sources des logiciels ne sont pas rendus publics et si lois ne sont pas modifiées dans les années à venir pour favoriser les tests des systèmes et pour protéger les hackers qui veulent les améliorer, le combat est perdu d’avance. L’Allemagne semble un peu plus avancée que la France dans ce domaine.

En attendant, on peut saluer le déblocage d’une enveloppe d’un million d’euros dans le cadre d’un projet pilote visant à organiser l’audit des logiciels Open Source utilisés par les institutions européennes, obtenu par les députés européens Julia REDA (Parti Pirate) et Max ANDERSSON (Parti Vert).

  • # Correction

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

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

  • # ennuis

    Posté par . Évalué à 5.

    je ne sais pas qui t'a fait cette réponse curieuse, mais elle ne saurait être une réponse officielle de l'organisateur de la conférence. on peut tout à fait discuter de ce sujet. tant que des informations classifiées ne sont pas divulguées il n'y a aucune raison pour que les services de rens s'en émeuvent.

    une réponse plus officielle serait : la sécurité des infrastructures sensibles s'appuie sur des dispositifs multiples dans une logique de défense en profondeur. la sécurité par l'obscurité (ie ne pas divulguer les sources) en est l'une des composantes, qui n'est pas incompatible avec d'autres composantes classiques (cloisonnement des réseaux, audits de code, tests d'intrusion, etc). l'état pratique évidemment des audits indépendants, qui s'appuient sur des prestataires considérés comme de confiance. les résultats n'en sont évidemment pas publiés pour ne pas divulguer typiquement des infos sur des vulnérabilités qui seraient difficilement corrigeables à court terme.

    • [^] # Re: ennuis

      Posté par (page perso) . Évalué à -8.

      oui oui, je suis charlie aussi

      • [^] # Re: ennuis

        Posté par . Évalué à 3.

        tant que la "communauté" répondra par l'ironie et le mépris aux problématiques industrielles, il ne faudra pas s'étonner qu'on ne lui fasse pas confiance

        • [^] # Re: ennuis

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

          On ne peut pas dialoguer avec ceux qui ne le veulent pas. La réponse était l'archétype même de la langue de bois, d'éléments de langage vide qui n'ont pour but que de donner une réponse vide à une vraie question.

          Tant que la communauté s’essoufflera à perdre son temps avec des gens qui ne veulent pas d'elle, elle n'en sortira qu'aigrie. Il faut savoir se tourner vers les gens qui ont envie de travailler avec nous.

          Il ne faut pas rêver, les gens se tournent vers le libre que lorsqu'ils sont coincés (budget, fonctionnalité, besoin de développement en interne…) mais que très rarement par philosophie et bien souvent le retour pour la communauté est minime par rapport au gain qui est apporté dans la balance.

          Maintenant c'est le jeux et c'est leur droit je ne le reproche pas, mais ne viens pas me parler de mépris ou d'ironie devant une réponse aussi creuse.

          Il y avait des tonnes de chose que l'on pouvait dire : habitude, connaissance, système atypique, processus long à mettre en place, secrets industriels….

          Mais là c'est un méta-caricature cette réponse, on croirait un : message à caractère informatif

          • [^] # Re: ennuis

            Posté par . Évalué à -6.

            parfait, c'est très clair, je vous laisse continuer un débat très fructueux entre jeunes couillons libristes et vieux couillons libristes. là il faut que je retourne bosser pour que ta mère puisse encore avoir de l'eau potable au robinet malgré les efforts de vladimir.

          • [^] # Re: ennuis

            Posté par . Évalué à 5.

            La réponse était l'archétype même de la langue de bois, d'éléments de langage vide

            Euh ? Son texte est bizarrement tourné et nécessite d'être relu 3 fois, mais il est compréhensible et a même du sens.

            la sécurité des infrastructures sensibles s'appuie sur des dispositifs multiples

            Les trucs importants (centrales nucléaires, réseaux de transports, machines militaires) bénéficient de plusieurs mesures de sécurité.

            la sécurité par l'obscurité (ie ne pas divulguer les sources) en est l'une des composantes

            Ils sont persuadés que ne pas divulguer leurs sources est une bonne pratique. On pourrait en discuter, mais faut bien avouer une chose : le jour où on divulguera le code source du firmware des missiles nucléaires français, ça sera forcément audité par plusieurs armées, qui y mettront plus de moyens que n'importe quel libriste. Donc c'est pas tout à fait stupide pour un type très spécifique de code.

            qui n'est pas incompatible avec d'autres composantes classiques (cloisonnement des réseaux, audits de code, tests d'intrusion, etc)

            Ils se contentent pas de pas montrer le code et ont aussi d'autres pratiques de sécurité (je t'invite à googler les termes entre parenthèses avant de les qualifier d'éléments de langage vides).

            l'état pratique évidemment des audits indépendants, qui s'appuient sur des prestataires considérés comme de confiance

            Je sais pas toi, moi ça me semble assez clair, même pas besoin d'expliquer.

            les résultats n'en sont évidemment pas publiés pour ne pas divulguer typiquement des infos sur des vulnérabilités qui seraient difficilement corrigeables à court terme

            Quand ils trouvent une vulnérabilité, ils s'auto-infligent pas un 0-day : ils savent qu'il sera exploité. D'abord ils corrigent, ensuite ils testent, le tout sans précipitation, pour avoir le temps de bien faire.

            Ça, ce sont les sources. Le mouton que tu veux est dedans.

    • [^] # Re: ennuis

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

      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.

      • [^] # Re: ennuis

        Posté par . Évalué à 5.

        J'ajoute que la sécurité de chaque application (logiciel) prise indépendamment est une chose, mais qu'au niveau du SI global, il faut aussi considérer les interactions entre toutes les applications, et dans ce domaine, c'est la fête du slip.

      • [^] # Re: ennuis

        Posté par . Évalué à 3.

        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é

        Le problème, c'est que dans ce cas très précis, "la communauté", ça risque fort d'être les Chinois et les Russes. Ils ne te corrigeront pas tous tes bugs gratuitement, et même si tu les payes, ils ne les corrigeront quand même pas tous…

        Ça, ce sont les sources. Le mouton que tu veux est dedans.

    • [^] # Re: ennuis

      Posté par (page perso) . Évalué à 3. Dernière modification le 11/01/15 à 22:13.

      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.

      • [^] # Re: ennuis

        Posté par . Évalué à 1.

        toutafé

        Cela les obligerait bien sûr à dépenser plus dans la sécurisation de leurs produits mais au final, tout le monde serait gagnant.

        le seule souci que je vois c'est la compréhension du SI par les décideurs publique.

        regardons ensemble la photo du fameux

        https://www.sesam-vitale.fr/nous-connaitre/gouvernance-membres.asp

        j'y compte 20 personnes dont 7 femmes, d'après moult théorie et surtout notre chère ex ministre de la culture, 35% du GIE pige que dalle à l'informatique

        le reste étant composé principalement de gratte papier pour représenter les organismes en dessous de la photo, comme moi tu n'y vois pas le CCC ou le logo Anonymous ni meme thales ou dassault system

        alors expliquer/comprendre le langage machine voir le protocole serie -> LOL

        d'ailleurs la personne sur la droite qui se tiens le menton se demande s'il ne s'est pas trompé de salle de réunion et si le café est bien commandé \o/
        La république leurs a donné les moyens de poursuivre les personnes comme cette ingénieur, ils ne s'en privent pas.

        Et quand ils posent une question au sous traitant qui s'occupe de la carte vitale la réponse est toujours la même : très bien sécurisé conformément au cahier des charges

      • [^] # Re: ennuis

        Posté par . Évalué à 8.

        Oui oui bien sur. Ne pas oublier: le monde n'est pas parfait, et les gentils informaticiens de l'Etat et de ses opérateurs héritent de systèmes conçus avant eux il y a des dizaines d'années. A titre personnel, je m'oppose formellement à ce que le code des vieux machins soit publié, sauf à vouloir voir péter tout un tas de systèmes industriels. On n'a pas besoin de l'aide de la communauté, on a besoin de budgets pour faire des audits et développer les correctifs nécessaires.

        La communauté, pour rappel, c'est 10% de gentils libristes, et 90% de services de rens étrangers et/ou hackers malveillants.

        Il y a comme un problème à croire que les logiques du logiciel libre puissent d'appliquer à tous les contextes et à tous les problèmes. Le monde n'est pas si simple.

        • [^] # Re: ennuis

          Posté par . Évalué à 2.

          A titre personnel, je m'oppose formellement à ce que le code des vieux machins soit publié, sauf à vouloir voir péter tout un tas de systèmes industriels. On n'a pas besoin de l'aide de la communauté, on a besoin de budgets pour faire des audits et développer les correctifs nécessaires.

          budgets que l'on a pas de toute façon, donc entre un truc qui ne sera jamais audité par personne, jamais corrigé sauf si grosse faille, et pour lequel il faut attendre l'action d'un obscur éditeur (qui peut avoir disparu, ou avoir été racheté par un autre, et qui entre temps a vu tous ceux qui connaissaient le logiciel se barrer ), et ne pas pouvoir vérifier le fait que le correctif qu'il a livré corrige bien la faille sans en entroduire d'autres, ou choisir un logiciel libre qui certes ne sera pas forcément audité én permanence (exemple de ssl) mais qui, lorsqu'un problème arrivera, permettra à tous ceux qui se sentent concerné de reprendre le sujet et éventuellement de forker le logiciel (toujours comme SSL), je préfère la seconde option.

          Il y a comme un problème à croire que les logiques du logiciel libre puissent d'appliquer à tous les contextes et à tous les problèmes. Le monde n'est pas si simple.

          Il n'y a aucun contexte ou le logiciel libre ne peut s'appliquer. Utiliser des logiciels libre ne signifie pas non plus dévoiler à tout le monde la façon dont ils sont utilisés et implémentés dans une architecture et un contexte donné. De plus le logiciel libre a d'énormes avantages lorsque l'on joue le jeu et reverse les modifications que l'on a apportées à la commmunauté. Il n'y a que les logiciels peu utilisés pour lesquels on ne gagne pas forcément d'un point de vue économique (mais on n'y perd pas non plus), mais on gagne d'autres avantages.

          Les seuls qui ont des problèmes avec le libre, ce sont ceux qdont le coeur de métier est l'édition de logiciel : ceux pour qui le logiciel est un outil pour faire leur métier ont tout à gagner à utiliser le libre.

          • [^] # Re: ennuis

            Posté par . Évalué à 3.

            "ceux pour qui le logiciel est un outil pour faire leur métier ont tout à gagner à utiliser le libre."

            Oui mais ils sont souvent trop bête pour s'en apercevoir. Ils refusent de payer une gros service qui développerait l'outil correctement et qu'en plus leur concurrent pourrait utilisé. Il préfère que tout le monde paye les 30% de coûts supplémentaires, liés au frais de vente.

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

            • [^] # Re: ennuis

              Posté par (page perso) . Évalué à 3. Dernière modification le 12/01/15 à 10:23.

              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.

        • [^] # Re: ennuis

          Posté par . Évalué à -1.

          La communauté, pour rappel, c'est 10% de gentils libristes, et 90% de services de rens étrangers et/ou hackers malveillants.

          lol, source ?

          • [^] # Re: ennuis

            Posté par . Évalué à 3.

            82,3% des statistiques sont fausses, mais quand on ne connaît pas la proportion réelle une répartition avec ordre de grandeur 20%/80% est à peu près valable partout :-)

        • [^] # Re: ennuis

          Posté par . Évalué à 1.

          La vrai safety se fait par couche étanche. En gros, pour qu'une catastrophe arrive, il faut que plus d'une barrière saute. En gros, pour faire simple, sur un site web, il faut une faille distante user, puis une autre faille pour passer root.

          Donc, rien n’empêche d'avoir 2 branches dans la sécurité faite par l'état: l'une qui sécurise avec la communauté ssl, TLS, gpg, truecrypt et autre… Et une autre branche qui fonctionne avec du code caché.

          Que personne n'est payé pour avoir un openssl en bon état, est juste scandaleux.

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

      • [^] # Re: ennuis

        Posté par . Évalué à 7.

        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.

        Ben voyons, quand on voit comment la communaute relit avec attention son propre source code a elle (bash, heartbleed, debian openssl), qu'est ce qui te fait penser qu'elle relira celui la?

        Linuxfr, le portail francais du logiciel libre et du neo nazisme.

        • [^] # Re: ennuis

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

          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.

          • [^] # Re: ennuis

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

            Source ? Ça arrive tout le temps à MS de trouver des failles et de les corriger. Pourquoi pas celles-ci ?

            • [^] # Re: ennuis

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

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

              • [^] # Re: ennuis

                Posté par . Évalué à 9.

                Ben le truc, c'est que mettre 25 ans a trouver une faille, c'est sensiblement pareil que ne pas la trouver.

                Techniquement, oui, c'est mieux d'avoir le source.
                En pratique, personne de suffisament competent ne prend le temps de passer ces choses en revue. On a 3 exemples concrets de failles beantes, restees ouvertes pendant des annees.

                Qu'est ce qu'il te fait penser que ca serait different dans ce cas? Les attaquants potentiels vont par contre eux s'en donner a coeur joie (ils sont payes pour).

                Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                • [^] # Re: ennuis

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

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

                  • [^] # Re: ennuis

                    Posté par . Évalué à 4.

                    Tu ne reponds pas a la question "pourquoi cela serait different dans le cas de la defense", et donc quel est l'interet reel.

                    Si tu veux savoir si un logiciel renvoie des infos a la maison mere, c'est faisable sans code, t'analyse le traffic qui sort de la machine.

                    Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                    • [^] # Re: ennuis

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

                      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.

                      • [^] # Re: ennuis

                        Posté par . Évalué à 2.

                        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.

                        Et pourtant heartbleed a affecte ces domaines (bon pas la voiture sans pilote).
                        Le code de heartbleed n'a pourtant pas ete analyse.

                        Je repose donc ma question: pourquoi est ce que plus de gens relirais le code? On a deja la preuve qu'il ne le font pas, qu'est ce qui te fait donc penser que si on publie le code utilise pour la defense nationale, il sera relu correctement?

                        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.

                        Mmmh, ok, alors question piege pour toi: si la non disponibilite du code rend le code impossible a auditer, comment sait tu qu'il ya des defauts ou qu'ils sont incompetents?
                        T'as deux options ici: tu n'en sais rien et fait juste un proces d'intention ou alors, la non dispo du code n'est pas tant un probleme que ca.

                        Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                        • [^] # Re: ennuis

                          Posté par . Évalué à 4.

                          T'as deux options ici: tu n'en sais rien et fait juste un proces d'intention ou alors, la non dispo du code n'est pas tant un probleme que ca.

                          Tu oublis la 3ième possibilité : il a déjà bossé pour ce genre d'éditeur.

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

                        • [^] # Re: ennuis

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

                          "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.

                          • [^] # Re: ennuis

                            Posté par . Évalué à 3.

                            pour moi, c'est la condition de base pour qu'il soit auditable.

                            Il y à plusieurs façons de trouver les problèmes d'un système:
                            1) le regarder de l'intérieur, lire le code, qui permets de trouver certains problèmes mais sûrement pas tous, parce que la programmation, c'est compliqué, surtout quand ce n'est pas toi qui à écrit le source (ou que ça date un peu).
                            2)le fuzzing, qui lui me paraît nettement plus efficace en terme de rentabilité (temps passé / problèmes trouvés). Pas besoin de connaître la programmation ici: suffit de trouver, aléatoirement ou par brute force, un moyen de faire tomber la cible.

                            Perso, si je devais faire tomber les logiciels dont j'ai le source au taf, je te promets que je n'essaierais pas de les lire: vue la gueule du source, j'y perdrai ma santé mentale. Non, une bonne séance avec ces bons vieux netcat/wireshark me semble bien plus efficace, et c'est encore mieux si je sais à quoi l'outil est censé servir… d'ailleurs, c'est là que nmap peut entrer dans la danse, si tu fais une attaque complètement à l'aveugle.

                            • [^] # Re: ennuis

                              Posté par . Évalué à 2.

                              Je suis assez d'accord avec ti sur le fait qu'avoir le code source est loin d'être suffisant pour détecter des failles. Par contre lorsque tu la détectes :

                              • tu sais ou aller pour corriger, ou tu peux payer qui tu veux pour savoir et te faire un retour (l'inconvénient effectivement est qu'une personne mal intentionnée pourra se servir de ces informations pour nuire)

                              • la faille est diffusée à un grand nombre de personnes qui peuvent apprendre des erreurs des autres et ne pes les reproduire, contrairement à un logiciel proprio o l'éditeur peut cacher des informations sur ladite faille pour ne pas passer pour un guignol.

                          • [^] # Re: ennuis

                            Posté par . Évalué à 7.

                            Ensuite, il faut que des moyens financiers soient débloqués pour faire faire les audits.

                            Sans rapport. Si j'ai les moyens financiers de faire auditer le code, je n'ai pas besoin de le libérer: je paie déjà les auditeurs!

                            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.

                            "Comment sécuriser le code face à des équipes de professionnels qui ont 15ans d'expérience dans le domaine?
                            -Hmm… embauchons quelques stagiaires et tout ira bien!"

                            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.

                            Très franchement moi je paniquerai le jour où tu seras en charge de tous ces systèmes: tu vas tout ouvrir en pensant que dès que ce sera fait, on trouvera miraculeusement les ressources pour auditer le code mieux que la NSA et les renseignements chinois, et si on trouve pas, on mettra des stagiaires dessus. Effectivement, ma vie privée est en danger…

                            • [^] # Re: ennuis

                              Posté par . Évalué à 1.

                              Tu rentres dans la caricature là : on parle d'ouvrir du code logiciel, pas de laisser entrer quelqu'un dans un SI pour faire ce qu'il veut.

                          • [^] # Re: ennuis

                            Posté par . Évalué à 1.

                            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.

                      • [^] # Re: ennuis

                        Posté par . Évalué à 2.

                        La défense pourrait exiger de voir les codes sources pour audit. Si les boites comprennent bien l’intérêt du libre, elles veulent rarement payer, même un peu, pour aider les autres. Comme a dit je ne sais plus qui, c'est "Le 1er qui paye à perdu.".

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

                      • [^] # Re: ennuis

                        Posté par . Évalué à 4.

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

                        • [^] # Re: ennuis

                          Posté par (page perso) . Évalué à -5. Dernière modification le 12/01/15 à 10:36.

                          Sources ?
                          D'autre part, les tests de sécurité ne se réduisent pas à l'examen du code et avoir le code source de disponible permet d'analyser et de corriger le code, quand une faille est trouvée en examinant le code ou par tout autre moyen.

                          • [^] # Re: ennuis

                            Posté par . Évalué à 6. Dernière modification le 12/01/15 à 11:12.

                            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.

                          • [^] # Re: ennuis

                            Posté par (page perso) . Évalué à 4. Dernière modification le 12/01/15 à 12:53.

                            Sources ?

                            Une personne s'interessant un minimum sérieusement à la sécurité a lu sur ces failles et sait que ces failles ont été détectées sans le code source.

                            avoir le code source de disponible permet d'analyser et de corriger le code,

                            Ce que fait le propriétaire de code fermé quand on leur rapporte une faille, rien de nouveau, peu de différence avecl le libre (ce n'est pas forcément celui qui détecte la faille qui fournit le patch, mais l'upstream qui fait à sa sauce, le fix perso va surtout servir de hotfix au cas où un autre découvre entre sa découverte et le fix officiel mais bon c'est très temporaire). Tu veux en venir ou?

                            Pour aller dans l'autre sens, si tu t'étais interressé à la sécurité, tu saurais que le code fermé a même un avantage : les gens ont besoin de plus de temps pour trouver la faille lorsque que c'est du code fermé (on passe de 1-2 heures à 1-2 jours, ça permet de diffuser plus largement le patch avant les attaques, dans le cas d'un responsible disclosure), mais tu omets les inconvénients du libre pour être juste à charge contre le non libre (en étant HS, mais bon…)
                            Bref, le libre a plein d'avantage, mais pas ceux que tu décris.

                            tu veux en venir où? Ce n'est pas en racontant n'importe quoi sur le libre que tu vas convaincre. Ton but est-il de faire passer les libristes pour des nuls afin que les gens préfèrent le non libre?

                            • [^] # Re: ennuis

                              Posté par . Évalué à 0.

                              Pour aller dans l'autre sens, si tu t'étais interressé à la sécurité, tu saurais que le code fermé a même un avantage : les gens ont besoin de plus de temps pour trouver la faille lorsque que c'est du code fermé (

                              Argument non valable puisque personne ne s'intéresse au code source ni ne le lit.

                              • [^] # Re: ennuis

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

                                Argument non valable puisque personne ne s'intéresse au code source ni ne le lit.

                                Non. Personne ne lit les sources pour trouver une faille. Quand une faille est trouvée, c'est plus facile avec les sources de comprendre la logique de cette faille et voir comment l'exploiter au mieux. Cause/conséquence.

                                • [^] # Re: ennuis

                                  Posté par . Évalué à 0. Dernière modification le 12/01/15 à 13:31.

                                  Je sais, je suis juste un peu de mauvaise foi (je suis taquin aujourd'hui).

                    • [^] # Re: ennuis

                      Posté par (page perso) . Évalué à 0. Dernière modification le 12/01/15 à 09:31.

                      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.

                      • [^] # Re: ennuis

                        Posté par . Évalué à 3.

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

                        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?

                        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.

                        Ou alors ca a ete detecte, et analyse comme n'etant pas un probleme?

                        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

                        C'est a l'editeur de prendre en charge ce cout en laissant la communaute relire le code? Ca veut pas dire grand chose ce que tu racontes…

                        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.

                        Bon, tu sort enormement de lieu communs tournant autour de "le code ouvert, c'est plus mieux, parce que c'est mieux", donne nous un exemple concret. Le milieu du nucleaire, c'est quand meme super specifique, tu crois reellement que mr machin, developeur lambda, va etre capable de donner le moindre patch/avis sur un systeme pareil?

                        Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                        • [^] # Re: ennuis

                          Posté par (page perso) . Évalué à 1. Dernière modification le 12/01/15 à 10:17.

                          "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.

                          • [^] # Re: ennuis

                            Posté par . Évalué à 3.

                            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.

                          • [^] # Re: ennuis

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

                            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.

                            Backdoor dans OpenBSD ?

                          • [^] # Re: ennuis

                            Posté par . Évalué à 6.

                            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

                            dans un précédent commentaire du même auteur:

                            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.

                            Les stagiaires, c'est bon qu'à auditer du code…

                            • [^] # Re: ennuis

                              Posté par . Évalué à 3.

                              Au fond, il a raison: si les futurs dev lisaient plus de code pendant leurs cours, au lieu d'écrire des snippets, peut-être que le code serait moins crade…

                              Pas celui qu'ils lisent, hein, non non, je parle de celui qu'ils écriront!

                              Désolé, suis encore écœuré de ce que j'ai lu hier au taf…. un fichier de 2kloc (en java, mais peu importe le langage, c'est bien la faute du dev quand il ne vérifie pas le retour d'une fonction… même en java, la mémoire est un problème: accéder à un pointeur nul, peu importe le langage, c'est plantage direct) écrit par des… hum… «développeurs». Ce truc inclue une fonction de plus de 1000Loc, des copier collé partout ou j'ai pu, rien qu'à la lecture, découvrir plusieurs bugs latents, et la taille globale du fichier pourrait être réduite de 25% à vue de nez!

                              Donc, ouai, on devrait faire lire plus de code aux étudiants, et de préférence le code bien immonde, et leur demander de refacto tout ça. Avec évidemment une review par un vrai dev. C'est beau de rêver.

              • [^] # Re: ennuis

                Posté par . Évalué à -1.

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

          • [^] # Re: ennuis

            Posté par . Évalué à 5.

            Ouais, on a juste mit 25 ans, ca en dit long sur l'efficacite des code reviews…
            With enough eyes, all bugs are somebody else's problem.

            Linuxfr, le portail francais du logiciel libre et du neo nazisme.

            • [^] # Re: ennuis

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

              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…

              • [^] # Re: ennuis

                Posté par . Évalué à 5.

                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

                C'est quoi le rapport avec la Défense nationale et la sécurité du code qu'ils utilisent?

                mais le fabricant se garde bien de donner des informations, c'est sûr que sa sécurité est plus qu'aléatoire.

                Non, elle n'est pas aléatoire, elle dépend entièrement du fabricant.
                Tu as d'ailleurs plus de chances de trouver des codeurs pour regarder l'appareil de tout le monde que des codeurs pour auditer un code ultra-spécifique pour une centrale nucléaire. Cela dit, je suis à peu près certain qu'on finira par entendre parler de ce genre de compteur dans une conf BlackHat par des gens qui n'auront jamais vu le source.

                Ici, l'intérêt du source, ce serait pour toi de changer le code pour enlever ce qui ne te plait pas. Je ne suis pas sûr que ça affecte ta sécurité. Ça pourrait même peut-être la dégrader.

              • [^] # Re: ennuis

                Posté par . Évalué à 0.

                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.

                • [^] # Re: ennuis

                  Posté par . Évalué à 2.

                  La sécurité ce n'est pas uniquement la découverte des failles. Là vous focalisez dessus, mais la découverte des failles n'est qu'un aspect de la sécurité.

          • [^] # Re: ennuis

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

            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.

            Clair qu'en écrivant ça, tu as d'un coup une énorme crédibilité sur le sujet de la sécurité.
            Au secours…

            PS : une faille de sécurité non détéctée ne dérange pas, c'est sa détection qui dérange, donc en fait tu viens de dire que le code fermé est supérieur au code libre (ben oui, tu dis qu'avec du code fermé les failles ne sont pas détectées sous-entendant qu'avec le libre elle le sont, le fermé gagne un point il permet d'après toi de ne pas détecter les failles), entre autres (je rpécise : c'est faux).

        • [^] # Re: ennuis

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

      • [^] # Re: ennuis

        Posté par . Évalué à 7.

        Les récents déboires de systèmes sensibles pourtant Libres montrent que la sécurité par le Libre, ça ne marche que si un nombre critique de contributeurs qualifiés et bienveillants s'attellent au problème.
        Plus on va vers des systèmes critiques, plus le nombre de candidats est réduit.
        Il faut en plus qu'ils décident d'eux-même d'auditer ton code.

        Pourquoi feraient-ils cela?
        1. Parce qu'ils utilisent aussi le code à titre personnel
        Peu probable, vu qu'on parle de la Défense
        2. Parce qu'ils sont payés pour ça
        Ben si c'est le cas, fermé ou ouvert, le problème c'est qu'il faut sortir des sous pour payer le contributeur
        3. Par passion
        C'est très beau mais dans la vraie vie, je doute qu'on voit beaucoup de gens qui codent sur un projet qui ne les intéresse pas bénévolement, parce que "quelqu'un doit le faire, et ce sera moi!".
        4. Autre
        Par patriotisme? Pour protéger ses intérêts personnels indirectement? Pas sûr que ça bouge les foules non plus.

        Du coup non, pour le coup, je ne suis pas convaincu que libérer le code servira à autre chose que se faire dépouiller encore plus qu'on ne l'est déjà.

        • [^] # Re: ennuis

          Posté par (page perso) . Évalué à 1. Dernière modification le 12/01/15 à 08:50.

          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.

          • [^] # Re: ennuis

            Posté par . Évalué à 4.

            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.

            Si tu légifères, voilà ce qu'il va se passer: le code sera ouvert, et les moyens en face ne seront toujours pas mis parce que tu n'auras pas résolu grand chose en ouvrant le code, et nulle part tu ne trouves une source de financement supplémentaire.
            Les services de renseignement étrangers vont se gaver.

            Je veux bien qu'on râle tout le temps sur le manque de moyens, mais à un moment faut comprendre que "tout faire bien", ça nous à conduit à une dette abyssale.
            Tu coupes quoi à la place pour garder un budget contenu?

            • [^] # Re: ennuis

              Posté par . Évalué à 2.

              faut comprendre que "tout faire bien", ça nous à conduit à une dette abyssale.

              lapin compris. Déjà, de quoi tu parles quand tu dis "tout faire bien" ?

              Tu coupes quoi à la place pour garder un budget contenu ?

              formulé comme ça, forcément. Mais il se trouve que l'état maîtrise son budget. Contrairement à l'individu lambda, il peut déterminer une partie de ses recettes. Le choix de contenir un budget est un choix idéologique et politique, pas une contrainte technique.

              • [^] # Re: ennuis

                Posté par . Évalué à 2.

                formulé comme ça, forcément. Mais il se trouve que l'état maîtrise son budget. Contrairement à l'individu lambda, il peut déterminer une partie de ses recettes. Le choix de contenir un budget est un choix idéologique et politique, pas une contrainte technique.

                Blablabla.
                Conclusion: si l'argent pour faire les audits n'a pas été alloué, l'État qui maîtrise son budget doit l'allouer. Soit il augmente la dette, soit il le prend sur un autre budget (qui sera forcément moins important à tes yeux, ça va de soi).

                Ou alors tu as une solution magique qui permet de concilier l'un et l'autre sans passer par "et si…".

                • [^] # Re: ennuis

                  Posté par . Évalué à 5.

                  Conclusion: si l'argent pour faire les audits n'a pas été alloué, l'État qui maîtrise son budget doit l'allouer.

                  ok.

                  Soit il augmente la dette, soit il le prend sur un autre budget (qui sera forcément moins important à tes yeux, ça va de soi).

                  Pour une année donnée, éventuellement. Et une fois les budgets alloués à un service donné, évidemment, le service doit organiser ses activités dans le périmètre de ce budget.
                  Cela dit, l'état peut non seulement ré-allouer d'une année sur l'autre, mais augmenter son budget global d'une année sur l'autre (voire en cours d'année, cf les lois de rectification budgétaire). Tu sembles prétendre que la seule façon pour l'état d'augmenter son budget global est d'emprunter, ce qui est faux. Pour la partie qu'il contrôle, l'état peut jouer sur les impôts directs et indirects, d'une part, dans certains pays, il peut jouer sur les cours monétaires. La conjoncture économique a également un impact (l'augmentation de l'activité économique entraîne l'augmentation des recettes). Ce qui peut amener à disposer d'un budget supérieur à ceux prévus l'année précédente, c'est à dire la possibilité d'allouer des budgets supplémentaires quelque part sans en retirer ailleurs.

                  Soit dit en passant, mes yeux n'ont rien à voir ça. L'allocation du budget est un sujet sacrément complexe, et résulte de compromis entre les différentes missions de l'état. La vision simpliste que tu présentes de la question ne me convainc pas.

                  • [^] # Re: ennuis

                    Posté par . Évalué à 3.

                    Soit dit en passant, mes yeux n'ont rien à voir ça. L'allocation du budget est un sujet sacrément complexe, et résulte de compromis entre les différentes missions de l'état. La vision simpliste que tu présentes de la question ne me convainc pas.

                    Non mais à te lire, on a l'impression qu'il "suffisait" d'y mettre plus d'argent, et ce que j'essaie de pointer ici, c'est que s'il "suffisait" d'y mettre plus d'argent, on pourrait résoudre quasiment tous les problèmes d'un pays en un rien de temps.

                    • [^] # Re: ennuis

                      Posté par . Évalué à 2.

                      Non mais à te lire, on a l'impression qu'il "suffisait" d'y mettre plus d'argent, et ce que j'essaie de pointer ici, c'est que s'il "suffisait" d'y mettre plus d'argent, on pourrait résoudre quasiment tous les problèmes d'un pays en un rien de temps.

                      dans l'absolu, c'est peut-être pas faux ;-) mais non, ce n'est pas ce que je disais. De mon côté, je réagissais au côté "il n'y a pas d'alternative" de ton commentaire.

                      Sachant qu'il y avait un autre point aussi, qui était : "tout faire bien", ça nous a conduit à une dette abyssale".
                      Je crois que je comprends ce que tu veux dire, et je ne suis pas d'accord avec ce que je crois que tu dis. Mais comme je ne suis pas sûr, tant que tu n'explicites pas, je retiens mon clavier.

                      • [^] # Re: ennuis

                        Posté par . Évalué à 3.

                        Ben non, je pense que tu comprends très bien:

                        On lit partout "si on avait vraiment mis les moyens…"
                        Moi aussi, je peux dire à mon chef qu'avec un plus gros budget, tout ira mieux, donc c'est de sa faute.

                        Mais voilà, à un moment des choix ont été faits.
                        Au lieu de dire "les moyens de sécuriser le code n'ont pas été mis", moi je peux écrire "on a fait un projet plus gros que ce qu'on pouvait faire correctement et maintenant c'est la faute de l'État qui nous a pas donné assez de sous!"

      • [^] # Re: ennuis

        Posté par . Évalué à 2.

        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

        Et qu'est ce qui te fait croire que la non ouverture de certaines briques n'est pas un risque pris en compte et pallié par d'autres mesures lors de la conception de ces systèmes ?

        • [^] # Re: ennuis

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

          Comme partout, le coût élevé, manque de moyens et de personnels. Mais c'est pratique de pouvoir le cacher.

          • [^] # Re: ennuis

            Posté par . Évalué à 0.

            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.

            • [^] # Re: ennuis

              Posté par . Évalué à 1.

              Attention, on ne parle pas de la même chose. Ce que je dis, c'est que la non ouverture du code est quelque chose qui est pris en compte au moment de la conception du système au global par la maîtrise d’œuvre et la maîtrise d'ouvrage, de façon à ce que le risque sur le système soit considéré comme acceptable. On ne parle pas (ici) de ce que fait l'éditeur de la brique lui-même.

            • [^] # Re: ennuis

              Posté par . Évalué à 4.

              Sûrement que Google, MS et Apple ont des bonnes pratiques et mettent les moyens concernant le code.

              Mais concernant tout le domaine de l'informatique industrielle et militaire, c'est SSII à gogo et irresponsabilité totale, et c'est de ça dont on parle.

              • [^] # Re: ennuis

                Posté par . Évalué à 1. Dernière modification le 12/01/15 à 15:09.

                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 ?

                • [^] # Re: ennuis

                  Posté par . Évalué à 2.

                  Pas dit le contraire.
                  (un léger bémol : en général, même dans les projets obscurs il y a une volonté de faire les choses bien plutôt qu'une volonté de livrer coute que coute. Mais bon)

                  • [^] # Re: ennuis

                    Posté par . Évalué à 0.

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

                    • [^] # Re: ennuis

                      Posté par . Évalué à 3.

                      Le problème n'est pas d'aimer, le problème est d'avoir la possibilité. Si seulement le… hum… chef de projet acceptait d'ouvrir les yeux sur le fait que, oui, le code qui à été pondu est dégueulasse (non, s'il faut 6 mois pour qu'un dev soit compétent sur le soft, c'est pas parce que le soft fait trop de trucs, c'est surtout que le code est immonde et mal conçu en fait) peut-être que l'on pourrait nettoyer, et dégommer les bugs que l'on peut trouver à la simple première lecture d'un fichier source.

                      • [^] # Re: ennuis

                        Posté par . Évalué à 6.

                        Ou qu'il faut 6 mois pour former les gens correctement et que l'enseignement initial n'est pas au niveau de ce que l'on attends en entreprise.

                        Rien que le fait de faire un grep leur parait surhumain; dès que le truc n'est pas géré (ou mal géré) par eclipse le gars ne sait plus se dépatouiller, son poste de dev n'est qu'a moitié fonctionnel, faire un script ou un for i in … pour automatiser des copie est largement au dessus de leur volonté d'apprendre.

                        Donc oui, sur les gros projets, il leur faut bien 6 mois pour apprendre les incantation magique pour qu'eclipse fonctionne a peu près, pour avoir récupéré à droite à gauche 5000 lignes de commandes dans un fichier texte avec un commentaire décrivant vaguement ce que ça fait, et malheureusement, oui ces gens codent sur le projet qui date d'avant java 1.5, avec des vieillerie qui sont copiées/collées, et non ils ne trouvent pas anormal d'avoir des fichier de 10000 lignes.

                        Tu peux décider de faire un freeze des fonctionnalités pour nettoyer le code, mais le temps de tout réécrire iso-fonctionnel, les prestas auront changés, parce que le service achat trouve qu'il est obligatoire de faire tourner, et tu te retrouves avec de nouveau juniors à former, des clients mécontents parce que ça fait 2 ans que tu n'as pas fait d'évolutions, et de toutes façons les mauvaises pratiques qui reprennent, parce que dans les juniors y a un gars qui est 'autodidacte' depuis qu'il a 12 ans et qu'il sait mieux que toi ce qu'il faut faire.

                        Quant à dégommer les bugs à la première lecture des fichiers sources, c'est risqué, parfois il y a du code autour qui sait que ça bug et donc tu te retrouves avec un spaghetti géant à devoir modifier/tester et ça tient plus les délais.

                        Ensuite ça ne m'empêche pas de relire le code du fichier que je modifie, remplacer les Iterator par les foreach, et je modernise le code, et je fais du refactoring simple, par contre avant de faire de gros changement je demande la permission au responsable, parce que ça peut avoir des impacts plus gros que prévu (notamment au sujet du portage d'éventuelle corrections sur la branche livrée )

                        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                        • [^] # Re: ennuis

                          Posté par . Évalué à 4.

                          Effectivement.

                          par eclipse

                          Parfois, je me demande si les IDEs ne sont pas l'une des causes du code dégueulasse. Ils facilitent la duplication de code, que ce soit avec la souris ou avec l'auto-complétion sur le projet complet… ils ont aussi tendance à embarquer des générateurs de code, et je n'ai pas encore vu de code généré qui soit maintenable sur le moyen-long terme.
                          Je ne dis pas que c'est la faute d'éclipse si l'utilisateur est un branque, hein, faut pas repousser la faute sur l'outil, mais la facilité engendre régulièrement ce genre d'«erreur humaine» j'ai l'impression.

                          Donc oui, sur les gros projets, il leur faut bien 6 mois pour apprendre les incantation magique pour qu'eclipse fonctionne a peu près,

                          Sauf qu'en l'occurrence, c'est moi qui doit me faire ch… à apprendre, et niveau personnel sur le merdier, y'a plus qu'un dev qui n'a que croisé un des dev de l'équipe d'origine il y à moins de 2 ans, et la… hum… chef de projet.

                          Quant à dégommer les bugs à la première lecture des fichiers sources, c'est risqué

                          Je ne le fais pas, de toute façon pour le moment je ne travaille pas officiellement dessus. Je me suis contenté de le signaler. De toute façon, tant que j'ai pas accès au SVN et au bugtracker je ne patcherai rien.

                          je fais du refactoring simple,

                          Dans le cas auquel je pense, le bug c'est un bloc de code qui n'a pas été transformé en fonction (20 lignes, copiées/collées 10 fois, et ces 20 lignes elles-même incluent un sous-copier-coller de 2x4 lignes…). Le refactoring simple ici corrigerai le bug du même coup ;) mais bon.

                          Je me dis surtout qu'il va être temps pour moi de changer de boîte, quitte à devoir bouger sur Paris… sauf que je manque "légèrement" de diplôme (oui, je suis auto-didacte, mais quand je vois le travail de certains qui ont appris à l'école, ça me désole). Verrai bien, y'a p'tet moyen de sauver les meubles quand même.

                          • [^] # Re: ennuis

                            Posté par . Évalué à 3.

                            Parfois, je me demande si les IDEs ne sont pas l'une des causes du code dégueulasse.

                            Il en simplifie grandement l'écriture, et le coté compile instantanée + chargement à chaud ou tu vois immédiatement tes modifs sans avoir à relancer l'appli ont tendance à favoriser le quick&dirty. Quand tu fais ton code puis ta compile tu réfléchis un peu plus avant, et de toute façons avec le temps de la compile tu peux réfléchir à la meilleur façon de faire.

                            Avec un IDE, il faut prendre la discipline de se forcer à réfléchir à la conception, chose qui est généralement absente chez pas mal de collègue.

                            Sauf qu'en l'occurrence, c'est moi qui doit me faire ch… à apprendre, et niveau personnel sur le merdier, y'a plus qu'un dev qui n'a que croisé un des dev de l'équipe d'origine il y à moins de 2 ans, et la… hum… chef de projet.

                            J'ai déjà eu le cas, c'est pas la mort, et dis toi que ça va arriver de plus en plus

                            Je me dis surtout qu'il va être temps pour moi de changer de boîte, quitte à devoir bouger sur Paris… sauf que je manque "légèrement" de diplôme (oui, je suis auto-didacte, mais quand je vois le travail de certains qui ont appris à l'école, ça me désole). Verrai bien, y'a p'tet moyen de sauver les meubles quand même.

                            Après 2 ans en entreprise, ce qui importe c'est les postes, les technos, les méthodes usités le diplôme c'est de l'histoire ancienne.

                            Par contre ne pas dire à un recruteur que la principale différence entre la méthode agile et la Rache, c'est que la Rache prévoie la perte de post'it, ils n'ont pas tous le sens de l'humour.

                            Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                            • [^] # Re: ennuis

                              Posté par . Évalué à 2.

                              Par contre ne pas dire à un recruteur que la principale différence entre la méthode agile et la Rache, c'est que la Rache prévoie la perte de post'it, ils n'ont pas tous le sens de l'humour.

                              J'aime :D

              • [^] # Re: ennuis

                Posté par . Évalué à 3.

                Mais concernant tout le domaine de l'informatique industrielle et militaire, c'est SSII à gogo et irresponsabilité totale, et c'est de ça dont on parle.

                Concernant le domaine de la défense, c'est un fantasme. Soit tu l'as vu et auquel cas il y a un problème, soit c'est du "on dit". Je ne m'exprimerai pas sur l'informatique industrielle.

          • [^] # Re: ennuis

            Posté par . Évalué à 2.

            C'est dommage que tu penses ça, parce que c'est pourtant le cas.

  • # Commentaire supprimé

    Posté par . Évalué à 10.

    Ce commentaire a été supprimé par l'équipe de modération.

  • # fiabilité !

    Posté par . Évalué à 4.

    "On peut calculer globalement la résistance d’un système électronique et prévoir sa fiabilité mais elles sont généralement plus faibles que celles d’un système mécanique. "

    C'est juste complètement faux. Les avions sont bien plus fiables, depuis que les commandes de vol sont électriques. La redondance est bien moins coûteuse par exemple : 7 systèmes électroniques contre 3 mécaniques sur les avions de ligne plus ancien.

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

    • [^] # Re: fiabilité !

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

      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.

      • [^] # Re: fiabilité !

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

        Mais les États-Unis peuvent détourner à distance un avion en prenant le contrôle à distance des commandes de vol

        Source ?

        Et les derniers accidents montrent que les commandes électroniques sont souvent perturbées par les orages.

        Les orages ce sont surtout des températures très faibles et de forts courants atmosphériques qui peuvent paralyser l'avion. Ce n'est pas l'électronique qui lâche dedans (d'ailleurs les sondes Pitot sont des éléments mécaniques par exemple et sont sensibles à ces phénomènes).

        • [^] # Re: fiabilité !

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

          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.

          • [^] # Re: fiabilité !

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

            Tu lis un peu tes articles ?
            Le premier dit que ce sont des recherches et qu'en 2001 les Boeing de ligne n'en étaient pas équipés, sans préciser si aujourd'hui c'est le cas.
            Puis entre un pacemaker et un avion, ce n'est pas la même chose.

            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.

            Tellement connu et maitrisé qu'il y a moins de 5 ans une catastrophe a eu lieu à cause de ça… Bref tu n'as aps démontré que l'électronique causait plus de dommages que la mécanique.

            • [^] # Re: fiabilité !

              Posté par (page perso) . Évalué à -7. Dernière modification le 12/01/15 à 10:25.

              "Tu lis un peu tes articles ?" : reste calme s'il te plaît.

            • [^] # Re: fiabilité !

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

              "Tellement connu et maitrisé qu'il y a moins de 5 ans une catastrophe a eu lieu à cause de ça" : je n'ai pas dit que c'était maîtrisé mais maîtrisable.

              • [^] # Re: fiabilité !

                Posté par . Évalué à 6.

                Donc tu nous dis que si c'est mécanique, on pourrait le faire fiable mais on ne le fait pas, alors que si c'est électronique, on ne peut pas le faire fiable.
                Sans doute parce que c'est moins cher de crasher un avion que d'optimiser une sonde Pitot?

                Et ces affirmations fracassantes se basent sur des données je suppose très très solide couplées à une grande aisance technique dans les 2 domaines?

      • [^] # Re: fiabilité !

        Posté par . Évalué à 1.

        "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."

        Non, c'est une question de poids.

        "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."

        Source ? Ton article site des fonctionnalités évoqués, une feature, pas un bug.

        "Et les derniers accidents montrent que les commandes électroniques sont souvent perturbées par les orages."

        C'est archi faux également. Les avions n'aiment pas les cumulo-nimbus, et c'est à causes des vents violents, pas des éclaires.

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

      • [^] # Re: fiabilité !

        Posté par . Évalué à 2.

        Et les derniers accidents montrent que les commandes électroniques sont souvent perturbées par les orages.

        A ma connaissance, jamais personne n'a écrit cela.

        • [^] # Re: fiabilité !

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

          • [^] # Re: fiabilité !

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

            Si on résume tes 3 liens :

            • L'un parle que l'orage c'est dangereux à cause du vent et de la grêle ;
            • L'autre que l'électronique comme la mécanique peuvent être endommagés par la foudre mais que c'est rare (2 cas recensés) ;
            • Et un autre parle d'un des cas recensés.

            En sachant que les risques de la foudre sont de plus en plus réduits par un choix des matériaux adéquats.
            Moralité, on attend toujours une preuve que l'électronique à bord des avions est plus critique que la mécanique et cause ainsi plus d'accidents.

            • [^] # Re: fiabilité !

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

              parce qu'elle n'est réellement fonctionnelle qu'avec la totalité des messages provenant de capteurs. Ainsi avec un mauvais retour capteur, elle prend des mauvaises décisions parce qu'elle n'a pas d'intelligence.

              C'était le cas avec les capteurs givrés lors du fameux vol air-france : l'électronique à pris une décision fatale parce que le capteur n'envoyait pas la bonne information. Alors on peut se dire que cela vient du capteur ou du pilote qui n'avait qu'a outrepasser l'avionique, mais c'est l'électronique qui a pris la mauvaise décision.

              • [^] # Re: fiabilité !

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

                L'électronique 'na connu dans cette affaire aucune défaillance, c'est le capteur qui a merdé et qui repose sur des principes physiques et non électroniques.
                De toute façon, un pilote avec des indications de capteurs fausses ne ferait pas forcément mieux qu'un pilote automatique de ce point de vue (il y a peu de visibilité sur l'extérieure et si tu ignores ta vitesse et ton altitude t'es en aveugle totale).

                Ce n'est pas pour rien que de nombreux pilotes ont soutenu les pilotes de ce vol, ils savent qu'ils n'auraient pas pu faire mieux à ce moment là. Ce n'est pas l'électronique qui est en tort là dedans.

              • [^] # Re: fiabilité !

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

                Il n’y a aucune défaillance électronique dans l’accident du vol AF447, l’électronique a juste détecté une incohérence (la rendant inapte à prendre des décisions) entre les vitesses air à gauche et à droite lors du givrage des sondes pitot et rendu la main (désengagement du pilote automatique et de l’auto-manette, et réduction des protections automatiques de domaine de vol — l’informatique d’un Airbus t’empêche normalement de faire de la voltige avec, même si tu manœuvre les commandes en buttée). Ce qui est exactement ce qui était attendu d’elle et programmé dans la situation rencontrée.

                Le reste, ce sont des erreurs de conception :

                • Sondes pitot qui givrent (problème connu pour ce modèle, elles étaient en cours de remplacement sur la flotte)
                • Alarme de décrochage qui ne fonctionne que si la vitesse air horizontale est supérieure à 60 nœuds (valeur choisie pour éviter des alarmes intempestives au roulage ou lors de phases d’atterrissage / décollage).
                • Absence de mise en évidence claire des valeurs (vitesses, attitude, etc.) considérées comme valides ce qui à certainement entraîné le doute sur toutes les valeurs affichées pour les pilotes alors que seules la vitesse air était mauvaise (et pendant un temps relativement court).
                • Absence d’affichage de l’incidence (angle entre le flux d’air et les ailes) qui aurait pu permettre aux pilote de réaliser la situation de décrochage.

                Et de formation / réaction de l’équipage :

                • Non application de la procédure dite « IAS douteuse » lorsque les vitesses ne sont plus valides.
                • Non prise en compte des alarmes de décrochage.
                • Incompréhension totale de la situation (décrochage rattrapable pendant au moins 2 minutes en poussant sur le manche.

                À la décharge des pilotes, voir les erreurs de conception, plus le fait que :

                • Ce type d’avion étant sensé t’empêcher de faire de la voltige, les approches de décrochage sont quasiment impossible et donc peut-être moins étudiées que sur d’autres appareils.
                • Les actions enseignées en simulateur pour sortir d’une approche de décrochage (cabrer légèrement + pousser les gaz à fond, le but étant ici de ne pas rendre d’altitude) sont contraire à celles à prendre pour sortir d’un décrochage engagé (pousser le manche pour se mettre en piqué + réduire les gaz afin d’une part de ne pas prendre trop de vitesse, d’autre part de faciliter l’action à piquer les moteurs placés sous les ailes pouvant avoir plus d’impact sur l’inclinaison que les surfaces mobiles mal « soufflées » lors d’un décrochage).
                • Les limites de la simulation informatique de l’écoulement de l’air turbulent et les coûts et risques qu’entraînerait la prise de mesures en conditions réelles d’un décrochage de tels appareils font qu’un pilote de ligne ne rencontre ni en simulateur ni normalement durant sa formation à bord de décrochage engagé, rendant cette situation potentiellement difficile à appréhender et même à envisager.
    • [^] # Re: fiabilité !

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

      S'il faut 7 systèmes de redondance pour l'électronique au lieu de 3 pour la mécanique, c'est donc bien parce que l'électronique est moins fiable du fait de sa complexité. Cela confirme ce que je dis.

  • # Résistance aux pannes ou aux attaques ?

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

    Je ne comprends pas, au début ça parle de pannes, ensuite d'attaques. Or une serrure mécanique n'est pas « relativement facile à sécuriser » par exemple (crochetage), mais elle est assez résistante aux pannes (rouille).

    • [^] # Re: Résistance aux pannes ou aux attaques ?

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

      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.

      • [^] # Re: Résistance aux pannes ou aux attaques ?

        Posté par . Évalué à 1.

        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.

        • [^] # Re: Résistance aux pannes ou aux attaques ?

          Posté par . Évalué à 6.

          Pas plus tard qu'hier, j'ai réparé un transistor dans un i7 au fer à souder (mais avec une petite pane hein!)

          Bon,j'ai peut-être aussi quelque peu "réparé" une dizaine de milliers d'autres transistors dans la foulée ainsi que toutes les couches de routage métal. Mais je suis sûr que le transistor ciblé remarche!! C'est con qu'on arrive plus à le tester…

          --------> [ ]

        • [^] # Re: Résistance aux pannes ou aux attaques ?

          Posté par . Évalué à 4.

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

          Rien du tout. Il n'y a pas de faille HW dans un CPU intel.
          Bon il se trouve que ce modele précis a été retire du marche plus vite que prévu, et a été remplace par un modele tres similaire, mais ca a rien a voir. (Alesia? Quoi Alesia? Je ne connais pas Alesia)

          De toutes facons, on a pas les sources du CPU, donc on peut pas trouver les failles. Si on les avait (les sources, pas les failles, faut suivre un peu), on pourrait mettre un stagiaire en CAP coiffure sur le coup, et il corrigerait les problemes, comme ca, paf, pasteque.

          Linuxfr, le portail francais du logiciel libre et du neo nazisme.

  • # je suis effaré

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

    Je lis les commentaires et je comprends (pertinent- inutile) que la majorité est pour la fermeture du code (pour sa sécurité).

    O tempra, O mores

    • [^] # Re: je suis effaré

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

      Mais il n'y aucune notion de préférence ou de morale dans les arguments exposés, simplement des faits concrets.

      Si tu as des arguments montrant qu'un code aussi spécialisé serait plus sûr en étant libre, donne-les.

    • [^] # Re: je suis effaré

      Posté par . Évalué à 4.

      pas "pour" la fermeture.
      Juste un rappel que diffuser du code ne le rend pas magiquement sur et fiable, et que les contributions de la communauté se réduisent a peau de balle quand il s'agit de la sécurité.

      Ca veut pas dire qu'une licence libre est une mauvaise chose, mais que publier le source publiquement (oui, y'a une difference) n'a en l'occurence aucun avantage et apporte surtout des inconvenients.

      Linuxfr, le portail francais du logiciel libre et du neo nazisme.

    • [^] # Re: je suis effaré

      Posté par (page perso) . Évalué à -2. Dernière modification le 13/01/15 à 07:31.

      Si tu enlèves les commentaires dépressifs-dédaigneux-agressifs-insultants que Zenitram, pasBill pasGates et 2-3 autres bizarres déversent systématiquement chaque semaine par centaines dans tous les posts, les commentaires sont parfois constructifs. Sinon, je trouve effectivement que poster sur LinuxFR devient de moins en moins intéressant. Je poste de plus en plus sur des blogs persos répercutés sur Planet-Libre, on peut virer les commentaires inutiles et avoir de vrais débats. Et j'ai maintenant plus de visiteurs avec Planet-Libre qu'avec LinuxFR.

      • [^] # Re: je suis effaré

        Posté par . Évalué à 1.

        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.

    • [^] # Re: je suis effaré

      Posté par . Évalué à 1.

      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.

      • [^] # Commentaire supprimé

        Posté par . Évalué à 3.

        Ce commentaire a été supprimé par l'équipe de modération.

        • [^] # Re: je suis effaré

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

          Ton livre parle d'algo de chiffrement (et un chiffrement faible est cassé avec des méthodes totalement différentes de la recherche de failles classiques). Le journal parle de l'intégralité du code (et oui, les failles peuvent se trouver partout), et de codes extrêmement spécialisés (industrie de défense).

          En pratique, on constate que
          * un code open-source utilisé par beaucoup de monde peut contenir des failles graves et très vieilles (heartbleed, shellshock, debian+ssh, …), donc soit il n'y a pas de relecture, soit elle est inutile,
          * les failles sont dans leur très grande majorité trouvées sans utiliser le code source.

          Maintenant, prenons un code utilisé dans une centrale nucléaire ou un avion de combat.
          Qui ira relire bénévolement des milliers de lignes de code qu'il ne pourra pas réutiliser, à part les services de renseignement étrangers ?
          Pourquoi cette relecture serait-elle magiquement plus efficacement que sur les codes classiques ?

          Réponse donnée par Scoubidou : des gens qu'on paierait pour relire le code… bon, bah pour ça, il n'y a pas besoin de donner le code aux services étrangers, et de toute façon c'est probablement déjà fait (ça s'appelle des audits et c'est très classique).
          Dans beaucoup de cas, dévoiler le code revient à dévoiler nos capacités, sans même parler des failles potentielles que les services étrangers garderaient pour eux…

          Je vois bien ce qu'on peut y perdre, mais je ne vois pas trop ce qu'on y gagne.

        • [^] # Re: je suis effaré

          Posté par . Évalué à -1.

          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.

        • [^] # Re: je suis effaré

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

          Tiens, justement, un article intéressant qui d'être posté, concernant les méthodes de revues de code : https://linuxfr.org/news/code-trouver-les-erreurs

Suivre le flux des commentaires

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