pledge() - uma system call do OpenBSD portada  para Linux

 Alguns dias atrás eu li o artigo From OpenBSD to Linux: How Pledge can Enhance Linux Security no site It's FOSS e como eu tenho um artigo voltado a system calls do Linux (Linx: Mais do que um Unix), decidi escrever esse para integrar ao assunto.

 pledge(), ou simplesmente Pledge, é uma system call do OpenBSD que foi portada para Linux por Justine Tunney. Na verdade esta implementação para Linux foi inspirada no pledge() do OpenBSD porém fazendo uso dos recursos da API do próprio Linux (já descrito no artigo Linux: Mais do que um Unix sobre a própria API do Linux) SECCOMP BPF (já abordado no meu artigo: Linux: Mais do que um Unix) e Landlock LSM (introduzido no kernel Linux 5.13 para reforçar a segurança). Pledge força os processos a serem executados de forma restrita e limitada dentro de um sandbox (algo que é ótimo para a execução de scripts e ferramentas automatizadas).

 Como descrito por Justine em seu site, "Pledge é como se fosse o fruto proibido que todos nós cobiçamos quando o chefe nos diz para utilizar algo como Linux"... pois ..."Linux nunca possuiu uma camada de segurança que meros mortais conseguissem entender"...; ..."Pledge torna a segurança mais compreensível". Bom, neste ponto não há como discordar de Justine visto como todos nós reclamamos como é trabalhoso configurar o SELinux (muitos até reclamam que a vida é muito curta para utilizar o SELinux) ou a diferença enorme de sintaxe entre iptables do Linux e o packet filter que apesar de muito famoso através do FreeBSD, o packet filter é na verdade do OpenBSD e foi portado para o FreeBSD. Até mesmo a sintax do antigo ipfw que o FreeBSD herdou do MacOSX possui sintax muito mais facil.

 Justine mesmo passou por situação como esta ao utilizar o SECCOMP BPF para implementar pledge:

"Houveram poucos desenvolvedores no passado que tentaram isso. Não vou citar nomes pois a maioria destes projetos nunca foram concluídos.  Quando se trata de SECCOMP, os tutoriais online explicam apenas como inserir lista de permissões das system calls em si, então a maioria das pessoas perdem interesse antes de compreender como filtrar argumentos. Os projetos que foram mais longe também tinham equívocos tal como permitir a alteração de setuid/setgid/sticky bits. Então nenhuma das alternativas atuais deveriam ser utilizadas. Acredito que esse esforço nos deixa muito mais próximos de ter pledge() do que nunca."

 Um apelo que faço a todas as comunidades Linux: Parem de perder tempo com bobeiras de ideologias e filosofias! Nós somos técnicos e não filósofos; deixem a filosofia para os filósofos e gastem tal energia elaborando documentações que inclusive, sejam de fácil compreensão. Vejam aí mais um grande exemplo de problema do Linux demorar ter um grande e tão importante recurso pela simples falta de uma boa documentação.

 Apesar disso, muitos esforços tem sido feitos para sanar tais problemas no Linux e torná-lo produtivo como o próprio e odiado (sem razão lógica) systemd que trás padronizações para as distribuições e torna a configuração dos serviços muito mais fácil; o Btrfs que facilita muito trabalhar com gerenciamento de volumes e outros recursos que, em outros sistemas de arquivos, eram serviços bem mais complexos de se trabalhar; o Netfilter que eu agradeço por nos conceder o nftables com sintaxe tão fácil que se aproxima do BSD pf (além de trazer também vários recursos que anteriormente eram difíceis de implementar no iptables).

 O segundo grande motivo que levou Justine portar Pledge para Linux foi devido a baixa adesão ao OpenBSD. Em 2002 a base de usuário de OpenBSD era de apenas 7.000 usuários tendo seu crescimento sempre baixo. O que nos leva a ideia de usuários não somente migrarem mas como também portar suas ferramentas para outro sistema operacional com maior base de usuários, melhor ecossistema e melhor adesão. Isso vem ocorrendo com a base de usuários do Solaris como relata Brendan Gregg em seu artigo Solaris to Linux Migration de 2017 que está ocorrendo migração e também port de ferramentas do Solaris para Linux como o caso do Dtrace:

 Eu venho portando muitas de minhas ferramentas do DTrace para o bpftrace e cubro estas no meu livro BPF Performance Tools: Linux System and Application Observability, as ferramentas que eu tornei publicas e open source aqui. Brendan Gregg

 Bom, e o terceiro motivo que eu ponho aqui é que Justine havia desenvolvido seu Pledge para ser utilizado como uma solução sandbox para o servidor web de sua própria autoria, o redbean. Justine chegou a conclusão que Pledge é tão robusto e útil que poderia reger outros processos; então, Justine teve uma grade ideia: Ao invés de configurar o Pledge diretamente no código fonte do programa como pode ser visto man page do OpenBSD ou no código do comando cat do OpenBSD: 

