BitTorrent dévoile Bleep : une messagerie chiffrée, sans serveur central

Le 01/08/2014 à 10h08

Konrad a écrit :

Dans le cas d’un code fermé, un reviewer externe aura des obligations similaires aux développeurs internes : interdiction de dévoiler le code source, interdiction de parler des failles potentiellement découverte, interdiction de parler des processus de développement…

Bien sûr. Ce qui me hérisse c’est les sous-entendus, sur le fond, encore une fois je suis assez d’accord.

TZDZ

Le 01/08/2014 à 20h16

Mihashi a écrit :

Tu auras beau développer le meilleur algorithme qui soit, si tu ne peux pas me prouver que c’est le meilleur, je ne pourrais pas considérer qu’il l’est.

Au passage, mon premier commentaire était : “le consensus sur la sécurité, c’est que l’algorithme doit être ouvert, pour le code on peut en discuter”.

Konrad

Le 02/08/2014 à 08h33

TZDZ a écrit :

Au passage, mon premier commentaire était : “le consensus sur la sécurité, c’est que l’algorithme doit être ouvert, pour le code on peut en discuter”.

Pour programmer moi-même, je sais qu’on peut définir :

ce que tu veux faire

ce que fait l’algorithme

ce que donne l’implémentation que tu en as faite

L’idéal c’est que les trois soient la même chose, en particulier on souhaite que le code soit une implémentation parfaite de l’algorithme. Malheureusement ce sont souvent trois choses distinctes " /> Les failles dans Windows, dans Firefox, Heart Bleed, etc. sont autant d’exemples où l’algo était bon, mais l’implémentation était foireuse.

Un code ne peut pas être plus sûr que son maillon le plus faible. L’algorithme doit être ouvert, je pense qu’il n’y a pas trop de débat là-dessus : la fiabilité et la sécurité de l’algo peuvent être démontrées mathématiquement.

Si l’algorithme est ouvert mais que le code est fermé, les deux premiers points sont visibles de tous, en revanche personne ne peut vérifier que l’implémentation a été bien faite. La force du troisième maillon est cachée, inconnue. Au contraire si le code est Open Source, tout le monde (entreprises, etc.) peut vérifier la solidité de toute la chaîne.

Bien sûr ces considérations ne disent rien sur la sécurité en elle-même : si le code est Closed Source et que l’implémentation est bien faite, alors le code sera sécurisé (encore une fois c’est une évidence). Par contre, personne ne pourra vérifier que l’implémentation a été bien faite, et personne (à part l’éditeur) ne pourra patcher le code si besoin. Cela pose donc un problème de confiance : il faut faire confiance à une entreprise qui te donne une boîte noire dont tu ne sais rien de ce qu’elle fait. Et on a vu ce que ça donne au final : le code source fermé d’Apple iOS était peut-être sécurisé, mais il contenait des backdoors. Voilà pour la confiance.

Quand le code est Open Source, l’implémentation peut être plus ou moins bonne, il peut être sécurisé ou non. En revanche un code Open Source ne demande à personne de lui faire confiance : il peut être lu par tous, et plusieurs entreprises passent derrière les programmeurs pour vérifier le code source, l’améliorer, le patcher, etc. Ces entreprises ne s’en remettent pas aveuglément à la confiance : elles auditent et vérifient le code, parce qu’elles en ont besoin elles-mêmes et parce que la sécurité est cruciale pour leurs besoins.

Glyphe

Le 02/08/2014 à 10h16

Konrad a écrit :

(…)

Tu viens de résumer totalement ce que j’ai essayé de dire depuis le début. Enfin je ne pensais pas qu’il fallait rappeler que le closed source relevait d’un principe de confiance “aveugle” en la société qui développe l’application. Du coup mes premiers commentaires ont pu être pris pour du fanatisme, ce qui n’était en rien mon intention. Je voulais juste faire remarquer que dans le domaine de la sécurité, j’ai toujours trouvé “plus logique” de se baser sur de l’open-source correctement revu que sur du proprio même réputé.

snoopy1492

Le 31/07/2014 à 08h29

" /> pour le sous - titre.

Trop facile, peut mieux faire " />

anonyme_c81656a6914322f787aebc9dfc4d2ae4

Le 31/07/2014 à 08h30

Je vais probablement poser une question con mais comment un client A peut connaître l’adresse IP d’un client B sans serveur centralisé ?

jpaul

Le 31/07/2014 à 08h32

Nathan1138 a écrit :

Je vais probablement poser une question con mais comment un client A peut connaître l’adresse IP d’un client B sans serveur centralisé ?

Sûrement avec un système d’échange de pairs (et peut être un tracker pour bootstraper)?

aureus

Le 31/07/2014 à 08h33

jpaul a écrit :

Sûrement avec un système d’échange de pairs (et peut être un tracker pour bootstraper)?

Si tu pouvais être plus explicite pour les néophites ca m’interesse aussi " />

Par ce que si je me trompe pas c’est le gros problème actuelle des logiciels P2P, c’est qu’il nécessite tout de même un serveur, la donnée est en P2P, mais les métadonnées sont centralisés.

Soltek

Le 31/07/2014 à 08h34

Moi ce qui me choque dans ce truc c’est que les 2 qui conversent vont manger de la salade " />

Jarodd Abonné

Le 31/07/2014 à 08h34

Pré-alpha ça commence à faire, ça veut dire qu’ils ont juste designé l’appli et fait quelques slides de présentation ?

Sinon pour ce genre de communications, les outils commencent à se multiplier (merci Snowden). Perso j’ attends avec impatience que les solutions passant par WebRTC soient plus mûres.

Lady Komandeman

Le 31/07/2014 à 08h42

Soltek a écrit :

Moi ce qui me choque dans ce truc c’est que les 2 qui conversent vont manger de la salade " />

Logique, les libristes sont tous des Vegans ! " />

Qruby

Le 31/07/2014 à 10h23

Glyphe a écrit :

Ben en réalité il n’y a aucun besoin de business model pour les systèmes distribués étant donné qu’ils sont pour la toute frande majorité gratuit (et les meilleurs open-source). Et aucun besoin de ressources financières importantes étant donné qu’il n’y a pas d’infrastructure à administrer et entretenir, chaque utilisateur utilise sa propore infra.

