El salto a RPM 6.0 marca un antes y un después en el gestor de paquetes más extendido en el ecosistema de Red Hat Enterprise Linux, SUSE y derivadas. En esta entrega confluyen años de trabajo para modernizar seguridad, formato de paquetes y herramientas, y se nota en cada rincón del proyecto. Si administras sistemas o empaquetas software, este cambio te interesa porque afecta a cómo construyes, firmas, verificas e instalas paquetes.

La publicación se realizó el 22 de septiembre de 2025 y llega tras una candidata que finalmente se ha confirmado como versión final. Además del anuncio público, hay un esfuerzo grande en documentación y en cambios de comportamiento por defecto. RPM 6.0 introduce compatibilidad con el nuevo formato v6 y refuerza la verificación criptográfica, a la vez que mantiene el soporte para paquetes v4 y elimina la instalación de v3.

Qué es RPM 6.0 y por qué importa

Con RPM 6.0, el proyecto consolida prácticas más seguras de firma, desactiva algoritmos obsoletos y abre la puerta a un formato de paquete preparado para tamaños y metadatos modernos. El formato v4 cumple 25 años y la base de código se acerca al 30 aniversario, así que esta revisión mayor era necesaria para ponerse a la altura de los estándares actuales y del tamaño de los repositorios contemporáneos.

El anuncio oficial destaca hitos como la gestión de múltiples firmas OpenPGP, soporte para claves y firmas OpenPGP v6 (incluyendo criptografía postcuántica), y la adopción de estrategias para obtener tarballs de lanzamiento inmaculados y verificables. El objetivo principal es elevar el listón de seguridad sin romper la compatibilidad en el día a día de empaquetadores y administradores.

Descargas y huellas

La distribución incluye el archivo fuente principal rpm-6.0.0.tar.bz2, acompañado por su suma SHA256 para comprobación de integridad. SHA256: 14abb1b944476788d90005d8d61d5d30fce80d9f0de11eb657b14e5c9ef27441.

Visión general de cambios frente a 4.20.1

• Soporte de paquetes v4 y v6, con notas de compatibilidad detalladas.
• Firmas OpenPGP múltiples por paquete y soporte para OpenPGP v6 y claves PQC.
• Actualización de claves previamente importadas y uso de huella o ID completo en todo el ciclo.
• El instalador de paquetes v3 se retira; se pueden consultar y extraer con rpm2cpio, pero no instalar.
• Aplicación estricta por defecto de la comprobación de firmas, elevando la seguridad del ecosistema.
• Gran revisión de páginas de manual y documentación, con contenido versionado en la web oficial.
• Tarballs de publicación prístinos y verificables, reforzando reproducibilidad y auditoría.

Cambios y mejoras para uso general

La utilidad rpmkeys gana muchísimo peso en la gestión de llaves: ahora permite actualizar claves con rpmkeys –import (incluida la actualización del identificador corto ambiguo a huella completa), importar desde un pipe, exportar con rpmkeys –export, y operar de forma consistente entre distintos backends de llavero. Además, con rpmkeys –rebuild se puede reconstruir el contenido del llavero y migrar entre backends, y las búsquedas de claves pasan a ser insensibles a mayúsculas y minúsculas.

rpmsign también da un salto: se puede firmar con GnuPG o con Sequoia-sq controlándolo con el macro %_openpgp_sign. El subcomando rpmsign –addsign deja de reemplazar firmas existentes; por defecto añade cualquier número de firmas en paquetes v6, y también en v4 si se usa –rpmv6. En cambio, rpmsign –resign sustituye todas las firmas previas por una nueva.

Para consultas, se suman extensiones de etiquetas como rpmformat (descubrir si es v3, v4 o v6) y openpgp (gestión de todas las firmas OpenPGP). Se incorpora el formateador :hashalgo para mostrar nombres de algoritmos de hash, y aparece el alias –filemime para consultar el MIME por fichero. La terminología se homogeneiza en los mensajes: se usa OpenPGP de forma consistente y las firmas de cabecera y carga de v3 se etiquetan como heredadas.

Nueva función de cálculo y fallos corregidos en RPM 6.0

