La gestión de paquetes en Arch Linux lleva muchos años girando en torno a pacman y libalpm, pero en los últimos tiempos ha surgido una iniciativa que está cambiando el panorama desde la base: el proyecto ALPM escrito en Rust. Esta nueva hornada de herramientas no solo replica lo que ya existía, sino que intenta redefinir cómo describimos, verificamos y automatizamos todo lo relacionado con paquetes, repositorios y firmas.
Lejos de ser un simple “reemplazo de pacman”, el proyecto ALPM se ha convertido en un framework completo de gestión de paquetes para Arch y distribuciones afines. Incluye especificaciones formales, librerías en Rust, utilidades de línea de comandos, bindings para Python, un sistema de linting muy flexible e incluso un nuevo modelo para verificar artefactos firmado criptográficamente. Todo ello con un foco muy claro: seguridad, reproducibilidad y herramientas modernas para desarrolladores.
Qué es ALPM y por qué importa en Arch Linux
El término ALPM (Arch Linux Package Management) hace referencia al proceso completo de empaquetado en Arch Linux: obtener las fuentes de los proyectos upstream, construirlas (cuando procede), agrupar los resultados en un formato de paquete específico (alpm-package) y distribuir esos paquetes a los usuarios de la distribución. El formato utilizado para los paquetes binarios es abierto, documentado públicamente y reutilizable en otras distribuciones o plataformas.
Dentro de este ecosistema distinguimos claramente entre varios tipos de repositorio. Un alpm-source-repo es el repositorio de código fuente (normalmente un repo git) que contiene los scripts PKGBUILD y, opcionalmente, un fichero SRCINFO con metadatos derivados del PKGBUILD. A partir de ese origen se construyen uno o varios archivos de paquete alpm-package. En el otro extremo está el alpm-repo, que es el repositorio binario (por ejemplo, un directorio servido vía web) con los paquetes ya construidos, sus firmas y los ficheros de base de datos alpm-repo-db que describen el estado del repo.
La conexión entre alpm-source-repo, alpm-package y alpm-repo-db se basa en una malla de ficheros de metadatos: PKGBUILD y SRCINFO en el origen, BUILDINFO, PKGINFO y ALPM-MTREE dentro del paquete, y posteriormente alpm-repo-desc y alpm-repo-files en la base de datos del repositorio. A su vez, cuando el paquete se instala en un sistema, la base de datos local alpm-db (gestionada por libalpm/pacman) almacena su propio conjunto de ficheros alpm-db-desc y alpm-db-files, manteniendo el estado de cada paquete instalado.
Ciclo de vida de un paquete ALPM: de PKGBUILD al sistema
Todo comienza en un alpm-source-repo con un PKGBUILD. Ese script define el entorno de construcción: fuentes, dependencias para compilar y en tiempo de ejecución, pasos de build, pruebas e instalación, además de metadatos básicos como nombre, versión, descripción, URL, licencia o grupos. Un ejemplo típico de PKGBUILD puede crear un único archivo de datos, instalarlo bajo /usr/share y registrar un archivo de configuración en /etc.
A partir de ese PKGBUILD se genera un fichero SRCINFO que recoge de forma declarativa la información de metadatos relevante (pkgbase, pkgname, versión, licencia, arquitectura, URL, etc.). Esta representación está pensada para que herramientas como el AUR o scripts de automatización puedan leer fácilmente la información sin ejecutar el propio PKGBUILD, lo que es clave para seguridad y análisis estático.
El proceso de construcción lo orquesta normalmente makepkg, que se apoya en los scripts bash PKGBUILD. Lo deseable es que la build se haga en un entorno aislado y reproducible (chroots, contenedores o máquinas virtuales) que contenga únicamente las dependencias necesarias. Por sí solo, makepkg no garantiza un entorno extremadamente limpio, por lo que Arch recurre a pkgctl, que genera chroots limpios mediante systemd-nspawn y lanza makepkg dentro de ellos. De este modo, se reducen sorpresas y se mejora la reproducibilidad.
Durante la fase de descarga y verificación, las fuentes (locales, remotas o en sistemas de control de versiones) se bajan y se comprueban contra sumas de verificación bloqueadas (definidas en el PKGBUILD). Esto no solo ayuda a garantizar que las fuentes no se han alterado, sino que es uno de los pilares de las reproducible builds y una defensa clara frente a ataques a la cadena de suministro. Además, cada origen puede ir acompañado de una firma criptográfica para autenticar al autor.
En muchos casos se necesitan modificaciones sobre las fuentes antes de compilar: parches para corregir bugs, ajustes para una arquitectura concreta, o cambios para integrar mejor el software en el sistema. Todo esto suele hacerse en una fase de preparación tras la descarga y verificación.
La etapa de build se encarga de generar los binarios, traducciones y otros artefactos: se invoca el sistema de compilación adecuado (meson, cmake, autotools, herramientas específicas de cada lenguaje, etc.) usando las dependencias declaradas en el PKGBUILD. Después, se ejecutan las pruebas disponibles para garantizar que el resultado funciona correctamente en el entorno objetivo.
Finalmente, en la fase de instalación dentro del árbol temporal, todos los archivos generados se copian a un directorio vacío que simula la raíz del sistema de destino. Aquí también se crean los ficheros de metadatos específicos de ALPM: BUILDINFO (descripción detallada del entorno de construcción), PKGINFO (metadatos del paquete, como versión, tamaño, dependencias o licencias) y ALPM-MTREE (árbol de ficheros con modos, propietarios, checksums, etc.). Si el PKGBUILD genera varios paquetes a partir de la misma base, se crean varios directorios de salida y un alpm-package para cada uno de ellos.
De cada directorio de salida se genera un archivo de paquete ALPM, que es básicamente un tar opcionalmente comprimido que contiene el árbol de datos, los ficheros de metadatos (BUILDINFO, PKGINFO, ALPM-MTREE) y, si procede, un script de instalación .INSTALL (alpm-install-scriptlet). Estos paquetes pueden ir sin comprimir o comprimidos con tecnologías diversas: .gz, .bz2, .xz, .zst, .lz4, .lzo, .lz, .lrz, .Z, etc., según la configuración de makepkg.conf (variables COMPRESSBZ2, COMPRESSGZ, COMPRESSZST, PKGEXT, etc.).
Una vez creado, el paquete puede ser firmado con OpenPGP mediante firmas separadas. La firma es otro archivo que añade el sufijo .sig al nombre del paquete (por ejemplo, shadow-4.18.0-1-x86_64.pkg.tar.zst.sig). Esto permite que más adelante el gestor de paquetes verifique la autenticidad utilizando el certificado OpenPGP del empaquetador.
Estructura interna de un paquete ALPM y formatos relacionados
Los paquetes basados en ALPM distinguen claramente entre metadatos, scripts y ficheros de datos. En la raíz del tar siempre deben aparecer tres ficheros: .BUILDINFO, .MTREE (es decir, ALPM-MTREE) y .PKGINFO. Estos elementos describen el entorno de build, los atributos de cada fichero empaquetado y la información general del paquete, y permiten tanto reconstruir el entorno de compilación como verificar la instalación.
Además de esos ficheros obligatorios, puede existir un script .INSTALL que actúa como alpm-install-scriptlet. Este script ejecuta acciones en momentos concretos (pre/post instalación, actualización o desinstalación) y es un punto crítico donde las distribuciones suelen aplicar políticas y lints específicos para evitar abusos o prácticas inseguras.
El resto del contenido son ficheros de datos que se extraen en la raíz del sistema al instalar el paquete. No hay un listado explícito de rutas permitidas, pero las buenas prácticas recomiendan seguir el estándar de jerarquía de ficheros de systemd y el Filesystem Hierarchy Standard, evitando a toda costa tocar directorios que contengan datos de usuario (por ejemplo, nada en /home). En general, todos los archivos y directorios del paquete se asumen propiedad de root, salvo que la política de la distribución indique lo contrario.
Los formatos asociados a ALPM están minuciosamente documentados: ALPM-MTREE, BUILDINFO, PKGBUILD, PKGINFO, SRCINFO, alpm-db, alpm-db-desc, alpm-db-files, alpm-package, alpm-package-relation, alpm-package-source-checksum, alpm-repo, alpm-repo-db, alpm-repo-desc, alpm-repo-files, alpm-source-repo, alpm-split-package, entre otros. Toda esta familia de especificaciones define cómo se describe un paquete, cómo se comprueba su integridad, cómo se resuelven las dependencias y cómo se representan tanto los repositorios binarios como el estado local del sistema.
Base de datos local, repositorios y funcionamiento de pacman
En el sistema cliente, pacman y libalpm gestionan una base de datos ubicada normalmente en /var/lib/pacman. Dentro de esta carpeta hay un subdirectorio local y varios subdirectorios sync. El primero almacena la información de todos los paquetes instalados en el sistema, mientras que los directorios sync contienen las bases de datos comprimidas de los repos remotos configurados.
Cada entrada de la base de datos local es un directorio por paquete, cuyo nombre combina nombre y versión. Para separarlos se usa una convención bastante frágil: se busca el penúltimo guion en el nombre (porque el último suele separar la arquitectura), algo que ya de por sí da idea de la complejidad heredada. En cada directorio de paquete hay tres archivos principales: desc, files y mtree. Los dos primeros usan un formato tipo bloque de claves con marcadores %CAMPO%, mientras que el tercero es un mtree comprimido con gzip.
El fichero desc contiene los metadatos del paquete: nombre, versión, base, descripción, URL, arquitectura, fecha de build e instalación, empaquetador, tamaño instalado, razones de instalación, licencias, tipo de validación, dependencias, etc. El archivo files contiene la lista de ficheros gestionados por el paquete en el sistema. El archivo mtree vuelve a listar esos ficheros (y algunos adicionales de la build) con información extendida como tamaños, checksums, permisos y tiempos.
Desde el punto de vista de alguien que quiere consultar la base de datos local de forma eficiente, el diseño tiene ciertas pegas: para comprobar si un fichero instalado sigue siendo el correcto, hay que leer y correlacionar tanto files como mtree, normalizar las rutas (porque pueden estar representadas de forma distinta) y filtrar elementos. En sistemas con muchos paquetes, esto implica abrir miles de pequeños archivos, lo que se traduce en un montón de llamadas al sistema y tiempos de lectura elevados. Desarrolladores que han explorado estos entresijos desde Rust han señalado que, aunque es posible acelerar el proceso comparando cadenas directamente, ello puede ser frágil y excluir rutas válidas.
A pesar de esa complejidad, la base de datos local alpm-db es crucial: refleja qué versión de cada paquete está instalada, qué ficheros posee, qué archivos de configuración se deben tratar como backup (con checksums MD5), y mantiene una copia del ALPM-MTREE original, lo que permite detectar ficheros faltantes o modificados.
En el lado de los repositorios binarios, un alpm-repo combina paquetes únicos (por nombre y versión), sus firmas y un fichero de base de datos alpm-repo-db. En este último, cada paquete se describe mediante un alpm-repo-desc que agrega datos de PKGINFO, la firma y el propio archivo de paquete (tamaños, checksums, etc.), y un alpm-repo-files que recoge la lista de rutas incluidas. Herramientas como repo-add gestionan estos ficheros, y para entornos más complejos con múltiples mantenedores, Arch se apoya en dbscripts, que automatiza la gestión de repos oficiales.
Por su parte, pacman descarga los ficheros alpm-repo-db de cada repo configurado, compara su contenido con la base de datos local y, si encuentra versiones más nuevas, descarga e instala los paquetes correspondientes. Cada instalación implica tres pasos básicos: eliminar los ficheros de la versión anterior, añadir los de la nueva y actualizar la información en alpm-db. Todo ello está soportado por los metadatos generados en las fases de build e instalación.
Rust entra en juego: modernizar ALPM y superar limitaciones
En los últimos años, parte de la comunidad se ha mostrado interesada en reimplementar la lógica de libalpm y pacman en Rust, sobre todo para aprovechar un modelo de tipos más rico, mayor seguridad de memoria y mejores abstracciones. Intentar envolver directamente libalpm desde Rust no es trivial: la biblioteca C tiene APIs de larga duración con callbacks para progreso, descargas y otros eventos que se vuelven difíciles de adaptar a un wrapper completamente seguro en Rust.
Esto ha llevado a algunos desarrolladores a plantear una implementación de ALPM totalmente en Rust, con objetivos ambiciosos: que sea segura y rápida, que replique el comportamiento de libalpm, que ofrezca una API mucho más expresiva y que sea multiplataforma (incluyendo Windows). De conseguirlo, se abriría la puerta a crear herramientas parecidas a chocolatey o gestores más amigables sobre la base del formato de paquetes de Arch, sin la corsé de las APIs C existentes.
El trabajo exploratorio se ha centrado especialmente en el acceso a la base de datos local y la creación de librerías Rust para leer los directorios de /var/lib/pacman, parsear los formatos desc/files/mtree y exponerlos con tipos seguros. Una de las mejoras notables es el cargado perezoso de paquetes: en lugar de leer de golpe todos los paquetes y sus metadatos (algo que puede tardar minutos si se cruzan files y mtree a fondo), se retrasan las lecturas hasta que realmente se necesitan, permitiendo inspeccionar uno o pocos paquetes sin penalizaciones masivas.
Al mismo tiempo, desde el propio proyecto ALPM se ha optado por un enfoque bottom-up, centrado en librerías reutilizables. Se han creado crates básicos como alpm-types, que define tipos de bajo nivel compartidos por muchos formatos, y alpm-common, que ofrece traits y utilidades comunes. Para el parsing de formatos personalizados, se ha elegido la librería de combinadores de parsers winnow, sobre la que se construye alpm-parsers, un conjunto de herramientas reutilizables para gestionar todos estos ficheros ad hoc que usa la infraestructura de paquetes de Arch.
Otra pieza esencial es alpm-solve, un nuevo enfoque para la resolución de dependencias basado en la biblioteca genérica resolvo. Aquí se intenta replantear la lógica de resolución con un modelo más moderno, preciso y extensible que el legado de libalpm, siempre apoyado en tipos fuertes.
Para el manejo de la compresión en paquetes y bases de datos de repos, se ha creado la librería alpm-compress, que abstrae de forma extensible los distintos algoritmos de compresión utilizados por los archivos alpm-package y alpm-repo-db. Y para manipular los propios paquetes, la crate alpm-package permite crear paquetes a partir de directorios de entrada ya preparados y, a la vez, iterar fácilmente sobre los ficheros de datos y extraer metadatos validados.
Un problema clásico del empaquetado es que el proceso de build necesita crear ficheros propiedad de root (por ejemplo, al instalar en un árbol que simula /usr, /etc, etc.), pero no se quiere ejecutar todo el proceso con privilegios de superusuario. Para este escenario el proyecto ofrece rootless-run, una librería que proporciona una abstracción genérica para ejecutar comandos “como root” utilizando backends como fakeroot o rootlesskit. Más adelante se planea integrar también libkrun para ofrecer aislamiento reforzado mediante KVM, incluso en contextos donde fakeroot o rootlesskit tienen limitaciones.
Especificaciones, documentación y tooling alrededor de ALPM
Uno de los saltos de calidad más importantes ha sido la formalización exhaustiva de las especificaciones que definen los diferentes formatos y procesos: alpm-db, alpm-repo, alpm-package, alpm-package-version, alpm-package-name, alpm-architecture, etc. Esta documentación no solo permite entender qué hace cada fichero, sino que sirve como base robusta para crear parsers y validadores en Rust, Python u otros lenguajes sin necesidad de rastrear código C o scripts dispersos.
Estas especificaciones se distribuyen también como paquete alpm-docs, de modo que cualquier desarrollador o maintainer puede instalarlas y consultarlas localmente. Además, el proyecto mantiene una documentación web actualizada donde se explica de manera accesible la arquitectura general, el papel de cada fichero y la relación entre ellos. El documento alpm(7), por ejemplo, es una especie de puerta de entrada de alto nivel al mundo de la gestión de paquetes en Arch.
Sobre esta base documental se han construido varias herramientas específicas. La crate alpm-srcinfo ofrece librería y CLI para parsear, validar y crear ficheros SRCINFO a partir de PKGBUILD. Dado que los PKGBUILD son scripts bash con lógica dinámica, generar SRCINFO correctos sin ejecutar código arbitrario no es trivial. Por eso se complementa con el proyecto alpm-pkgbuild-bridge, la crate alpm-pkgbuild y una capa de traducción en alpm-srcinfo que permite obtener una representación fiable y segura de los datos.
Del mismo modo, alpm-buildinfo proporciona una librería y una herramienta de línea de comandos para gestionar BUILDINFO, el formato que describe el entorno de build y que es esencial para reproducir builds bit a bit. Con esta herramienta es posible analizar, validar y generar archivos BUILDINFO que luego se incluyen en los paquetes.
El formato ALPM-MTREE se maneja mediante la crate alpm-mtree, que permite parsear, validar y generar estos ficheros. Al tratarse de un subconjunto del formato mtree de libarchive y ser más bien un metalenguaje que un simple formato de datos, la escritura se apoya en bsdtar, pero la lógica de validación y lectura reside en Rust. La información allí contenida sirve para verificar que las propiedades de los ficheros instalados (permisos, propietarios, checksums) siguen siendo las esperadas.
Para los metadatos generales del paquete, la crate alpm-pkginfo cubre el formato PKGINFO: dependencias, relaciones alpm-package-relation, nombre de paquete, versión, arquitectura, licencias, tamaño, etc. A partir de aquí se consigue una representación fuertemente tipada de los metadatos que antes estaban dispersos en texto plano.
La base de datos del sistema, alpm-db, se trata con la crate homónima: alpm-db. Esta permite parsear, validar y generar alpm-db-desc y alpm-db-files, y trabaja hacia un modelo de acceso con propiedades ACID, pensado para integrarse en aplicaciones que necesiten leer o manipular la base de datos con garantías de consistencia.
Otro formato delicado es el relacionado con ficheros ELF, en particular las sonames que se utilizan para expresar dependencias binarias. La crate alpm-soname se centra en gestionar y extraer información de los formatos alpm-sonamev2 (más moderno) y, en general, de los sonames definidos en binarios y bibliotecas ELF. Esto facilita vincular las dependencias reales de ejecución con las relaciones de paquetes que luego aparecen en PKGINFO y otras estructuras.
Para las bases de datos de repositorios, la crate alpm-repo-db gestiona los ficheros alpm-repo-desc y alpm-repo-files, y se está extendiendo para soportar la creación, lectura, escritura y compresión de alpm-repo-db completos, así como la adición, actualización y eliminación de entradas. A medio plazo, será una pieza clave para herramientas que quieran manejar repositorios de forma programática sin depender de scripts heredados.
Como banco de pruebas, el proyecto mantiene también dev-scripts, una crate sin releases pensada para probar la integración con datos reales: descarga repositorios de fuentes oficiales y del AUR, obtiene repos binarios, y permite validar que las librerías ALPM se comportan correctamente frente a grandes volúmenes de paquetes reales.
Linting, integración con Python e internacionalización
Con toda esta base de especificaciones y librerías, el paso natural ha sido crear un framework de linting centrado en ALPM. La crate alpm-lint actúa como núcleo de este sistema, con una CLI llamada alpm-lint(1) y una arquitectura extensible para añadir nuevas reglas. La idea es contar con un único punto central que pueda validar todos los aspectos de la gestión de paquetes: desde el contenido de un alpm-source-repo (PKGBUILD, SRCINFO, parches) hasta un alpm-package completo o incluso elementos de un repo.
Aunque por ahora el número de lints es pequeño, el proyecto anima a mantenedores y desarrolladores Rust a colaborar para ampliarlos. Entre los objetivos está integrar alpm-lint en las herramientas oficiales de build de Arch de forma que la calidad de los paquetes mejore sin depender tanto de revisiones manuales. Cada regla de lint se documenta detalladamente y existe una web específica donde se listan todos los lints y su significado, generada a partir de la documentación del código.
Para facilitar su adopción en proyectos Python, el equipo ha desarrollado python-alpm, unos bindings que exponen los parsers y tipos verificados a este lenguaje. La principal consumidora potencial es AURweb, la aplicación FastAPI que gestiona el Arch User Repository, que actualmente usa una biblioteca nativa en Python para SRCINFO. Con python-alpm, se obtiene un parsing mucho más robusto, basado en las mismas librerías Rust que usa el resto del proyecto ALPM.
Estos bindings ya están disponibles en PyPI, y se está trabajando en integrarlos en AURweb, sustituyendo gradualmente a las soluciones previas. Más adelante se plantea ampliar la cobertura de python-alpm para abarcar otras necesidades, como integraciones con archinstall u otros servicios que dependan fuertemente de la infraestructura de paquetes.
En cuanto a la internacionalización, el proyecto ha adoptado el framework fluent para gestionar textos traducibles y mensajes de error. Sobre fluent se ha construido la crate fluent-i18n, que simplifica su uso en las librerías y CLI del proyecto. Las traducciones se coordinan mediante Weblate, con unas directrices claras para colaboradores que quieran traducir mensajes a otros idiomas. La idea es que tanto los usuarios finales como administradores de sistemas que no dominen el inglés puedan obtener mensajes claros y útiles en su idioma.
VOA: verificación de artefactos sin depender de keyrings estatales
Otro frente importante que aborda el proyecto ALPM es la verificación criptográfica de paquetes y otros artefactos. Tradicionalmente, Arch usa OpenPGP y un keyring central basado en GnuPG para verificar tanto paquetes como metadatos de repos. Este modelo, sin embargo, tiene varios problemas: el keyring es independiente del contexto (no distingue entre diferentes conjuntos de firmas según el uso), está ligado a GnuPG y su comportamiento específico, es stateful (requiere un agente y gestión de estado) y, sobre todo, se ha vuelto problemático a medida que GnuPG se ha alejado del estándar OpenPGP impulsado por la IETF.
Antes incluso de 2024 ya se estaba explorando una alternativa: en vez de usar un keyring monolítico, se propuso una jerarquía de directorios con “verificadores”, inicialmente pensada solo para OpenPGP pero pronto extendida a un enfoque agnóstico en cuanto a tecnología. De esa idea nace la especificación File Hierarchy for the Verification of OS Artifacts (VOA), que describe cómo organizar certificados OpenPGP, claves SSH públicas o certificados X.509 en un árbol claro que indique en qué contexto debe usarse cada verificador al validar artefactos.
La versión inicial de esta especificación, con soporte explícito para OpenPGP, se publicó en 2025, y existen borradores para otros backends (SSH, X.509, minisign, signify) pendientes de pulir. Paralelamente, se ha desarrollado la implementación de referencia en Rust a través del proyecto VOA, con varias crates especializadas.
La crate voa-core gestiona el tratamiento genérico de la jerarquía VOA, independientemente de la tecnología. Encima de ella se construye voa-openpgp, que implementa la verificación concreta con OpenPGP. Esta librería soporta varios modelos de verificación: un modo “plain” donde se verifican los artefactos únicamente con los verificadores disponibles (filtrables por huellas o dominios en los IDs de usuario), un modo basado en “trust anchors” simples donde los verificadores deben estar certificados por un conjunto de anclas con un número mínimo de firmas, y un modo de “Web of Trust” generalizado que permite configuraciones más complejas y descentralizadas de confianza.
En todos los casos se puede configurar cuántas firmas de datos independientes son necesarias para considerar un artefacto válido. En el caso concreto de Arch Linux, el modelo real que se usa hoy en día es parecido a un Web of Trust de un solo nivel: hay un conjunto de certificados que hacen de claves maestras (trust anchors), y los certificados de los empaquetadores deben tener IDs de usuario bajo el dominio archlinux.org y estar firmados por tres o más de esas claves maestras. Con voa-openpgp, esta política se expresa mejor mediante el modo de trust anchors con un número configurable de certificaciones requeridas.
La integración se completa con voa-config, que define un formato de configuración (voa(5)) para describir políticas de verificación específicas de una distribución o contexto, incluyendo cómo se seleccionan los verificadores y anclas de confianza. Un ejemplo es el archivo de configuración de Arch, que declara que para la tecnología openpgp se requiere una firma de datos válida, que los verificadores deben tener IDs de usuario con el dominio archlinux.org y al menos tres certificaciones de las claves maestras, cuyos fingerprints se listan explícitamente.
La crate voa proporciona una API de alto nivel para consumidores de VOA y una CLI para administradores. Con el comando voa config show se puede inspeccionar qué ajustes se aplican en un contexto dado (por ejemplo, “arch”), y con voa verify se pueden verificar archivos junto con sus firmas detached usando la jerarquía de verificadores instalada. Los resultados pueden devolverse también en JSON, lo que facilita la integración en pipelines automatizados.
Para que todo esto funcione de forma práctica, existe un paquete como voa-verifiers-arch que instala los verificadores VOA usados por Arch Linux. Tras instalarlo, por ejemplo, se puede verificar un paquete del caché de pacman indicando tanto el archivo .pkg.tar.zst como su .sig, y voa confirmará que la firma es válida de acuerdo con la política configurada.
En paralelo, el proyecto ha investigado el estado del Web of Trust en diferentes implementaciones y ha llegado a la conclusión de que las soluciones heredadas presentan limitaciones serias a la hora de calcular la confianza. De ese análisis ha surgido un nuevo algoritmo de pathfinding llamado Berblom, diseñado específicamente para calcular cantidades de confianza de forma general, robusta y eficiente en un grafo de certificaciones. La intención es integrar Berblom en la implementación VOA durante 2026 para ofrecer un Web of Trust más sólido y predecible.
Financiación, estadísticas y líneas de trabajo futuras
Todo este esfuerzo se ha visto impulsado de manera significativa por la financiación del Sovereign Tech Fund (STF), que entre 2024 y 2025 permitió trabajar a fondo en el proyecto ALPM durante unos 15 meses. En ese tiempo se han completado seis hitos principales que abarcan desde la formalización de especificaciones y la creación de librerías básicas hasta la verificación criptográfica avanzada, la gestión de bases de datos y el tooling para desarrolladores.
Los números hablan por sí mismos: cientos de commits de múltiples colaboradores, decenas de miles de líneas de código Rust, scripts, documentación y archivos de configuración repartidos en un workspace amplio. La filosofía del proyecto es clara: crear valor más allá de Arch Linux, proporcionando soluciones genéricas que puedan ser reutilizadas por otras distribuciones y proyectos de software libre, sin atarse a un nicho demasiado estrecho.
Aunque la financiación del STF ha terminado, la hoja de ruta de ALPM sigue muy viva. Hay planes para ampliar de forma notable el conjunto de lints en alpm-lint y estudiar su integración directa en las herramientas de build oficiales. También se baraja la posibilidad de ofrecer una C-API compatible con libalpm basada en las nuevas librerías Rust, aunque por ahora se prioriza que los consumidores usen directamente las APIs más finas y bien tipadas de ALPM.
En el terreno de los repositorios binarios, la intención es completar el soporte de alpm-repo-db para cubrir todo el ciclo de vida de una base de datos de repo: creación, lectura, compresión, actualización y eliminación de entradas. A la vez, se quiere añadir una capa para la descarga segura de artefactos desde alpm-repo, integrando estrechamente el sistema VOA para la verificación de paquetes y bases de datos usando OpenPGP (y, en el futuro, otros backends).
Sobre las integraciones, uno de los objetivos es seguir expandiendo python-alpm para cubrir más casos de uso, en especial aplicaciones como archinstall que necesitan un acceso flexible y fiable a la infraestructura de paquetes. También se anima a desarrolladores interesados en el cruce Rust/Python a colaborar para hacer más cómodo el uso conjunto de ambas tecnologías.
Gracias a todo este andamiaje de tipos seguros, parsers robustos y tooling de verificación e internacionalización, la comunidad tiene ahora una base mucho más sólida para crear nuevas aplicaciones especializadas de gestión de paquetes: desde frontends más amigables para usuarios finales hasta herramientas de auditoría, automatización de despliegues, análisis de dependencias o integración con sistemas de CI/CD. Para cualquiera que se mueva en el mundo de Arch Linux, Rust o la seguridad de la cadena de suministro, este ecosistema ALPM renovado se ha convertido en un terreno extremadamente fértil para experimentar, mejorar y, sobre todo, para construir cosas útiles sin tener que pelearse constantemente con detalles opacos heredados.