C’est un changement radical de philosophie de technologies et d’utilisation qui se cache derrière ces systèmes. Avec leurs avantages et leurs inconvénients. :)

Il y a forcément un business model. Gratuit != “ya pas de business model”.

Il y a beaucoup d’entreprises qui font de l’open source, et qui arrivent pourtant à générer des revenues. Dans la vie, rien n’est gratuit, tu paye forcément ce que tu utilise à un moment ou un autre. C’est pas une histoire de philosophie, c’est une histoire de logique économique (en opposition à un comportement opportuniste).

Que le développeur code bénévolement ou non, ça ne change pas que derrière il y a un intérêt économique. Le business model n’est qu’une explicitation de cet intérêt. (et le business model peut très bien être “on donne le produit gratuitement”).

Glyphe

Le 31/07/2014 à 10h35

Qruby a écrit :

Il y a forcément un business model. Gratuit != “ya pas de business model”.

Il y a beaucoup d’entreprises qui font de l’open source, et qui arrivent pourtant à générer des revenues. Dans la vie, rien n’est gratuit, tu paye forcément ce que tu utilise à un moment ou un autre. C’est pas une histoire de philosophie, c’est une histoire de logique économique (en opposition à un comportement opportuniste).

Que le développeur code bénévolement ou non, ça ne change pas que derrière il y a un intérêt économique. Le business model n’est qu’une explicitation de cet intérêt. (et le business model peut très bien être “on donne le produit gratuitement”).

Il est IMPOSSIBLE de gagner de l’argent avec une application gratuite basée sur la sécurité. Vu que théoriquement pour pouvoir être qualifiée de sécurisée elle DOIT être open-source sinon la sécurité est basée sur l’obscurité et j’irai même jusqu’à dire du vent.

Donc il faudra que tu m’expliques comment ut fais du fric en sortant un produit gratuit, dont tout le monde peut répliquer ou changer le produit vu que les sources sont disponibles et dont le fonctionnement est p2p c’est à dire que je n’ai pas besoin d’autre matériel que le miens pour le faire fonctionner.

C’est d’ailleurs pour ça que les projets les plus aboutis actuellement dans ce domaine (et ça risque de ne pas être le cas de Bleep tellement il accumule les tares dès son lancement) sont tous gratuit, open-source et financés par des fonds d’investissements publics. Exemple : Cryptocat ou WhisperSystems ou Tor dans un autre domaine.

D’autres sont des projets non financés mais collaboratifs (donc souvent plus lents) comme Twister ou Bitmessage.

TZDZ

Le 31/07/2014 à 10h54

Glyphe a écrit :

Vu que théoriquement pour pouvoir être qualifiée de sécurisée elle DOIT être open-source sinon la sécurité est basée sur l’obscurité et j’irai même jusqu’à dire du vent.

Franchement ce point est discutable. Le consensus, c’est plutôt que l’algorithme doit être libre. Après les études montrent que c’est un peu mieux (exemple), mais la conclusion n’est pas absolue ou indiscutable comme ta phrase le laisse sous entendre.

Un autre point de vue.

La grosse erreur (qui ressemble à de la mauvaise foi), c’est de dire que la sécurité des codes propriétaires se base sur le fait qu’ils ne sont pas libres : c’est juste faux.

Qruby

Le 31/07/2014 à 10h57

Glyphe a écrit :

Il est IMPOSSIBLE de gagner de l’argent avec une application gratuite basée sur la sécurité. Vu que théoriquement pour pouvoir être qualifiée de sécurisée elle DOIT être open-source sinon la sécurité est basée sur l’obscurité et j’irai même jusqu’à dire du vent.

Donc il faudra que tu m’expliques comment ut fais du fric en sortant un produit gratuit, dont tout le monde peut répliquer ou changer le produit vu que les sources sont disponibles et dont le fonctionnement est p2p c’est à dire que je n’ai pas besoin d’autre matériel que le miens pour le faire fonctionner.

C’est d’ailleurs pour ça que les projets les plus aboutis actuellement dans ce domaine (et ça risque de ne pas être le cas de Bleep tellement il accumule les tares dès son lancement) sont tous gratuit, open-source et financés par des fonds d’investissements publics. Exemple : Cryptocat ou WhisperSystems ou Tor dans un autre domaine.

D’autres sont des projets non financés mais collaboratifs (donc souvent plus lents) comme Twister ou Bitmessage.

En faisant du support, en donnant des formations, en acceptant des donnations, en utilisant ce service pour un autre service (multi-sided), etc.

Glyphe

Le 31/07/2014 à 11h02

TZDZ a écrit :

La grosse erreur (qui ressemble à de la mauvaise foi), c’est de dire que la sécurité des codes propriétaires se base sur le fait qu’ils ne sont pas libres : c’est juste faux.

Tu me fais dire ce que je n’ai pas dit là, relis mon post, tu n’y verras jamais mention de libre. Je parle bien de code open source ! Et oui ces 2 choses sont différentes l’une de l’autre.

Sinon j’ai toujours du mal avec les gens qui, en se basant sur leur propre expérience comme dans ton article de zdnet, viennent t’expliquer que vu qu’il y a de mauvais software open source, le propriétaire n’est pas moins adapté pour la sécurité que l’open source … " />

TZDZ

Le 31/07/2014 à 11h04

Glyphe a écrit :

Tu me fais dire ce que je n’ai pas dit là, relis mon post, tu n’y verras jamais mention de libre. Je parle bien de code open source ! Et oui ces 2 choses sont différentes l’une de l’autre.

Sinon j’ai toujours du mal avec les gens qui, en se basant sur leur propre expérience comme dans ton article de zdnet, ils viennent t’expliquer que vu qu’il y a de mauvais software open source, le propriétaire n’est pas adapté pour la sécurité que l’open source … " />

Bah remplace libre par open source, mea culpa. Mais bon tant que ça t’évite à répondre au fond de mon commentaire…

Glyphe

Le 31/07/2014 à 11h16

J’ai répondu déjà plus haut sur le fond de ta remarque en réalité, c’est toi qui décide de l’ignorer ou de la prendre pour une remarque philosophique, ce qu’elle n’est pas, c’est totalement pratique.

Tu mets sur le même niveau une application dont tu dois faire confiance uniquement à celui qui la développe et de l’autre côté côté une dont tout le monde peut revoir le code source donc le fonctionnement.

