Quando li sobre isso ontem no H fiquei pensando se nessas horas não compensa o conservadorismo do Debian.

(Embora não sei se não foi afetado também)

O “conservadorismo” do Debian se justifica na estabilidade e segurança do servidor.

Spif,

Obrigado por interpretar o texto para os demais leitores.

@Weber Jr,

O QA do Debian costuma sempre analisar os códigos de suas aplicações empacotadas.. muito provavelmente o bug deve existir em outros lugares… mas não lá. Agora.. problemas acontecem em qualquer distribuição.. e se pensar em ser “conservador”, o RedHAT com 10anos de TS é super conservador e o Ubuntu LTS com 5 anos… também… e agora? :D

“O QA do Debian costuma sempre analisar os códigos de suas aplicações empacotadas.. muito provavelmente o bug deve existir em outros lugares… mas não lá.”

Sim, é o que eu imaginei, e acho muito bom.

“Agora.. problemas acontecem em qualquer distribuição..”

Claro que sim, mas o Debian, principalmente depois que surgiu o Ubuntu, recebeu muita crítica por ser “lento” na adoção de versões novas dos softwares empacotados. Por isso comentei.

‘se pensar em ser “conservador”, o RedHAT com 10anos de TS é super conservador e o Ubuntu LTS com 5 anos… também… e agora? :D’

Acho que aí não se aplica, é mais uma questão de suporte do que precaução.

é impressionantes em todos os lugares e profissões existem pessoas mal caráter, por isso sempre enfrentaremos esse problemas em pacotes.

Más deixando a humanidade de lado e voltando ao sistema, o linux mais seguro é aquele onde voce tem controle do que está sendo instalado. compilar os fontes em servidores de produção é essencial e aumenta ainda mais a segurança dessas aplicações. seja no ubuntu, no debian ou no slack.

Tiago Nóbrega: http://www.defendendoolinux.in

@tiagonobrega, discordo plenamente de você.
se você baixou o código fonte do projeto diretamente do site oficial – que por sinal foi comprometido – e compilou vc mesmo, continuaria com o mesmo problema dos outros, e o estrago seria bem maior, por causa da falsa sensação de segurança.

Compilar codigo infectado e achar que está seguro só porque baixou do site oficial é tão inseguro do que baixar do astalavista e auditar linha por linha.

@Tiago Nóbrega sem analisar linha por linha e acompanhar os projetos upstream, compilar é mais perigoso do que confiar em empacotadores.

@Tiago,

Além do que.. deixar um compilador funcional no seu servidor só ajuda pessoas que conseguiram acesso ao seu sistema na compilação fácil de backdoors. :D

Fonte vs Pacote, mais uma das picuinhas inúteis do Software Livre.

(BTW, prefiro pacote)

Alguém pode acrescentar alguma informação a respeito de se foi feita alguma iniciativa para identificar quem enviou o backdoor para o repositório? Isso seria importante para evitar novas ocorrências do mesmo tipo de problema.

Governança aberta é algo bastante produtivo, mas é vulnerável a esse tipo de ataque.