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

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

Biiiiiiiiiiip

Avatar de l'auteur
Sébastien Gavois

Publié dans

Logiciel

31/07/2014 2 minutes
75

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

BitTorrent vient de présenter Bleep, une messagerie instantanée qui ne nécessite pas l'utilisation d'un serveur central pour fonctionner et qui chiffre les conversations de bout en bout. Pour le moment, elle n'est disponible qu'en pré-alpha, sur invitation et  sur Windows uniquement, mais d'autres plateformes suivront par la suite.

Bleep BitTorrent

 

Plus ou moins régulièrement, BitTorrent dévoile de nouveaux produits exploitant le Peer-to-Peer. C'est par exemple le cas de Sync, un client de synchronisation pour vos données qui ne nécessite pas de serveur central, contrairement à des solutions comme Dropbox, Google Drive, OneDrive, etc.

 

La société continue sur sa lancée et présente aujourd'hui une messagerie fonctionnant sur la même idée, c'est-à-dire de manière décentralisée : Bleep. Pour rappel, ce n'est pas la première fois que BitTorrent se lance dans ce genre de projet puisqu'on a déjà eu Chat par le passé. Cette fois-ci, il n'est par contre pas question uniquement de messages texte, mais aussi d'appels audio, à la manière de ce que propose Skype par exemple.

 

Sur son blog, la société explique que « les messageries reposent actuellement toutes sur des serveurs centraux. Ces dépôts de métadonnées sont une cible de choix pour la surveillance des organismes gouvernementaux et des pirates ». BitTorrent ajoute ensuite que sa messagerie dispose de plusieurs atouts : elle ne stocke aucune métadonnée (qui communique avec qui, quand, etc.), y compris de manière temporaire, et tous les échanges sont chiffrés de bout en bout.

 

De plus, pour s'identifier, il est possible d'utiliser un numéro de téléphone, une adresse mail ou tout simplement en étant « incognito ». Des arguments qui devraient faire mouche auprès de certains à l'heure des révélations d'Edward Snowden. Il faudra par contre voir comment on peut s'assurer que la personne en face de nous soit bien celle que l'on attendait, un point qui était parfois problématique avec Cryptocat, sauf à passer par les conversations privées de Facebook par exemple. Comme pour BitTorrent Sync, certains regretterons surement que Bleep ne soit pas open source.

 

Bleep BitTorrent

 

Pour le moment, Bleep n'est disponible qu'en version pré-alpha et sur invitation uniquement. Vous pouvez d'ailleurs vous inscrire par ici. Pour l'instant, seuls Windows 7 et 8 sont supportés, mais d'autres plateformes arriveront prochainement, y compris sur mobile évidemment.

Écrit par Sébastien Gavois

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Fermer

Commentaires (75)


<img data-src=" /> pour le sous - titre.

Trop facile, peut mieux faire <img data-src=" />


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








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









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 <img data-src=" />



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.



Moi ce qui me choque dans ce truc c’est que les 2 qui conversent vont manger de la salade <img data-src=" />


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.








Soltek a écrit :



Moi ce qui me choque dans ce truc c’est que les 2 qui conversent vont manger de la salade <img data-src=" />





Logique, les libristes sont tous des Vegans ! <img data-src=" />



Enfin une application qui utilise Internet <img data-src=" />








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… <img data-src=" />









aureus a écrit :



Si tu pouvais être plus explicite pour les néophites ca m’interesse aussi <img data-src=" />



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 ?









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.









geekounet85 a écrit :



… chez EA, on appelle ça une version gold et on le vend 60€ la semaine suivante… <img data-src=" />





<img data-src=" /> pour tacle au niveau des genoux.









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 <img data-src=" />









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.









John Shaft a écrit :



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









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.





<img data-src=" />









Qruby a écrit :



Enfin une application qui utilise Internet <img data-src=" />



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.



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.








aureus a écrit :



Si tu pouvais être plus explicite pour les néophites ca m’interesse aussi <img data-src=" />



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é :)



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








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.









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. :)









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









aureus a écrit :



Si tu pouvais être plus explicite pour les néophites ca m’interesse aussi <img data-src=" />



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 :http://fr.wikipedia.org/wiki/Table_de_hachage_distribu%C3%A9e









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”).









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.









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.









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.









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 … <img data-src=" />









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 … <img data-src=" />





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



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








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









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









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é ! <img data-src=" />



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 ?








Glyphe a écrit :



Il nous manquait un captain obvious sur cette discussion … C’est bon on l’a trouvé ! <img data-src=" />







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



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








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.









Soltek a écrit :



Moi ce qui me choque dans ce truc c’est que les 2 qui conversent vont manger de la salade <img data-src=" />







<img data-src=" />



<img data-src=" />









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 ?









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.









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.









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.









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…









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… <img data-src=" />









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… <img data-src=" />





J’allais dire exactement la même chose, merci <img data-src=" />









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… <img data-src=" />









<img data-src=" /> <img data-src=" />









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 …






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) <img data-src=" />








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… <img data-src=" />





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.









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… <img data-src=" />





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 …









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.









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.









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 <img data-src=" />









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 https://en.wikipedia.org/wiki/Safety_Integrity_Level), 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.









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 <img data-src=" />





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.









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









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.





<img data-src=" />

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 …









Lafisk a écrit :



<img data-src=" />

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.









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









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.









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









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.









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 <img data-src=" /> 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









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 ? <img data-src=" />



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.









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…









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









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.









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 <img data-src=" />



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.









Konrad a écrit :



Tout à fait <img data-src=" />



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.









Konrad a écrit :



Tout à fait <img data-src=" />



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 ?









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 <img data-src=" />



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.









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.









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









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 <img data-src=" /> 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.









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