Ca me semble assez logique que le fonctionnement de révision par des universitaires indépendants, des sociétés d’audit de code, des experts réputés dans leur domaine fonctionne mieux qu’un système basé sur la confiance dans une société privée, la plupart du temps à but lucratif, soumise à des lois territoriales qui peut lui imposer secrètement d’introduire du code arbitraire.

Je t’accorde que l’open source fonctionne correctement uniquement s’il y a full disclosure, c’est à dire que tous ces reviewers compétents parlent publiquement de ce qu’ils ont trouvé. Mais je reste d’avis qu’on ne peut certainement pas mettre le proprio et l’open source au même niveai dans le domaine de sécurité !

canti

Le 31/07/2014 à 11h35

Glyphe a écrit :

Par contre, je suis surpris qu’aucun article de presse, ni de réaction sur les réseaux sociaux, ne mentionne le fait que BitTorrent ne semble pas vouloir ouvrir les sources de son produit.

Ça reste selon moi toujours un problème quand on veut faire un produit soit-disant sécurisé …

Il faudra faire confiance à la société BitTorrent et c’est une très mauvaise façon de faire des outils basés sur la cryptographie.

tout a fait, c’est globalement ce qui me retiens de faire du pseudo cloud avec btsync, avec des données boulot :/

Lafisk

Le 31/07/2014 à 12h00

Glyphe a écrit :

Vu que théoriquement pour pouvoir être qualifiée de sécurisée elle DOIT être open-source sinon la sécurité est basée sur l’obscurité et j’irai même jusqu’à dire du vent.

Un truc securisee, c’est un truc qu’on arrive pas a casser, open source ou pas … mais rien n’est incassable eternellement

Glyphe

Le 31/07/2014 à 12h11

Lafisk a écrit :

Un truc securisee, c’est un truc qu’on arrive pas a casser, open source ou pas … mais rien n’est incassable eternellement

Il nous manquait un captain obvious sur cette discussion … C’est bon on l’a trouvé ! " />

guildem Abonné

Le 31/07/2014 à 12h19

ce genre de protocole P2P, avec lequel chaque client devient un noeud du réseau, c’est pas quelque chose qui peut consommer beaucoup de data (si jamais ça devient aussi utilisé qu’une messagerie facebook ou hangout par exemple) ?

car dans le cas du DHT, si j’ai bien compris, tu es connecté à quelques pairs, qui sont eux même connecté à quelques pairs, etc.. donc si tu fais une demande pour connaitre le chemin de ton correspondant, tu vas propager cette demande sur l’intégralité du réseau (même si je suppose qu’il y a forcément au moins un garde fou pour bloquer le renvoi d’une commande déjà passée). ça fait un nombre de demandes qui est décuplé en fonction de la taille du réseau, non ?

et avec un pair mal intentionné, n’y a-t-il pas moyen de pouvoir cartographier les clés publiques en écoutant ces demandes ?

Lafisk

Le 31/07/2014 à 12h23

Glyphe a écrit :

Il nous manquait un captain obvious sur cette discussion … C’est bon on l’a trouvé ! " />

Ben faut croire que c’etait pas si obvious pour toi … vu que tu dis et insistes lourdement sur le fait que ca DOIT etre open source … hors non proprio ou open source, si tu le casses pas c’est securise. Donc ta definition me parait franchement bancale

Glyphe

Le 31/07/2014 à 12h30

ça doit être open source parce que si les algos de chiffrement utilisés sont fiable ACTUELLEMENT (bien sur quand 30 ans le brute force sur du chiffrement actuel sera sûrement possible), l’implémentation de la crypto dans les sources du soft elle peut être totalement boguée. Et pour une soft comme Bleep ça permettrait de voir DES LE DÉPART que l’application n’est pas sécurisée ou contient du code qui ne devrait pas y être.

Faire un audit de sécurité sur un soft close source c’est totalement aléatoire, tu n’es jamais certain de trouver tout ce qui ne fonctionnerait pas correctement. le RE est beaucoup plus complique que de l’audit …

Khalev

Le 31/07/2014 à 15h03

Lafisk a écrit :

Ben faut croire que c’etait pas si obvious pour toi … vu que tu dis et insistes lourdement sur le fait que ca DOIT etre open source … hors non proprio ou open source, si tu le casses pas c’est securise. Donc ta definition me parait franchement bancale

C’est pas parce que tu le casses pas que c’est sécurisé. D’autres ont pu le casser sans que tu le saches. Où il est même possible qu’il n’y ait même pas besoin de casser la sécurité. Si celui qui possède les clés du logiciel fait n’importe quoi ce n’est plus sécurisé, pourtant la sécurité n’a pas été cassée.

matroska

Le 31/07/2014 à 15h04

Soltek a écrit :

Moi ce qui me choque dans ce truc c’est que les 2 qui conversent vont manger de la salade " />

" />

" />

TZDZ

Le 31/07/2014 à 19h25

Glyphe a écrit :

J’ai répondu déjà plus haut sur le fond de ta remarque en réalité, c’est toi qui décide de l’ignorer ou de la prendre pour une remarque philosophique, ce qu’elle n’est pas, c’est totalement pratique.

Tu mets sur le même niveau une application dont tu dois faire confiance uniquement à celui qui la développe et de l’autre côté côté une dont tout le monde peut revoir le code source donc le fonctionnement.

Encore faut-il qu’il y en ait qui le fassent. Une boîte d’informaticiens professionnels (qui peut faire appel à des audits de sécurité) ou bien l’éventualité d’un relecteur attentif… Je ne suis pas sûr de quel côté penche la balance. Toi tu relis le code source ou tu vérifies que des gens l’ont relu avant d’utiliser un programme ? Je ne sais pas pourquoi mais je parie que tu te dis “bah c’est libre s’il y avait une faille énorme dans le code des passionnés de relecture l’auront bien trouvé”. Un peu comme pour Openssl\heartbleed (faille qui aurait pu être trouvée grâce à la relecture du code ouvert… mais qui aurait été trouvée dans un code fermé de toute façon).

Glyphe a écrit :