system call pledge sendo utilizado no código fonte: Medium

Justine desenvolveu um pequeno comando para utilizar o Pledge.

Opções do comando pledge

 Para executar o comando, basta digitar pledge (ou ./pledge caso ainda não houver salvo o comando dentro de um diretório da variável $PATH) seguido do comando desejado. Pldge é intuitivo, o próprio comando pledge indicará quais systemcalls serão necessárias para executar o comando desejado. Veja no exemplo abaixo a terceira coluna indicando quais syscall necessárias para executar o comando ls com o comando pledge:

syscalls necessárias para executar o comando ls

 A principio eu não consegui um bom resultado após adicionar as syscalls indicadas pelo pledge pois, após seguir o passo a passo de duas formas diferentes, o único resultado apresentado foi a mensagem invalid system call (core dump) e o Gnome reportando erros:

Erro apresentado ao executar o comando ls através do Pledge

 Depois, lendo um pouco mais no site da Justine, percebi que havia faltado a syscall rpath dentro das opções selecionadas e assim consegui executar normalmente. Apesar disso, o comando ls com a opção --l ainda apresentou dois erros sendo uma de permissão (talvez seja esse o motivo pois Justice menciona em seu site que é necessário utilizar pledge como root, algo que acabei não fazendo) e outro de syscall que eu não consegui encontrar nas opções (lgetxattr). Mesmo assim, no final das linha foi apresentado o resultado do comando com sucesso:

O comando ls sendo executado com o pledge de forma mais correta

 Agora resta a mim aprender melhor como utilizar o comando pldge. Eu vou continuar estudando e testando para ver como posso aplicar de forma mais clara.

 Bom trabalho feito pela Justine que merece todos os créditos principalmente pelo desenvolvimento da biblioteca libcosmopolitan (que lhe rendeu um premio do Google em 2023; o premio Open Source Peer Bonus que extremamente difícil de conquistar) e muitos outros recursos; alias, Justine é financiada por mais ou menos uma centena de desenvolvedores no GitHub.

 Apesar que Justine informar que só implementou por enquanto coisas descritas na man page do OpenBSD, ainda precisar trabalhar em materiais primários mas que são providos do pledge do kernel do OpenBSD, também precisam de mais feedback da comunidade.

 Andreas Kling adicionou o suporte a pledge() ao SerenityOS sendo o segundo sistema operacional a adotar os mecanismos pledge() e unveil() do OpenBSD. Talvez Linux é o terceiro sistema operacional a realizar esta façanha. Quem sabe no futuro esta system call faça parte até mesmo da API do Linux? Vantagem para todos nós.

Porting OpenBSD pledge() to Linux

GitHub - jart/pledge: OpenBSD APIs ported to Linux userspace using SECCOMP BPF and Landlock LSM

Toca do Tux: Linux: Mais do que um Unix

Mais sobre o OpenBSD aqui no blog

BSD is dying

From OpenBSD to Linux: How Pledge can Enhance Linux Security

QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :)

