Contribuciones a Debian: Trabajos patrocinados por Freexian y opciones de apoyo

Por qué este informe mensual importa más de lo que parece

El 9 de octubre de 2026, Colin Watson publicó su reporte mensual de actividad como desarrollador de Debian. Para la mayoría de los lectores suena a nota interna: otro mantenedor contando qué hizo. Pero si lo lees con atención, el documento destapa la maquinaria invisible que mantiene vivo tu servidor: parches críticos de seguridad, transiciones de Python 3.15, limpieza de pkg_resources, y soporte de sysvinit que sigue vigente en servidores legacy.

Colin no es un mantenedor cualquiera. Antes de volver a Debian a tiempo completo fue CTO de Canonical durante más de una década. Su trabajo aparece en openssh-server, groff, parted y más de 70 paquetes de Python que probablemente tienes instalados en producción sin saberlo. Que en septiembre toda su actividad haya sido patrocinada por Freexian nos da pie para entender un modelo de financiamiento del software libre que casi nadie fuera del ecosistema Debian conoce.

Freexian: el modelo de patrocinio corporativo que sostiene Debian

Freexian es una empresa francesa fundada en 2010 por Christophe Fillot y otros ex contribuidores de Debian. Su modelo de negocio tiene dos patas: consultoría alrededor de Debian para empresas (migraciones, LTS a medida, soporte profesional) y un programa de patrocinio abierto donde cualquier organización o persona puede financiar horas de trabajo de mantenedores upstream.

El artículo de Colin lo deja explícito al inicio: “My Debian contributions this month were all sponsored by Freexian.” Detrás de esa frase hay un contrato de medio tiempo o tiempo completo entre Freexian y el desarrollador, por el cual Freexian paga un salario mientras el desarrollador trabaja en bugs, transiciones, y mantenimiento general del archivo de Debian. Los clientes de Freexian — bancos, ISPs, proveedores de hosting — se benefician indirectamente porque ese trabajo termina en los paquetes estables que corren en sus servidores.

El programa de contribuciones de Freexian se llama Debian LTS en su faceta de soporte extendido, pero el aporte a sid y bookworm/trixie sale del programa regular. Empresas como Cloudways, Evolix y otros proveedores franceses aparecen históricamente entre los patrocinadores. La particularidad frente a Canonical es que Freexian no compite con Debian: lo sostiene. No hay un Ubuntu paralelo, no hay una marca comercial propia; el valor está en pagar a la gente que mantiene los paquetes que todos usamos.

Lo que se hizo en septiembre: OpenSSH, groff y parted

Tres paquetes recibieron cambios visibles en septiembre. Cada uno toca servidores en distintas capas, así que vale la pena revisarlos uno por uno.

OpenSSH: limpieza de libselinux y fix de reload con sysvinit

Colin trabajó con upstream para remover el enlace dinámico contra libselinux en /usr/sbin/sshd. El bug upstream es mindrot bugzilla 3996. ¿Por qué importa? El binario sshd arrastraba libselinux aunque la mayoría de las instalaciones no usan SELinux; eso significa más superficie de ataque en cada servidor Debian, dependencias que se rompen cuando actualizas libselinux, y un binario más grande de lo necesario. Si corres ldd /usr/sbin/sshd en una versión anterior, probablemente veas libselinux.so.1 en la salida. Tras el parche, esa dependencia desaparece en sistemas donde no es necesaria.

ldd /usr/sbin/sshd | grep -i selinux
# Antes: libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1
# Después: (vacío)

El segundo cambio es un fix aplicado por Mark Robillard Jr y subido por Colin al bug 1148188: el script de init de sysvinit tenía una lógica de reload rota. Si tu servidor Debian todavía usa sysvinit (no systemd), el /etc/init.d/ssh reload puede no estar recargando la configuración correctamente desde hace tiempo. La señal típica es editar /etc/ssh/sshd_config, ejecutar el reload, y que el proceso siga con la configuración vieja.

groff: 1.24.1 → 1.24.2 corrige vulnerabilidades de inyección

El paquete groff (el formateador de texto clásico de Unix) subió de 1.24.1 a 1.24.2. La actualización cierra varias vulnerabilidades de inyección de comandos. groff parece software de los 90 — y lo es — pero sigue activo: se usa en páginas man, en la pipeline de documentación de varios proyectos, y en herramientas como pdfroff. Si sirves páginas man vía HTTP, el motor de rendering pasa por groff. La actualización es recomendable apenas entre al archive.

