feat: Integración de Siguldry PKCS#11 y spooler de firmas

* Implementación del rol de Ansible 'siguldry' para CentOS Stream 10
* Migración del plugin de firmas de Koji Hub a un spooler asíncrono
* Modificación de roles para utilizar empaquetamiento RPM nativo de siguldry-pkcs11
* Documentación de decisiones (ADRs) y roadmap en docs/technical/
* Limpieza de binarios locales pesados de PKCS#11 en Ansible

Co-developed-by: Gemini AI <renich+gemini@woralelandia.com>
Signed-off-by: Rénich Bon Ćirić <renich@woralelandia.com>

docs/technical/decisiones/2026-06-16-01-migracion_sigul_y_lookaside_centos.rst

@@ -0,0 +1,38 @@
+=============================================================
+Decisión de Diseño: Migración a Sigul Real y Lookaside CentOS
+=============================================================
+
+Este registro documenta la decisión de diseño de migrar a una infraestructura real de Sigul, estandarizar el lookaside cache para asemejarse a CentOS Stream, y posponer la autenticación basada en Kerberos en el entorno de staging.
+
+Contexto
+--------
+
+Para la distribución MxOS, es crucial emular la infraestructura de CentOS Stream 10 para garantizar compatibilidad, permitir la colaboración ascendente, y facilitar un entorno realista de aprendizaje. 
+
+Durante el desarrollo de la prueba de concepto (PoC) en staging:
+* Se implementó un emulador de firmas basado en una aplicación Flask simulada.
+* Se utilizó un script de descarga de fuentes personalizado en Mock que imita la estructura de CentOS Stream pero carece de integración oficial de herramientas de empaquetado.
+* Se consideró la integración de Kerberos (GSSAPI) para la autenticación en Koji. Sin embargo, no se dispone de un servidor FreeIPA inmediatamente y la máquina anfitrión de staging cuenta con recursos de hardware limitados que dificultan la ejecución de un nodo de identidad adicional.
+
+Decisión
+--------
+
+Se han tomado las siguientes decisiones de diseño:
+
+* **Migrar a Sigul Real**: Reemplazar el servidor Flask simulado por una implementación real de Sigul, compuesta por los demonios `sigul-server` (aislado) y `sigul-bridge` (intermediario), junto con el cliente `sigul` en lote.
+* **Estandarizar Lookaside Cache**: Alinear la estructura del lookaside cache y el script de obtención de fuentes con la herramienta estándar `get_sources.sh` y el formato oficial del archivo `sources` de CentOS Stream.
+* **Posponer Kerberos**: Mantener la autenticación en Koji mediante certificados SSL (TLS) en staging, y documentar el diseño de Kerberos/FreeIPA para implementaciones de producción de alta disponibilidad en el roadmap técnico.
+
+Justificación
+-------------
+
+* **Seguridad y Paridad**: El flujo de firmas real con Sigul previene que las llaves GPG de producción estén en contacto con Koji Hub o con Apache mod_wsgi, manteniendo las llaves seguras e igualando la arquitectura de producción de Red Hat/CentOS.
+* **Limitación de Recursos**: Prescindir de FreeIPA en staging permite que el entorno local se ejecute sin sobrecargar de memoria y procesamiento la máquina anfitrión, mientras se mantiene el foco en el flujo de compilación y empaquetado.
+* **Facilidad de Colaboración**: La estandarización de los metadatos Git y el lookaside cache asegura que los repositorios de paquetes de MxOS puedan interactuar limpiamente con otras instancias de Koji o herramientas de CentOS Stream.
+
+Consecuencias
+-------------
+
+* Se requiere configurar una PKI adicional para la comunicación segura entre el Hub, el puente y el servidor de Sigul.
+* Se deben actualizar los playbooks de Ansible para configurar Sigul y remover el servidor mock Flask.
+* La autenticación por certificados SSL (TLS) seguirá siendo el mecanismo principal para las conexiones de administración y compilación en staging.

docs/technical/decisiones/2026-06-16-02-bloqueo_python_nss_opciones_sigul.rst

