Votre automatisation reçoit un secret, le conserve puis l’envoie à GitHub pour lire un dépôt. Elle fonctionnait hier, mais une valeur plus longue est maintenant tronquée au passage. Les droits peuvent être corrects et la requête échouer quand même. La fin du déploiement des nouveaux jetons d’installation GitHub Apps, annoncée le 2 octobre 2026, invite à suivre ce secret sur tout son parcours.
Identifier le secret concerné avant de chercher partout
Une GitHub App est une application à laquelle vous accordez des permissions sur un ensemble de dépôts. Son installation possède un contexte d’accès propre. Le jeton d’installation sert aux appels effectués dans ce contexte ; il se distingue du secret d’un utilisateur et de la clé privée de l’application.
La documentation GitHub sépare l’authentification de l’application et la génération d’un jeton pour son installation. Avant votre audit, retrouvez donc le composant qui obtient effectivement ce dernier. Une configuration portant simplement le nom « GitHub token » ne suffit pas à identifier sa famille. Documentation des jetons d’installation.
Le 2 octobre, GitHub a annoncé la fin du déploiement commencé le 27 avril : les nouveaux jetons d’installation utilisent par défaut un format stateless. Ils gardent le préfixe ghs_ et font environ 520 caractères, contre 40 auparavant. Les permissions, le périmètre des dépôts, l’expiration d’une heure et l’endpoint restent inchangés. L’en-tête temporaire X-GitHub-Stateless-S2S-Token sera déprécié le 30 novembre 2026. Annonce de fin du déploiement.
Stateless décrit ici le nouveau format du fournisseur. Vous n’avez pas besoin d’en comprendre l’intérieur pour transmettre le secret correctement. La valeur doit rester opaque : votre application la transporte, mais ne construit pas ses règles d’accès en décodant ce qu’elle pense y reconnaître. L’ordre de grandeur publié n’est pas une nouvelle longueur exacte à imposer dans un formulaire.
Dessiner le trajet réel, du fournisseur à la requête
Notre exemple fictif est un outil interne qui consulte l’état de dépôts. Un service obtient le jeton, un stockage le conserve brièvement, un processus de travail le charge et un client HTTP l’envoie. Une interface d’administration et une collecte d’erreurs peuvent également le manipuler. Chacun de ces passages peut conserver une hypothèse ancienne.
Commencez par les noms de variables, les propriétés et les paramètres qui transportent la valeur. Recherchez ensuite les contraintes sur leur longueur et les transformations appliquées : découpe de chaîne, suppression de caractères, encodage ou copie vers un champ différent. Une contrainte peut venir du code, d’un schéma de base ou d’un composant externe.
Une colonne trop courte peut provoquer une erreur explicite, mais certains chemins peuvent tronquer silencieusement. Un champ d’interface peut refuser la saisie avant même l’appel réseau. Un masque de journal peut reconnaître seulement l’ancien secret et laisser une partie du nouveau apparaître. Ne réduisez donc pas l’audit à la ligne qui construit l’en-tête d’authentification.
| Composant à examiner | Question utile | Preuve attendue |
|---|---|---|
| Service d’obtention | La réponse est-elle copiée entièrement ? | Égalité sur une valeur factice |
| Stockage | La capacité et les contrôles conviennent-ils ? | Lecture après écriture sans perte |
| Chargement | La valeur est-elle modifiée en transit ? | Comparaison avant et après passage |
| Client réseau | L’en-tête contient-il la bonne valeur ? | Capture dans un transport simulé |
| Journaux et erreurs | Une partie du secret apparaît-elle ? | Recherche négative dans les sorties |
Cette grille est une proposition Partitech. Ajoutez un responsable par ligne, car un test concluant sur le code applicatif ne valide pas nécessairement le proxy ou l’outil de stockage géré par une autre équipe.
Tester une propriété, plutôt qu’un exemple de format
La propriété recherchée est simple : la valeur qui entre doit être identique à celle qui atteint le transport prévu. Une chaîne de test n’a pas besoin de ressembler à un vrai secret. Choisissez un préfixe explicite, par exemple FAUX_SECRET_TEST_, et des tailles variées, dont une dépassant l’ordre de grandeur annoncé. Ces valeurs ne doivent jamais permettre une authentification.
Vous pouvez inclure une chaîne courte, une plus longue et une valeur contenant les caractères que votre composant accepte selon son contrat. Les tailles sont des paramètres de test locaux, pas une estimation des futurs jetons GitHub. Conservez des limites raisonnables contre les entrées abusives ; évitez seulement une contrainte issue d’un format ancien sans justification technique.
Pseudocode du contrôle proposé, non exécuté ici :
pour chaque valeur factice du jeu de test
écrire dans le stockage de test
relire par le chemin de chargement réel
envoyer au client HTTP simulé
vérifier l'égalité avec la valeur de départ
provoquer une erreur de transport simulée
vérifier l'absence de la valeur dans toutes les sorties
Ajoutez un cas qui dépasse volontairement la capacité définie de votre composant. L’erreur doit être claire et ne doit ni tronquer puis continuer, ni afficher le contenu reçu. Ce test vérifie la qualité du refus ; il ne vous demande pas d’accepter des chaînes de taille infinie.
Pour le masquage, recherchez le secret complet mais aussi les segments reconnaissables susceptibles d’être exposés. Une règle qui cache le début et affiche la fin reste une fuite. Inspectez la réponse d’erreur, la console, les journaux structurés et les éventuelles pièces jointes de diagnostic. Faites cela avec des valeurs factices, afin que l’investigation ne devienne pas elle-même une exposition.
Corriger la frontière fautive sans élargir les droits
Si le stockage tronque, corrigez sa capacité selon les conventions de votre application. Si une expression régulière exige exactement l’ancienne longueur, remplacez cette hypothèse par un contrôle cohérent avec l’usage réel. Si un outil de diagnostic reconnaît seulement un motif ancien, préférez retirer la propriété secrète de la collecte plutôt qu’essayer de deviner toutes ses formes futures.
Une erreur de format ne justifie pas d’ajouter des permissions à l’application. Dans notre outil fictif, la lecture de dépôts reste une lecture de dépôts, même après correction du stockage. Revérifiez séparément les permissions réellement nécessaires ; ne confondez pas un refus local avec un refus d’autorisation distant.
Lorsqu’une modification de schéma est nécessaire, préparez-la avec le mécanisme de migration existant. Vérifiez l’ordre de déploiement entre la base et le code, les anciennes instances encore actives et la manière dont elles lisent la nouvelle donnée. Une écriture correctement élargie peut toujours être mal relue par une instance qui conserve l’ancienne validation.
Évitez de conserver davantage de secrets pour faciliter la comparaison. Votre preuve peut consigner « égalité vérifiée » et le nom du scénario de test, sans garder la valeur. Un stockage temporaire doit conserver son expiration et ses contrôles d’accès. Le travail porte sur le transport fidèle, pas sur la multiplication des copies.
Préparer le 30 novembre et la surveillance
L’annonce du 15 mai présentait un en-tête temporaire permettant de choisir le comportement de génération pendant la transition. Elle reste un contexte historique, distinct de la fin du déploiement annoncée en octobre. Annonce de l’en-tête de transition.
Dressez la liste des composants qui utilisent encore cet en-tête. Affectez la suppression à une version de livraison, avec un responsable et un test de compatibilité. L’échéance du 30 novembre annoncée par GitHub doit figurer dans votre suivi : une option de transition n’est pas un mécanisme permanent de retour arrière.
Après les tests locaux, une qualification autorisée sur un environnement GitHub de test peut vérifier l’obtention et l’usage du jeton, avec les droits minimaux nécessaires. Elle doit garder les secrets hors des captures. Distinguez dans votre bilan ce que le transport simulé a prouvé de ce que cet appel réel a confirmé.
Pour la surveillance, suivez les erreurs par composant et par étape : obtention, stockage, chargement, requête. Comparez les tendances avant et après livraison, sans associer un incident à un format uniquement parce qu’il apparaît à la même date. Une réponse de refus peut avoir plusieurs causes ; votre inventaire permet de tester la bonne hypothèse.
Choisir un retour arrière qui reste compatible
Un retour à une ancienne version qui tronque les nouveaux jetons réintroduirait le problème. Préparez donc une version de secours qui conserve la correction de compatibilité, ou un plan de retrait du changement fonctionnel qui ne restaure pas l’ancienne contrainte. Documentez ce point avant de lancer la livraison.
La tâche peut être considérée comme qualifiée lorsque les passages réels ont un responsable, les essais factices préservent intégralement la valeur, les erreurs restent sans secret et le retrait de l’en-tête temporaire est planifié. Aucun test exécuté sur une intégration Partitech n’est revendiqué dans cet article.
Pour votre prochaine revue technique, choisissez un seul parcours de jeton d’installation et appliquez la grille de bout en bout. Vous obtiendrez un périmètre de correction concret, au lieu d’une réécriture générale de l’authentification. La robustesse utile tient à la fidélité du transport et à la discrétion des diagnostics, indépendamment de la forme actuelle du secret.
Sources et date de vérification
Sources ouvertes le 6 octobre 2026 : fin du déploiement, en-tête temporaire de mai et documentation GitHub Apps. Les tests décrits constituent un protocole proposé, sans secret fonctionnel ni résultat fabriqué.