Una función nueva calcula un conjunto configurable de resúmenes durante la verificación y los guarda en la base de datos de RPM, ayudando a identificar el archivo de paquete de origen. Se solucionan múltiples problemas operativos: errores de scriptlets ahora sí influyen en el código de resultado de la transacción; determinados triggers fallidos impactan en las operaciones relacionadas; y se arreglan incidencias con –hash, –percent y –test junto a –restore.

Se corrigen fallos como un segfault y fugas en rpmgraph, el sufijo usado por rpm2archive para tar y cpio, y se acomete una gran reescritura de las páginas de manual: estilo uniforme con ejemplos, nuevas páginas para componentes y formatos, reubicación de comandos de usuario en la sección 1 y cobertura de aspectos antes no documentados. La documentación versionada en la web oficial incluye páginas man, manual de referencia y API.

Empaquetado y construcción de paquetes

rpmbuild ahora puede generar dos formatos distintos controlados por el macro %_rpmformat (valores 6 o 4). Además, se habilita el auto-firmado en la construcción si se define %_openpgp_autosign_id, y se añade la herramienta rpm-setup-autosign para facilitar esa configuración.

En macros, llega %{span:…} para facilitar definiciones multilínea y %{xdg:…} para evaluar rutas base XDG. Se incorpora soporte para arquitectura E2K y una batería de correcciones: orden de fuentes y parches en la cabecera, glob de Lua respetando el argumento c, validación de arquitectura en el punto correcto, aceptación de secciones %prep específicas de sistemas de build, y arreglos en check-rpaths cuando coexisten RPATH y RUNPATH.

Se corrige una pérdida de memoria en rpmspec –shell, una regresión de 4.20 en rpmbuild -rs con directorios inexistentes, y un salto de línea extra en rpm –eval. También se soluciona un segfault ante salidas inválidas del generador de dependencias en modo multi, y se elimina la política brp-elfperms. Por último, se retira el obsoleto conmutador –nodirtokens de rpmbuild.

Cambios en la API

En el área de llaveros, se añaden funciones para iterar y gestionar claves: rpmKeyringInitIterator, rpmKeyringIteratorNext, rpmKeyringIteratorFree, rpmKeyringVerifySig2, rpmKeyringLookupKey y rpmKeyringModify. Para rpmPubkey llegan accesores como rpmPubkeyFingperint, rpmPubkeyFingerprintAsHex, rpmPubkeyKeyIDAsHex y rpmPubkeyArmorWrap, además de rpmPubkeyMerge para fusionar descriptores de la misma clave.

Para el llavero permanente de transacciones se incluyen rpmtxnImportPubkey, rpmtxnDeletePubkey y rpmtxnRebuildKeystore. La operación rpmSign se controla con flags nuevos: RPMSIGN_FLAG_RESIGN, RPMSIGN_FLAG_RPMV4 y RPMSIGN_FLAG_RPMV6. También se añaden rpmteVfyLevel y rpmteSetVfyLevel, con sus equivalentes te.VfyLevel y te.SetVfyLevel en los bindings de Python.

Para múltiples firmas, aparecen identificadores como RPMTAG_OPENPGP, RPMSIGTAG_OPENPGP (alias del anterior) y el flag de verificación RPMVSF_NOOPENPGP. Se incorporan nuevas etiquetas: 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.

Hay etiquetas renombradas: RPMTAG_PAYLOADDIGEST pasa a RPMTAG_PAYLOADSHA256, RPMTAG_PAYLOADDIGESTALT a RPMTAG_PAYLOADSHA256ALT, y RPMTAG_PAYLOADDIGESTALGO se marca como obsoleta bajo RPMTAG_PAYLOADSHA256ALGO. Se suman identificadores de SHA-3: RPM_HASH_SHA3_256 y RPM_HASH_SHA3_512, además de símbolos relacionados con MIME por fichero en paquetes v6, como rpmfilesFMime y rpmfiFMime, y el flag RPMFI_NOFILEMIME.

En el terreno OpenPGP, se añaden identificadores conforme a RFC 9580 y la función pgpDigParamsSalt para recuperar la pre-sal de firmas v6. Para conjuntos de resúmenes aparece rpmDigestBundleUpdateID (actualiza identificadores individuales). Otras novedades: rpmtsAddInstallElement devuelve 3 ante formatos no soportados y fdSize reporta error en archivos no regulares.

