le logiciel libre n'est pas intrinsèquement plus sur en tant que code, mais par l'ouverture des sources, il permet de créer un mécanisme dynamique de révision (dans la meme logique que celle des cercles scientifiques), qui le rend statistiquement moins vulnérable, résumé par la "lois de Linus" selon laquelle : given enough eyeballs all bugs are shallow (s'il y assez de pairs d'yeux ,alors tous les bugs deviennent évident)
Ce mécanisme n'est vrai que s'il y a effectivement assez de personne pour un projet donnée, et qui effectivement ont les compétences techniques nécessaires , ainsi que le temps et la volonté pour s'investir dans cette révision.
Je rappelle le proof of concept par l'un des père d'Unix nommé le Ken Thompson Hack qui se pose la question de la manière de s'assurer que son propre code source lors de la compilation ne va pas etre vérolé par un compilateur qui contiendrait un mécanisme d'ajout de code malveillant tiers , tout en étant invisible dans le code source du compilateur en tant que tel.
>
Ken describes how he injected a virus into a compiler. Not only did his compiler know it was compiling the login function and inject a backdoor, but it also knew when it was compiling itself and injected the backdoor generator into the compiler it was creating. The source code for the compiler thereafter contains no evidence of either virus.
Au final, Ken en tire plusieurs conclusion, dont le fait qu'on ne peut jamais etre sur à 100 % d'un code que l'on a pas soi meme écrit, étant donnée que l'on dépend forcément d'un niveau précédent d'un niveau plus bas (niveau de l'assembleur par exemple-), l'on ne peut jamais etre sur réellement, à moin de pouvoir remonter toutes la chaine soi meme. En outre, plus le code malveillant se trouve dans des niveaux bas, plus il est difficile de le détecter.
On peut en faire un parallèle par rapport à la probatio diabolica en droit privé, qui nécessite de remonter toute la chaine des propriétaires pour s'assurer qu'on détient une propriété légitime.
Il est évident que lors d'utilisation de logiciel non libre, étant donnée que l'accès au code source est interdit, le risque d'une attaque (via un bug ou autre) est augmenté de manière drastique. L'on ne se remet qu'au bon vouloir de l'auteur sans aucune garantie quelconque.
Je précise que mon but (contrairement à l'appel du journal) n'est pas de lancer des trolls (il y en a assez sur internet qui gaspille la bande passante et l'énergie de ses usagers).
Plusieurs articles fesait état lors de la diffusion d'android sur certains appareil de backdoor et meme de trojan.
Il nous faudrait plus de détails pour pouvoir évaluer clairement ou se situait le problème (est ce dans des parties propriétaires ou libre ? ) ainsi que le type de mécanisme et le comportement réellement adopté.
Sinon , il faudrait rappeler les fait de la NSA KEY inclus dans la base de régistre de Microsoft Windows, ainsi que l'affaire cryptome qui avait fait leaker les documents par rapport à l'architecture d'enregistrement et d'accès au réseaux msn (enregistrement des conversations, accès à certains services de sécurité gouvernmentaux ).
# En fait ...
Posté par eastwind☯ . En réponse au journal Actualité geek-libriste d'été : licencisme libriste chez Disney. Évalué à 10. Dernière modification le 20 août 2012 à 16:36.
le logiciel libre n'est pas intrinsèquement plus sur en tant que code, mais par l'ouverture des sources, il permet de créer un mécanisme dynamique de révision (dans la meme logique que celle des cercles scientifiques), qui le rend statistiquement moins vulnérable, résumé par la "lois de Linus" selon laquelle : given enough eyeballs all bugs are shallow (s'il y assez de pairs d'yeux ,alors tous les bugs deviennent évident)
Ce mécanisme n'est vrai que s'il y a effectivement assez de personne pour un projet donnée, et qui effectivement ont les compétences techniques nécessaires , ainsi que le temps et la volonté pour s'investir dans cette révision.
Je rappelle le proof of concept par l'un des père d'Unix nommé le Ken Thompson Hack qui se pose la question de la manière de s'assurer que son propre code source lors de la compilation ne va pas etre vérolé par un compilateur qui contiendrait un mécanisme d'ajout de code malveillant tiers , tout en étant invisible dans le code source du compilateur en tant que tel.
>
Ken describes how he injected a virus into a compiler. Not only did his compiler know it was compiling the login function and inject a backdoor, but it also knew when it was compiling itself and injected the backdoor generator into the compiler it was creating. The source code for the compiler thereafter contains no evidence of either virus.
Au final, Ken en tire plusieurs conclusion, dont le fait qu'on ne peut jamais etre sur à 100 % d'un code que l'on a pas soi meme écrit, étant donnée que l'on dépend forcément d'un niveau précédent d'un niveau plus bas (niveau de l'assembleur par exemple-), l'on ne peut jamais etre sur réellement, à moin de pouvoir remonter toutes la chaine soi meme. En outre, plus le code malveillant se trouve dans des niveaux bas, plus il est difficile de le détecter.
On peut en faire un parallèle par rapport à la probatio diabolica en droit privé, qui nécessite de remonter toute la chaine des propriétaires pour s'assurer qu'on détient une propriété légitime.
Il est évident que lors d'utilisation de logiciel non libre, étant donnée que l'accès au code source est interdit, le risque d'une attaque (via un bug ou autre) est augmenté de manière drastique. L'on ne se remet qu'au bon vouloir de l'auteur sans aucune garantie quelconque.
Je précise que mon but (contrairement à l'appel du journal) n'est pas de lancer des trolls (il y en a assez sur internet qui gaspille la bande passante et l'énergie de ses usagers).
Plusieurs articles fesait état lors de la diffusion d'android sur certains appareil de backdoor et meme de trojan.
les appareils fournie par la société chinoise zte
Certains appareils appartenant à la gamme Samsung Galaxy (il y aurait un backdoor d'après l'article de zataz du 17 aout 2012)
Et certains trojan qui ont infectés des androids et dont le but était de récupérer les informations confidentiels pour les envoyés vers des serveurs à Shenzhen.
Il nous faudrait plus de détails pour pouvoir évaluer clairement ou se situait le problème (est ce dans des parties propriétaires ou libre ? ) ainsi que le type de mécanisme et le comportement réellement adopté.
Sinon , il faudrait rappeler les fait de la NSA KEY inclus dans la base de régistre de Microsoft Windows, ainsi que l'affaire cryptome qui avait fait leaker les documents par rapport à l'architecture d'enregistrement et d'accès au réseaux msn (enregistrement des conversations, accès à certains services de sécurité gouvernmentaux ).