Ca me semble assez logique que le fonctionnement de révision par des universitaires indépendants, des sociétés d’audit de code, des experts réputés dans leur domaine fonctionne mieux qu’un système basé sur la confiance dans une société privée, la plupart du temps à but lucratif, soumise à des lois territoriales qui peut lui imposer secrètement d’introduire du code arbitraire.

Aucun rapport. La boîte qui édite un logiciel open source est aussi à but lucratif (c’est toi qui me faisais la leçon sur libre/ouvert ? la bonne blague). Et tu peux très bien faire auditer ton code propriétaire (encore un argument de mauvaise foi). Le pire c’est que dans le fond je suis d’accord et je pense que l’ouverture est une bonne chose (cf. le rapport que je citais dans le message).

Glyphe a écrit :

Je t’accorde que l’open source fonctionne correctement uniquement s’il y a full disclosure, c’est à dire que tous ces reviewers compétents parlent publiquement de ce qu’ils ont trouvé. Mais je reste d’avis qu’on ne peut certainement pas mettre le proprio et l’open source au même niveai dans le domaine de sécurité !

Finalement c’est une histoire de confiance dans les deux cas. En gros les éditeurs de code proprio, on ne peut pas leur faire confiance ; par contre les personnes qui relisent du libre sont tous dignes de confiance (car le cas contraire tu reconnais que ça ne “fonctionne pas correctement”). Il n’y a pas un problème dans ton raisonnement ?

Qruby

Le 31/07/2014 à 08h45

Enfin une application qui utilise Internet " />

Minikea

Le 31/07/2014 à 08h46

Jarodd a écrit :

Pré-alpha ça commence à faire, ça veut dire qu’ils ont juste designé l’appli et fait quelques slides de présentation ?

Sinon pour ce genre de communications, les outils commencent à se multiplier (merci Snowden). Perso j’ attends avec impatience que les solutions passant par WebRTC soient plus mûres.

pré-Alpha, c’est le POC: ça marche, mais c’est moche et ça plante quand on fait un truc qu’on n’a pas prévu, c’est pas optimisé et bourré de failles…

chez EA, on appelle ça une version gold et on le vend 60€ la semaine suivante… " />

jpaul

Le 31/07/2014 à 08h50

aureus a écrit :

Si tu pouvais être plus explicite pour les néophites ca m’interesse aussi " />

Par ce que si je me trompe pas c’est le gros problème actuelle des logiciels P2P, c’est qu’il nécessite tout de même un serveur, la donnée est en P2P, mais les métadonnées sont centralisés.

Je n’en ai aucune idée, d’où le “sûrement”. J’imagine juste que cela utilise la techno BitTorrent et que la base de données d’utilisateurs est en fait un bête fichier fetché via BitTorrent ?

ColinMaudry Abonné

Le 31/07/2014 à 08h52

Jarodd a écrit :

Pré-alpha ça commence à faire, ça veut dire qu’ils ont juste designé l’appli et fait quelques slides de présentation ?

Sinon pour ce genre de communications, les outils commencent à se multiplier (merci Snowden). Perso j’ attends avec impatience que les solutions passant par WebRTC soient plus mûres.

Je trouve appear.in pas mal mûr, je l’utilise souvent. Sous Chrome (et ses dérivés) ou peut même partager son écran.

Bug

Le 31/07/2014 à 08h58

geekounet85 a écrit :

… chez EA, on appelle ça une version gold et on le vend 60€ la semaine suivante… " />

" /> pour tacle au niveau des genoux.

John Shaft

Le 31/07/2014 à 09h03

aureus a écrit :

Par ce que si je me trompe pas c’est le gros problème actuelle des logiciels P2P, c’est qu’il nécessite tout de même un serveur, la donnée est en P2P, mais les métadonnées sont centralisés.

On tend de plus à s’en passer grâce au DHT et la recherche locale de pairs sur BitTorrent " />

Glyphe

Le 31/07/2014 à 09h06

Nathan1138 a écrit :

Je vais probablement poser une question con mais comment un client A peut connaître l’adresse IP d’un client B sans serveur centralisé ?

En utilisant la technologie DHT déjà largement utilisée chez Bittorrent notamment dans µtorrent. Ça consiste à être en contact avec les peers les plus proches de toi pour demander des informations ou en envoyer, si jamais tu cherches quelqu’un qui n’est pas dans tes peers, l’info est propagée par les autres peers dans une chaîne qui fera aboutir ta demande à la bonne personne.

Pour être sur que tout ça est sécurisé Bleep se sert aussi du système de cryptographie à clé publique pour l’identification des peers, sur le réseau tu es donc identifié non pas comme une personne avec un compte (il n’y a pas de login) mais comme une clé publique. Ca marche en gros comme ça.

aureus

Le 31/07/2014 à 09h18

John Shaft a écrit :

On tend de plus à s’en passer grâce au DHT et la recherche locale de pairs sur BitTorrent " />

Glyphe a écrit :

En utilisant la technologie DHT déjà largement utilisée chez Bittorrent notamment dans µtorrent. Ça consiste à être en contact avec les peers les plus proches de toi pour demander des informations ou en envoyer, si jamais tu cherches quelqu’un qui n’est pas dans tes peers, l’info est propagée par les autres peers dans une chaîne qui fera aboutir ta demande à la bonne personne.

Pour être sur que tout ça est sécurisé Bleep se sert aussi du système de cryptographie à clé publique pour l’identification des peers, sur le réseau tu es donc identifié non pas comme une personne avec un compte (il n’y a pas de login) mais comme une clé publique. Ca marche en gros comme ça.

" />

GruntZ Abonné

Le 31/07/2014 à 09h20

Qruby a écrit :

Enfin une application qui utilise Internet " />

C’est effectivement la remarque que je me suis fait.

Il est plus que temps que les Serveurs Minitel à la Facebook et consorts trouvent des concurrents modernes.

Glyphe

Le 31/07/2014 à 09h36

Par contre, je suis surpris qu’aucun article de presse, ni de réaction sur les réseaux sociaux, ne mentionne le fait que BitTorrent ne semble pas vouloir ouvrir les sources de son produit.

Ça reste selon moi toujours un problème quand on veut faire un produit soit-disant sécurisé …

Il faudra faire confiance à la société BitTorrent et c’est une très mauvaise façon de faire des outils basés sur la cryptographie.

vermi Abonné

Le 31/07/2014 à 09h39