E não esqueçam de conferir também o meu mini curso de atributos no Linux

Licença GPL pode em breve morrer

 

A defesa do licenciamento FOSS recai sobre os ombros de um cara na Virgínia

 No dia 27 de Fevereiro de 2025 o site The Register publicou a noticia FYI: An appeals court may kill a GNU GPL software licens (Um tribunal de apelações pode matar uma licença de software GNU GPL). Tudo começa quando a empresa Neo4j inc processou as empresas PureThink e iGov por violações da licença de seu software e de direitos autorais (sendo esta a maior parte).

 A Neo4j inc desenvolve um sistema gráfico de gerenciamento de banco de dados tendo a versão community sob licença GPLv3. Porém, em 2018 o Neo4j EE (enterprise edition) foi migrada para a licença Commons Clause que permite manter a licença anteriormente adotada notando certas ressalvas do que pode ser ou não feito com o software, incluindo restrições comerciais por parte de terceiros. Foi dentro deste contesto que iniciou-se o processo legal pois as empresas processadas criaram um fork do Neo4j com o nome ONgDB sendo oferecendo como uma alternativa ao Neo4j. Isso pode ocorrer também com outro fork do Neo4j conhecido como DozerDB.

 A licença commons Clause é utilizado da seguinte forma; no final do texto da licença (de apenas 14 linhas no máximo) possui três linhas descrevendo o nome do software, a licença utilizada e o licenciador.

Descrição da licença Commons Clause

 Em sua FAQ descreve que a Commons Clause não é uma licença Open Source e que aplicando a Commons Clause a um projeto open source, significará que o código fonte está disponível e atende muitos dos elementos da Open Source Definition tal como livre acesso ao código fonte, liberdade de modificá-lo e liberdade de redistribuir.

 John Mark Suhy, fundador e CTO da PureThink e da Gov concedeu entrevista a The Register e afirmou que que está fazendo tudo em pro utilizando todas as suas economias para lutar contra isso no tribunal e que fica surpreso que a FSF não se importar muito com isso:

 "Eles sempre tem uma desculpa sobre não ter dinheiro para isso. Felizmente a Software Freedom Conservancy entrou e ajudou."

 Esse já não é o primeiro caso que a FSF não se manifesta. Questionada no caso de pessoas que foram presas por desbloquear o PS3 (por volta de 2010), a FSF respondeu que essa não é a luta deles. Outro caso foi das urnas que ela nunca se manifestou sobre o código fonte não ser publico.

 Agora devemos aguardar o desenrolar de toda esta história. Lembrando que o Neo4j Community Edition permanece livre (estando sob GPL3) e o caso ocorre sobre o Neo4j Enterprise Edition que é regido pela Commons Clause.

Adverse appeals court ruling could kill GPL software license • The Register

Free Software Foundation rides to defense of AGPLv3 • The Register

QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :)

E não esqueçam de conferir também o meu mini curso de atributos no Linux

openSUSE Tumbleweed migra para SELinux

Fonte da imagem: It's FOSS News

 No dia 19 de Fevereiro de 2025 Cathy Hu anunciou que o openSUSE Tumbleweed será migrado do AppArmor para SELinux como sistema MAC (Mandatory Access Control) padrão no próximo lançamento. A equipe já vinha debatendo sobre essa mudança desde Julho do ano passado pois, apesar das criticas de gerenciamento, o SELinux possui uma comunidade maior, melhor suporte e melhor aceitação em ambientes de segurança; algo que foi provado inicialmente no openSUSE MicroOS mas outros já vinham testando o SELinux no openSUSE por cinco anos.

 Foi informado que a instalação será realizada como enforcing mode como opção padrão porém:

