MxOS/ansible-koji
SHA256
Watch
6
0
Fork
You've already forked ansible-koji
 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions
ansible-koji/docs/technical/decisiones/2026-06-16-04-empaquetamiento_y_git_flujo_siguldry.rst
Rénich Bon Ćirić 89d6f66be8
 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>
2026-06-16 10:06:44 -06:00

2.9 KiB
Raw Blame History

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.