Universidade de Minnesota banida pelo kernel Linux

https://diolinux.com.br/noticias/universidade-banida-do-kernel-linux.html

Os membros da Universidade de Minnesota tiveram suas contribuições ao kernel Linux re-avaliadas e foram banidos pelos mantenedores do kernel Linux.

10 Curtidas

Achei justo. Fazer uma “experiência” dessas sem algum aviso prévio (nem que fosse para apenas um dos mantenedores) é de muito mal gosto.

6 Curtidas

Isto aconteceu há mais de um mês atrás:

4 Curtidas

Punição justa! O Kernel Linux não é um simples projeto de garagem para q esse tipo de coisa (implementar vulnerabilidades) seja realizada, e sim um projeto de larga escala usado mundialmente em vários serviços. O certo ao meu ver é jamais deixar que essa universidades ou até associados trabalhem novamente no desenvolvimento de patchs para o Kernel Linux.

7 Curtidas

Não seja por isso, sem consultar o desenvolvedor, isso é sacanagem com qualquer projeto. Tenho certeza que tomarias as mesmas atitudes se teu projeto de fim de semana recebesse commits com vulnerabilidades.

6 Curtidas

bota-se o dedão na ferida e vem a ira divina dos endeusadores de causas! que coisa boa que isso tenha acontecido!!! ótima oportunidade para se testar in loco se essa história de código aberto ser imune a isso ou aquilo realmente funciona! deveriam aproveitar a oportunidade e tirar um grande aprendizado: que se não avisassem, ninguém saberia.

em vez de punir uma instituição, regulamentem esse tipo de teste. o kernel vai ganhar muito mais.

4 Curtidas

beleza. quando a “”“experiência”"" chegar no seu kernel, veremos se sua opinião irá mudar :slight_smile:

1 Curtida

e vc acha que n tem aqui algum buraco da CIA, mossad no kernel etc? vc acredita mesmo que a rede tor é infalível, q n foi hackeada? tsc tsc tsc. cê acha mesmo que revisam milhões de linhas de código? a turma do kernel tá irada pq foi pega com as calças nas mãos.

1 Curtida

De novo:

Falar é fácil quando isto não aconteceu a você. Pimenta nos olhos alheios é refresco. Imagine se você mantém um projeto que basicamente move a espinha dorsal da internet, e de repente você recebe uma carta de uma universidade dizendo que inseriu código malicioso no seu projeto, sem ao menos lhe avisar. Você muda de opinião rapidinho. Pimenta nos próprios olhos é apenas pimenta.

Não apenas acho como tenho certeza. Um belo exemplo é observar as changelogs. Estão sempre removendo linhas que fazem referência a hardware antigo demais ou que caiu em desuso. Se não revisassem o código, teríamos um kernel muuuuuuuito mais inchado com coisas que ninguém usa.

Aliás, as vulnerabilidades descobertas são corrigidas no kernel em questão de horas.

7 Curtidas

Felizmente não chegará, pois foram detidas antes.

5 Curtidas

Difícil de comentar num tópico desses porque existe muita fé em cima do software livre. A fé de que o software livre é imune de bugs, vulnerabilidades e injeções maliciosas de código. Existem revisões e correções de código ? Existem. Existem pessoas buscando bugs e vulnerabilidades ? Existem. Mas nesse caso específico, os commits foram pegos apenas porque o paper foi publicado. Ninguém sabe se essas vulnerabilidades chegariam ou não ao usuário final.

No fim das contas o que faz a maior vantagem também cria maior desvantagem do software livre. Em projetos com menor número de pessoas envolvidas, a deficiência pessoal (falta de mão de obra) torna o projeto extremamente difícil de ser auditado, assim muita gente prefere tornar o software livre no maior modo “somente leitura”, ou seja, você tem o código, pode forquear mas não pode editar o original. Dessa forma a evolução se torna mais lenta que o normal (já que nesse caso os desenvolvedores raramente possuem um empenho único a isso, usualmente dividem a atenção com sua fonte de renda) e bugs ou demoram muito para ou raramente são corrigidos.