"Se os usuários preferirem utilizar o AppArmor ao invés do SELinux, eles serão capazes de alterar a seleção para AppArmor manualmente no instalador. O AppArmor continua a ser mantido por Christian Boltz (@cboltz) exatamente como antes."

 Instalações existentes que utilizam o AppArmor não serão migradas; o Leap 15.x não foi afetado por essa mudança. Caso o usuário deseje migrar para o SELinux, o guia pode ser consultado na wiki do openSUSE wiki clicando aqui. Qualquer problema pode ser informado no bug report do Opensuse clicando aqui.

 Bom, eu particularmente já ouço os rangeres de dentes a toa por parte dos amantes de software livre simplesmente pelo fato de o SELinux ter sido criado pela NSA...

 

Leia o anuncio do SELinux como sistema MAC padrão no openSUSE Tumbleweed

Mais sobre Suse pode ser lido clicando aqui

Mais sobre a NSA pode ser lido clicando aqui

QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :)

E não esqueçam de conferir também o meu mini curso de atributos no Linux

Lançamento do ONLYOFFICE Docs v8.3: carimbos em PDF, compatibilidade de formato estendida, Mesclar Formas e muito mais

Lançamento do ONLYOFFICE Docs v8.3

 No dia 5 de Fevereiro o  Klaibson Natal Ribeiro Borges informou o lançamento do ONLYOFFICE Docs v8.3 e aqui está uma rápida visão geral dos principais novos recursos:

• Visualização de formatos Apple iWork (Pages, Keynote, Numbers) e arquivos Hancom Office (.hwp e hwpx) e sua conversão para OOXML para edição posterior.
• Carimbos profissionais e seleção de várias páginas em arquivos PDF;
• Atualização automática de links externos e novas opções de preenchimento automático em planilhas;
• Nova guia Design e desenho em slides durante uma apresentação de slides em apresentações;
• Recurso Mesclar Formas em documentos, planilhas, slides e PDFs;
• Aprimorado para idiomas da direita para a esquerda (RTL) e muito mais.

Para saber mais, assista ao webinar no canal do OnlyOffice no YouTube ou leia blog OnlyOffice. A versão desktop gratuita do pacote para Windows, Linux e macOS será atualizada posteriormente.

Baixe o ONLYOFFICE Docs v8.3 gratuitamente

QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :)

E não esqueçam de conferir também o meu mini curso de atributos no Linux

 

 Lançado Nim 2.2.2

 A equipe da linguagem Nim anunciou no dia 05 de Fevereiro de 2025 o lançamento da versão 2.2.2; quatro meses após o lançamento da versão  2.2.0 e contem 203 commits, trazendo bugfixes (um total de 35) e melhorias. A lista completa de mudanças está disponível aqui.

 A versão Nim 2.2.2 pode ser baixada diretamente neste link ou através do comando choosenim (garanta somente que a versão do choosenim é a 0.8.5 ou superior):

$ choosenim update self

$ choosenim update stable

Nim version 2.2.2 released - Nim Blog

Leia mais sobre a linguagem Nim clicando aqui

QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :)

E não esqueçam de conferir também o meu mini curso de atributos no Linux

Lançado toybox 0.8.12

 Quase nove meses depois do seu ultimo lançamento, No dia 18 de Janeiro foi lançada a versão 0.8.12 do toybox. Essa nova versão não traz nenhum novo comando, nenhum comando promovido e foi mais focado em trazer novos recursos a comandos já existentes e várias correções.

RECURSOS

 Nesta nova versão o comando netcat recebeu as opções de saída hexadecimal -o para evitar grupos de entrada original e -O para contínuos. Além destas, agora netcat -f permite a comunicação com dispositivos serial.

 O comando tar agora permite tratar com alguns formatos obsoletos de tarballs além de permitir também compactar utilizando zstd (-Z ou --zstd); o comando devmen recebeu as opções -f ARQUIVO, --no-sync e --no-mmap; o comando mount recebeu a opção LABEL= e Firas Khana (autor da distribuição Glaucus Linux que eu tive a chance de entrevista-lo) fez com que os comandos lsusb e lspci verifiquem também dentro do diretório /usr/share/hwdata. O comando dmesg recebeu a opção -W (--follow-new) e o getconf recebeu as opções NPROCESSORS_CONF e NPROCESSORS_ONLN.

