⏱️ Lectura: 11 min

El proyecto HardenedBSD Radicle dio un paso importante esta semana: el fork endurecido de FreeBSD oficializó la migración de sus repositorios principales a Radicle, la red peer-to-peer para colaboración en código abierto. La novedad fue anunciada el 26 de abril de 2026 por Shawn Webb, fundador del proyecto, y marca uno de los movimientos más concretos hacia infraestructura de código soberana en el mundo BSD.

📑 En este artículo
  1. Qué pasó: HardenedBSD oficializa su presencia en Radicle
  2. Qué es Radicle y por qué este movimiento importa
  3. HardenedBSD: el fork endurecido de FreeBSD, en breve
  4. Cómo conectarse al nodo seed y clonar los repos
  5. Datos y cifras: qué tan grande es esto
  6. Impacto y análisis: el goteo lento del éxodo de GitHub
  7. Qué sigue para HardenedBSD en Radicle
  8. Preguntas frecuentes
    1. ¿Radicle reemplaza a Git?
    2. ¿Tengo que instalar todo HardenedBSD para usar Radicle?
    3. ¿Cuánto tarda en clonar el árbol src de HardenedBSD?
    4. ¿GitHub deja de ser un mirror oficial?
    5. ¿Es seguro depender de un protocolo P2P para mi código?
    6. ¿Cómo verifico la autenticidad de un commit en Radicle?
  9. Referencias

No es un experimento aislado. HardenedBSD Radicle ahora alberga los tres repos centrales del proyecto —src, ports y pkg— accesibles desde un nodo seed dedicado. Aunque el propio Webb reconoce que aún quedan aristas por pulir (especialmente en performance para repos grandes), la funcionalidad básica ya es usable, e incluso permite construir ports-mgmt/pkg tirando los distfiles directamente de una instancia de radicle-httpd. Esto último, en jerga de FreeBSD, equivale a tener un sustituto funcional de USE_GITHUB y USE_GITLAB dentro del árbol de ports.

En este artículo explicamos qué se migró, cómo funciona Radicle por dentro, cómo conectarse al nodo seed de HardenedBSD desde cualquier sistema, y por qué la decisión importa más allá del nicho BSD.

Qué pasó: HardenedBSD oficializa su presencia en Radicle

Durante la última semana, Webb trabajó en llevar los repositorios de HardenedBSD a Radicle. La conclusión: la red ya es usable para el proyecto, con los tres repos disponibles públicamente:

  • HardenedBSD-srcrad:z2HLHXgL1xevBNQsf8BmQW7MpJmtm
  • HardenedBSD-portsrad:z2XrdvALg77ycnuZRXgScb27yb3wM
  • HardenedBSD-pkgrad:z3QDZAW2FAfuLvihrhiyDC9fAD8G9

Esos identificadores no son hashes de Git tradicionales: son RIDs (Radicle Identifiers), direcciones únicas dentro de la red P2P que identifican un repositorio sin depender de un dominio o servidor central. Cualquier persona puede browsear el contenido vía la interfaz web del proyecto en radicle.network/nodes/rad.hardenedbsd.org, sin necesidad de instalar el cliente.

Webb adelantó que el plan es migrar el 100% de los repositorios con el tiempo. secadm —la utilidad de administración de políticas de seguridad de HardenedBSD— probablemente sea el siguiente. La integración con el árbol de ports todavía es básica y naive (palabras del propio Webb), pero suficiente para construir paquetes desde Radicle. Es el primer paso, no el último.

💭 Clave: HardenedBSD no abandonó GitHub —los mirrors siguen ahí—, pero ya no depende de un solo proveedor para distribuir su código. El término correcto es code sovereignty: el proyecto controla su propia infraestructura de distribución.

Qué es Radicle y por qué este movimiento importa

Radicle es un protocolo de red peer-to-peer construido sobre Git. La idea, en una línea: convertir cada clon de un repositorio en un nodo capaz de propagar cambios sin servidores centralizados. Bajo el capó usa libp2p (la misma stack que IPFS y Ethereum), un sistema de identidad criptográfica basado en claves Ed25519, y un modelo de gossip donde los nodos seedean repos del mismo modo en que un cliente de BitTorrent comparte trozos de un archivo.

HardenedBSD Radicle red P2P de Git con nodos seed distribuidos
Radicle convierte cada clon en un nodo capaz de propagar cambios sin servidores centrales.

La diferencia con GitHub o GitLab no es estética. En GitHub, si la cuenta del proyecto es suspendida, el repo desaparece para todo el mundo (sucedió con youtube-dl en 2020). En Radicle, mientras al menos un nodo siga seedeando el RID, el repo sigue accesible. La autoría se valida con firmas criptográficas, no con la palabra del proveedor. Cada commit, cada issue, cada patch propuesto va firmado por una clave que el autor controla.

