Andy Garcia · dev freelance
FRENES
Retour au blog
DevOps & CI

GitHub prévient que certains clones anonymes de dépôts publics peuvent échouer. Des utilisateurs de CI le signalaient depuis le 2 septembre

19 octobre 2026 8 min de lecture

Le lundi 19 octobre, GitHub a publié une courte entrée de changelog à longue traîne : « 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 français : en période de trafic inhabituel, GitHub peut exiger temporairement une authentification pour certains clones et fetches de dépôts publics en HTTPS, afin de protéger la disponibilité de github.com). Une opération touchée « will fail with a message indicating that authentication is required », c'est-à-dire qu'elle échoue avec un message indiquant qu'une authentification est requise.

Git authentifié en HTTPS, Git en SSH, les pushes et le trafic web et API sans rapport ne sont pas concernés. La protection s'applique aux dépôts sur github.com, tous forfaits confondus. GitHub n'a pas dit à quelle fréquence il compte l'activer, ni pour combien de temps.

L'entrée est nouvelle. Le comportement, non. Le 2 septembre, une discussion de la GitHub Community intitulée « Unauthenticated clone of a public repo intermittently returns 401 (prompts for Username) from CI workers » s'ouvrait sur le cas d'une équipe dont les workers CI sous Docker clonent le dépôt public MariaDB/server en HTTPS sans aucun identifiant. D'autres utilisateurs ont signalé le même symptôme sur des runners CI, sur des mises à jour Homebrew et sur des catalogues d'applications TrueNAS. Le 3 septembre, un Community Admin de GitHub a répondu que GitHub avait « expanded our traffic protections for unauthenticated requests » (élargi ses protections de trafic pour les requêtes non authentifiées) et que, lorsqu'elles s'appliquent, « we now return 401 signaling Git to retry with authentication if it has credentials available » (on renvoie désormais un 401 qui indique à Git de réessayer avec authentification s'il dispose d'identifiants). L'entrée du 19 octobre ne renvoie pas vers ce fil, mais elle décrit le même résultat : un clone anonyme refusé avec une demande d'authentification.

Lu vite, on dirait un non-événement : les dépôts publics restent publics, et tu peux attendre puis réessayer. Lu par quelqu'un qui livre du logiciel, ça dit quelque chose de plus net. Toute étape de build qui clone un dépôt public sans identifiants peut désormais échouer sans que rien n'ait changé de ton côté, par intermittence, et avec un message d'erreur qui peut pointer vers la mauvaise cause.

En septembre, j'ai écrit sur l'endroit où vit ton code quand GitHub tombe. Voici la version plus discrète de la même question : GitHub reste en ligne, et c'est ton build qui s'arrête.

Ce que l'annonce promet vraiment

Trois phrases portent la politique. GitHub « applies this protection as narrowly as possible using signals associated with anomalous traffic » (applique cette protection de la façon la plus ciblée possible, à partir de signaux associés à un trafic anormal). Il concède que « legitimate unauthenticated operations may occasionally be affected » (des opérations légitimes non authentifiées peuvent parfois être touchées). Et il ajoute : « This is not a general authentication requirement for public repositories » (ce n'est pas une obligation générale d'authentification pour les dépôts publics).

Rien n'est donc promis dans un sens ni dans l'autre. Ton clone anonyme n'est pas la cible, mais il n'est pas protégé non plus. Et « tous forfaits » veut dire que payer GitHub ne dispense pas un runner qui ne dit pas qui il est.