toysh, sh e bash

 Os comandos que a equipe do toybox mais pretende alcançar um bom nível de maturidade são o toysh, o sh e o bash pois estes comandos são essenciais para a execução de scripts e inicialização tanto do sistema operacional quanto da sessão de login. Tendo estes comandos completamente funcionais torna possível ter um sistema operacional com um shell independente. O grande problema é que eles ainda não estão prontos para serem utilizados em produção tendo a equipe um longo trabalho pela frente até conseguir obter algo realmente funcional e compatível com outros shells. Confira meu vídeo abaixo a respeito do bug que eu reportei a equipe:

 Bom, o que podemos fazer agora é aguardar para que estes três comandos amadureçam ao ponto de poderem ser compatíveis com todos os nossos scripts. Voltando as novidades, foram adicionados ao comando test as opções -ef, -ot e -nt seguindo a especificação POSIX 2024.

 Foi implementado return, move break e continue para substituir special cases; houveram mudanças no design que permitem "trap" assincronamente chamar funções de um manipulador de interrupções e aplicaram outras correções. Dentre os testes com  TEST_HOST que passou no bash 5.2.

Vi

 E por que não falar da implementação do editor de texto vi já que falamos de shellscript e se tratar de uma ferramenta necessária para a criação de nossos scripts? A implementação do vi do toybox (ainda como pendente) recebeu suporte a tratar de argumentos inválidos da opção `:g`  sem gerar buffer overflow; correção de buffer overflow quando entrar comandos longos; simplificação de testes e verificação de leitura de out of bounds em buffer vazio na opção `p`.

PENDENTES

 Nos pendentes estão a implementação do awk.c que recebeu 46 commits até o momento; o comando diff recebeu a opção --no-dereference e correção nas comparações entre links simbólicos e fifos; o cornd recebeu várias correções; o stty recebeu FLUSH ao invés de DRAIN e o toybox recebeu suporte inicial a UTF-8.

 Houveram várias correções de bugs e limpezas; a biblioteca do toybox recebeu modificações e remoção de recursos legados. Agora é usufruir das novidades da nova versão e aguardar pela versão 1.0 (torço muito por isso).

para conferir as novidades completas da versão 0.8.12 toybox, basta clicar aqui

Mais sobre o toybox pode ser lido clicando aqui

Mais sobre a distribuição Glaucus pode ser lido clicando aqui

QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :)

E não esqueçam de conferir também o meu mini curso de atributos no Linux

 

BZip3: Um sucessor espiritual do bzip2

 Recentemente eu postei o artigo Qual o futuro do bzip2? descrevendo história de mantenedores, o perigo que isso poderia ser já que tivemos história parecida com ao do xz, quem é o seu atual mantenedor e os planos para o seu futuro. 

 Além de agora o bzip2 ter uma nova equipe e ter surgido uma implementação em Rust do bzip2, a desenvolvedora alemã Kamila Szewczyk desenvolveu o BZip3, o sucessor espiritual do bzip2 baseado no BWT (Burrows-Wheeler transform code) sendo este melhor, mais rápido e mais poderoso.

POR BAIXO DO CAPÔ

 O bzip3 foi projetado para fazer uso de multi-thread (algo que planejam implementar como pode ser conferido no anrtigo no bzip2) e supera o desempenho de compactadores como bzip2, zstd, LZMA e RAR. Seu processamento geralmente é linear mas pode realizar codificação paralela que pode possuir velocidade do linear em computadores multi-CPU e multi-core (já que cada bloco é codificado independentemente).

 Particularmente eu acredito que ainda preciso entender melhor como funciona o BZip3 pois, fazendo teste descompactando o próprio código do BZip3, que dá um total de mais de 7 Megabytes, eu não consegui atingir o máximo de compressão oferecido atingindo no máximo 2.8M de compactação enquanto que baixando o BZip3 compactado com bzip2 tem o tamanho de 332K e com o xz, 280k. Estranhamente eles mesmo disponibilizam seu código também compactado com bz3 com o tamanho de 270... 

