Depuis le 22 avril 2021, une polémique grandit aux Etats-Unis après que les membres de l’Université du Minnesota ont été interdit de contribuer aux recherches sur le noyau Linux.
1 « J'aime »
On touche du doigt les limites du collaboratif.
La validation du code est le point faible. Une « petite » protection de ce point faible, c’est bien sûr le retrait de ce que l’on a détecté comme problématique mais aussi le bannissement de l’origine… Le but de la « recherche » était intéressant pour détecter les failles de la validation, mais c’était jouer avec le feu.
Quel est votre avis sur cette question essentielle de la sécurité de l’Open Source?
2 « J'aime »
Les « chercheurs » payent le fait qu’ils aient voulu tester les contributeurs en leur donnant plus de travail.
Soumettre des failles pour analyse (sans que les contributeurs le sachent) pour voir si c’est cette modification passe (et si c’est accepté alors rattraper la modification avant qu’elle soit vraiment intégré).
Je peux comprendre le bénévoles à qui ça donne plus de travail pour les bénévoles qui n’ont déjà pas assez de temps disponible pour les choses valables.
Si c’est pour donner du taff en plus pour finalement une recherche qui ne semble pas soutenu par l’université des « chercheurs », c’est quand même con !
Donc le bannissement c’est aussi pour faire réagir l’université et stopper les recherches qui dégradent le travail des bénévoles sans apporter de bienfait sur le long terme.
8 « J'aime »
Y a des Limites à ennuyer les gens juste pour voir le résultat, bien fait pour cette université et peut être qu’avec de telles sanctions on limiterai les tentatives de hack crées, rien que pour le fun. Ce bannissement devrai être défendu et généralisé dans nombre de cas, on pourrai espérer laver un peu le web.
4 « J'aime »
Leurs travaux universitaires avaient alors été menés pour pointer du doigt les failles de sécurité existantes, montrant qu’un code malveillant pouvait outrepasser tout processus d’approbation et potentiellement infecter le noyau Linux.
Faut croire que leur petit jeu n’est pas passé entre les mailles du coup ^^
Malheureusement, cela risque de donner des idées à d’autres…
2 « J'aime »
Le pire étant que dans leur papier ils disent sur les 5 patchs « trompeurs » envoyés, deux ont réussi à tromper les mainteneurs parce que ces patchs n’ont pas été refusé pour les bugs que les chercheurs essayaient d’insérer… Mais pour d’autres bugs que les chercheurs n’avaient pas vu. Tu parles d’un « succès »
Clairement la communauté Linux a autre chose à foutre qu’être un cobaye involontaire et non rémunéré pour une recherche d’un candidat PhD…
Et si les changelistes les plus récentes ont été générées automatiquement par un outil de détection de bugs (comme essayent de l’affirmer ces chercheurs), la communauté n’a jamais demandé à être le sujet d’un alpha ou béta test de leur outil foireux.
La réponse finale de Kroah-Hartman le résume bien :
You, and your group, have publicly admitted to sending known-buggy patches to see how the kernel community would react to them and published a paper based on that work.
Now you submit a new series of obviously incorrect patches again, so what am I supposed to think of such a thing?
They obviously were NOT created by a static analysis tool that is of any intelligence, as they all are the result of totally different patterns and all of which are obviously not even fixing anything at all. So what am I supposed to think here, other than that you and your group are continuing to experiment on the kernel community developers by sending such nonsense patches?
When submitting patches created by a tool, everyone who does so submits them with wording like « found by tool XXX, we are not sure if this is correct or not, please advise. » which is NOT what you did here at all. You were not asking for help, you were claiming that these were legitimate fixes, which you KNEW to be incorrect.
A few minutes with anyone with the semblance of knowledge of C can see that your submissions do NOT do anything at all, so to think that a tool created them, and then that you thought they were a valid « fix » is totally negligent on your part, not ours. You are the one at fault, it is not our job to be the test subjects of a tool you create.
Our community welcomes developers who wish to help and enhance Linux. That is NOT what you are attempting to do here, so please do not try to frame it that way.
Our community does not appreciate being experimented on, and being « tested » by submitting known patches that are either do nothing on purpose or introduce bugs on purpose. If you wish to do work like this, I suggest you find a different community to run your experiments on, you are not welcome here.
7 « J'aime »
Compléments et précisons ici : L'université du Minnesota bannie du développement du noyau Linux - ZDNet
Le modèle collaboratif de linux est un modèle qui marche et qui a fait ses preuves. Lors de chaque nouvelle release, des stats sont produites et les chiffres sont impressionnants, de mémoire : 90 « gros » contributeurs par release, 1000 contributeurs significatifs et 10000 mineurs.
Mais dans ce qui est décrit, à savoir entre les travaux de recherche et ce qui a été posté, on a l’impression que le doute des mainteneurs du noyau est que développeur a voulu créer un « exploit », en gros démontrer par la pratique le thème de sa recherche : montrer qu’il pouvait contourner le processus d’approbation. Le problème c’est que cela a eu l’effet inverse. Le besoin de nouvelles révisions a été décelé par le processus d’approbation. La question est donc de savoir si d’autres soumissions de code n’ont pas passé les mailles du filet.
D’où la suspicion, en tout cas c’est ce que je comprends, mais à vrai dire je ne connais pas le processus d’approbation.
Edit : ok, j’avais pas lu les autres posts, à priori c’est plus de l’incompétence de l’UMN alors
2 « J'aime »
Ton lien est le 2nd lien source de l’article, juste au dessus 
1 « J'aime »
Ah les linuxiens, ils ne changeront jamais. Je me souviens d’avoir été injurié, il y a quelques années, après avoir posté un message sur un forum en disant que j’avais des soucis avec ma carte graphique sous Linux, alors que celle-ci fonctionnait parfaitement sous Windows. Pour beaucoup, Linux est comme une religion alors si l’on ne croit en aucun dieu, c’est foutu.
2 « J'aime »
lol en effet, je regarde rarement les sources, my bad…
Par contre y’a eu coupe drastique sur les explications fournies dans cette source du coup.
1 « J'aime »
C’est en effet du grand foutage de gueule…
1 « J'aime »
Ce que vous appelez le collaboratif signifie open source (qui n’est pas forcément collaboratif) et il n’est pas plus vulnérable aux failles de sécurité que le propriétaire (qui peut aussi être collaboratif soit dit en passant - à moins que le code source de Windows ait été produit par un seul développeur).
Windows a aussi son lot de failles et de backdoors.
L’avantage du « collaboratif » est justement la validation que vous considérez comme un point faible : sur le propriétaire la phase de validation est souvent inexistante où repose uniquement sur des processus automatisé afin de réduire les coûts et on se contente des testes (de plus en plus automatisés) pour détecter les bogues → il est plus simple dans ces conditions d’introduire des failles de sécurité (volontairement ou pas)
Des outils pour scanner le code et détecter des vulnérabilité sont utilisés dans les 2 cas sur les projets d’envergure mais ces outils ont des limites.
1 « J'aime »
Ç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! 
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… 
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 »!
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!
@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.