apt changelog groff | head -20
# Verifica que tu versión instalada sea 1.24.2 o superior.
# Si todavía está en 1.24.1, forzar actualización:
sudo apt-get install --only-upgrade groff groff-base

parted: 3.7 → 3.8 corrige CVE-2026-89085 y CVE-2026-89088

Este es el cambio con más impacto operativo inmediato. parted es la herramienta que usas para particionar discos, redimensionar, y crear tablas de particiones. Está involucrada en instalaciones, en scripts de provisioning, y en cualquier herramienta de automatización que prepare storage. La versión 3.8 corrige dos CVE: CVE-2026-89085 y CVE-2026-89088. Si tienes un servidor Debian que use parted automáticamente — por ejemplo, en un script de Terraform, en una imagen AMI, o en partman durante la instalación desatendida — la actualización es prioritaria.

parted --version
# Si dice 3.7 o anterior, actualiza:
sudo apt-get install --only-upgrade parted libparted2
# Reinicia cualquier servicio que mantenga handles abiertos sobre /dev/sdX.

Después de actualizar parted, valida que el particionador sigue reconociendo tus discos con un dry-run no destructivo. parted no tiene modo dry-run real, pero puedes usar parted -s /dev/sda unit s print para listar la tabla sin modificarla.

Python packaging: la limpieza silenciosa que sostiene tu distro

El grueso del reporte de Colin son paquetes de Python. Literalmente, septiembre cerró con 50+ paquetes actualizados a nuevas versiones, correcciones de FTBFS contra Python 3.15, y remoción sistemática de pkg_resources. Si te parece detalle menor, recuerda que Python es el runtime de ansible, nginx (algunos módulos), fail2ban, prometheus-node-exporter, y prácticamente toda la stack de monitoring moderna.

setuptools 84 ya no contiene pkg_resources

setuptools 84 entró a Debian. Esto cierra un ciclo: pkg_resources está deprecado upstream hace años y se eliminaría por completo en versiones futuras. Colin hizo otra barrida de paquetes que aún lo importaban, entre ellos flufl.password, junos-eznc, python-launchpadlib, sphinxcontrib-log-cabinet, straight.plugin y una decena más. Si tu propio código Python importa pkg_resources, esa importación va a fallar en algún momento durante 2027. Mejor migrar a importlib.metadata ahora.

grep -rn "import pkg_resources" /usr/lib/python3/dist-packages/ 2>/dev/null | head -10
# Si hay resultados, ese paquete va a romperse cuando setuptools 85 entre al archive.
# Para tu propio código: reemplazar pkg_resources por importlib.metadata
# https://docs.python.org/3/library/importlib.metadata.html

CVEs en el ecosistema Python que ya están parcheados en Debian

Algunos paquetes Python de los que actualizó Colin traen CVEs críticos resueltos en la nueva versión. Vale la pena que los listes en tu propio audit porque seguramente están en tus servidores:

Paquete	CVE	Aplicación típica
djangorestframework	CVE-2026-73228, CVE-2026-73229	APIs REST
python-anyio	CVE-2026-63349, CVE-2026-63374, CVE-2026-64847	async runtime
python-pyzipper	CVE-2026-44722	manejo de ZIP cifrado

Si corres alguno de estos en producción, ejecuta apt list --upgradable 2>/dev/null | grep -i django y similares para confirmar que tu mirror ya ofrece la versión parcheada.

Build failures contra Python 3.15

Septiembre también trajo parches para paquetes que no compilaban contra Python 3.15rc2. La lista incluye python-blockbuster, storm, tagpy. Esto no te afecta hoy si corres Python 3.12/3.13, pero te avisa que la transición a 3.15 ya está moviéndose por el archive de Debian. Es un buen momento para empezar a probar tu propio código contra 3.15 en un entorno staging.

Cómo apoyar tú a un mantenedor de Debian

Colin publica al inicio de cada reporte sus vías de patrocinio directo: Liberapay y GitHub Sponsors. Si su trabajo te parece valioso (y si lees esto, lo es), puedes apoyarlo mensualmente con montos pequeños. Pero más allá de Colin, hay un ecosistema entero de mantenedores que viven al borde del burn-out porque nadie les paga.