Em casos como o do kernel, onde um número abissal de pessoas e empresas está envolvido, existe um empenho em manter o código limpo mas o código atingiu um patamar tão alto de tamanho, complexidade e número de modificações que bugs e vulnerabilidades podem passar desapercebidos num primeiro momento. Até podem ser pegas no futuro, mas nem sempre isso pode ser verdade. Ainda mais com vulnerabilidades conhecidas e que já são consideradas “corrigidas”.

O que esse pesquisador fez pode até ser considerado “imoral” pelos desenvolvedores mas expôs exatamente este ponto que citei acima, mostrou como uma vulnerabilidade pode passar desapercebida e pega somente quando algum envolvido com sua inclusão a torna pública.

No fim o kernel linux está fadado a se tornar um código aberto onde todos podem ler o código mas apenas grandes empresas e “amigos do rei” podem editar. Justamente pelo perigo de terceiros injetarem códigos maliciosos no meio que podem passar desapercebido se não houver um trabalho extremamente pesado de revisão, problema esse que pode causar perdas financeiras consideráveis para “grandes players” do projeto, como google por exemplo.

6 Curtidas

Isso que pensava a certo tempo (está lendo mentes? :thinking:), que o Open Source/Software Livre é muito bom pela liberdade, mas exige uma segurança máxima.

Infelizmente é essa a realidade, fadado para apenas as grandes empresas contribuirem (comunidade UEFI, Microsoft, Dell, Acer, HP, Asus e todas as outras fabricantes).

2 Curtidas

Sim e eu passo por isso hoje. Sou co-autor de um pacote para python que é usado por alguns pesquisadores por ai, mantendo o código hoje tem só eu e o outro autor.

Para fazer uma implementação de um recurso simples que já foi solicitado antes estou demorando meses justamente por ter outras tarefas que me engolem o tempo. Eu e o meu colega, portanto decidimos manter o código com o mínimo possível de submissões de terceiros justamente porque não temos capacidade de auditar o que chega!

Entre ter um bug ou outro no código ou o risco de injetarem códigos maliciosos, decidimos pelo menos pior.

1 Curtida

Pois é. As vezes chego a pensar que o Open Source nunca será 100% Open Souce puro e livre, como dizem as filosofias.

Já fui muito anti windows/office e coisas do tipo, mas hoje chego a pensar que brigar por sistema operacional e/ou programa por ser livre ou não é inútil. Um usuário comum, por exemplo, não liga se o programa o qual usa é Open Source ou não, só quer realizar suas tarefas nele.

Pra mim, se usa Windows ou Linux, Office ou LibreOffice, tanto faz. Vejo que muitos se preocupam com a “filosofia” e se esquecem do seu objetivo.

Como dizem: O melhor sistema operacional/programa é aquele que melhor te atende

4 Curtidas

Acho que vc está confundindo OpenSource com Software Livre.

4 Curtidas

Na verdade não, falo do OS mesmo. Infelizmente, projetos grandes como o LINUX em si (coloquei em caixa alta e negrito para dar ênfase) estão “abertos” para as grandes empresas. como o @renard162 falou:

Sobre minha opinião, resumidamente, não ligo se é open ou free ou pago. Se consigo fazer minhas tarefas de forma segura e completa, tá ok. Gosto do Open Source, mas não sou extremo.

3 Curtidas

Ah, acho q entendi agr. Vlw

2 Curtidas

Pra complementar: Não acho que isso mostra um grande problema do Kernel, digo, ao meu ver não acho q isso vai fazer com q só um grupo seleto possa implementar patchs,l até porq o que pode e acredito que acontece é q se vc faz um patch, ele vai ser (ou pelo menos deve) analisado antes de ir para uma versão final do kernel por exemplo. E se pensarmos de forma mais geral qualquer software está sujeito a isso, basta que uma pessoa com más intenções e determinado acesso ao desenvolvimento do software em si faça.

4 Curtidas

Sim, eu mesmo posso relatar um problema normalmente. O problema é que, para eles, seria muito mais rápido ver um commit/pull de uma empresa (confiável) do que de um mero usuário. Não que eles não liguem para a comunidade, creio que seja apenas questão de segurança. :confused:

3 Curtidas

De fato faz sentido até porq os maiores contribuidores pro kernel linux atualmente são empresas e não a comunidade em sí.

3 Curtidas