Commentaires : L'Université du Minnesota est interdite de contribuer au noyau Linux... Que s'est-il donc passé?

Ça n’a rien à voir avec les linuxiens. Il y a de tels individus partout. Faut arrêter les amalgames.

2 « J'aime »

Vous avez raison de me faire remarquer que j’utilise collaboratif au lieu de Open Source collaboratif! :smiley:
Je ne parle pas de la validation qui est assez proche de celle d’un logiciel closed source, mais de la principale difficulté de l’Open Source: le contrôle des malveillances ou des erreurs. Car c’est ici que le travail de contrôle devient encore plus complexe, les contributeurs étant moins plus divers, moins surveillés et moins contrôlés par définition.
Ceux qui ont déjà travaillé sur des TestU, de la validation ou de la vérification industrielles comprennent surement ce que je veux dire, même si je ne suis pas très clair… :stuck_out_tongue:
Quel contributeur n’a jamais eu un mal fou avec du code étrange, mal codé voir même buggé. Je me souviens du code BT et RS232 de Qt il y a quelques années ou on a du tout recoder parce qu’il ne respectait pas les règles de codage, qu’il était illisible et surtout qu’il était truffé de bugs: pas mal de jardinage évident (WTF!!!), beaucoup d’imprécisions, mauvais support des protocoles, …, la totale quoi.

Tout à fait, cela s’appelle des « fans boys ». Des gens dépourvus de toute objectivité dès qu’on évoque leur marque préférée. Il suffit de lancer une discussion AMD vs Intel, iPhone/Androïd, Nvidia/AMD pour en trouver !

2 « J'aime »

Je ne sais pas… Quand je soumet un PR sur un projet open source, il y a TOUJOURS quelqu’un pour le revoir.
Il y a presque toujours des templates à compléter et des standards sur la manière de structurer le code. Ce ne sont pas des PR qui viennent de nulle part sans qu’on sache pourquoi et le code doit être compréhensible pour qu’il soit validé et testé.

On ne porte pas non plus la même attention à des nouveaux contributeurs qu’à des personnes qui ont déjà fait leurs preuves. Dans le cas de l’article, ces personnes ont clairement utilisé l’université pour gagner en crédibilité. Si ils avaient soumis le même code via un compte personnel sans lien avec l’université, il aurait peut-être été analysé avec plus d’attention.

Quand je soumet du code dans un des repository de l’entreprise pour laquelle je bosse, le code est généralement automatiquement approuvé et quand c’est manuel, la personne qui approuve se contente généralement de vérifier que ça compile sans même jeter un œil au code.
On part du principe qu’il y a un climat de confiance or bon nombre de sabotages viennent de l’intérieur.
Et une entreprise vvictime de malveillance ne va pas s’en vanter.

Tout ça pour dire qu’aucun système n’est parfait et des personnes malveillantes pourront toujours arriver à leurs fins, aussi bien dans l’open source que dans le code fermé auquel ils contribuent. Il ne faut pas être parano pour autant.

L’avantage du code ouvert est qu’on peut facilement auditeur le code, vérifier si une vulnérabilité est effectivement corrigée et le cas échéant faire soi-même un patch. Avec du code propriétaire, on doit croire l’éditeur (si il s’agit d’un cas compliqué à tester), et on dépend de son bon vouloir pour avoir un correctif (patch payant, version plus supportée, etc.).

Bref, ce genre d’incident n’entame pas ma confiance dans l’open source. Au moins ça à le mérite de forcer à davantage de vigilance… Au moins pour un temps.

4 « J'aime »

J’ai aussi toujours confiance en l’Open Source, mais c’est quand même un point délicat.
Si ta boite ne fait pas plus de tests, je suppose que ce n’est pas du code « sensible »! :stuck_out_tongue:
Dans le cas de l’aéronautique ou je bosse actuellement, ou de l’automobile ou j’ai bossé, il y a plusieurs niveau de certification et de vérification, avec des boites différentes pour réduire au maximum les risques d’oubli, de mauvaises habitude voir de malveillance. Et c’est souvent d’ailleurs dans ces vérifications que l’on tombe sur les problèmes de l’Open Source ou de Closed Source, en plus des problèmes internes! :stuck_out_tongue:

@metta messages supprimés pour le motif message non-constructif/hors-sujet.

Et il est toujours conseillé aux nouveaux inscrits d’aller lire la charte du forum.