Mejoras internas

El código de RPM pasa a C++20 (salvo plugins y bindings de Python). Se renombran fuentes a .cc y .hh, se migran estructuras dinámicas a STL, y se refuerza el recuento de referencias con operaciones atómicas. Además, se amplía la suite de pruebas y se simplifica la creación de tests.

Se introduce una abstracción real de llavero y un backend experimental basado en openpgp.cert.d. Añadido el objetivo de build make site para renderizar documentación local, y la imagen de pruebas se adapta a toolbox. Se permiten guiones bajos en nombres de RPMTAG y se corrigen regresiones, por ejemplo el tamaño reservado para firmas y el mecanismo de alternativas interferiendo con firmas.

Se corrigen lecturas del llavero sin bloqueo de transacción, una condición de carrera en rpmioMkpath, la profundidad de recursión en mensajes de error de macros, y una casuística donde campos vacíos de passwd o group provocaban ignorar entradas. Las macros internas vuelven a estar disponibles antes de cargar archivos, se maneja correctamente el fallo de fdSize en rpmSign, se limpian pseudo-etiquetas en –querytags, y se respeta el prefijo de instalación en los scripts legacy de find-provides y find-requires.

Otras mejoras internas

También se resuelven fugas de referencia en Python relacionadas con archivos, se estabiliza el almacenamiento de dependencias para evitar no determinismo, se corrige el escape de chroot en el script sysusers con entradas u!, y se arregla una regresión de 4.19 en códigos de retorno de actualización fallida. Se avisa sobre macrofiles en rpmrc, se recrea el lock de transacción tras –rebuilddb, se eliminan provides gpg(keyid) de gpg-pubkey, y se limpian símbolos filtrados involuntariamente al ABI.

Se eliminan usos no portables de signal, se optimiza el bloqueo de rpmlog, y en los bindings de Python se soporta el aislamiento de módulos para múltiples subintérpretes y se corrigen fugas de recursos con pruebas bajo ASAN. Son mejoras que mejoran robustez, portabilidad y mantenibilidad en todos los frentes.

Requisitos para compilar RPM

Ahora se requiere un compilador C++20 además de C99; no es preciso soporte de módulos de C++20. Para construir con Sequoia se exige rpm-sequoia 1.9.0 o superior (y es la opción por defecto), Python 3.10 o superior para los bindings, y el generador scdoc para las páginas man.

La documentación de API precompilada deja de enviarse en los tarballs de release; su construcción es opcional con Doxygen. Las API preconstruidas por versión están disponibles en el FTP del proyecto.

Compatibilidad de RPM 6.0 y notas clave del formato

El formato de paquete v6 trae tamaños de fichero y límites relacionados en 64 bits, modernización criptográfica con retirada de MD5 y SHA1, hash SHA3-256 en cabecera y resúmenes SHA512 y SHA3-256 en la carga. Se añade información MIME por fichero, y hay amplia compatibilidad con RPM a partir de 4.14 (con matices). El modo del generador de dependencias externo deja de ser compatible con v6 y se eliminan dependencias rpmlib heredadas previas a 4.6 para limpiar ruido.

Los paquetes v6 se pueden consultar con RPM desde 4.6, descomprimir con 4.12, y verificar e instalar con 4.14 o superior atendiendo a las limitaciones conocidas. Los paquetes v4 siguen plenamente soportados y los generados por 6.0 son idénticos a los de la rama 4.x; no obstante, bajo la configuración por defecto no se verifican los paquetes construidos con RPM menores que 4.14 por usar digests débiles. Se puede cambiar %_pkgverify_level a signature para ignorar esos resúmenes, o restaurar el comportamiento 4.x con %_pkgverify_flags a 0 si se necesita verificar los digests débiles.

La instalación de v3 se elimina, aunque se puede consultar y extraer con rpm2cpio. Por defecto, RPM construye paquetes v6; esto se puede revertir marcando %_rpmformat al valor 4. En paquetes construidos con RPM 6.0 o superior, la familia Lua posix.fork queda deshabilitada, mientras que en paquetes construidos con 4.20 o anterior sigue funcionando.