Liberapay vs GitHub Sponsors vs Open Collective

Las tres plataformas funcionan, pero tienen diferencias operativas que importan:

• Liberapay está operado por una asociación francesa sin fines de lucro (Liberapay SARL). Las donaciones se procesan vía Stripe y el sitio se queda con una comisión pequeña. Es popular entre desarrolladores europeos.
• GitHub Sponsors está integrado al perfil de GitHub. Microsoft no cobra comisión a los mantenedores durante los primeros 12 meses, después aplica un fee. Tiene la ventaja de que el dinero llega al mantenedor vía Stripe o transferencia bancaria.
• Open Collective permite crear una organización transparente con presupuestos públicos. Es más común para proyectos que para mantenedores individuales, pero existe la opción de “fiscal host”.

Para un mantenedor individual como Colin, Liberapay y GitHub Sponsors son las opciones más simples. Si quieres apoyar a un proyecto entero (por ejemplo, Debian como tal), el mecanismo correcto es donar a Software in the Public Interest (SPI), la organización sin fines de lucro que maneja los fondos de Debian. También existen donaciones vía la Debian donation page oficial.

Empresas: el apoyo fiscal y el tiempo del equipo

Si diriges un equipo de ingeniería que corre Debian en producción, hay tres formas de contribuir que cuestan poco y rinden mucho:

1. Pagar horas de tu equipo para reportar bugs con parches. Cada bug que tu ingeniero reporta con un parche funcional ahorra tiempo a un mantenedor externo. Patrocinio indirecto, pero valuable.
2. Contratar a Freexian o a una consultora similar para que tu dinero regrese al ecosistema. Es consulting que financia el mismo software que usas.
3. Configurar una suscripción corporativa a Liberapay o GitHub Sponsors en nombre de la empresa. Algunas empresas grandes (Google, Microsoft, AWS) ya lo hacen; cualquier PYME puede sumarse con 50-200 USD mensuales.

Verifica tu propio servidor después de las actualizaciones

Si tienes un servidor Debian y aplicaste las actualizaciones de octubre, vale la pena hacer un audit rápido para confirmar que ninguno de los paquetes mencionados quedó en versión vulnerable.

dpkg -l | awk '/openssh-server|groff|parted/ {print $2, $3}'
# Confirma versiones actuales. Para openssh-server, debería ser >= 1:9.x reciente.
# Para groff, debería ser 1.24.2 o superior.
# Para parted, debería ser 3.8 o superior.
apt list --upgradable 2>/dev/null | grep -E "django|anyio|pyzipper"
# Si alguno aparece, hay un fix esperando.

Para un audit de Python más amplio, escanea el filesystem buscando imports de pkg_resources en tus dependencias de terceros:

grep -rn "from pkg_resources" /opt/ /srv/ /var/www/ 2>/dev/null | head -20
# Si hay hits, tu propio código (o el de tu proveedor) va a romperse
# cuando setuptools 85 entre al archive. Planifica la migración.

Opinión: vale la pena este modelo para sysadmins hispanos

El modelo Freexian — pagar a mantenedores para que trabajen en Debian a tiempo parcial o completo — funciona. Lo que vemos en el reporte de Colin es evidencia: tres paquetes de seguridad actualizados, una transición de Python completa, docenas de bugs resueltos, todo en un solo mes, todo documentado. No es caridad: es infraestructura profesional.

Para sysadmins hispanohablantes, este modelo tiene una barrera cultural: donamos poco a proyectos open source. La cultura del patrocinio individual vía Liberapay o GitHub Sponsors es mucho más fuerte en Europa y en la comunidad anglosajona que en Latinoamérica. Cuando un mantenedor latinoamericano deja de mantener un paquete porque se quema y no le pagan, perdemos todos. El cambio cultural que falta no es técnico: es aceptar que el software libre serio cuesta dinero y que ese dinero tiene que salir de algún lado.

Si Debian es tu distro de servidor, tienes una obligación práctica — no solo ética — de devolver algo al ecosistema. Suscríbete a Liberapay de un mantenedor que uses. Pide a tu empresa que done a SPI. O, más modesto aún, reporta el próximo bug que encuentres con un parche decente. Es la misma lógica del reporte de Colin: trabajo visible, financiación visible, infraestructura que se sostiene.

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux