Andy Garcia · dev freelance
FRENES
Volver al blog
DevOps y CI

GitHub avisa de que algunos clones anónimos de repositorios públicos pueden fallar. Usuarios de CI lo reportaban desde el 2 de septiembre

19 de octubre de 2026 8 min de lectura

El lunes 19 de octubre, GitHub publicó una breve entrada de changelog con una larga cola: "During periods of unusual traffic, GitHub may temporarily require authentication for some clones and fetches of public repositories over HTTPS to help protect github.com's availability." (en español: en periodos de tráfico inusual, GitHub puede exigir temporalmente autenticación para algunos clones y fetches de repositorios públicos por HTTPS, para proteger la disponibilidad de github.com). Una operación afectada "will fail with a message indicating that authentication is required", es decir, falla con un mensaje que indica que se requiere autenticación.

Git autenticado por HTTPS, Git por SSH, los pushes y el tráfico web y de API no relacionado no se ven afectados. La protección se aplica a los repositorios de github.com, en todos los planes. GitHub no dijo con qué frecuencia piensa activarla, ni durante cuánto tiempo.

La entrada es nueva. El comportamiento, no. El 2 de septiembre, una discusión de la GitHub Community titulada "Unauthenticated clone of a public repo intermittently returns 401 (prompts for Username) from CI workers" se abría con el caso de un equipo cuyos workers de CI en Docker clonan el repositorio público MariaDB/server por HTTPS sin ninguna credencial. Otros usuarios reportaron el mismo síntoma en runners de CI, en actualizaciones de Homebrew y en catálogos de aplicaciones de TrueNAS. El 3 de septiembre, un Community Admin de GitHub respondió que GitHub había "expanded our traffic protections for unauthenticated requests" (ampliado sus protecciones de tráfico para las solicitudes no autenticadas) y que, cuando se aplican, "we now return 401 signaling Git to retry with authentication if it has credentials available" (ahora devolvemos un 401 que indica a Git que reintente con autenticación si dispone de credenciales). La entrada del 19 de octubre no enlaza ese hilo, pero describe el mismo resultado: un clon anónimo rechazado con una petición de autenticación.

Leído deprisa, suena a no-noticia: los repositorios públicos siguen siendo públicos y puedes esperar y reintentar. Leído por alguien que entrega software, dice algo más afilado. Cualquier paso de build que clone un repositorio público sin credenciales ahora puede fallar sin que haya cambiado nada de tu lado, de forma intermitente, y con un mensaje de error que puede apuntar a la causa equivocada.

En septiembre escribí sobre dónde vive tu código cuando GitHub se cae. Esta es la versión más discreta de la misma pregunta: GitHub sigue en pie y es tu build el que se detiene.

A qué se compromete realmente el anuncio

Tres frases cargan con la política. GitHub "applies this protection as narrowly as possible using signals associated with anomalous traffic" (aplica esta protección de la forma más acotada posible, usando señales asociadas a tráfico anómalo). Concede que "legitimate unauthenticated operations may occasionally be affected" (operaciones legítimas no autenticadas pueden verse afectadas ocasionalmente). Y añade: "This is not a general authentication requirement for public repositories" (esto no es un requisito general de autenticación para los repositorios públicos).

Así que no se promete nada en ningún sentido. Tu clon anónimo no es el objetivo, pero tampoco está protegido. Y "todos los planes" significa que pagar por GitHub no exime a un runner que no dice quién es.

GitHub no dice cuál es ese tráfico inusual. El 8 de mayo de 2025, cuando actualizó los límites de tasa para las solicitudes hechas sin autenticación, incluido "cloning repositories over HTTPS" (clonar repositorios por HTTPS), citó "an increase in scraping activity targeting our API" (un aumento de la actividad de scraping dirigida a nuestra API) y animó a todo el mundo a autenticarse. Diecisiete meses después, el consejo es el mismo, y los clones anónimos llevan ahora una advertencia explícita: pueden simplemente fallar.

Por qué tu portátil será el último en enterarse