graph LR
    A["Dev local"] -->|push| B["Nodo Radicle local"]
    B -->|gossip libp2p| C["Seed node HardenedBSD"]
    C -->|gossip| D["Nodo seed comunitario 1"]
    C -->|gossip| E["Nodo seed comunitario 2"]
    D -->|fetch| F["Otro dev"]
    E -->|fetch| F

Para proyectos como HardenedBSD —cuyo enfoque entero es endurecer un sistema operativo contra ataques y sesgos de proveedores— moverse hacia infraestructura descentralizada es coherente con la misión. Radicle ya es la opción preferida de varios proyectos de criptografía, y empieza a ganar tracción en el mundo BSD y de seguridad.

HardenedBSD: el fork endurecido de FreeBSD, en breve

Para quien no lo conozca: HardenedBSD es un fork de FreeBSD que aplica mitigaciones agresivas de seguridad por defecto. Entre lo que trae out of the box:

  • ASLR avanzado — randomización de direcciones de memoria aplicada a stack, heap, librerías y mmap, con entropía superior al ASLR de FreeBSD vanilla.
  • SafeStack y CFI — protecciones de Clang activadas en gran parte del userland.
  • W^X estricto — bloqueo de páginas escribibles y ejecutables al mismo tiempo, mitigando varias clases de exploits de memoria.
  • secadm — un sistema de policies que permite restringir qué binarios pueden hacer qué (similar en espíritu a SELinux pero con sintaxis BSD).

El proyecto existe desde 2014, está liderado por Shawn Webb y Oliver Pinter, y aunque su comunidad es pequeña comparada con FreeBSD, su trabajo se cita regularmente en papers de seguridad de sistemas. Esa misma cultura —desconfiar de los defaults, controlar la cadena— es la que explica por qué el salto a Radicle no llega como sorpresa.

Cómo conectarse al nodo seed y clonar los repos

El proceso requiere tener instalado el cliente rad. La instalación cambia según el sistema:

# Linux / macOS (script oficial)
curl -sSf https://radicle.xyz/install | sh

# Linux con paquetes (Arch)
sudo pacman -S radicle

# Windows (vía WSL2 — Radicle aún no tiene binario nativo)
wsl --install
# Dentro de WSL:
curl -sSf https://radicle.xyz/install | sh

Una vez instalado, los pasos que Webb recomienda como los más confiables son tres. Primero, conectar al seed VM oficial de HardenedBSD:

rad node connect z6MknwwMpmZET1PcvQjPYhA6hGY7wkYzxb9YtSRh5j2qSQdG@rad.hardenedbsd.org:8776

Después, indicarle al nodo que seedee el repo desde el seed remoto. En este ejemplo es el árbol src, pero el comando es idéntico para ports y pkg cambiando el RID:

rad seed --from z6MknwwMpmZET1PcvQjPYhA6hGY7wkYzxb9YtSRh5j2qSQdG \
         rad:z2HLHXgL1xevBNQsf8BmQW7MpJmtm

El cliente empieza a descargar el árbol completo a ~/.radicle/storage/. El propio Webb advierte que tarda bastante —el árbol src de un BSD pesa varios GB de historia— y sugiere paciencia. Cuando el directorio temporal rad:<ID>.tmp se renombra a rad:<ID>, el repo está listo localmente. Recién entonces se hace el clone:

rad clone rad:z2HLHXgL1xevBNQsf8BmQW7MpJmtm
⚠️ Ojo: Radicle aún tiene problemas de performance con repos grandes. Editá ~/.radicle/config.json y subí node.limits.fetchPackReceive a por lo menos 3GB antes de seedear el árbol src, o el fetch va a fallar a mitad de camino.

Para devs en LATAM con conexiones inestables, vale la pena hacer el primer fetch desde una VPS cercana (DigitalOcean São Paulo, AWS Brasil, GCP São Paulo) y después rsyncear el directorio ~/.radicle/storage a la máquina local. Es el mismo patrón que se usa con repos pesados de Git.

Datos y cifras: qué tan grande es esto

Para dimensionar la migración:

  • 3 repos migrados oficialmente al cierre de abril 2026 (src, ports, pkg).
  • ~3 GB mínimo recomendado de buffer (fetchPackReceive) para fetchear src.
  • 2014 es el año de fundación de HardenedBSD; lleva 12 años de historia versionada.
  • USE_GITHUB y USE_GITLAB son los macros existentes en el árbol de ports de FreeBSD para tirar distfiles desde esos servicios; HardenedBSD ya tiene un equivalente naive para Radicle.
  • $19,369 USD recaudados en su último ciclo de donaciones contra una meta de $15,000 — el proyecto se autofinancia, lo que refuerza el incentivo de no depender de plataformas centralizadas.
