La petición llegó como una captura de pantalla de Easypanel: un botón «Enable/Disable Auto Deploy» y una URL de webhook que se puede llamar desde cualquier sitio. sh0 ya desplegaba con cada push de Git. No es lo mismo, y la diferencia está en para quién existe sh0.
El usuario decide la forma
El primer público de sh0 es la clientela de la empresa de hosting: más de 1.200 desarrolladores que vienen de
cPanel. Entregan su propio código como Dockerfile o como archivo comprimido, y apenas usan GitHub. Un webhook
que solo acepta una firma de GitHub, GitLab o Bitbucket no les sirve de nada. Hasta esta sesión, su único
disparador remoto era POST /apps/:id/deployments con una clave de API, y una clave de API es una credencial de
cuenta: abre todas las aplicaciones a las que tiene acceso su dueño.
Lo que necesitan es algo que un curl -X POST pegado en un job de CI, un cron o un script de build pueda llamar,
y que no sea capaz de hacer nada más que volver a desplegar una sola aplicación.
El diseño, en cuatro restricciones
- El token es la autenticación, así que vive en la ruta. Una sola forma, nunca cabecera y ruta. Es lo que
- un
curlcopiado y pegado llama sin ninguna configuración. El token tiene 256 bits del generador aleatorio - del sistema y se muestra una sola vez. Se guarda como hash SHA-256 (la misma primitiva que las claves de API;
- con una entropía tan alta, un hash lento no aporta nada) y se compara en tiempo constante.
- Un rechazo no dice nada. Una aplicación desconocida, una URL desactivada y un token incorrecto devuelven
- el mismo 404, byte por byte. Cuando la aplicación no tiene ninguna URL, el handler calcula igualmente un hash
- contra un digest ficticio, para que esa rama cueste lo mismo que un token incorrecto.
- Exactamente el botón Deploy. No escribimos una segunda vía de despliegue. El handler del botón se dividió,
- y la URL llama a la misma función
launch_deployment. La refactorización corrigió además una fuga antigua: el - cliente Docker del nodo de la aplicación ahora se resuelve antes de insertar la fila, de modo que un nodo
- inalcanzable ya no deja un despliegue
queuedhuérfano. - Diez llamadas no apilan diez despliegues. Cada aplicación mantiene en memoria una única plaza
- «pendiente». Una llamada que encuentra la plaza ocupada se suma a ese despliegue. La plaza se libera cuando el
- pipeline adquiere el cerrojo de despliegue de la aplicación. Mantenerla en memoria fue deliberado: una fila en
- la base de datos sobreviviría a un fallo y podría bloquear la URL para siempre.
La prueba se ejecutó en la máquina de demostración: diez llamadas lanzadas en paralelo durante un despliegue en
curso produjeron exactamente un despliegue adicional, y nueve respuestas decían "coalesced": true.
Lo que encontró la auditoría
El agente de auditoría de solo lectura devolvió GO-WITH-FIXES. Dos de sus hallazgos cambiaron el código antes de generar la release candidate.
El token estaba a un nivel de log de acabar en journald. El span por defecto del TraceLayer de tower_http registra
la URI completa. En el nivel info, ese span está desactivado. Ejecutar sh0 con --log-level debug para
perseguir un bug sin relación habría escrito en claro todos los tokens de despliegue activos. Nada en el código
de la funcionalidad registraba el token. Lo hacía el framework. La corrección es un span propio que oculta el
segmento del token y ya no registra las query strings en absoluto. La campaña de verificación lo comprobó
después: journalctl -u sh0 | grep <token> devolvió cero líneas.
Un desarrollador podía crear una credencial que le sobreviviera. La especificación decía «los roles que
pueden desplegar la aplicación». El problema es que una URL de despliegue es una credencial al portador. Sacar
al desarrollador del proyecto no revoca la URL que creó. Emitir o rearmar una credencial es un acto de
administrador, así que la rotación y la activación o desactivación exigen ahora el rol admin del proyecto, y los
desarrolladores conservan el acceso de lectura. El log de sesión lo registra como una decisión tomada sin el
CEO, porque se aparta del prompt y se puede deshacer en una línea.
El interruptor, probado con un clic
El interruptor «Auto deploy» de la barra de acciones escribe el flag auto_deploy existente. La prueba fue un
clic, no un PATCH: un Chromium headless, controlado por CDP, hizo clic en [data-testid=auto-deploy-toggle].
aria-pressed pasó de true a false, y la API leyó después auto_deploy=false. Un test de ruta solo puede
demostrar que la ruta funciona. El clic demuestra que el botón llama a la ruta.
Lo que sigue abierto
- Si falla la inserción del primer despliegue, quien se haya sumado a él recibe un id que no apunta a nada. Es
- poco frecuente, está documentado y tiene arreglo.
- Un despliegue que nunca libera el cerrojo congela la plaza pendiente hasta el reinicio.
- En una instalación a la que se accede por IP sin dominio de panel, la URL es
http://, así que el token viaja - en claro. Es la misma limitación que tienen los webhooks de Git existentes.
Cada uno de estos puntos está anotado en el log de sesión, en «Deferred». Ninguno se esconde detrás de un «corregido».
Desde entonces, en la sesión 261120 del 17 de octubre, el lado de Git se puso al día: activar el despliegue automático hace ahora que sh0 cree el webhook de GitHub por sí mismo y, cuando no puede, sh0 recurre a consultar la rama periódicamente. La prueba de extremo a extremo contra un repositorio real de GitHub sigue pendiente, y la incidencia sigue abierta hasta que se produzca.