Por defecto, Git no envía credenciales hasta que el servidor las pide. La respuesta de GitHub del 3 de septiembre lo dijo así: "in most cases Git will attempt all requests without authentication first, and only authenticate if it receives a 401 response" (en la mayoría de los casos Git intenta primero todas las solicitudes sin autenticación, y solo se autentica si recibe una respuesta 401). El manual de gitcredentials dice que Git "may need to ask for a username and password in order to access a remote repository over HTTP" (puede necesitar pedir un nombre de usuario y una contraseña para acceder a un repositorio remoto por HTTP), y prueba los credential helpers configurados antes de recurrir a un aviso en el terminal.

En la máquina de un desarrollador, un helper suele guardar ya un token de GitHub. La propia documentación de GitHub recomienda GitHub CLI o Git Credential Manager para recordar las credenciales HTTPS. Cuando GitHub exige autenticación, el helper responde, el clon pasa y nadie se entera.

Un runner de CI, un build de Docker o un sandbox de agente recién creado normalmente no tiene helper ni nadie al teclado. Donde GIT_TERMINAL_PROMPT vale false, Git "will not prompt on the terminal (e.g., when asking for HTTP authentication)" (no pedirá nada en el terminal, por ejemplo al solicitar autenticación HTTP), y el paso simplemente falla. La protección cae donde menos vigilas: el job programado, el despliegue que corre de noche.

Luego viene la depuración. La página del Cargo Book sobre la autenticación de Git dice: "Cargo does not require authentication for public git dependencies so if you see an authentication failure in that context, ensure that the URL is correct" (Cargo no exige autenticación para las dependencias git públicas, así que si ves un fallo de autenticación en ese contexto, asegúrate de que la URL es correcta). Sigue siendo cierto para Cargo. Ya no es toda la historia para GitHub. Un error de autenticación en una dependencia pública ahora puede significar que la URL está bien y que la protección está activada.

Dónde se esconden los clones anónimos

Oriento mi trabajo con Claude Code, y lo primero que le encargaría a un agente aquí es una búsqueda: cada URL de github.com en los archivos que construyen cosas. Esta es la lista que le daría, con lo que dice la documentación de cada herramienta.

GitHub Actions. actions/checkout autentica por defecto el checkout de tu propio repositorio: su entrada token vale por defecto el github.token del job. La pregunta son todos los demás clones del workflow: un paso run con git clone, un script que compila una herramienta desde el código fuente, un gestor de paquetes que resuelve una dependencia Git.

Dockerfiles. Una línea RUN git clone contra una URL de github.com es anónima salvo que hayas hecho que no lo sea. La documentación de Docker es tajante sobre el arreglo tentador: "Build arguments and environment variables are inappropriate for passing secrets to your build, because they persist in the final image" (los argumentos de build y las variables de entorno no son adecuados para pasar secretos al build, porque persisten en la imagen final). Usa en su lugar un secret mount. Para un repositorio Git usado como contexto de build o traído con ADD, BuildKit tiene dos secretos predefinidos, GIT_AUTH_TOKEN y GIT_AUTH_HEADER.

Gestores de paquetes. npm acepta URL git+https como dependencias y, dado un commit, "clone exactly that commit" (clona exactamente ese commit). Cargo resuelve por sí mismo las dependencias Git y "does not ask for passwords" (no pide contraseñas): la autenticación HTTPS pasa por un credential helper de Git que configuras de antemano. Terraform, para los módulos alojados en GitHub, "clones and uses the default branch referenced by HEAD" (clona y usa la rama por defecto a la que apunta HEAD). Go es una excepción parcial. GOPROXY vale por defecto proxy.golang.org con un respaldo directo, así que los módulos públicos normalmente llegan por el proxy. Pero un módulo que coincide con GOPRIVATE, o un 404 o 410 del proxy, manda al comando go al propio sistema de control de versiones.

Paquetes Swift. La guía de Apple sobre cómo construir paquetes Swift en integración continua dice que un proyecto que depende solo de paquetes públicos no necesita configuración adicional. También dice que xcodebuild "uses Xcode's built-in Git tooling" (usa las herramientas Git integradas de Xcode), y solo usa la instalación y la configuración de Git de tu Mac si pasas -scmProvider system. Así que un credential helper en tu configuración de Git puede no llegar nunca hasta él. Para los paquetes que necesitan autenticación, el consejo de Apple son URL Git por SSH con credenciales SSH, y SSH está en la lista de casos no afectados de GitHub.