entièrement d’accord avec la décision de bannir cette université jusqu’à nouvelle ordre, on ne peut pas resté les bras croisés, inactif face à de telle risque aussi grave.

Il y a des individus ou des organisations qui ont des intérêts à inclure des failles dans des logiciels open sources. Cela pourrait très bien être une agence gouvernementale des USA derrière cela…

On va vu avec Snowden, ils ne se gênent pas pour espionner, mais déchirent leurs chemises quand un autre pays espionne.

Bref, même si c’est open-source, il faut se méfier des contributeurs… d’où l’importance des « code reviews ». C’est une sage décision d’avoir bani cette université. Il y a quelque chose de louche dans cette affaire.

J’ai l’impression que l’étudiant a découvre quel que chose qui ne le devrais pas être .

Malheureusement dans l’informatique ou même dans la nature c’est dans la Méthode essai-erreur que l’on évolue !
Sans les erreurs les choses n’avancent pas très vite .
La ce n’est pas un code Linux qui est dans la nature .
Aucun Linux utilise présentement se code dans leur noyaux .
Je suis sur qui a découvert une faille potentiel dans le système " peut-être x 86 " que tout monde veut enterrer sous peur de poursuite .
" Dans ce cas-là " il n’aura pas juste les Linux de concerner .

Comme dit benben99
Il y a quelque chose de louche dans cette affaire.
Il ne nous dit pas tout la vérité .

N’iimporte quoi…

  • Les changelistes de ces étudiants sont dispos
  • C’est la base de code principale de Linux
  • Il n’y a pas de vraie correction de bug, mais au contraire un ajout volontaire de bugs dans ces changeslistes
  • Le premier papier de ces étudiants où ils expliquent ce qu’ils ont fait l’année précédente dans leurs premières changeliste est disponible.

Non seulement il n’y a rien de caché, mais en plus les étudiants ont expliqué ce qu’il faisaient. Y voir du complotisme, c’est vraiment vouloir s’aveugler soi-même.

1 « J'aime »

Et oui le côté libre de Linux est une illusion. Linux est dirigé par des personnes comme une entreprise. Il y a des gens qui décident qui peut fournir du code et qui ne peut pas, quelle fonctionnalité on ajoute ou quelle fonctionnalité on refuse. C’est un open source très closed source finalement car l’ouverture est très limitée, c’est au bon vouloir des gens là. La principale différence avec une vraie entreprise c’est que les gens bossent gratuitement grâce à ce système.

Franchement , faut vraiment etre aveugle pour raconter de la ****e comme tu le fais.
Des milliers de personnes et d’entreprises travailles sur le noyau, derrière chaque patch il y a des grandes firmes (Microsoft, AMD , Intel , NV…) , des universités , des petits devs , et dans tout ça , il y a un gros lot de Bugs et de failles potentiel dont une vérification est plus que nécessaire.
Quand des étudiants , surement supervisés par leurs profs , essaye de soumettre volenterement du code bugué , tu le prends comment ? tu l’integres car " ohhh c’est open source tout le monde peut contribué " ??? mais t’es vraiment à l’ouest mon gars.
Travailler gratuitement … lol .

2 « J'aime »

Ça part certainement d’une bonne intention, mais ils oublient que Linux n’est pas un jouet expérimental pour geeks, mais le noyau utilisé en prod d’une chiée de serveurs, de machines, avec un haut degré de sécurité.
Si tout le monde commence à faire ce genre d’expérience, ça créera un tel risque pour la sécurité que les entreprises qui ont besoin de sécurité vont tout simplement se passer de Linux.
tester la sécurité, mettre à l’épreuve, oui, mais pas n’importe comment.

1 « J'aime »

Ben oui, il faut bien qu’il y ait un minimum de gouvernance pour pas que ça devienne n’importe quoi. Mais il y a dans quasiment tous les gros projets open-source un processus démocratique pour attribuer les pouvoirs, c’est pas un gars tout seul ou un groupe fermé qui décident de tout.
Et surtout, comme ça reste de l’open-source, ça n’empêche pas à quiconque d’implémenter une fonctionnalité dont la communauté ne veut pas : il suffit de forker.

L’écrasante majorité des contributions à l’open-source sont faites par des gens qui ont été payés pour. Le geek qui fait ça chez lui dans son coin juste pour le plaisir, c’est un mythe auquel ne croient que ceux qui n’ont jamais vraiment travaillé dans l’open-source…