aureus a écrit :

Si tu pouvais être plus explicite pour les néophites ca m’interesse aussi " />

Par ce que si je me trompe pas c’est le gros problème actuelle des logiciels P2P, c’est qu’il nécessite tout de même un serveur, la donnée est en P2P, mais les métadonnées sont centralisés.

Bittorrent utilise DTH pour trouver les informations et communiquer. DHT = Distributed Hast Table. En gros, c’est une base de données publique et distribuée sur le réseau. Tout le monde peut écrire et lire dedans.

Pour se connecter la première fois, un client bittorrent utilise les noeuds router.bittorrent.com et router.utorrent.com, qui lui donnent les adresses d’autres clients. Par la suite, le client se connecte aux nouvelles adresses IP qu’il a enregistré :)

Crazy Diver

Le 31/07/2014 à 09h39

Quel est la différence avec TOX, hormis la renommé de Bittorrent ?

Qruby

Le 31/07/2014 à 09h47

GruntZ a écrit :

C’est effectivement la remarque que je me suis fait.

Il est plus que temps que les Serveurs Minitel à la Facebook et consorts trouvent des concurrents modernes.

Ce qui est dommage c’est que cela arrive trop tard. Les principales raisons sont la difficulté de trouver un business model pour les entreprises développant des logiciels massivement P2P, et la performance des abonnements Internet utilisateurs.

Glyphe

Le 31/07/2014 à 09h56

Qruby a écrit :

Ce qui est dommage c’est que cela arrive trop tard. Les principales raisons sont la difficulté de trouver un business model pour les entreprises développant des logiciels massivement P2P, et la performance des abonnements Internet utilisateurs.

Ben en réalité il n’y a aucun besoin de business model pour les systèmes distribués étant donné qu’ils sont pour la toute frande majorité gratuit (et les meilleurs open-source). Et aucun besoin de ressources financières importantes étant donné qu’il n’y a pas d’infrastructure à administrer et entretenir, chaque utilisateur utilise sa propore infra.

C’est un changement radical de philosophie de technologies et d’utilisation qui se cache derrière ces systèmes. Avec leurs avantages et leurs inconvénients. :)

Flo_1

Le 31/07/2014 à 10h09

Crazy Diver a écrit :

Quel est la différence avec TOX, hormis la renommé de Bittorrent ?

Tox est libre, ce qui est un peu l’une des conditions essentielles pour un outil de chiffrement

billos35

Le 31/07/2014 à 10h12

aureus a écrit :

Si tu pouvais être plus explicite pour les néophites ca m’interesse aussi " />

Par ce que si je me trompe pas c’est le gros problème actuelle des logiciels P2P, c’est qu’il nécessite tout de même un serveur, la donnée est en P2P, mais les métadonnées sont centralisés.

Des outils existent pour se passer de serveur central.

DHT : Wikipedia

Lafisk

Le 01/08/2014 à 08h53

Khalev a écrit :

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

Lafisk

Le 01/08/2014 à 08h55

Mihashi a écrit :

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.

" />

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 …

Mihashi Abonné

Le 01/08/2014 à 08h59

Lafisk a écrit :

" />

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 …

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.

Lafisk

Le 01/08/2014 à 09h05

Mihashi a écrit :

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

Mihashi Abonné

Le 01/08/2014 à 09h10

Lafisk a écrit :

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

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.

Lafisk

Le 01/08/2014 à 09h16

Mihashi a écrit :

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

TZDZ

Le 01/08/2014 à 09h17

Mihashi a écrit :

Ça aussi c’est faux, indépendant ça ne veut pas dire isolé. Un universitaire est indépendant généralement, et c’est pas un gus dans son garage, y a tout un labo derrière.

J’ai une mauvaise nouvelle pour toi : un universitaire n’est pas indépendant… Et je dis ça en ayant une thèse, fils de prof, époux de prof, je pense avoir un aperçu relativement significatif de comment se passent les projets université/privé. Tu penses que les faibles sources de revenu public des labos sont là pour qu’ils fassent des audits pour le privé ?? Il n’est pas plus indépendant que des acteurs privés de la sécurité. Les labos universitaires sont sur le même créneau que des entreprises pour les prestations.

Pour la qualité de la doc, admettons.

Khalev a écrit :

Blabla

Tout à fait d’accord.

Khalev

Le 01/08/2014 à 09h21

Lafisk a écrit :

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

Tu peux aussi exiger de faire des audits chez le dev externes. Audit des process et demande des rapports de suivi.