Otras consideraciones: la configuración de la clave de firmado se define ahora con %_openpgp_sign_id (compatibilidad hacia atrás con %_gpg_name), los macros de firmado de bajo nivel pasan a ser paramétricos y los overrides personalizados de %__gpg_sign_cmd dejan de funcionar tal cual. Se admite que %_passwd_path y %_group_path sean listas separadas por dos puntos para usar múltiples fuentes NSS, y se retiran los conmutadores de consulta –pkgid y –hdrid.

RPM 6.0 y Fedora 43: alcance, beneficios y pruebas

La actualización a RPM 6.0 en Fedora 43 busca reforzar seguridad y preparar el terreno para el formato v6, pero sin adoptar todavía el nuevo formato como predeterminado. En Fedora 43 se seguirá generando v4 por defecto, y la aplicación estricta de la verificación de firmas se abordará como un cambio del sistema en una versión posterior.

Beneficios destacados para Fedora: las claves OpenPGP pasan a identificarse siempre por huella o ID completo, se pueden actualizar con rpmkeys –import, se admiten múltiples firmas por paquete, el auto-firmado local en la construcción y el uso de Sequoia-sq como alternativa a GnuPG. También se facilita probar el formato v6 en el ecosistema sin forzar su adopción global.

No están en el alcance: la migración general de Fedora al formato v6 ni el cambio del modo de verificación por defecto. Los responsables del cambio se encargan de rebasar RPM y asistir con incompatibilidades, mientras que el resto de desarrolladores deben probar, reportar problemas y adaptar herramientas de terceros cuando sea preciso.

Impacto de actualización y compatibilidad: scripts y herramientas de terceros podrían requerir ajustes por el nuevo formato de dirección de claves y cambios de salida relacionados con firmas. Para pruebas tempranas conviene validar: actualización de claves importadas, gestión del llavero con rpmkeys, y compatibilidad del formato v6 con software externo (construyendo con %_rpmformat a 6).

Experiencia de usuario de RPM 6.0 en Fedora

Experiencia de usuario: la salida relacionada con firmas y claves se estandariza en mayúsculas y minúsculas, y las claves se muestran por huella o ID completo, abandonando el antiguo ID corto susceptible a colisiones. rpmkeys se instituye como herramienta oficial para manipular el llavero; métodos antiguos como tocar manualmente pseudo-paquetes gpg-pubkey quedan obsoletos y deben migrarse a rpmkeys o a las nuevas APIs.

Dependencias: no cambia el soname, así que no se requieren reconstrucciones por dependencias; no hay dependencias con otros cambios de Fedora. RPM se construye como C++, por lo que añade dependencia en tiempo de ejecución de libstdc++. Firmar con Sequoia requiere sequoia-sq 1.0 o superior como dependencia opcional y solo afecta al firmado de paquetes.

Plan de contingencia: revertir a RPM 4.20 si hiciera falta, con fecha tope en la congelación de la beta, sin bloquear el lanzamiento. La entrega sigue adelante aunque el formato v6 no sea aún el predeterminado en la distribución.

Notas de lanzamiento y contexto del anuncio de RPM 6.0

La candidata previa incorporó correcciones de errores y actualizaciones de páginas man, y fue promovida a final. El anuncio firmado por el equipo de RPM subraya que se ha trabajado hacia este hito desde el reinicio de rpm.org alrededor de 2007, con hitos como tamaños de archivo de 64 bits, generadores de dependencias enchufables, plugins de transacción, dependencias ricas, disparadores de fichero, mejoras de debuginfo, nuevos backends de base de datos, integración Lua y expresiones macro, build-requires dinámicos, generación de spec, soporte de usuarios y grupos, y sistemas de build declarativos.

Más de 300 personas han contribuido código desde múltiples distribuciones y organizaciones. La historia del proyecto y su comunidad explican la estabilidad y el alcance que RPM 6.0 hereda y amplía.

El panorama que dibuja RPM 6.0 es el de un gestor de paquetes reforzado para la próxima década: mejor criptografía, formato preparado para grandes volúmenes, herramientas más potentes y documentación al día, con una senda de compatibilidad clara para que administradores, empaquetadores y ecosistemas adopten las novedades sin sustos.