O salto para RPM 6.0 marca um antes e um depois no gerenciador de pacotes mais difundido no ecossistema de Red Hat Enterprise Linux, SUSE e derivados. Esta versão combina anos de trabalho para modernizar a segurança, os formatos de pacotes e as ferramentas, e isso é evidente em todos os aspectos do projeto. Se você gerencia sistemas ou software de pacotes, essa mudança é importante porque afeta a maneira como você cria, assina, verifica e instala pacotes.
O lançamento foi feito em 22 de setembro de 2025 e segue um candidato que finalmente foi confirmado como a versão final. Além do anúncio público, há um grande esforço na documentação e mudanças de comportamento padrão. RPM 6.0 Apresenta suporte para o novo formato v6 e fortalece a verificação criptográfica, mantendo o suporte para pacotes v4 e eliminando a instalação do v3.
O que é RPM 6.0 e por que é importante
Com o RPM 6.0, o projeto consolida práticas de assinatura mais seguras, descontinua algoritmos desatualizados e abre caminho para um formato de pacote pronto para tamanhos e metadados modernos. O formato v4 completa 25 anos e a base de código está se aproximando de seu 30º aniversário., então essa grande revisão foi necessária para adequá-lo aos padrões atuais e ao tamanho dos repositórios contemporâneos.
O anúncio oficial destaca marcos como o gerenciamento de múltiplas assinaturas do OpenPGP, suporte para chaves e assinaturas do OpenPGP v6 (incluindo criptografia pós-quântica) e a adoção de estratégias para obter tarballs de lançamento verificáveis e imaculados. O objetivo principal é elevar o nível de segurança sem comprometer a compatibilidade. no cotidiano de embaladores e administradores.
Downloads e pegadas
A distribuição inclui o arquivo fonte principal rpm-6.0.0.tar.bz2, acompanhado de sua soma de verificação SHA256 para verificação de integridade. SHA256: 14abb1b944476788d90005d8d61d5d30fce80d9f0de11eb657b14e5c9ef27441.
Visão geral das alterações em comparação com 4.20.1
- Suporte para pacotes v4 e v6, com notas detalhadas de compatibilidade.
- Várias assinaturas OpenPGP por pacote e suporte para chaves OpenPGP v6 e PQC.
- Atualizando chaves importadas anteriormente e usando a impressão digital ou ID completa durante todo o ciclo.
- O instalador do pacote v3 está sendo descontinuado; ele pode ser visualizado e extraído com rpm2cpio, mas não instalado.
- Aplicação rigorosa da verificação de assinatura por padrão, aumentando a segurança do ecossistema.
- Grande revisão das páginas de manual e da documentação, com conteúdo versionado no site oficial.
- Tarballs de lançamento verificáveis e imaculados, fortalecendo a reprodutibilidade e a auditoria.
Mudanças e melhorias para uso geral
O utilitário rpmkeys ganha muito peso no gerenciamento de chaves: Agora permite atualizar chaves com rpmkeys –import (incluindo a atualização do identificador curto ambíguo para uma impressão digital completa), importar de um pipe, exportar com rpmkeys –export e operar consistentemente em diferentes backends de keychain. Além disso, com rpmkeys –rebuild, o conteúdo do keychain pode ser reconstruído e migrado entre backends, e as pesquisas de chaves agora não diferenciam maiúsculas de minúsculas.
rpmsign também dá um salto: Pode ser assinado com GnuPG ou Sequoia-sq controlado com a macro %_openpgp_sign. O subcomando rpmsign –addsign não substitui mais assinaturas existentes; por padrão, ele adiciona qualquer número de assinaturas aos pacotes v6 e também aos pacotes v4 se –rpmv6 for usado. RPMsign –resign, por outro lado, substitui todas as assinaturas anteriores por uma nova.
Para consultas, extensões de tags como rpmformat (descubra se é v3, v4 ou v6) e openpgp (gerenciamento de todas as assinaturas OpenPGP) são adicionadas. O formatador :hashalgo é adicionado para exibir nomes de algoritmos de hash, e o alias –filemime aparece para consultar o MIME por arquivo. A terminologia é padronizada em todas as mensagens: o OpenPGP é usado de forma consistente, e as assinaturas de cabeçalho e carga útil v3 são rotuladas como legadas.
Nova função de cálculo e correções de bugs no RPM 6.0
Um novo recurso calcula um conjunto configurável de resumos durante a verificação e os salva no banco de dados RPM, ajudando a identificar o arquivo do pacote de origem. Vários problemas operacionais resolvidosErros de scriptlet agora afetam códigos de resultados de transações; certos gatilhos com falha impactam operações relacionadas; e problemas com –hash, –percent e –test em conjunto com –restore foram corrigidos.
Bugs como falhas de segmentação e vazamentos no rpmgraph, o sufixo usado pelo rpm2archive para tar e cpio, foram corrigidos, e uma grande reescrita das páginas de manual foi realizada: Estilo uniforme com exemplos, novas páginas para componentes e formatos, realocando comandos de usuário para a seção 1 e abordando aspectos anteriormente não documentados. A documentação versionada no site oficial inclui páginas de manual, um manual de referência e uma API.
Embalagem e construção de embalagens
O rpmbuild agora pode gerar dois formatos diferentes controlados pela macro %_rpmformat (valores 6 ou 4). Além disso, a autoassinatura é habilitada na compilação Se %_openpgp_autosign_id for definido, a ferramenta rpm-setup-autosign for adicionada para facilitar essa configuração.
Em macros, %{span:…} é adicionado para facilitar definições de várias linhas e %{xdg:…} é adicionado para avaliar caminhos base XDG. Suporte para arquitetura E2K adicionado e uma bateria de correções: ordem de origem e patches no cabeçalho, Lua glob respeitando o argumento c, validação de arquitetura no ponto correto, aceitação de seções %prep específicas do sistema de construção e correções em check-rpaths quando RPATH e RUNPATH coexistem.
Corrige um vazamento de memória em rpmspec –shell, uma regressão 4.20 em rpmbuild -rs com diretórios inexistentes e uma nova linha extra em rpm –eval. Um erro de segmentação também foi corrigido. no caso de saída inválida do construtor de dependências no modo multi, e a política brp-selfperms foi removida. Por fim, a opção obsoleta –nodirtokens do rpmbuild foi removida.
Alterações na API
Na área de chaves, são adicionadas funções para iterar e gerenciar chaves: rpmKeyringInitIterator, rpmKeyringIteratorNext, rpmKeyringIteratorFree, rpmKeyringVerifySig2, rpmKeyringLookupKey e rpmKeyringModifyPara rpmPubkey, acessadores como rpmPubkeyFingperint, rpmPubkeyFingerprintAsHex, rpmPubkeyKeyIDAsHex e rpmPubkeyArmorWrap são adicionados, bem como rpmPubkeyMerge para mesclar descritores da mesma chave.
Para o conjunto de chaves de transação permanente, rpmtxnImportPubkey, rpmtxnDeletePubkey e rpmtxnRebuildKeystore estão incluídos. A operação rpmSign é controlada com novos sinalizadores: RPMSIGN_FLAG_RESIGN, RPMSIGN_FLAG_RPMV4 e RPMSIGN_FLAG_RPMV6. rpmteVfyLevel e rpmteSetVfyLevel, junto com seus equivalentes te.VfyLevel e te.SetVfyLevel, também foram adicionados às vinculações do Python.
Para assinaturas múltiplas, identificadores como RPMTAG_OPENPGP, RPMSIGTAG_OPENPGP (alias dos anteriores) e o sinalizador de verificação RPMVSF_NOOPENPGP aparecem. Novos rótulos são adicionados: RPMTAG_PAYLOADSIZE, RPMTAG_PAYLOADSIZEALT, RPMTAG_RPMFORMAT, RPMTAG_FILEMIMEINDEX, RPMTAG_MIMEDICT, RPMTAG_FILEMIMES, RPMTAG_SOURCENEVR, RPMTAG_PAYLOADSHA512, RPMTAG_PAYLOADSHA512ALT, RPMTAG_PAYLOADSHA3_256, RPMTAG_PAYLOADSHA3_256ALT, RPMTAG_SHA3_256HEADER.
Há tags renomeadas: RPMTAG_PAYLOADDIGEST foi movido para RPMTAG_PAYLOADSHA256, RPMTAG_PAYLOADDIGESTALT foi movido para RPMTAG_PAYLOADSHA256ALT e RPMTAG_PAYLOADDIGESTALGO foi marcado como obsoleto em RPMTAG_PAYLOADSHA256ALGO. Identificadores SHA-3 são adicionados: RPM_HASH_SHA3_256 e RPM_HASH_SHA3_512, bem como símbolos relacionados a MIME por arquivo em pacotes v6, como rpmfilesFMime e rpmfiFMime, e o sinalizador RPMFI_NOFILEMIME.
No domínio OpenPGP, identificadores compatíveis com RFC 9580 e a função pgpDigParamsSalt são adicionados para recuperar o pré-sal de assinaturas v6. Para pacotes de resumo, rpmDigestBundleUpdateID aparece. (atualiza identificadores individuais). Outros novos recursos: rpmtsAddInstallElement retorna 3 para formatos não suportados e fdSize relata um erro para arquivos não regulares.
Melhores internas
O código RPM foi movido para C++20 (exceto para plugins e vinculações Python). As fontes foram renomeadas para .cc e .hh, estruturas dinâmicas são migradas para STL e a contagem de referências é reforçada com operações atômicas. Além disso, o conjunto de testes é expandido e a criação de testes é simplificada.
Uma abstração de chaveiro real e um backend experimental baseado em openpgp.cert.d são introduzidos. Adicionado build make site target para renderizar a documentação local, e a imagem de teste se adapta à caixa de ferramentas. Sublinhados são permitidos em nomes RPMTAG, e regressões foram corrigidas, como o tamanho reservado para assinaturas e o mecanismo de alternativas que interferia nas assinaturas.
Leituras de keychain corrigidas sem bloqueio de transação, uma condição de corrida em rpmioMkpath, profundidade de recursão em mensagens de erro de macro e um caso em que campos passwd ou group vazios faziam com que as entradas fossem ignoradas. Macros internas estão disponíveis novamente antes de carregar arquivos, o erro fdSize em rpmSign é tratado corretamente, as pseudo-tags são limpas em –querytags e o prefixo de instalação é respeitado nos scripts legados find-provides e find-requires.
Outras melhores coisas internas
Também foram corrigidos vazamentos de referência relacionados a arquivos no Python, o armazenamento de dependências foi estabilizado para evitar o não determinismo, o escape de chroot no script sysusers com entradas u! foi corrigido e uma regressão de 4.19 em códigos de retorno de atualização com falha foi corrigida. Aviso sobre arquivos de macro em rpmrc, o bloqueio de transação é recriado após –rebuilddb, fornece gpg(keyid) é removido de gpg-pubkey, e símbolos que foram vazados acidentalmente para o ABI são limpos.
Usos não portáteis de sinal foram removidos, o bloqueio do rpmlog foi otimizado e as vinculações do Python oferecem suporte ao isolamento de módulo para vários subinterpretadores e corrigem vazamentos de recursos com testes ASAN. São melhorias que melhoram a robustez, a portabilidade e a manutenibilidade. em todas as frentes.
Requisitos para compilar RPM
Agora é necessário um compilador C++20, além do C99; o suporte ao módulo C++20 não é mais necessário. Para construir com Sequoia, é necessário rpm-sequoia 1.9.0 ou superior (e é a opção padrão), Python 3.10 ou superior para ligações e o gerador scdoc para páginas de manual.
A documentação da API pré-compilada não está mais incluída nos tarballs de lançamento; compilá-la é opcional com o Doxygen. APIs pré-construídas por versão estão disponíveis no FTP do projeto.
Principais notas sobre compatibilidade e formato do RPM 6.0
O formato de pacote v6 traz tamanho de arquivo de 64 bits e limites relacionados, modernização criptográfica com a remoção de MD5 e SHA1, hashes SHA3-256 no cabeçalho e resumos SHA512 e SHA3-256 na carga útil. As informações MIME são adicionadas por arquivo, e há amplo suporte para RPM a partir da versão 4.14 (com nuances). O modo gerador de dependências externas não é mais suportado na versão 6, e as dependências rpmlib legadas anteriores à 4.6 foram removidas para eliminar ruídos.
Os pacotes v6 podem ser verificados com RPM a partir da versão 4.6, descompactados com a versão 4.12 e verificados e instalados com a versão 4.14 ou superior, sujeitos às limitações conhecidas. Os pacotes v4 continuam totalmente suportados e os gerados pela versão 6.0 são idênticos aos da versão 4.x; no entanto, na configuração padrão, pacotes compilados com RPMs inferiores a 4.14 não são verificados porque usam resumos fracos. Você pode definir %_pkgverify_level como assinatura para ignorar esses resumos ou restaurar o comportamento da versão 4.x definindo %_pkgverify_flags como 0 se a verificação de resumo fraco for necessária.
A instalação v3 foi removida, embora possa ser visualizada e extraída com rpm2cpio. Por padrão, o RPM cria pacotes v6; isso pode ser revertido definindo %_rpmformat como 4. Em pacotes construídos com RPM 6.0 ou superior, a família Lua posix.fork é desabilitada, enquanto em pacotes construídos com 4.20 ou anterior ela continua funcionando.
Outras considerações: a configuração da chave de assinatura agora é definida com %_openpgp_sign_id (compatibilidade com versões anteriores de %_gpg_name), macros de assinatura de baixo nível se tornam paramétricas e substituições personalizadas de %__gpg_sign_cmd não funcionam mais imediatamente. %_passwd_path e %_group_path podem ser listas separadas por dois pontos. para usar múltiplas fontes NSS, e as opções de consulta –pkgid e –hdrid são removidas.
RPM 6.0 e Fedora 43: Escopo, benefícios e testes
A atualização para RPM 6.0 em Fedora 43 Ele busca fortalecer a segurança e preparar o terreno para o formato v6, mas sem ainda adotar o novo formato como padrão. O Fedora 43 continuará gerando a v4 por padrão., e a aplicação rigorosa da verificação de assinatura será abordada como uma mudança de sistema em uma versão futura.
Os principais benefícios do Fedora incluem: as chaves OpenPGP agora são sempre identificadas por impressão digital ou ID completo, elas podem ser atualizadas com rpmkeys –import, várias assinaturas por pacote são suportadas, a autoassinatura local é suportada durante compilações e o uso do Sequoia-sq como uma alternativa ao GnuPG. Também torna mais fácil testar o formato v6 no ecossistema sem forçar sua adoção global.
Fora do escopo: migração geral do Fedora para o formato v6 ou alteração do modo de verificação padrão. Os agentes de mudança são responsáveis por exceder o RPM e ajudar com incompatibilidades, enquanto o restante dos desenvolvedores deve testar, relatar problemas e adaptar ferramentas de terceiros quando necessário.
Impacto de atualização e compatibilidade: scripts e ferramentas de terceiros podem exigir ajustes devido ao novo formato de endereço de chave e alterações de saída relacionadas à assinatura. Para testes iniciais É aconselhável validar: atualização de chaves importadas, gerenciamento de keychain com rpmkeys e compatibilidade do formato v6 com software externo (compilando com %_rpmformat para 6).
Experiência do usuário do RPM 6.0 no Fedora
Experiência do usuário: a saída de assinatura e chave é padronizada para letras maiúsculas e minúsculas, e as chaves são exibidas por impressão digital ou ID completo, abandonando o antigo ID curto propenso a colisões. rpmkeys é estabelecido como uma ferramenta oficial para manipular o keychain; métodos antigos, como tocar manualmente em pseudo-pacotes gpg-pubkey, estão obsoletos e devem ser migrados para rpmkeys ou para as novas APIs.
Dependências: O SOName não muda, portanto, não é necessário reconstruir dependências; não há dependências em outras alterações do Fedora. O RPM é construído em C++, portanto, adiciona uma dependência de tempo de execução à libstdc++. A assinatura com o Sequoia requer sequoia-sq 1.0 ou superior como uma dependência opcional e afeta apenas a assinatura do pacote.
Plano de contingência: reverter para o RPM 4.20 se necessário, com prazo de congelamento do beta, sem bloquear o lançamento. A entrega continua mesmo que o formato v6 ainda não seja o padrão na distribuição.
Notas de lançamento e anúncio de histórico do RPM 6.0
O candidato anterior incorporou correções de bugs e atualizações de páginas de manual e foi promovido à posição final. O anúncio assinado pela equipe do RPM Ele destaca que o trabalho foi feito em direção a esse marco desde o reinício do rpm.org por volta de 2007, com marcos como tamanhos de arquivo de 64 bits, geradores de dependências plugáveis, plug-ins de transação, dependências avançadas, gatilhos de arquivo, melhorias no debuginfo, novos backends de banco de dados, integração com Lua e expressões de macro, requisitos de construção dinâmicos, geração de especificações, suporte a usuários e grupos e sistemas de construção declarativos.
Mais de 300 pessoas contribuíram com código de diversas distribuições e organizações. A história do projeto e sua comunidade explicam a estabilidade e o escopo que o RPM 6.0 herda e expande.
A perspectiva para o RPM 6.0 é de um gerenciador de pacotes fortalecido para a próxima década: Melhor criptografia, formato de alto volume, ferramentas mais poderosas e documentação atualizada., com um caminho de compatibilidade claro para administradores, empacotadores e ecossistemas adotarem novos recursos sem problemas.