Testando a compactação do BZip3 e comparando com o gzip, bzip2 e o xz

 O BZip3 combina vários algoritmos como um contexto de order-0 que mistura codificador de entropia (métodos de compressão sem perda de dados); uso do BWT já anteriormente mencionado para processamento tempo linear e construção de arrays de sufixo do texto e então deduzir as strings do BWT (um oposto realizado pelo bzip2); uma variante especial Run-length encoding (RLE) iniciado no dado inicial que realiza a estimativa e ajustes antes de iniciar a compressão, algoritmos de Abraham Lempel e Jacob Ziv (Lempel ziv+Prediction pass = LZP), o LZ77 e codificação aritmética utilizando indicador de  modelagem de contexto.

 Uma coisa interessante é BZip3 não considera níveis (-1 a -9) como uma métrica de seu desempenho permitindo o usuário explicitamente especificar o tamanho do bloco de compressão (que vão de 65 KiB a 511 MiB) com a premissa de quanto maior o bloco, melhor se torna a compressão.

Tamanho de compressão dos blocos no BZip3

 Assim como o gzip e o bzip2, o bzip3 é somente um compactador de arquivos individuais. O tar é necessário para arquivar diretórios e assim poder compacta-los. Ao concluir a compactação, o BZip3 gera um arquivo BZ3v1.

LICENÇA

 Os códigos do BZip3 estão sob diferentes licenças já que faz uso de vários recursos e algoritmos. Porém, o BZip3 está sob a LGPv3. O código é escrito na linguagem C e existem algumas partes em Python, PHP, Racket e Lua.

 

ARQUITETURAS E SISTEMAS OPERACIONAIS

 O BZip3 está disponível para várias distribuições Linux, MacOS, diferentes BSDs e Windows. Também está disponível para x86, x86_64, armv6, armv7, aarch64, ppc64le, mips, mips64, sparc e s390x.

Github do BZip3

Leia mais sobre compactadores

QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :)

E não esqueçam de conferir também o meu mini curso de atributos no Linux

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.

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. 

• compress/doc/bzip2-format.pdf at master · dsnet/compress (github.com)
• bzip2
• Maintaining BZip2 (micahsnyder.dev)
• Micah · GitLab
• Introduction (micahsnyder.dev)
• Cisco-Talos/clamav: ClamAV - Documentation is here: https://docs.clamav.net (github.com)
• ClamAV® blog: Celebrating 20 years of ClamAV

QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :)

E não esqueçam de conferir também o meu mini curso de atributos no Linux

Lançado Alpine Linux 3.21.0

  Hoje, dia 05/12/2024, foi lançada a versão 3.21.0 do  Alpine Linux. Essa nova versão trás o kernel Linux 6.12, o GCC 14 e o LLVM 19, o Node.js lts 22.11, Rust 1.83, Crystal 1.14, Go 1.23, PHP 8.4, Sway  1.10 e o .NET 9.0.

 Na parte de interface gráfica o Alpine 3.21.0 trás o GNOME 47, o KDE Plasma 6.2 e o LXQt 2.1 e com isso, o Qt 6.8.

 Agora o Alpine Linux passou a ter suporte inicial ao loongarch64 (que nada mais é do que um MIPS chinês) e o linux-firmware agora é compactado com o ZSTD.

 Vi relato de que o desempenho dessa versão está tão bom que ao atualizar da versão anterior, o Alpine concluiu o  Nextcloud container em menos de 10 minutos (só levou muito tempo por conta da transição do PHP 8.2 para 8.3 e precisou da instalação de algumas aplicações. O Nginx levou menos de 30 segundos e o Postfix menos de um minuto.

Mais sobre o Alpine Linux pode ser lido aqui

Baixe o Alpine Linux 3.21.0 clicando aqui

QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :)

E não esqueçam de conferir também o meu mini curso de atributos no Linux