@@ -0,0 +1,46 @@
+=============================================================
+Decisión de Diseño: Bloqueo de python-nss y Opciones de Firma
+=============================================================
+
+Este registro documenta el hallazgo técnico del bloqueo de compilación de ``python-nss`` en CentOS Stream 10 y evalúa las opciones de diseño para implementar la firma de paquetes RPM.
+
+Contexto
+--------
+
+Al intentar instalar el sistema de firmas oficial de CentOS Stream (Sigul legacy), encontramos que los paquetes de dependencias críticas ``python3-nss`` y ``python3-fedora`` no están disponibles en CentOS Stream 10 / EPEL 10. 
+
+Al intentar compilar ``python-nss`` directamente desde el código fuente de PyPI usando Python 3.12 y GCC 14 en el Hub VM, la compilación falló debido a un error de sintaxis C en el uso de la macro ``va_start`` en el archivo ``src/py_nspr_error.c``:
+
+.. code-block:: text
+
+   src/py_nspr_error.c:189:23: error: macro "va_start" requires 2 arguments, but only 1 given
+     189 |         va_start(vargs);
+         |                       ^
+
+Este error impide la instalación directa del cliente de firmas Sigul heredado en Python.
+
+Opciones de Diseño
+------------------
+
+Presentamos dos caminos de resolución para el entorno de staging:
+
+Opción A: Reconstruir Sigul Legacy (Homologación Estricta)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+* **Descripción**: Descargar el código fuente de ``python-nss``, aplicar un parche en C para corregir el uso de la macro ``va_start`` (pasándole el último argumento nombrado del método), compilar el módulo de Python manualmente e instalar el SRPM de ``sigul`` heredado de EPEL 9 con la bandera ``--nodeps``.
+* **Pros**: Utiliza exactamente el mismo software, cliente CLI y flujo de firma que CentOS Stream usa actualmente.
+* **Contras**: Requiere mantener un parche manual en C para una dependencia heredada.
+
+Opción B: Adoptar Siguldry Moderno (Futuro de Fedora/CentOS)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+* **Descripción**: Configurar los servicios nativos de ``siguldry`` (que ya está disponible como paquete RPM en EPEL 10 por estar escrito en Rust). Dado que el cliente Rust no expone una llamada CLI directa de firma de archivos para PGP, se debe configurar el módulo PKCS#11 (``libsiguldry_pkcs11.so``) y enlazar ``rpmsign`` para que firme mediante este módulo de criptografía seguro.
+* **Pros**: Es nativo de CentOS Stream 10, no tiene dependencias de Python rotas, y es la arquitectura moderna elegida por el equipo de infraestructura de Fedora.
+* **Contras**: Requiere mayor complejidad de configuración criptográfica en el cliente (PKCS#11).
+
+Decisión de SCM (Git)
+---------------------
+
+Independientemente de la opción elegida para Sigul, se decide añadir restricciones estrictas de SCM en el archivo ``/etc/koji-hub/hub.conf`` para forzar que Koji únicamente acepte tareas de compilación provenientes del servidor Git local de MxOS:
+
+.. code-block:: ini
+
+   AllowedSCMs = git.mx-os.mx:/RPMs/*.git:*:use_common_checkout

docs/technical/decisiones/2026-06-16-03-implementacion_siguldry_pkcs11_spooler.rst

@@ -0,0 +1,29 @@
+========================================================
+Implementación de Siguldry PKCS#11 y Spooler de Firmas
+========================================================
+
+Este registro documenta la decisión e implementación de usar la compilación cruzada local del módulo PKCS#11 de Siguldry, su distribución e integración con el spooler de firmas de Koji.
+
+Contexto
+--------
+
+En el registro `2026-06-16-02` identificamos el bloqueo de compilación de ``python-nss`` en CentOS Stream 10, imposibilitando el cliente de Sigul tradicional. Seleccionamos Siguldry (Rust) como alternativa nativa moderna. 
+
+Sin embargo, al configurar el paquete RPM de ``siguldry`` en EPEL 10, encontramos que la biblioteca dinámica del módulo PKCS#11 (``libsiguldry_pkcs11.so``) no está empaquetada ni disponible en los repositorios de CentOS Stream 10 / EPEL 10, a pesar de que los servicios principales (server, bridge y client) sí están presentes.
+
+Decisión
+--------
+
+Para resolver la ausencia del módulo PKCS#11 y mantener la compatibilidad con el backend de firmas moderno de CentOS Stream 10, tomamos las siguientes decisiones:
+
+1. **Compilación en Host de Desarrollo**: Compilar localmente el sub-crate ``siguldry-pkcs11`` en la máquina de desarrollo del administrador (Fedora 43 x86_64) utilizando ``cargo build --release``.
+2. **Distribución vía Ansible**: Colocar la biblioteca compilada ``libsiguldry_pkcs11.so`` en los archivos del rol ``koji_hub`` y desplegarla en ``/usr/lib64/libsiguldry_pkcs11.so`` del Hub VM con permisos de ejecución.
+3. **Migración del Spooler a rpmsign**: Reescribir el demonio ``koji-sign-spooler`` para invocar el comando nativo ``rpmsign`` con el backend de Sequoia PGP (motor por defecto en EL10), configurando las variables de entorno ``PKCS11_MODULE_PATH`` y ``SIGULDRY_SOCKET`` en el proceso.
+4. **Almacenamiento de Credenciales con systemd**: Utilizar el directorio nativo ``/etc/credstore/`` para alojar las claves TLS y la frase de paso de GPG, permitiendo que systemd las exponga al demonio a través del mecanismo seguro de credenciales ``ImportCredential=siguldry.*``.
+
+Implicaciones
+-------------
+
+* **Seguridad Mejorada**: Las claves GPG y TLS se gestionan e importan usando los mecanismos de aislamiento modernos de systemd, sin exponer credenciales en archivos planos del sistema.
+* **Integración Transparente**: Al firmar los paquetes RPM en caliente mediante ``rpmsign`` sobre el almacenamiento NFS de Koji, extraemos la firma directamente usando ``koji.rip_rpm_sighdr`` para guardarla en la base de datos de Koji, igualando el comportamiento del Hub oficial.
+* **Independencia de Compilación en VMs**: Las máquinas virtuales de staging de Koji no requieren instalar herramientas de desarrollo pesadas como ``cargo`` o ``rustc``, manteniendo una huella de memoria ligera.

docs/technical/decisiones/2026-06-16-04-empaquetamiento_y_git_flujo_siguldry.rst

@@ -0,0 +1,46 @@
+====================================================================
+ADR 2026-06-16-04: Empaquetamiento y Flujo de Git para rust-siguldry
+====================================================================
+
+Estatus
+-------
+
+Propuesto
+
+Contexto
+--------
+
+La suite ``siguldry`` es crítica para implementar la firma de paquetes RPM en MxOS utilizando la integración de PKCS#11 con el spooler de firmas. Dado que el paquete upstream de EPEL 10 no incluye el módulo PKCS#11 (debido a limitaciones de las plantillas base de rust2rpm), necesitamos crear y mantener una versión modificada del paquete RPM que contenga el subpaquete ``siguldry-pkcs11`` (con la biblioteca ``libsiguldry_pkcs11.so``).
+
+Necesitamos definir:
+1. Dónde hospedar este repositorio en nuestra infraestructura de Git (Gitea/Forgejo en ``git.mx-os.mx``).
+2. Cómo interactuará esta versión con el sistema automatizado de sincronización ``rpms-sync``.
+3. Cuál será la estrategia para reducir la deuda técnica a largo plazo y colaborar con upstream.
+
+Decisión
+--------
+
+Adoptaremos las siguientes decisiones de diseño y organización:
+
+1. **Ubicación en Forgejo**:
+   Hospedaremos el repositorio en ``git.mx-os.mx/RPMs/rust-siguldry``. Esto mantiene el paquete clasificado junto a todos los demás RPMs de la distribución.
+
+2. **Estrategia de Ramas para rpms-sync**:
+   Seguiremos estrictamente la convención documentada en el flujo de trabajo de ``rpms-sync``:
+   * La rama ``c10s`` será un espejo limpio de sólo lectura del upstream de EPEL 10 y será gestionada exclusivamente por ``rpms-sync``.
+   * Crearemos la rama de distribución ``c10s-mxos`` a partir de ``c10s``. En esta rama aplicaremos nuestros parches al spec file (para definir el subpaquete ``siguldry-pkcs11`` y su instalación).
+   * De esta forma, las actualizaciones automatizadas de upstream se integrarán limpiamente vía merges periódicos de ``c10s`` a ``c10s-mxos`` por parte de los mantenedores, previniendo sobreescrituras accidentales.
+
+3. **Propuesta de Contribución a Upstream**:
+   Presentaremos el spec modificado al mantenedor oficial del paquete en Fedora/EPEL (en ``src.fedoraproject.org/rpms/rust-siguldry``). Dado que el módulo PKCS#11 es una funcionalidad estándar y esperada de Siguldry para la firma de RPMs, es altamente probable que sea aceptado upstream. Una vez fusionado, podremos prescindir de la rama de distribución local ``c10s-mxos`` y consumir el paquete directamente de EPEL 10.
+
+Consecuencias
+-------------
+
+* **Positivas**:
+  * Integración perfecta con el ciclo de vida y herramientas de MxOS (como ``rpms-sync``).
+  * Reducción de la deuda técnica al planear y ejecutar la contribución directa a EPEL 10.
+  * Mayor facilidad en el mantenimiento de actualizaciones de seguridad del paquete.
+
+* **Negativas / Desafíos**:
+  * Requiere un esfuerzo inicial de comunicación con los mantenedores de Fedora/EPEL y seguir sus lineamientos de empaquetamiento.