Submódulos, tareas cron y agentes. Un archivo .gitmodules con URL HTTPS, un script nocturno que clona un conjunto de datos, un script de instalación, un agente de código que clona una biblioteca en un directorio temporal para leer su código fuente: todos son clientes HTTPS anónimos salvo que alguien los haya configurado de otro modo.

El arreglo, entorno por entorno

Las recomendaciones de GitHub son breves. En GitHub Actions, usa el GITHUB_TOKEN integrado. En otros sistemas de CI, "prefer a GitHub App installation access token" (prefiere un token de acceso de instalación de GitHub App); un personal access token también sirve. Las operaciones que no puedan autenticarse deben reintentar cuando se haya levantado la protección temporal.

En una máquina que ya guarda credenciales, el ajuste http.proactiveAuth de Git hace que "attempt authentication without first making an unauthenticated attempt and receiving a 401 response" (intente la autenticación sin hacer antes un intento no autenticado y recibir una respuesta 401). La respuesta de GitHub del 3 de septiembre lo nombraba, junto con SSH, como las dos formas de forzar la autenticación.

Tres detalles cambian cómo lo cableas.

Vida de los tokens. Un token de acceso de instalación "will expire after 1 hour" (caduca después de 1 hora). El GITHUB_TOKEN vive hasta que termina el job, hasta 6 horas en los runners alojados por GitHub. Si un pipeline genera un único token de App al empezar y una etapa posterior clona en el minuto 70, ese token lleva muerto 10 minutos. Genera un token por etapa, o deja que lo haga una biblioteca: GitHub señala que sus SDK Octokit regeneran el token una vez caducado.

Alcance. En la vía del personal access token, la documentación de GitHub dice que los tokens de grano fino "always include read-only access to all public repositories on GitHub" (siempre incluyen acceso de solo lectura a todos los repositorios públicos de GitHub). El token de grano fino más estrecho que puedes crear ya lee código público. No hay motivo para darle a un build un token clásico con permisos amplios para esto.

Reintentos. Reintentar cuando se levanta la protección es el propio consejo de GitHub para todo lo que no pueda autenticarse, así que un reintento acotado con backoff alrededor de los pasos de clonado es razonable. Mantenlo acotado y registra el mensaje. Un error de autenticación en un repositorio público es ahora una señal que merece contarse, no ruido que tragarse.

La auditoría que haría

Como CTO que además publica apps de iOS y un juego de estrategia por su cuenta, lo trataría como una auditoría de una tarde, no como un proyecto.

Primero, el inventario: los archivos de workflow, los Dockerfiles, package.json, Cargo.toml, go.mod y cualquier ajuste GOPRIVATE, .gitmodules, las fuentes de módulos de Terraform y el archivo Package.resolved de cada proyecto Xcode, donde Xcode registra cada dependencia de paquete.

Segundo, autenticar lo que se despliega: GITHUB_TOKEN en Actions, un token de App generado por etapa en otros sitios, un secret mount en Docker, SSH o -scmProvider system para xcodebuild.

Tercero, reducir el número de clones. Cachear las dependencias entre ejecuciones, donde la cadena de herramientas lo permita, significa menos viajes a GitHub, y un clon que no haces no puede ser rechazado.

Cuarto, hacer legible el fallo. Añade una línea al runbook: un error de autenticación en un repositorio público de GitHub significa revisar primero las credenciales y el changelog de GitHub, y después la URL.

Los repositorios públicos siguen siendo públicos. Lo que cambió el 19 de octubre es que el acceso anónimo es ahora explícitamente de mejor esfuerzo, y un build que no sabe decir quién es lo descubrirá el día de mayor carga de GitHub, no el tuyo.

Fuentes

¿Un proyecto del mismo estilo?

Diseño y despliego productos como este. Hablemos.

Hablemos