Les contributeurs indépendants sont loin d’être une petite minoritaire :

D’abord, c’est pas parce que le commit est fait avec une adresse perso que le travail n’a pas été fait en étant payé par une boîte.

J’ai déjà poussé plus d’une fois mes contributions avec une adresse perso, bien qu’elles aient été réalisées pendant mon temps de travail, parce que mon employeur ne souhaitait pas l’exposer officiellement (contribution sur des librairies PHP et Boostrap qu’on utilisait sur un projets internes, y avait des bugs chiants, on les a corrigés, et on a poussé les correctifs avec l’accord de notre hiérarchie, parce qu’on leur a bien fait comprendre que c’était la bonne façon de faire et que ça nous ferait même faire des économies à moyen terme puisqu’on n’aurait pas à repatcher à chaque mise à jour de la lib).

Certains parmi les plus gros contributeurs ont aussi l’habitude de contribuer avec une adresse perso, pour qu’ils puissent changer d’employeur tout en gardant le même identifiant auprès de la communauté. C’est toutefois de nos jours souvent remplacé par une adresse sur le domaine du projet.

Tiens, prenons un exemple au « hasard ». Dans les derniers commits sur torvalds/linux.git, le plus récent à avoir utilisé une adresse non pro, c’est Helge Deller, qui utilise une adresse gmx.de. Et si on regarde son profil, on voit qu’il est responsable du LinuxLab de SAP. Donc en faite de fortes chances que son activité sur le noyau Linux soit bel et bien rémunérée, même s’il pousse avec une adresse perso (et on peut pousser un poil plus loin en constatant qu’une large majorité de ses commit sont faits en semaine à des horaires de bureau). Le premier @gmail.com que j’ai trouvé, c’est Andrey Konovalov, employé de Google, qui travaille sur la recherche et la corrections de failles dans les noyaux Linux et Android… Là encore, y a donc de fortes chances que le gros de son activité sur le repo git de Linux soit directement liée à son boulot.

Ensuite, même si on considérait que tous ces gmail.com sont des indépendants, c’est certes le domaine qui a fait le plus de commits, mais ça ne représente tout de même que 9% du total des commits (donc une petite minorité face à une majorité qui a commité avec des domaines d’entreprise… Gmail étant quasiment le seul provider de mail public listé dans ce top 30, il y a aussi gmx, mais loin derrière…).

Enfin, le nombre de commits est de toute façon une métrique qui atteint vite ses limites… Un indépendant qui va faire 10 commits modifiant chaque fois une ligne, donc des modifications absolument mineures, si ce n’est cosmétique (genre correction de typo dans un fichier de langue…), ça compte comme 10 fois plus qu’un professionnel qui pousse en un seul commit le travail d’une semaine pour ajouter une feature majeure à un produit… Histoire de se faire une idée, sur un des projets sur lequel j’ai bossé, le 2ème plus gros contributeur a fait 117 commits, mais seulement 8275 lignes de code. Y’en a un autre qui a fait 70 305 lignes, mais en seulement 26 commits… Y a des chances qu’en pratique il ait contribué bien plus que le précédent…

Tu penses que étudiants voulait juste créé un bug dans le noyau de Linux volontaire .
J’imagine très bien la scène .
Professeur " universitaire " ; pouvons nous amusez a créé des bugs dans Linux pour le faire planter " question de s’amuser un peu .
Voyons donc ça pas d’allure comme histoire .

C’est sur que on ne connait pas tout l’histoire mais il avait surement un but à cette manœuvre et ce n’était surement pas pour mal faire .
Là c’est de la chasse au sorcière .
Trouver un coupable pour une histoire non aboutie et qui a été abandonné .
Il n’y a pas de bobo c’est quoi le but de la manœuvre du bannissement .

Ah, donc tu n’as même pas lu l’article. Bon, bah pas la peine de discuter plus.

J’ai lu l’article et je vois pas le problème .
En résumé :
Une étudiants a induite des codes dans le noyau de Linux surement pour améliorer sans tenir compte de l’aspect de la sécurité ?
Par-contre L’Université du Minnesota dit que c’est un logiciel qui a créé le bug et bla bla bla a qui la faute !
pis alors
Si je manque mon gâteau est ce que je n’aurait plus le droit de faire du gâteau .
Je l’ai écrie que l’évolution fonction dans la Méthode essai-erreur !
C’est la base même de tout composant l’électronique .

Faux