Pacotes das distribuições são realmente seguros?
Distribution packages considered insecure (Lukas's Random Thoughts)
É um argumento válido e demonstrável. Não questiono a infraestrutura que gera os pacotes. Apesar de alguns tropeços no passado, as distribuições têm sistemas seguros. Trata-se dos binários entregues aos usuários, se são seguros, se não possuem falhas de segurança conhecidas.
Já expressei aqui que acho a atual forma de distribuição de programas do GNU/Linux quebrada no que diz respeito aos desktops (e adiciono plataformas móveis). Porém para servidores é interessante, pois neles podemos esperar que tudo venha dos repositórios oficiais.
Para o modelo funcionar, no entanto, requerimentos são necessários: empacotadores e projeto upstream responsivos. Isso nem sempre há. Como resultado, podemos ter pacotes abandonados, que ficam um tempão com vulnerabilidades e bugs diversos sem correção.
Uma característica na política de atualização de versões estáveis, particularmente do Debian, mas também adotada por outras distribuições, é a proibição de atualizações até de minor versions dos pacotes. O empacotador é obrigado a escolher a dedo (cherry-pick) apenas patches que consertem bugs de segurança, ficando de mãos amarradas enquanto o projeto upstream já consertou uma miríade de outros problemas. Exceções existem para outros bugs, quando graves, ainda que dependam da boa vontade e competência do empacotador.
Quando há, fortuitamente, upstream ativo, preocupado em manter versões antigas vivas (repetindo, nem sempre há!), considero uma péssima política. Suponha que um pacote qualquer tenha duas major versions, 5.x e 6.x. E uma distribuição use a série 5.x. Enquanto o upstream lançar atualizações dessa série, o downstream (a distribuição) deveria atualizar imediatamente, trabalhando junto ao upstream com intuito de garantir que nenhuma API será quebrada — esse é o objetivo de minor versions.
Não incomum temos algo diverso: o pacote travado numa versão 5.x específica, que vai ficando cada vez mais velha, com alguns backports aqui e acolá, e uma tonelada de bugs.
Por fim, temos a pior possibilidade, que é a falta de empacotadores responsivos. Nesse caso, os usuários ficam simplesmente no mato sem cachorro. Pendurados no pincel.
Portanto, ciclo de vida estável, onde atualizações são previsíveis e não trazem mudanças bruscas, tem propósito, mas nem sempre a coisa funciona bem na prática.
É um argumento válido e demonstrável. Não questiono a infraestrutura que gera os pacotes. Apesar de alguns tropeços no passado, as distribuições têm sistemas seguros. Trata-se dos binários entregues aos usuários, se são seguros, se não possuem falhas de segurança conhecidas.
Já expressei aqui que acho a atual forma de distribuição de programas do GNU/Linux quebrada no que diz respeito aos desktops (e adiciono plataformas móveis). Porém para servidores é interessante, pois neles podemos esperar que tudo venha dos repositórios oficiais.
Para o modelo funcionar, no entanto, requerimentos são necessários: empacotadores e projeto upstream responsivos. Isso nem sempre há. Como resultado, podemos ter pacotes abandonados, que ficam um tempão com vulnerabilidades e bugs diversos sem correção.
Uma característica na política de atualização de versões estáveis, particularmente do Debian, mas também adotada por outras distribuições, é a proibição de atualizações até de minor versions dos pacotes. O empacotador é obrigado a escolher a dedo (cherry-pick) apenas patches que consertem bugs de segurança, ficando de mãos amarradas enquanto o projeto upstream já consertou uma miríade de outros problemas. Exceções existem para outros bugs, quando graves, ainda que dependam da boa vontade e competência do empacotador.
Quando há, fortuitamente, upstream ativo, preocupado em manter versões antigas vivas (repetindo, nem sempre há!), considero uma péssima política. Suponha que um pacote qualquer tenha duas major versions, 5.x e 6.x. E uma distribuição use a série 5.x. Enquanto o upstream lançar atualizações dessa série, o downstream (a distribuição) deveria atualizar imediatamente, trabalhando junto ao upstream com intuito de garantir que nenhuma API será quebrada — esse é o objetivo de minor versions.
Não incomum temos algo diverso: o pacote travado numa versão 5.x específica, que vai ficando cada vez mais velha, com alguns backports aqui e acolá, e uma tonelada de bugs.
Por fim, temos a pior possibilidade, que é a falta de empacotadores responsivos. Nesse caso, os usuários ficam simplesmente no mato sem cachorro. Pendurados no pincel.
Portanto, ciclo de vida estável, onde atualizações são previsíveis e não trazem mudanças bruscas, tem propósito, mas nem sempre a coisa funciona bem na prática.
Posso estar enganado mas o Fedora sempre manda os pacotes que estão no upstream em seus lançamentos não sei se eles tem o mesmo cuidado assim como tem o kernel linux como podemos acompanhar nesse post https://fedoramagazine.org/kernel-release-cycle/
ResponderExcluirAham, a política do Fedora permite atualizar minor versions dentro de um ciclo estável (major versions não).
Excluir