Universidade de Minnesota banida pelo kernel Linux - Diolinux
Os membros da Universidade de Minnesota tiveram suas contribuições ao kernel Linux re-avaliadas e foram banidos pelos mantenedores do kernel Linux.
11 curtidas
Isto aconteceu há mais de um mês atrás:
5 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.
7 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
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.
8 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.
7 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
Com toda educação discordo de sua opinião, de ser inútil porque só basta o software cumprir seu objetivo para o usuário.
Motivo? Nem sempre o usuário sabe o real poder de suas decisões e de graça, ou simples conveniência, trocam sua liberdade. Exemplo: Atualmente as pessoas estão reféns das Big Tech’s entregando seus dados à preço de banana.
Não só isso, veja o exemplo da Adobe que abruptamente por conta de questões políticas impediu o uso do Photoshop para alguns de seus usuários em determinados países. Num mundo Full software proprietário qualquer um poderia se encontrar nessa posição. Enquanto num cenário livre é virtualmente impossível.
Então, mesmo o usuário final não entendendo o poder que tem em suas mãos não significa que não tem tal poder.
Esses usuários profissionais de Adobe Photoshop ficaram de uma hora para outra num mato sem cachorro. Mesmo pagando caro por assinaturas, sendo interrompidas abruptamente por questões fora de seu controle.
Volto a dizer, imagina isso ocorrendo mais vezes. Num contexto de software proprietário é totalmente plausível. Afinal, a licença dá preferência ao proprietário e não o usuário.
7 curtidas
Não sou ingênuo em dizer que software proprietário vai acabar (creio que deve existir a liberdade para licenciar como quiser). No entanto é mais lógico convergir, lentamente e de forma inteligente, de softwares centrais proprietários para livres.
Claro, nem sempre é possível (paciência). Mas penso toda vez em contextos como esse incidente com a Adobe, e que quando viável uma alternativa aberta é mais garantido.
2 curtidas
Quando vais testar um Antivirus, vocês dizem pra ele qual vírus é ou onde ele esta …? A comunidade é grande porém revisar leva tempo e dedicação e expor essa falha tem só de acrescentar e que tem não só de revisar um grupo mas sim o todo, assim como eles se expuseram, imagina o que deve ter por ai que foi colocado e ninguém sabe…
Faz sentido, devemos entender não como uma punição, mas como uma defesa do sistema e de uma ação para evitar trabalho desnecessário. Existe um repositório aberto para commits, se alguém faz um commit muito ruim cheio de erros você vai banir essa pessoa para evitar ter que perder tempo revisando os commits de uma pessoa que comete erros primários. Se a Universidade resolveu fazer esse teste sem aviso, tudo indica que no futuro ela pode fazer de novo e isso obriga a equipe a dedicar uma revisão mais aprofundada em todos os commits futuros desse colaborador, se não há como confiar deve sim ser banido assim como seria banido um colaborador com conhecimento insuficiente. Infelizmente essa universidade enviou commits com erros que um colaborador não pode cometer, má fé, falta de conhecimento técnico ou simples distração, NÃO IMPORTA!!! Erro primário deve sim ser banido pois mais atrapalha que ajuda.
4 curtidas
Eu ia comentar exatamente isso. O problema mais grave que algumas das vulnerabilidades são conhecidas CVEs. Lendo alguns comentários aqui da impressão que qualquer pessoa pode enviar qualquer coisa para o kernel sem que ninguém saiba o que não é verdade, sempre terá alguém revisando o que está sendo enviado e não somente a comunidade empresas pagam “revisões” para ajudar manter o kernel limpo estável, todo commit é analisado para ver se nada de estranho entre. A atitude dos membros da Universidade foi grotesca.
1 curtida
Difícil comentar aqui mas acho que a sua fala provavelmente uma das mais incorretas que eu tenho visto provavelmente porque você não se internou completamente da história ainda.
Primeiramente seguindo os emails e análise que a própria fundação do Linux divulgou de todos os testes dos patches que o pessoal da universidade de Minnesota mandou encontraram apenas seis patches errados com bugs.
Alguns desses bugs foram corrigidos posteriormente ou seja não é necessário corrigi-los agora; um outro acabou nem sendo incluído pois apesar da tentativa de ajuda do desenvolvedor do Linux para que o código pudesse ser melhorado e então incluído no kernel não não obteve resposta satisfatória inclusive isso deixou o desenvolvedor do Linux muito triste por que se tratava de um aluno da universidade de Minnesota.
Na verdade, essa história toda só provou o seguinte: que o sistema de controle e desenvolvimento do kernel do Linux é muito seguro, mais seguro do que inclusive a gente entendia que era.
Quanto aos comentários de que o Linux é um software aberto só que somente os chefoes podem fazer modificações esse também está equivocado. Qualquer um ou qualquer grupo de pessoas pode fazer um fork do Linux e aplicar qualquer modificação que queira. Agora, se vai tomar o lugar do projeto original é outra história…
Assim como no bitcoin, eh desvantajoso ir contra as regras do sistema e o cara vai ganhar mais se tentar ajudar ao invés de destruir ou burlar…
O pesquisador vai sofrer sanções por ter realizado pesquisas com seres humanos e o aluno de graduação no mínimo vai ficar com muita vergonha e ter uma história ingrata para contar, mas pode por a culpa nos desorientadores…
8 curtidas
Você não entendeu o que eu escrevi.
Eu nunca falei que eles enviaram “uma enxurrada de patches maldosos ou mesmo legítimos ou patches diversos” ou mesmo que a universidade era “uma grande contribuidora do projeto”.
As falhas só foram descobertas após a publicação do paper, se isso não tivesse acontecido nada pode dizer se as falhas seriam ou não descobertas antes de entrar na release final. Provavelmente seriam descobertas devido ao tamanho do projeto mas nada além de especulação pode-se fazer sobre isso.
Não, vamos ao dicionário: está fadado a: Está destinado a, no futuro acontecer. Eu nunca falei que o desenvolvimento do linux está assim hoje, ele está se encaminhando a ficar assim e está cada vez mais próximo disso. E eu me referi ao repositório base, não à liberdade de forquear ele.
Ou seja, pelo fundamento do software livre, o que o kernel do linux é, qualquer um pode COPIAR e editar A SUA CÓPIA e isso dificilmente irá mudar.
A versão original, que todos usam como base, que é mais estável, que mais gente mantém, que as empresas mais utilizam, a base de tudo (o repositório base), cada vez menos recebe participação de pessoas independentes e cada vez mais está atrelado a grupos e empresas. E é esse o ponto que cheguei no final, o repositório base é cada vez mais fechado à edições de pessoas independentes justamente porque existe um custo (pessoal e financeiro) muito alto para auditar todas as modificações que chegam e que podem afetar de forma negativa os grandes que lideram o projeto.
Eu não poderia ligar menos para o que vai acontecer com eles ou que tipo de consequências a universidade vai sofrer, eu apontei para a dificuldade de auditar um volume tão grande de modificações que um projeto dessa magnitude recebe.
2 curtidas
Olha eu acho que eu não deixei claro que na verdade estava respondendo todo mundo ali naquela mensagem não soh o renard beleza?!
Mas assim cara eu quero dizer que esse pensamento seu está errado e esse tipo de pensamento já foi detectado pelo Kroah-Hartman em um dos primeiros emails que o pesquisador principal mandou para a lista do Linux e que acabou nem aparecendo na lista de mensagens porque ele tinha mandado a mensagem dele formatada em HTML com alguns questionamentos. O Kroah-Hartman respondeu alertando que esse é um pensamento errado, o mesmo que tu está dizendo, desde o início então nas correspondências que a fundação do Linux tem soltado se você tem acompanhado, eles mencionam isso então foi desenterrado essas mensagens e foi detectado que esse eh um pensamento problemático e condenável desde o começo.
Open software eh software aberto e acessivel a quem quer que seja, mas isso envolve as pessoas então não eh só uma questão de código.
Além do mais, o Linux Não eh open source, eh software livre e aqui há uma diferença muito grande apesar que o Linus advoga pelo Open source.
Essa pesquisa deve ser feita por Antropólogos cok o consentimento dos developers , até lá ficaremos com essas dúvidas e acreditando que as coisas são possíveis pq as pessoas tem mais bom do que mau
2 curtidas
Em relação à falta de ética da pesquisa, nem tem muito o que dizer, de fato houve essa falha, tanto que eu preferi nem comentar a respeito disso porque considerei literalmente “chover no molhado”, ainda mais sujeitando tanta gente e tantas empresas ao risco.
Em relação aos e-mails, sou muito cético em relação à essas declarações. Situações como a do git-hub mostraram que todos (ou quase todos, existem algumas pessoas como o Stallman, mas são raríssimos casos) têm seu preço. Acredito que essas declarações e mensagens tentando tirar a relação do linux com grandes corporações não passe de um jogo de marketing, um discurso bonito para acalmar gente fanática ou manter a “imagem de santo”, tentando passar a imagem de que o projeto linux é “incorruptível” (de novo, git-hub).
Mas nesse ramo estou especulando. Com base no que observo no mercado, mas apenas especulando. O “pronunciamento oficial” é de fato que “o kernel linux não se renderá às grandes corporações”.
P.S.: Você tem o link para essas mensagens que o Kroah-Hartman enviou ? Estou curioso para ler na íntegra o material e tirar minhas conclusões de forma mais precisa.
3 curtidas
Sobre os links vou verificar.
Muitas mensagens eu li na lista de emails do kernel mesmo
Mas eu tinha um link de inicio da linha de mensagens,
Agora nao me lembro o sitio com essas referências organizadas. Tb li algumas dessas ultimas cartas que a Linux Software Foundation liberou em resposta a Uni de Minessotta.
Amanhã tento trazer pelo menos algumas refs para vc começar a puxar o fio do novelo, se já não comecou…
2 curtidas
O que houve neste caso é bizarro, e até que alguém comprove, não chegou às versões finais do kernel, logo, a revisão cumpriu seu objetivo.
A expulsão é pouco, fora uma possível indenização, pelo intuito, falta de ética, possíveis danos à imagem.
Não foi uma crítica construtiva, foi sabotagem.
Quem garante que não houve alguém pagando um por fora para se beneficiar de uma situação destas? Qual era o objetivo real? Se desse certo, o que exatamente visavam?
Porque é muito fácil ser pego na botija e dizer que era em nome da ciência.
E casos semelhantes em eventuais contribuidores de software fechado, como são tratados? Garantem um resultado melhor? Duvido.
E o padrão de uso foi totalmente descabido. Se, por exemplo, um empregado com raiva do chefe resolve fazer uma promessa que prejudique o negócio, ainda que tenha agido com deslealdade, seja demitido e passível de processo, enquanto preposto, o local onde trabalhava é responsável pelo cumprimento da obrigação.
Logo, neste episódio lamentável, ficou a lição de que o risco foi mitigado. Se houve alguma falha ou possível melhoria no processo, espero que sirva de lição para todos os envolvidos, especialmente, aqueles que jogaram sujo.
4 curtidas