GitHub ne dit pas quel est ce trafic inhabituel. Le 8 mai 2025, quand il a mis à jour les limites de débit des requêtes faites sans authentification, « cloning repositories over HTTPS » (le clonage de dépôts en HTTPS) compris, il a cité « an increase in scraping activity targeting our API » (une hausse de l'activité de scraping visant notre API) et a encouragé tout le monde à s'authentifier. Dix-sept mois plus tard, le conseil est le même, et les clones anonymes portent désormais un avertissement explicite : ils peuvent simplement échouer.

Pourquoi ton portable sera le dernier à le savoir

Par défaut, Git n'envoie pas d'identifiants tant que le serveur ne les demande pas. La réponse de GitHub du 3 septembre le formule ainsi : « in most cases Git will attempt all requests without authentication first, and only authenticate if it receives a 401 response » (dans la plupart des cas, Git tente toutes les requêtes sans authentification d'abord, et ne s'authentifie que s'il reçoit une réponse 401). Le manuel gitcredentials dit que Git « may need to ask for a username and password in order to access a remote repository over HTTP » (peut avoir besoin de demander un nom d'utilisateur et un mot de passe pour accéder à un dépôt distant en HTTP), et il essaie les credential helpers configurés avant de se rabattre sur une invite dans le terminal.

Sur une machine de développeur, un helper détient souvent déjà un jeton GitHub. La documentation de GitHub recommande elle-même GitHub CLI ou Git Credential Manager pour mémoriser les identifiants HTTPS. Quand GitHub exige une authentification, le helper répond, le clone passe, et personne ne remarque rien.

Un runner CI, un build Docker ou un bac à sable d'agent tout neuf n'a généralement pas de helper et personne au clavier. Là où GIT_TERMINAL_PROMPT vaut false, Git « will not prompt on the terminal (e.g., when asking for HTTP authentication) » (n'ouvrira pas d'invite dans le terminal, par exemple pour demander une authentification HTTP), et l'étape échoue, tout simplement. La protection tombe là où tu surveilles le moins : le job planifié, le déploiement qui tourne la nuit.

Vient ensuite le débogage. La page du Cargo Book sur l'authentification Git dit : « 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 n'exige pas d'authentification pour les dépendances git publiques, donc si tu vois un échec d'authentification dans ce contexte, vérifie que l'URL est correcte). C'est toujours vrai pour Cargo. Ce n'est plus toute l'histoire pour GitHub. Une erreur d'authentification sur une dépendance publique peut désormais vouloir dire que l'URL est bonne et que la protection est active.

Où se cachent les clones anonymes

J'orchestre mon travail avec Claude Code, et la première chose que je confierais à un agent ici, c'est une recherche : toutes les URL github.com dans les fichiers qui construisent des choses. Voici la liste que je lui donnerais, avec ce que dit la documentation de chaque outil.

GitHub Actions. actions/checkout authentifie par défaut le checkout de ton propre dépôt : son entrée token vaut par défaut le github.token du job. La question, ce sont tous les autres clones du workflow : une étape run avec git clone, un script qui compile un outil depuis les sources, un gestionnaire de paquets qui résout une dépendance Git.

Dockerfiles. Une ligne RUN git clone vers une URL github.com est anonyme, sauf si tu as fait en sorte qu'elle ne le soit pas. La documentation de Docker est directe sur la correction tentante : « Build arguments and environment variables are inappropriate for passing secrets to your build, because they persist in the final image » (les arguments de build et les variables d'environnement ne conviennent pas pour passer des secrets à ton build, parce qu'ils persistent dans l'image finale). Utilise plutôt un secret mount. Pour un dépôt Git utilisé comme contexte de build ou récupéré avec ADD, BuildKit a deux secrets prédéfinis, GIT_AUTH_TOKEN et GIT_AUTH_HEADER.

Gestionnaires de paquets. npm accepte des URL git+https comme dépendances et, avec un commit, « clone exactly that commit » (clone exactement ce commit). Cargo résout lui-même les dépendances Git et « does not ask for passwords » (ne demande pas de mots de passe) : l'authentification HTTPS passe par un credential helper Git que tu configures au préalable. Terraform, pour les modules hébergés sur GitHub, « clones and uses the default branch referenced by HEAD » (clone et utilise la branche par défaut référencée par HEAD). Go est une exception partielle. GOPROXY vaut par défaut proxy.golang.org avec un repli en direct, donc les modules publics arrivent normalement par le proxy. Mais un module qui correspond à GOPRIVATE, ou un 404 ou 410 du proxy, envoie la commande go vers le système de gestion de versions lui-même.

Paquets Swift. Le guide d'Apple sur la construction de paquets Swift en intégration continue dit qu'un projet qui ne dépend que de paquets publics n'a besoin d'aucune configuration supplémentaire. Il dit aussi que xcodebuild « uses Xcode's built-in Git tooling » (utilise l'outillage Git intégré à Xcode), et n'utilise l'installation et la configuration Git de ton Mac que si tu passes -scmProvider system. Un credential helper dans ta configuration Git peut donc ne jamais l'atteindre. Pour les paquets qui exigent une authentification, Apple conseille des URL Git SSH avec des identifiants SSH, et SSH figure sur la liste des cas non concernés de GitHub.