C’est ce qui est le plus utilisé dans les secteurs où je bosse. (Déjà que juste pour faire de la validation sur le projet sans avoir accès au code source il faut l’accord du ministère de l’intérieur " /> alors donner l’accès au code source à des auditeurs externes j’y crois pas trop).

Après je trouve qu’un peu plus de rigueur dans les audits serait la bienvenue parce qu’à chaque fois on rajoute de la qualité en interne parce qu’on trouve que ça manque de traça & co et les auditeurs sont surpris qu’on rajoute des trucs comme ça…

Un exemple tout con, le fait de rajouter une étape de relecture des nouveaux tests par quelqu’un d’expérimenté : il a fallu expliquer à l’auditeur l’intérêt du truc /facepalm

Konrad

Le 01/08/2014 à 09h22

Lafisk a écrit :

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 …

90%, srlsy ? Source ? " />

C’est un peu une lapalissade de dire que les codes non relus sont moins sécurisés que les codes relus. Ça n’a effectivement rien à voir avec le fait qu’un code soit Open Source ou pas.

Maintenant, si on veut comparer Open et Closed Source, ça ne sert à rien de comparer un mauvais logiciel Open Source pas audité, avec un logiciel Closed Source super surveillé. Ça serait évidemment biaisé. On ne peut comparer que des tendances et des comportements globaux.

Cette étude montre que quand une vulnérabilité est connue, elle est patchée beaucoup plus rapidement (-137%). Ceci est vrai aussi bien pour les codes Open et Closed Source.

Ensuite, les logiciels Open Source ont tous une politique de full-disclosure : quand une vulnérabilité est connue, elle est publiée et visible de tous. Ceci appelle donc à un patch rapide. Ça a été le cas de la faille Heart Bleed (corrigée dans les 48h), c’est le cas de toutes les vulnérabilités découvertes dans le noyau Linux, etc.

La plupart des logiciels Closed Source, au contraire, ne divulguent pas leurs failles quand l’éditeur en a connaissance. Sécurité par l’obscurité : l’éditeur parie sur le fait qu’il est le seul à connaître la faille, et donc qu’il a du temps pour la corriger. Les logiciels Closed Source mettent donc plus de temps à être patchés. Voir par exemple cette étude qui montre que les vulnérabilités dans Firefox sont corrigées beaucoup plus rapidement que dans Internet Explorer.

Voilà pour les failles. Maintenant, parlons des backdoors. On sait que certains éditeurs de logiciels Closed Source incluent des backdoors dans leurs produits. Du côté de Microsoft on se souvient de la NSAKEY, du côté de Apple cela a été révélé récemment. Il n’y a pas de spéculation, ce sont des faits avérés. Ce sont des raisons solides pour douter de tous les logiciels propriétaires.

A-t-on trouvé la moindre backdoor avérée dans un produit Open Source ? Non. Donc tu peux aussi douter et dire que, si ça se trouve, il y en a, mais ces doutes ne s’appuient sur rien de concret. Je dirais même, au contraire : le code de beaucoup de logiciels libres (Linux, Firefox…) est utilisé et relu par des gens de beaucoup de pays (contributeurs, sociétés comme Canonical ou Suse qui développent leur propre distrib GNU/Linux, etc.). La Chine par exemple développe sa propre distribution GNU/Linux, et pour cela ils vérifient et modifient pas mal de logiciels libres. Si tous ces gens-là trouvaient la moindre backdoor dans un logiciel libre, ils cracheraient sûrement dessus face au monde entier. Cela n’est jamais arrivé.

Il reste l’argument «une simple faille peut en fait être une backdoor mise volontairement par un développeur». Sauf qu’encore une fois, magie du libre, les contributions ne sont pas anonymes, et il est possible de remonter à la personne qui a introduit ou modifié un bout de code particulier. Pour la faille Heart Bleed, on sait quand et par qui elle a été introduite, et on sait que ça a été une erreur, et non une backdoor introduite volontairement. Dans un logiciel propriétaire, même après la découverte et le patchage d’une faille, impossible de savoir quand et par qui elle a été introduite, ni si ça a été fait volontairement ou non…

En conclusion : oui, il faut rester vigilant, et «Open Source» ne veut pas systématiquement dire «sécurisé». Il faut des audits, il faut des gens qui patchent le code très vite quand une vulnérabilité est découverte. Mais ce n’est pas usurpé d’affirmer que, en moyenne, les codes Open Source sont plus sûrs que les codes propriétaires.

TZDZ

Le 01/08/2014 à 09h24

Mihashi a écrit :

D’un coté, t’as un logiciel pour qui tu doit faire confiance à une seule personne qui a des intérêts dedans.

Mais pourquoi un code fermé ne pourrait pas être relu par des personnes externes ?

Pourquoi des devs open-source publieraient-ils forcément les revues externes de leur travail ? Ils sont aussi dépendant de leur chiffre d’affaire que les autres…

TZDZ

Le 01/08/2014 à 09h31

Konrad a écrit :

En conclusion : oui, il faut rester vigilant, et «Open Source» ne veut pas systématiquement dire «sécurisé». Il faut des audits, il faut des gens qui patchent le code très vite quand une vulnérabilité est découverte. Mais ce n’est pas usurpé d’affirmer que, en moyenne, les codes Open Source sont plus sûrs que les codes propriétaires.

Je suis d’accord avec la conclusion, à laquelle j’ajouterais “code fermé ne veut pas dire systématiquement “incompatible avec sécurité”“.

Mihashi Abonné

Le 01/08/2014 à 09h33

TZDZ a écrit :

Mais pourquoi un code fermé ne pourrait pas être relu par des personnes externes ?

Pourquoi des devs open-source publieraient-ils forcément les revues externes de leur travail ? Ils sont aussi dépendant de leur chiffre d’affaire que les autres…

Je compte les revues externe commandées par le développeur au même titre qu’une revue interne : il faut faire confiance à une seule personne choisie par le développeur, avec tous les intérêts qui en découlent.

Konrad

Le 01/08/2014 à 09h36

TZDZ a écrit :

Je suis d’accord avec la conclusion, à laquelle j’ajouterais “code fermé ne veut pas dire systématiquement “incompatible avec sécurité”“.

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.

Mihashi Abonné

Le 01/08/2014 à 09h40

Konrad a écrit :

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.

Et même sans parler des failles et de leur correction.

Quand on dit qu’un code fermé n’est pas sécuritaire, on veut pas dire qu’il est plein de failles ou de backdoors, mais juste qu’on ne peut pas soi-même vérifier qu’il n’y en ait pas.

Tu auras beau développer le meilleur algorithme qui soit, si tu ne peux pas me prouver que c’est le meilleur, je ne pourrais pas considérer qu’il l’est.

Lafisk

Le 01/08/2014 à 09h42

Konrad a écrit :

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 ?

Konrad

Le 01/08/2014 à 09h51

TZDZ a écrit :

Mais pourquoi un code fermé ne pourrait pas être relu par des personnes externes ?

Pourquoi des devs open-source publieraient-ils forcément les revues externes de leur travail ? Ils sont aussi dépendant de leur chiffre d’affaire que les autres…

Dans le cas d’un code fermé, un reviewer externe aura des obligations similaires aux développeurs internes : interdiction de dévoiler le code source, interdiction de parler des failles potentiellement découverte, interdiction de parler des processus de développement…

Encore une fois, l’immense majorité des projets Open Source ont pour politique d’avoir un développement ouvert (l’ensemble de l’historique est disponible, par ex. sur GitHub ou autre), et de rendre les failles publiques quand elles sont découvertes. Il n’y a pas vraiment de frontière entre un développeur ou reviewer interne ou externe : n’importe qui peut relire le code source et le critiquer.

Tiens, si Microsoft veut vraiment démonter Linux ou Firefox, ils peuvent payer un développeur pour trouver des vulnérabilités dans le code. Apple de son côté, utilise beaucoup de logiciels libres (Mac OS X est basé sur UNIX/Free BSD, et inclut beaucoup de logiciels GNU). Google aussi (Android…). Toutes ces entreprises sont aussi bien des reviewers externes, que des développeurs pour leurs propres besoins. Il n’y a aucun modèle équivalent dans le monde du proprio.

Lafisk a écrit :

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 ?

Je suis un scientifique, les chiffres à la louche j’ai pas trop confiance " />

Des chiffres à la louche, n’importe qui peut en donner : IE est 30 fois plus vulnérable que Firefox, 60% des développeurs de logiciels propriétaires sont des branques… Ça ne fait pas du tout avancer le débat, ça ne fait que troller.

Mihashi Abonné

Le 31/07/2014 à 19h49

TZDZ a écrit :

Encore faut-il qu’il y en ait qui le fassent. Une boîte d’informaticiens professionnels (qui peut faire appel à des audits de sécurité) ou bien l’éventualité d’un relecteur attentif… Je ne suis pas sûr de quel côté penche la balance. Toi tu relis le code source ou tu vérifies que des gens l’ont relu avant d’utiliser un programme ? Je ne sais pas pourquoi mais je parie que tu te dis “bah c’est libre s’il y avait une faille énorme dans le code des passionnés de relecture l’auront bien trouvé”. Un peu comme pour Openssl\heartbleed (faille qui aurait pu être trouvée grâce à la relecture du code ouvert… mais qui aurait été trouvée dans un code fermé de toute façon).

Le but c’est pas d’être sûr que quelqu’un a relu le code (même si ça serait mieux). Mais la grosse différence entre les deux approches c’est que dans un cas tu peux être es sûr que personne d’autre n’a relu le code.

TZDZ a écrit :

Finalement c’est une histoire de confiance dans les deux cas. En gros les éditeurs de code proprio, on ne peut pas leur faire confiance ; par contre les personnes qui relisent du libre sont tous dignes de confiance (car le cas contraire tu reconnais que ça ne “fonctionne pas correctement”). Il n’y a pas un problème dans ton raisonnement ?

Je ne fait pas confiance à quelqu’un qui essaye de me vendre quelque chose, c’est un principe de base.

Par contre, je ferais plus confiance à quelqu’un d’indépendant, qui n’a pas de parti pris.

TZDZ

Le 31/07/2014 à 20h06

Mihashi a écrit :

Je ne fait pas confiance à quelqu’un qui essaye de me vendre quelque chose, c’est un principe de base.

Par contre, je ferais plus confiance à quelqu’un d’indépendant, qui n’a pas de parti pris.

Mais comment fais tu dans ta vie de tous les jours ? Tu te fies aux commentaires en ligne, ou bien aux datasheet constructeurs ?

As-tu un exemple concret d’un logiciel dont tu as vérifié qu’il avait été vérifié intégralement par quelqu’un à la fois indépendant (de qui ? il gagne son pain d’une façon ou d’une autre) et compétant ? Je ne sais pas comment vous pouvez imaginer qu’il y a des gens pour relire la plupart des codes ouverts bénévolement (= indépendance…). Et dieu sait qu’une relecture est loin de suffire… On voit bien que ça n’est pas le cas et que des lignes parasites sont introduites parfois à l’insu de tout le monde…

Finalement c’est une position d’utilisateur lambda (comme moi). On nous a dit que c’était mieux, donné quelques arguments convaincants, mais concrètement on délègue la partie chiante aux autres en espérant qu’ils se dévouent. Tu fais plus confiance à un relecteur imaginaire qu’à une boîte vendant de la sécurité et qui perdrait potentiellement des clients en étant inefficace… Mouais.

Mihashi Abonné

Le 31/07/2014 à 20h35

TZDZ a écrit :

Mais comment fais tu dans ta vie de tous les jours ? Tu te fies aux commentaires en ligne, ou bien aux datasheet constructeurs ?

As-tu un exemple concret d’un logiciel dont tu as vérifié qu’il avait été vérifié intégralement par quelqu’un à la fois indépendant (de qui ? il gagne son pain d’une façon ou d’une autre) et compétant ? Je ne sais pas comment vous pouvez imaginer qu’il y a des gens pour relire la plupart des codes ouverts bénévolement (= indépendance…). Et dieu sait qu’une relecture est loin de suffire… On voit bien que ça n’est pas le cas et que des lignes parasites sont introduites parfois à l’insu de tout le monde…

Finalement c’est une position d’utilisateur lambda (comme moi). On nous a dit que c’était mieux, donné quelques arguments convaincants, mais concrètement on délègue la partie chiante aux autres en espérant qu’ils se dévouent. Tu fais plus confiance à un relecteur imaginaire qu’à une boîte vendant de la sécurité et qui perdrait potentiellement des clients en étant inefficace… Mouais.

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.

Lafisk

Le 31/07/2014 à 20h46

Mihashi a écrit :

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…

Konrad

Le 31/07/2014 à 22h11

TZDZ a écrit :

As-tu un exemple concret d’un logiciel dont tu as vérifié qu’il avait été vérifié intégralement par quelqu’un à la fois indépendant (de qui ? il gagne son pain d’une façon ou d’une autre) et compétant ? Je ne sais pas comment vous pouvez imaginer qu’il y a des gens pour relire la plupart des codes ouverts bénévolement (= indépendance…). Et dieu sait qu’une relecture est loin de suffire… On voit bien que ça n’est pas le cas et que des lignes parasites sont introduites parfois à l’insu de tout le monde…

Finalement c’est une position d’utilisateur lambda (comme moi). On nous a dit que c’était mieux, donné quelques arguments convaincants, mais concrètement on délègue la partie chiante aux autres en espérant qu’ils se dévouent. Tu fais plus confiance à un relecteur imaginaire qu’à une boîte vendant de la sécurité et qui perdrait potentiellement des clients en étant inefficace… Mouais.

Lafisk a écrit :

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…

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… " />

Mihashi Abonné

Le 31/07/2014 à 22h48

Konrad a écrit :

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… " />

J’allais dire exactement la même chose, merci " />

wawadou

Le 31/07/2014 à 23h36

geekounet85 a écrit :

pré-Alpha, c’est le POC: ça marche, mais c’est moche et ça plante quand on fait un truc qu’on n’a pas prévu, c’est pas optimisé et bourré de failles…

chez EA, on appelle ça une version gold et on le vend 60€ la semaine suivante… " />

" /> " />

Glyphe

Le 31/07/2014 à 23h40

TZDZ a écrit :

Toi tu relis le code source ou tu vérifies que des gens l’ont relu avant d’utiliser un programme ? Je ne sais pas pourquoi mais je parie que tu te dis “bah c’est libre s’il y avait une faille énorme dans le code des passionnés de relecture l’auront bien trouvé”.

En gros les éditeurs de code proprio, on ne peut pas leur faire confiance ; par contre les personnes qui relisent du libre sont tous dignes de confiance (car le cas contraire tu reconnais que ça ne “fonctionne pas correctement”). Il n’y a pas un problème dans ton raisonnement ?

Non il y a un problème dans ta façon d’interpréter les choses que je dis et sur ce que tu projettes de moi …

Premièrement je relis pas mal de code sur des projets open source sur Github, donc tes supputations sur la personne qui parle en face de toi sans la connaître montre surtout que sur le fond, tu n’as pas grand chose à dire. Toute ta réponse tourne à propos de ce que tu crois que je dis, en tapant la plupart du temps à côté de la plaque …

babolivier

Le 01/08/2014 à 01h06

Pour le moment, Bleep n’est disponible qu’en version pré-alpha et sur invitation uniquement.

Ouais, fin, si on va sur la page de Bleep, y’a moyen de le télécharger et de l’utiliser sans invitation (je viens de le faire, j’ai le programme lancé et connecté sous les yeux) " />

TZDZ

Le 01/08/2014 à 07h20

Konrad a écrit :

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… " />

Je n’ai jamais cru ça. Relis ce à quoi je répondais précisément (le gus dans son garage c’était pour, je cite, “l’indépendance”, car s’il est employé il n’est plus indépendant donc non fiable selon le commentaire auquel je répondais). De plus, la question c’était “est-ce que le code ouvert est intrinsèquement plus sûr que le fermé”. Bah la réponse c’est que dans un cas où dans l’autre il faut de la main d’œuvre derrière pour vérifier.

Pour le moment, le seul argument qu’apporte le libre c’est la possibilité de relecture par n’importe qui.

Lafisk

Le 01/08/2014 à 08h15

Konrad a écrit :

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 …

fitfat

Le 01/08/2014 à 08h27

TZDZ a écrit :

Pour le moment, le seul argument qu’apporte le libre c’est la possibilité de relecture par n’importe qui.

C’est un peu comme les urnes transparentes. Ca garantie pas qu’il y a pas de fraude mais ça permet à chacun de se rendre compte qu’il y en a pas eu.

Mihashi Abonné

Le 01/08/2014 à 08h33

TZDZ a écrit :

Je n’ai jamais cru ça. Relis ce à quoi je répondais précisément (le gus dans son garage c’était pour, je cite, “l’indépendance”, car s’il est employé il n’est plus indépendant donc non fiable selon le commentaire auquel je répondais). De plus, la question c’était “est-ce que le code ouvert est intrinsèquement plus sûr que le fermé”. Bah la réponse c’est que dans un cas où dans l’autre il faut de la main d’œuvre derrière pour vérifier.

Pour le moment, le seul argument qu’apporte le libre c’est la possibilité de relecture par n’importe qui.

Ça aussi c’est faux, indépendant ça ne veut pas dire isolé. Un universitaire est indépendant généralement, et c’est pas un gus dans son garage, y a tout un labo derrière.

Bah oui, c’est ça la différence, et elle est énorme.

D’un coté, t’as un logiciel pour qui tu doit faire confiance à une seule personne qui a des intérêts dedans.

De l’autre, un logiciel que n’importe qui peut relire, dont toi-même (ou quelqu’un que tu engages) si tu as besoin d’une sécurité poussée.

C’est le jour et la nuit.

Et ça se voit aussi dans l’écriture du code.

Le code ouvert est généralement bien écrit et commenté, car les devs savent qu’ils vont/peuvent être relus et critiqués.

Alors que pour le code fermé, on a des retours comme quoi c’est pas glorieux souvent…

Lafisk a écrit :

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 avec un code fermé, tu ne peux pas le faire relire ! C’est ce qu’on lui reproche.

Lafisk

Le 01/08/2014 à 08h44

Mihashi a écrit :

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

Khalev

Le 01/08/2014 à 08h45

Lafisk a écrit :

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

Là vous ne parlez pas de closed ou d’open source mais de la structure derrière.

Tu prends Linux, t’as toute la structure qui va bien pour vérifier les non-régressions, l’intégration de nouveaux trucs dans le noyau est bien documentée et structurée, tout ça est géré par la communauté et des entreprises, etc.

Tu prends openssl c’était l’inverse, 3 gus plus ou moins “de confiance” pas de relecture, pas de test suite, etc. Et d’autres projets sont encore pire que ça.

Mais au final c’est pareil dans le mode du closed-source. T’as des boites qui font des trucs propres avec des process clairs, vérifiés et revérifiés et d’autres qui font n’importe quoi en sortant des trucs à l’arrache et en by-passant certaines étapes par manque de ressources ou de rigueur.

Un exemple tout con, j’ai bossé dans 2 boites où je faisais du SIL3-SIL4 Wikipedia dans l’une tout ce que je faisais était tracé automatiquement et il y avait au minimum 2 relectures par 2 personnes différentes sur ce que j’avais fait (et je me prenais des remarques jusque sur mes commentaires).

Dans l’autre boite, je bossais sur le même type de système et c’est moi qui ait mis en place les process de détections des modifications (parce que de toute façon un système de versionning ça sert à rien…) et de traçabilité des relectures, mais avant ça il a fallut que je les convaincs de l’intérêt de faire des relectures, surtout quand on a 90% de nouveaux venus sur un projet.

Du coup la question à se poser niveau confiance est plutôt : ai-je confiance dans la structure derrière? leurs process sont-ils clairement identifiés et détaillés? Puis-ja m’assurer qu’ils sont respectés?

Et ça, ça vaut aussi bien pour le closed-source que l’open-source.

Mihashi Abonné

Le 01/08/2014 à 08h51

Lafisk a écrit :

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

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.

Catégories

Nous Suivre

À propos

BitTorrent dévoile Bleep : une messagerie chiffrée, sans serveur central

Biiiiiiiiiiip

Commentaires (75)