Terminal con comandos rad clone y rad seed para HardenedBSD Radicle
El cliente rad: seedear, clonar y empujar cambios sin pasar por GitHub.

Impacto y análisis: el goteo lento del éxodo de GitHub

HardenedBSD no es el primer proyecto serio en moverse fuera de GitHub. Drew DeVault construyó SourceHut con esa premisa. El kernel Linux usa git.kernel.org como fuente de verdad y trata GitHub como mirror. Codeberg y proyectos basados en Forgejo crecen sostenidamente. Lo distinto de Radicle es que no propone otra forja centralizada: propone que la forja sea la red.

Para LATAM, donde varias organizaciones de desarrollo se vieron afectadas por restricciones de exportación de software (sanciones a Cuba o Venezuela bloqueando cuentas de devs en GitHub en 2019 y 2021), un protocolo P2P resistente a censura es más que un capricho ideológico. Es continuidad operativa. Si tu cuenta de GitHub se cae mañana, ¿podés seguir colaborando? Con Radicle, sí: cualquier nodo seed con el repo basta.

💡 Tip: Si estás en LATAM y querés experimentar con Radicle sin compromiso, levantá un nodo en una VPS chica (1 vCPU, 2 GB RAM) y seedeá un par de repos pequeños. El gossip P2P trabaja bien aún con bandwidth modesto si el nodo está estable.

El otro ángulo es licenciamiento y supply chain. Cada commit firmado en Radicle es verificable contra la clave del autor sin intermediarios. En un mundo donde la firma de Sigstore y los SBOMs son cada vez más relevantes para compliance (NIS2 en Europa, lineamientos NIST en EE.UU.), la genealogía criptográfica nativa de Radicle encaja sin esfuerzo extra.

Qué sigue para HardenedBSD en Radicle

Webb fue claro: la migración no terminó. Próximos pasos públicos del proyecto:

  • secadm como siguiente repo a migrar — la utilidad estrella de seguridad del fork.
  • Mejorar la integración con el árbol de ports más allá de la versión inicial naive.
  • Optimizar la performance de Radicle para repos del tamaño de un kernel BSD.
  • Eventualmente, el 100% de los repos del proyecto.

Vale la pena seguir el blog oficial y el grupo de Signal de HardenedBSD para enterarse de cada migración. La comunidad bajó al canal de Matrix y a IRC libera para coordinar pruebas tempranas del cliente rad sobre FreeBSD/HardenedBSD.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Radicle reemplaza a Git?

No. Radicle está construido sobre Git. Es una capa de red P2P que reemplaza el rol de servidores como GitHub o GitLab, pero localmente seguís trabajando con un repo Git normal —git commit, git log, git diff funcionan igual—.

¿Tengo que instalar todo HardenedBSD para usar Radicle?

No. El cliente rad corre en Linux, macOS y Windows (vía WSL). Podés clonar los repos de HardenedBSD desde cualquier sistema; el sistema operativo del proyecto y el cliente de Radicle son cosas separadas.

¿Cuánto tarda en clonar el árbol src de HardenedBSD?

Depende de tu conexión y del nodo seed más cercano. Webb mismo dice que «tarda un buen rato, andá por una pizza y root beer». En la práctica, planificá 1 a 3 horas en una conexión hogareña típica de LATAM.

¿GitHub deja de ser un mirror oficial?

No por ahora. Los mirrors de GitHub siguen disponibles. La diferencia es que la fuente de verdad pasa a ser la red Radicle, y GitHub queda como espejo de conveniencia para quien no quiera correr rad.

¿Es seguro depender de un protocolo P2P para mi código?

Mientras al menos un nodo siga seedeando el RID, el repo es recuperable. Si querés mayor garantía, configurá tu propio nodo seed permanente. Es el mismo principio de redundancia que cualquier estrategia seria de backup.

¿Cómo verifico la autenticidad de un commit en Radicle?

Cada commit y cada propuesta de cambio están firmados con la clave Ed25519 del autor. El cliente rad verifica las firmas automáticamente al fetchear, y rechaza objetos cuya firma no coincide con la identidad declarada.

Referencias

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.

Categorías: Programación

Andrés Morales

Desarrollador e investigador en inteligencia artificial. Escribe sobre modelos de lenguaje, frameworks, herramientas para devs y lanzamientos open source. Cubre papers de ML, ecosistema de startups tech y tendencias de programación.

0 Comentarios

Deja un comentario

Marcador de posición del avatar

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.