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é :
- Y aura-t-il un scandale Sesam Vitale ?
- Les compteurs d’électricité intelligents déjà piratés ;
- Un réfrigérateur «intelligent» ciblé par une cyberattaque ;
- Encore un exemple de code spaghetti : Toyota ;
- Cas pratique de mauvaise gestion de crise avec les serrures Onity ;
- Vote électronique : anomalie détectée, une candidate UMP conteste l’élection ! et Le vote par Internet, c’est pire au second tour !
- Immigration : des faux passeports électroniques indétectables ? et Un hacker clone l'empreinte digitale d'une ministre allemande à partir de photos ;
- Nouveau vol massif de données personnelles chez Orange, 10 millions de données clients volés à Orange Espagne ?, Le ministère de la Défense attaqué par des 'Anonymous' ;
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 NumOpen . Évalué à 1.
Flûte, si quelqu'un peut corriger : perturbations électromécaniques -> perturbations électromagnétiques
[^] # Re: Correction
Posté par NeoX . Évalué à 2.
c'est corrigé
# ennuis
Posté par nopenope . É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 hervé Couvelard . Évalué à -8.
oui oui, je suis charlie aussi
[^] # Re: ennuis
Posté par nopenope . É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 hervé Couvelard . Évalué à 6. Dernière modification le 24 août 2019 à 18:08.
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 nopenope . É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 Liorel . Évalué à 5.
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.
Les trucs importants (centrales nucléaires, réseaux de transports, machines militaires) bénéficient de plusieurs mesures de sécurité.
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.
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).
Je sais pas toi, moi ça me semble assez clair, même pas besoin d'expliquer.
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 NumOpen . Évalué à 4.
C'était la
mise en garderé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 Enzo Bricolo 🛠⚙🛠 . É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 Liorel . Évalué à 3.
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 NumOpen . Évalué à 3. Dernière modification le 11 janvier 2015 à 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 Anonyme . Évalué à 1.
toutafé
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 nopenope . É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 totof2000 . Évalué à 2.
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 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 Nicolas Boulay (site web personnel) . Évalué à 3.
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 NumOpen . Évalué à 3. Dernière modification le 12 janvier 2015 à 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 pasBill pasGates . Évalué à -1.
Parce que les gens en charge ont, contrairement à toi, compris que ce que tu racontes ne tient pas debout et que faire ce que tu dis ne changerait en rien la qualité ou la securité.
[^] # Re: ennuis
Posté par NumOpen . Évalué à 2.
Ah bon ? http://www.numerama.com/magazine/32632-cyberdefense-chez-les-fai-des-produits-de-securite-qualifies-par-l-etat.html
[^] # Re: ennuis
Posté par needs . Évalué à -1.
lol, source ?
[^] # Re: ennuis
Posté par khivapia . É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 Nicolas Boulay (site web personnel) . É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 groumly . Évalué à 7.
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 NumOpen . É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 flan (site web personnel) . É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 NumOpen . É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 groumly . É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 NumOpen . É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 groumly . É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 NumOpen . É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 groumly . Évalué à 2.
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?
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 Nicolas Boulay (site web personnel) . Évalué à 4.
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 NumOpen . É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 freem . Évalué à 3.
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 totof2000 . É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 Maclag . Évalué à 7.
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!
"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!"
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 totof2000 . É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 pasBill pasGates . Évalué à 1.
Merci de confirmer ce que je pensais depuis le début, tu ne connais absolument rien à ce sujet.
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 Nicolas Boulay (site web personnel) . É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 pasBill pasGates . Évalué à 4.
Grosse connerie, aucun, je dis bien AUCUN de ces bugs n'a été trouvé en lisant le code.
[^] # Re: ennuis
Posté par NumOpen . Évalué à -5. Dernière modification le 12 janvier 2015 à 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 pasBill pasGates . Évalué à 6. Dernière modification le 12 janvier 2015 à 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 Zenitram (site web personnel) . Évalué à 4. Dernière modification le 12 janvier 2015 à 12:53.
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.
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 totof2000 . Évalué à 0.
Argument non valable puisque personne ne s'intéresse au code source ni ne le lit.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ennuis
Posté par totof2000 . Évalué à 0. Dernière modification le 12 janvier 2015 à 13:31.
Je sais, je suis juste un peu de mauvaise foi (je suis taquin aujourd'hui).
[^] # Re: ennuis
Posté par NumOpen . Évalué à 0. Dernière modification le 12 janvier 2015 à 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 groumly . Évalué à 3.
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?
Ou alors ca a ete detecte, et analyse comme n'etant pas un probleme?
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…
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 NumOpen . Évalué à 1. Dernière modification le 12 janvier 2015 à 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 pasBill pasGates . É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.
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 Zenitram (site web personnel) . Évalué à 5.
Backdoor dans OpenBSD ?
[^] # Re: ennuis
Posté par Maclag . Évalué à 6.
dans un précédent commentaire du même auteur:
Les stagiaires, c'est bon qu'à auditer du code…
[^] # Re: ennuis
Posté par freem . É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 pasBill pasGates . Évalué à -1.
Ah oui ? Comment oses-tu dés lors dire que les logiciels propriétaires sont mal écrits ?
[^] # Re: ennuis
Posté par groumly . É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 NumOpen . É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 Maclag . Évalué à 5.
C'est quoi le rapport avec la Défense nationale et la sécurité du code qu'ils utilisent?
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 pasBill pasGates . Évalué à 0.
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 totof2000 . É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 Zenitram (site web personnel) . Évalué à 2.
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 NumOpen . Évalué à 2.
http://www.numerama.com/magazine/32632-cyberdefense-chez-les-fai-des-produits-de-securite-qualifies-par-l-etat.html
[^] # Re: ennuis
Posté par Maclag . É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 NumOpen . Évalué à 1. Dernière modification le 12 janvier 2015 à 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 Maclag . Évalué à 4.
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 gaaaaaAab . Évalué à 2.
lapin compris. Déjà, de quoi tu parles quand tu dis "tout faire bien" ?
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 Maclag . Évalué à 2.
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 gaaaaaAab . Évalué à 5.
ok.
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 Maclag . Évalué à 3.
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 gaaaaaAab . Évalué à 2.
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 Maclag . É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 oinkoink_daotter . Évalué à 2.
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 NumOpen . É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 pasBill pasGates . É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 oinkoink_daotter . É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 navaati . É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 pasBill pasGates . Évalué à 1. Dernière modification le 12 janvier 2015 à 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 navaati . É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 pasBill pasGates . É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 freem . É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 fearan . É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 freem . Évalué à 4.
Effectivement.
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.
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.
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.
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 fearan . Évalué à 3.
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.
J'ai déjà eu le cas, c'est pas la mort, et dis toi que ça va arriver de plus en plus
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 freem . Évalué à 2.
J'aime :D
[^] # Re: ennuis
Posté par oinkoink_daotter . Évalué à 3.
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 oinkoink_daotter . Évalué à 2.
C'est dommage que tu penses ça, parce que c'est pourtant le cas.
# Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Cryptography Engineering: Design Principles and Practical Applications
Posté par nopenope . Évalué à 3.
Il y a des institutions qui refusent d'utiliser ce logiciel Acid pour les raisons évoquées. Quitte à passer pour le mouton noir.
[^] # Re: Cryptography Engineering: Design Principles and Practical Applications
Posté par NumOpen . Évalué à 4.
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.
[^] # Re: Cryptography Engineering: Design Principles and Practical Applications
Posté par khivapia . Évalué à 3.
Il faut qu’il n’exige pas le secret, et qu’il puisse sans inconvénient tomber entre les mains de l’ennemi
Ce principe de Kerckhoff ne signifie pas qu'il faille obligatoirement le faire tomber entre les mains de l'ennemi, et donc le publier !
Ça signifie seulement que la sécurité cryptographique ne doit pas reposer sur le secret de l'algorithme de chiffrement, contrairement à par exemple Enigma où le câblage des rotors était déjà une information importante (en plus des clefs).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 6. Dernière modification le 12 janvier 2015 à 19:10.
Ce commentaire a été supprimé par l’équipe de modération.
# fiabilité !
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
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 NumOpen . É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 Renault (site web personnel) . Évalué à 3.
Source ?
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 NumOpen . É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 Renault (site web personnel) . É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.
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 NumOpen . Évalué à -7. Dernière modification le 12 janvier 2015 à 10:25.
"Tu lis un peu tes articles ?" : reste calme s'il te plaît.
[^] # Re: fiabilité !
Posté par NumOpen . É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 Maclag . É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 Nicolas Boulay (site web personnel) . Évalué à 1.
Non, c'est une question de poids.
Source ? Ton article site des fonctionnalités évoqués, une feature, pas un bug.
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 oinkoink_daotter . Évalué à 2.
A ma connaissance, jamais personne n'a écrit cela.
[^] # Re: fiabilité !
Posté par NumOpen . Évalué à -4.
http://www.ladepeche.fr/article/2009/06/02/617134-la-foudre-un-risque-pour-les-avions-de-ligne.html
http://blogs.mediapart.fr/blog/yves-faucoup/070814/crash-au-mali-pourquoi-l-avion-n-pas-evite-lorage
http://www.orangerca.com/actualites/?p=318409
etc. il y a plein d'exemple en tapant dans un moteur de recherche "orage commande électronique avion"
[^] # Re: fiabilité !
Posté par Renault (site web personnel) . Évalué à 5.
Si on résume tes 3 liens :
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 hervé Couvelard . É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 Renault (site web personnel) . É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 Hobgoblins Master (Mastodon) . É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 :
Et de formation / réaction de l’équipage :
À la décharge des pilotes, voir les erreurs de conception, plus le fait que :
[^] # Re: fiabilité !
Posté par NumOpen . É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 Benoît Sibaud (site web personnel) . É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 NumOpen . É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 pasBill pasGates . Évalué à 1.
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 Maclag . É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 groumly . Évalué à 4.
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.
[^] # Re: Résistance aux pannes ou aux attaques ?
Posté par KiKouN . Évalué à 3.
Quelle est cette manie de donner des sujets de stage tiré par les cheveux à de futurs coiffeurs ?
[^] # Re: Résistance aux pannes ou aux attaques ?
Posté par totof2000 . Évalué à 2.
Pour leur ôter le poil de la main ?
[^] # Re: Résistance aux pannes ou aux attaques ?
Posté par freem . Évalué à 2.
En même temps, il faut dire qu'il n'y à pas mieux qu'un coiffeur pour démêler un chevelu (le nom que mes profs donnaient au schéma entre le schéma de conception et le dessin de la carte, qui portait très bien ce nom d'ailleurs).
# je suis effaré
Posté par hervé Couvelard . É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 flan (site web personnel) . É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 groumly . É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 NumOpen . Évalué à 2.
http://www.infodsi.com/articles/153291/professionnels-securite-informatique-font-plus-confiance-solutions-collaboration-open-source-solutions-proprietaires-olivier-thierry-chief-marketing-officer-zimbra-specialiste-open-source.html
[^] # Re: je suis effaré
Posté par pasBill pasGates . Évalué à 0.
LOL merci pour ce grand moment d'humour !
T'as oublié de nous mettre aussi une press release de Laurent Blanc disant que le PSG est la meilleure équipe du monde et une autre de José Mourihno disant que c'est Chelsea.
[^] # Re: je suis effaré
Posté par NumOpen . Évalué à 1.
http://www.numerama.com/magazine/32632-cyberdefense-chez-les-fai-des-produits-de-securite-qualifies-par-l-etat.html
[^] # Re: je suis effaré
Posté par NumOpen . Évalué à 5.
Lorsqu'on avait créé le LUG de Metz en 2000, quelqu'un nous avait développé rapidement un petit script PHP pour poster des nouvelles, bien avant que les blogs n'apparaissent. La semaine suivante, un groupe de hackers turcs nous ont renvoyé toute une série de failles et leurs corrections. j'avais trouvé la démarche très intéressante, c'était de vrais hackers. C'est cet esprit-là qu'il faut développer en France.
[^] # Re: je suis effaré
Posté par NumOpen . Évalué à -2. Dernière modification le 13 janvier 2015 à 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 pasBill pasGates . É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 NumOpen . Évalué à 1.
http://www.numerama.com/magazine/32632-cyberdefense-chez-les-fai-des-produits-de-securite-qualifies-par-l-etat.html
[^] # Re: je suis effaré
Posté par pasBill pasGates . É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 Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: je suis effaré
Posté par flan (site web personnel) . É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 pasBill pasGates . Évalué à -1.
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.
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.
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 NumOpen . Évalué à 1.
http://www.numerama.com/magazine/32632-cyberdefense-chez-les-fai-des-produits-de-securite-qualifies-par-l-etat.html
[^] # Re: je suis effaré
Posté par NumOpen . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.