Rappel des faits :
Lors d'une conférence, Linus Torvalds a répondu "non" avec la voix, et "oui" avec un signe de tête lorsque que la question suivante lui a été posée : "Avez vous déjà été approché par une agence du gouvernement américain pour ajouter une porte dérobée à Linux? "

Nouveauté :

"Nils Torvalds affirme à propos du double langage de Linus qu'en répondant ainsi (verbalement "non"), "il était en quelque sorte libre juridiquement. Il avait donné la réponse correcte, mais tout le monde a compris que la NSA l'a approché" "

Article complet : http://www.zdnet.fr/actualites/selon-le-pere-de-linus-torvalds-la-nsa-a-bien-demande-un-acces-derobe-dans-linux-39795598.htm

Grossièrement les commentairent racontent :

-Même si le noyau est libre est que tout le monde a accès aux sources, l'utilisateur lambda ne sait pas inspecter les codes sources.

-Un partie du noyau sur la plupart des distributions contient une partie non libre (blob), dont on ne peut controller le contenu ( Trisquel GNU/Linux par contre-exemple a un noyau 100% libre).

-Selon un commentaire, une faille de sécurité dans ssh était présent (et a même été intégrée à debian), faille qui a perduré 2 ans avant correction . Ce qui fait que le libre n'échappe pas aux erreurs.

-Si les sources sont accessible, la NSA peut elle aussi rechercher des 0-days .

-Le code source est tellement grand qu'il est difficile de tout vérifier .

Les avis sont mitigés, il y a du vrai, du cliché, etc ...

Et vous, qu'en dîtes vous ?

«Selon un commentaire, une faille de sécurité dans ssh était présent (et a même été intégrée à debian), faille qui a perduré 2 ans avant correction . Ce qui fait que le libre n'échappe pas aux erreurs. »

Il faut voir l'erreur en question, si ça se trouve ça demandait une réécriture complète d'une grosse partie et non une faille que personne ne connaissait. C'est beaucoup de travail et il n'y a pas forcément quelqu'un pour le faire, donc je mitige la conclusion que tu as faite.

«Le code source est tellement grand qu'il est difficile de tout vérifier . »

Sauf que c'est plusieurs petits commits et pas un gros tas d'un coup, c'est plus simple de vérifier ça. Les commits doivent être approuvé par beaucoup (hu hu) de personnes de la branche en question, Linus et tous ceux qui s'y intéressent (et c'est pas des débutants).

Un machin fait d'un coup, ça se voit. Un machin fait en plusieurs fois, c'est déjà plus subtile et moins voyant. C'est possible de le faire mais il faut, soit bien avoir prévu le coup, soit avoir une chanche de PD, soit pouvoir corrompre tout les développeurs... soit compiler une version modifié du noyau et la mettre dans une distribution... non?

« Ce qui fait que le libre n'échappe pas aux erreurs. »

En quoi le libre devrait-il être "parfait"?
Le coup d'OpenSSL chez Debian, c'est l'une des pires catastrophes historiques de la distro, mais que ce soit avant ou après ça le logiciel libre n'a jamais eu la prétention d'être invincible et irréprochable... je ne vois même pas ce qui devrait ressortir de cette histoire en fait.
A la base, cette histoire de "faille" a été introduite par une erreur venant d'un dev manifestement pas très expérimenté, qui pensait "corriger" un vice dans du code (variables non-initialisées, à des fins d'entropie justement) mais avait en réalité niqué l'entropie du générateur de clés de telle manière, que les clés résultantes étaient profondément bidons. Encore aujourd'hui certains sites en souffrent, car ils continuent à utiliser des certificats et autres paires de clés générés "à cette époque" (malgré le raffut que ça a provoqué sur le web, une fois découvert).

« -Si les sources sont accessible, la NSA peut elle aussi rechercher des 0-days . »
Oui, tout comme les russes, les Allemands du C3B, les français de Vupen... c'est normal, c'est dans le cycle de vie d'un logiciel.
Je ne vois sincèrement pas d'autre moyen de protéger un logiciel contre ça, que de prendre le temps de l'auditer soi-même, ou le faire auditer dans un cadre qu'on maîtrise, et garder une politique très stricte sur sa sécurité. (OpenBSD est l'exemple auquel je pense en écrivant ces lignes)
Donc l'importance des tâches réalisées par ce qu'on utilise comme software doit être proportionnelle à la confiance qu'on accorde aux développeurs pour le sécuriser, mais il vaut mieux partir du principe que le soft est trituré dans tous les sens en permanence par d'autres mecs, sinon on vit dans l'erreur.

J'aurai peut-être pas dû mettre d'exemples de commentaires, ça va finir en défonçade par citation

"ou le faire auditer dans un cadre qu'on maîtrise" il y a un endroit ou les audits de code sont accessibles au public (le rapport associé ?)

Je ne suis pas sûr de comprendre ton message là.
(je vois pas si c'est une question, et si ça n'en est pas une, je ne vois pas en quoi ça répond à mon post )

Ce que je voulais dire par là, c'est "faire auditer le code par une société qu'on paie", ou "par des membres externes au projet mais dignes de confiance", histoire d'être sûr de récupérer les éventuelles vulnérabilités découvertes.

(parce que bon, c'est pas toujours le cas, cf. Vupen qui trouve des failles pendant des concours mais refuse de les publier après)

Pardon, c'est une question ! Le "?" est mal placé.
Je reformule. Est-ce que les rapports d'audits d'OpenBSD sont consultables quelquepart

Pas que je sache, mais ils sont généralement évoqués sur misc@ et tech@, et font l'objet d'articles disponibles sur le site d'OpenBSD. Au pire en regardant les commits CVS

Cependant il a ete montrer que des techniques de diverse double-compiling [1] peuvent etre deploye pour contrer les problemes des trusting trust. Bien qu'elle soit difficile a mettre en place pour un particulier, une distribution peut deployer cette technique. (Et comme de toute facon, tu prends les binaire de chez eux, tu n'as pas le choix que de leur faire confiance.)

[1] http://www.acsa-admin.org/2005/abstracts/47.html