Sous-modules, tâches cron et agents. Un fichier .gitmodules avec des URL HTTPS, un script nocturne qui clone un jeu de données, un script d'installation, un agent de code qui clone une bibliothèque dans un dossier temporaire pour lire son code source : tous sont des clients HTTPS anonymes, sauf si quelqu'un les a configurés autrement.

La correction, environnement par environnement

Les recommandations de GitHub sont courtes. Dans GitHub Actions, utilise le GITHUB_TOKEN intégré. Dans les autres systèmes CI, « prefer a GitHub App installation access token » (privilégie un jeton d'accès d'installation de GitHub App) ; un personal access token marche aussi. Les opérations qui ne peuvent pas s'authentifier doivent réessayer une fois la protection temporaire levée.

Sur une machine qui détient déjà des identifiants, le réglage Git http.proactiveAuth lui fait « attempt authentication without first making an unauthenticated attempt and receiving a 401 response » (tenter l'authentification sans d'abord faire une tentative non authentifiée et recevoir une réponse 401). La réponse de GitHub du 3 septembre le citait, avec SSH, comme les deux moyens de forcer l'authentification.

Trois détails changent la façon de câbler tout ça.

Durée de vie des jetons. Un jeton d'accès d'installation « will expire after 1 hour » (expire au bout d'1 heure). Le GITHUB_TOKEN vit jusqu'à la fin du job, jusqu'à 6 heures sur les runners hébergés par GitHub. Si un pipeline génère un seul jeton d'App au début et qu'une étape ultérieure clone à la minute 70, ce jeton est mort depuis 10 minutes. Génère un jeton par étape, ou laisse une bibliothèque s'en charger : GitHub précise que ses SDK Octokit régénèrent le jeton une fois expiré.

Portée. Pour la voie du personal access token, la documentation de GitHub dit que les jetons à granularité fine « always include read-only access to all public repositories on GitHub » (incluent toujours un accès en lecture seule à tous les dépôts publics de GitHub). Le jeton à granularité fine le plus étroit que tu puisses créer lit déjà le code public. Aucune raison de donner à un build un jeton classique aux larges portées pour ça.

Nouvelles tentatives. Réessayer une fois la protection levée, c'est le conseil de GitHub lui-même pour tout ce qui ne peut pas s'authentifier. Un nombre borné de tentatives avec backoff autour des étapes de clone est donc raisonnable. Garde-le borné, et journalise le message. Une erreur d'authentification sur un dépôt public est maintenant un signal qui mérite d'être compté, pas du bruit à avaler.

L'audit que je ferais

En tant que CTO qui livre aussi des apps iOS et un jeu de stratégie en indépendant, je traiterais ça comme un audit d'un après-midi, pas comme un projet.

D'abord, l'inventaire : les fichiers de workflow, les Dockerfiles, package.json, Cargo.toml, go.mod et tout réglage GOPRIVATE, .gitmodules, les sources de modules Terraform, et le fichier Package.resolved de chaque projet Xcode, où Xcode consigne chaque dépendance de paquet.

Ensuite, authentifier ce qui part en production : GITHUB_TOKEN dans Actions, un jeton d'App généré par étape ailleurs, un secret mount dans Docker, SSH ou -scmProvider system pour xcodebuild.

Troisièmement, réduire le nombre de clones. Mettre les dépendances en cache entre les exécutions, là où l'outillage le permet, c'est moins d'allers-retours vers GitHub, et un clone que tu ne fais pas ne peut pas être refusé.

Quatrièmement, rendre l'échec lisible. Ajoute une ligne au runbook : une erreur d'authentification sur un dépôt GitHub public veut dire qu'il faut vérifier d'abord les identifiants et le changelog de GitHub, puis l'URL.

Les dépôts publics restent publics. Ce qui a changé le 19 octobre, c'est que l'accès anonyme est désormais explicitement au mieux de l'effort, et qu'un build qui ne sait pas dire qui il est l'apprendra le jour où GitHub est le plus chargé, pas le tien.

Sources

Un projet du même genre ?

Je conçois et déploie des produits comme celui-ci. Parlons-en.

Discutons