Toca do Tux: Qual o futuro do Bzip2?

Fonte da imagem: PNGWING

Por volta de Março de 2024 testemunhamos uma vulnerabilidade no SSH devido a um backdoor no xz e como todos se lembram, esse backdoor foi inserido pelo próprio "atual mantenedor" do xz que até ninguém faz a mínima ideia quem seja. Coincidência ou não o bzip2 anda passando por problema similar com seus mantenedores. O que nos leva a seguinte questão: Qual o futuro do bzip2?

Historicamente, o nível de compactação do bzip2 é tão potente (muito próximo ao do xz; confiram a minha aula sobre des/compactadores e empacotadores disponível livremente no meu curso de migração para Linux) que a medida que o kernel crescia em recursos e ficava maior, a solução acabou sendo disponibiliza-lo compactado com bzip2. Inclusive uma das principais opções de compactação do kernel durante o seu processo de compilação foi o bzip2 utilizando make bzimage.

Aula de des/compactadores e empacotadores no Linux. É possível reparar o nível de compactação de cada um dos compactadores

Apesar do seu nível de compactação ser melhor do que a do gzip, uma de suas desvantagens do bzip2 é o seu alto uso de CPU e o tempo de compactação e descompactação.

porém o real problema do bzip2 é que durante muito tempo ele não recebeu atualizações significativas, o que acarretou em acumulo de falhas, vulnerabilidades, não havendo repositório de controle de código fonte e nem rastreamento de bugs. Uma das poucas atualizações que o bzip2 recebeu eu cheguei a publicar no meu antigo blog em 2010. Por estes motivos, no final de 2013 o kernel passou a ser disponibilizado compactado sob o xz (leiam o artigo Happy new year and good-bye bzip2). Quando foi descoberta a vulnerabilidade no xz detectada no SSH, o kernel passou a ser disponibilizado temporariamente compactado com o gzip mesmo ficando um pacote bem maior e nem mesmo cogitando disponibiliza-lo sob o bzip2.

Happy new year and good-bye bzip2

Transições entre mantenedores

Em Junho de 2019, Federico Mena Quintero, um dos fundadores do projeto GNOME, anunciou que passou a ser o mantenedor do bzip2 chegando a lançar a versão 1.0.7 poucos dias depois do seu anuncio. Em julho de 2019 Mark Wielaard disponibilizou a versão 1.0.8 e depois disso não houveram mais grandes novidades. Federico Não tinha tempo o suficiente para concluir os objetivos que havia proposto e Micah não teve respostas claras sobre o futuro do bzip2 não fazendo revisão do trabalho de Micah para a versão 1.1.0. Então em Junho de 2021 Micah D. Snyder anunciou em seu blog que havia se tornado o principal mantenedor do bzip2. Se o xz passou por situação similar entre os mantenedores fazendo com que nos deparássemos com um backdoor, será que não estamos diante da mesma história só que desta vez no bzip2? Essa situação nos leva ao próximo questionamento: Quem é Micah D. Snyeder?

QUEM É MICAH D. SNYDER?

Micah D. Snyder é desenvolvedor da empresa Talos Intelligence, uma divisão da Cisco focada em pesquisas sobre ameaças comprovadas e confiabilidade. A Talos é responsável pelo desenvolvimento do IPS Snort e do antivirus ClamAV sendo Micah um dos principais responsáveis pelo seu avanço. Há até mesmo uma carta de celebração de 20 anos do ClamAV que entre eles, está o nome de Micah nas notas de agradecimento. Além de entusiasta em python, Micah também é fascinado por Rust. Então estamos seguros quanto a possibilidade de se repetir história parecida com a do xz que teve um mantenedor anônimo e acabou injetando um backdoor em seu código (deem valor a estas pessoas).

Qual o futuro do Bzip2?

Micah quer trabalhar no lançamento da versão 1.1.x do bzip2 que já era uma promessa antiga dos mantenedores. O status desta versão pode ser conferido no site oficial do sourceware que ainda está em estado experimental; Micah pretende modernizar a base de código do bzip2 como utilizar Meson build system e CMake build system ao invés de somente de Makefiles; coletar os vários patches da comunidade e melhorias significativas na compatibilidade com C99.

bzip2 sendo portado para Rust?

Como Micah é um entusiasta da linguagem Rust, foi lhe perguntado sobre a possibilidade de portar bzip2, a o que Micah respondeu que abandonou esse projeto. Na verdade estão preferindo trabalhar no suporte a multithreading em C (que para Micah é algo que seria muito interessante principalmente nas futuras versões 1.2 or 2.0 SE alguém trabalhar nisso) do que qualquer coisa em Rust. Houve no passado o projeto BZIP2SMP baseada na versão v1.0.2 que falhou portar para a versão 1.0.8 e já que existe outro projeto de port do bzip2 para Rust sendo desenvolvido por outro grupo e que Micah apoia que as pessoas contribuam para ele. Esse projeto está em melhor estágio de evolução, boa licença, bom suporte a compressão e descompressão. Mas estranhamente, a versão 1.1.x virá com um port experimental para Rust... Vai entender a vida...

Este projeto de port de bzip2-Rust pode ser conferido clicando aqui.

Eu estou testando o bzip2-rust porém com cautelas pois, como menciona o próprio projeto, "você utiliza por sua própria conta e risco". por enquanto parece que está completo na questão de opções (minha critica ainda fica na questão do tamanho dos binários.

Implementação do bzip2 em Rust

Trabalhem nisso, galera de rust; vocês ainda nem usam garbage collectors para justificarem esse exagero). Outras observações feitas pela equipe do bzip2 quanto portar o bzip2 para rust é que rust trabalha muito bem na maioria dos processadores i686 e x86_64 porém, em outras plataformas como armel, armhf, armv7, mips{64}, powerpc{64} e riscv{64} carece de suporte de primeira classe. Muita cautela ao pensar na adoção de Rust, não vão com muita sede ao pote. Ao invés disso, conheçam e analisem também outras linguagens Nim e Odin (Zig também é promissora) que também possuem suporte a segurança em memória e melhor suporte a arquiteturas.

CONCLUSÃO

Na questão do bzip2, vemos que estamos bem amparados se comparado com a recente história do xz, espero que tenhamos aprendido algo com isso e que possamos nos planejar melhor para as situações ao invés de perdemos tempo com conversas ideológicas.