S'identifier / Créer un compte
  • Actualités
  • Dossiers
  • Tests
  • Commentaires
  • INpactiens
Publicité
Avatar de Lafisk INpactien
Lafisk Inscrit le dimanche 3 juin 12 - 7132 commentaires -
Les derniers commentaires de Lafisk :
On peut lui couper la langue ? ca lui evitera de dire trop de connerie ...

Tout à fait

Il ne suffit pas d'ouvrir le code source pour qu'il devienne magiquement sécurisé : il faut prévoir les audits qui vont avec. Mais ça je pense que c'est un peu une évidence pour tout le monde...

Je voulais juste souligner que, utiliser ce simple fait pour dire que «90% des codes Open Source ne sont pas relus», c'est faux. Partir de là pour en déduire que «les codes Open Source ne sont pas plus sécurisés que les Closed Source», c'est une mauvaise déduction, et c'est aussi faux. Les faits montrent qu'en moyenne, les codes Open Source sont mieux sécurisés que les codes Closed Source.


Vu les commentaires, c'est pas forcement une evidence

Tu vas serieusement pinailler sur les "90%" ... les chiffres a la louches tu as jamais fait ?

Mais ça impliquerais de réinventer la roue à chaque fois, ça.
C'est quand même beaucoup plus simple (plus rapide, moins coûteux, etc) de faire relire du code déjà écrit et éprouvé ailleurs, que de partir de zéro.


Lui, mais la c'est sur que pour ce cas la, tu auras une meilleure securite avec l'open source, mais ca depend pour quel type de projet

si on prend un skype, je pense que y'a une grosse partie du truc qui est ecrit en interne

Si c'est pour un jeu, tu reecris pas forcement le moteur 3D a chaque fois ... voir plus ca va plus on uitlise des outils qui abstraient le code pour ce concentrer sur le contenue et la en effet pour la securite, tu es dependant de la securite de ton outils que tu ne peux garantir, mais la pour moi, si tu ne peux le garantir ... tu peux difficilement t'en revendiquer

Bon les exemples sont bidons mais c'est pour l'exemple hein

Je vais essayer d'être plus clair :
On ne parle pas du code développé en interne. Ça évidemment qu'on peut le faire relire par qui on veut.
On parle du code développé en externe. S'il est ouvert, alors oui aussi, on peut le faire relire par qui on veut. S'il est fermé, alors non, on l'a dans l'os.


Ok, la on est d'accord, mais sur le principe, si tu veux faire du securise, tu demandes pas un developpement externe au pire tu appelles un consultant externe qui vient bosser en interne

On parle du code d'un autre développeur d'une autre boîte, pas de soi-même, sinon ça n'as pas de sens évidemment.

mdr2.gif
Cela en a un ... ou ai je dis soi meme ? je te parle d'un hypothetique service de controle qualie ... ce ne sont donc pas les memes personnes qui relisent le code et le developpent ... ca empeche aucunnement de le faire en interne et c'est exactement pareil que de faire faire un audit par une boite tierce, le mec qui fait du Q&C c'est son boulot de dire ce qui ne va pas ...
Mais au final c'est pareil dans le mode du closed-source.

Mais, c'est au final, ce que je dis ... la boite privee qui veut faire du securisee, elle va mettre en place "facilement" les ressources necessaires en place. Dans l'open source, les gros projets soutenu par differents gros acteurs aussi vont avoir cette ressource mais par contre, ce peu soutenu mais tres utilises eux c'est deja moins bien

Maintenant la boite privee, qui fait un truc mais qui ne veut pas faire du securisee ou n'en a pas les moyens ... la aussi ca va etre la misere, donc la situation est equivalente au pire dans les deux cas ...

mais j'intervenais a la base sur le fait qu'il affirmais qu'un code ne peut etre securise que si il est open source ... ce qui me parait tres reducteur et avouons le un peu fanatique

Mais avec un code fermé, tu ne peux pas le faire relire ! C'est ce qu'on lui reproche.


En interne, si, c'est le principe du closed source quoi ...

D'ailleurs quand je parle d'un autre employe, c'est quoi que tu comprends pas ? Pourquoi un autre employe ne pourrait relire le code ? un code ne devient pas illisible des que tu changes l'employe qui le lit


Hey, il faut arrêter avec cette vision fantasmée des choses...

Prenons le code source de Linux par exemple. Parmi les contributeurs au noyau : des gens de chez Intel, Red Hat, Google... Des entreprises qui vendent du Linux, doivent en assurer le support, et ont tout intérêt à ce que le code soit bien audité et sécurisé.

Il en va de même avec la grande majorité des logiciels libres les plus populaires et les plus exposés.

Croire que tout est fait par des gus dans des garages qui ne relisent rien et espèrent juste que quelqu'un le fera à leur place...

Celui qui fantasme c'est plutot celui qui affirme que le code source open est plus securise que le code proprio...

Trouver quelques exemples ne contre balance pas le fait que 90% des projets open source ne sont pas relu etc...
comme le dit tres bien tzdz, la boite qui veut securisee, elle a les employes pour assurer la chose, les methodes aussi etc... Que tu fasses relire ton code par une autre boite, un mec dans son garage ou ce que tu veux, c'est pas mieux que de le faire relire par un autre employe dont c'est le boulot (Q&C, etc... )

Alors que potentiellement dans le libre ce n;est revu par personne, des grosse failles o dans le libre, ca c'est vu et sur des trucs tres gros et super utilise et y'a pas plus longtemps qu'il y a quelque mois encore ...

Mais je l'ai dit juste avant, le but n'est pas que tout soit relu par tout le monde.
C'est juste offrir une possibilité que le closed source ne permet pas.


Sauf que dans le closed source, si ils veulent faire du "securise" ils vont prendre les dispositions necessaires, meme si aucune ne suffit et c'est valable pour l'open source aussi, alors qu'avec l'open source, le mec ecrit son truc et espere que quelqu'un le relira pour voir si il a pas merder ... dans ce cas je dirais que le closed source me parait mieux car ils ont en general l'infrastructure leur permettant de faire en sorte que de bout en bout les procedures soient respectees (si ils le veulent, evidemment) la ou dans l'open source c'est loin d'etre fait voir au contraire rarement fait au final...


Oui, mais souvent l'AOC est déjà mondialement connu, comme le champagne. Alors, la plus part des entreprises s’appelle "champagne bidule", mais utiliser champagne pour une boite US qui produit un pétillant devrait être interdit.


Oui mais c'est deja le cas.

La ce qui pose probleme c'est l'extension .vin/.wine, hors un vin ne veut pas forcement dire aoc meme si c'est souvent le cas.

Je vois toujours pas le lien entre l'extension et l'aoc. Pour moi c'est un peu melange tout la, aujourd'hui si un mec vend du faux champagne en californie, tu l'as dans le cul (ou pas je sais pas trop). Mais ajouter une extension .vin n'a pas a garantir que le dit vin est AOC, puis franchement le probleme est deja exactement le meme actuellement sauf que l'extension sera differente soit .com soit .biz a la limite ... mais ca change pas le probleme de fond du respect de l'aoc peu importe le nom de l'extension.