Nettoyage des dépôts : supprimer les objets inaccessibles

Dans Git, supprimer une branche, un tag ou une pull request ne supprime pas ses commits. Les commits deviennent inaccessibles : plus aucune référence ne pointe vers eux, mais les objets restent sur le serveur et peuvent encore être récupérés ou consultés par quiconque connaît leur SHA, jusqu’à ce que le ramasse-miettes de Git les supprime à un moment ultérieur.

Supprimer les objets inaccessibles les supprime dès maintenant. Utilisez cette fonction lorsqu’un commit n’aurait jamais dû être poussé, par exemple parce qu’il contenait un secret, des données personnelles d’un client ou un fichier que vous n’êtes pas autorisé à conserver. Les propriétaires d’organisation la lancent eux-mêmes depuis la console, et chaque exécution se termine par une confirmation écrite que vous pouvez conserver.

Avant de commencer : renouvelez le secret

Si le commit contenait un secret (mot de passe, clé d’API, jeton ou clé privée), renouvelez ou révoquez d’abord le secret. Supprimer le commit ne rend pas le secret invalide. Toute personne ayant cloné ou récupéré le dépôt pendant que le commit s’y trouvait en possède une copie, tout comme les forks, les miroirs et les journaux CI (voir Ce qui n’est pas supprimé). La suppression limite qui peut obtenir le commit à partir de maintenant ; elle ne peut pas rappeler les copies qui existent déjà.

La protection des push bloque la plupart des secrets avant même qu’ils n’atteignent le serveur.

Qui peut la lancer

Les propriétaires de l’organisation. La page se trouve dans l’administration de l’organisation, à l’adresse :

frem.sh/<your-org>/_admin/repos-overview/<repo>/housekeeping

Vous avez besoin d’un accès propriétaire à l’administration de l’organisation, via votre connexion habituelle, qui exige l’authentification multifacteur. Il n’y a pas d’étape de confirmation supplémentaire. Pour lancer une exécution, vous saisissez le nom complet du dépôt, afin qu’une exécution ne puisse pas être lancée par erreur sur le mauvais dépôt.

Pas à pas

Renouvelez tout secret divulgué. Voir ci-dessus.
Supprimez ce qui contient le commit. Supprimez chaque branche, tag ou pull request qui contient encore le commit, ou réécrivez l’historique de la branche pour que le commit n’en fasse plus partie, puis faites un force-push. Un commit encore atteint par une référence n’est pas inaccessible, et la suppression ne l’enlèvera pas.
Aperçu. Ouvrez la page de nettoyage et lancez l’aperçu. Vous pouvez coller les SHA des commits à faire disparaître (jusqu’à 20) ; l’aperçu indique pour chacun s’il sera supprimé ou ce qui le retient encore. Voir Lire l’aperçu.
Lancez l’exécution. Choisissez d’inclure ou non les objets LFS orphelins, saisissez le nom du dépôt pour confirmer et lancez l’exécution. La page affiche sa progression.
Téléchargez la confirmation. Une fois l’exécution terminée, téléchargez la confirmation écrite au format PDF ou JSON et conservez-la avec votre dossier d’incident. Voir La confirmation écrite.

Lire l’aperçu

L’aperçu ne modifie rien. Il liste :

Pour chaque SHA collé : s’il existe dans le dépôt et, si une référence le retient encore, laquelle (une branche, un tag, une pull request ou une autre référence). Supprimez cette référence et relancez l’aperçu. Un SHA retenu uniquement par une entrée du reflog est supprimé par l’exécution.
Les commits inaccessibles qui seront supprimés, avec l’objet de leur message de commit.
Les commits inaccessibles en période de grâce : trop récents pour être supprimés maintenant. Voir La période de grâce de 30 minutes.
Les forks du dépôt, par nom. Un fork est une copie distincte et n’est pas modifié. Voir Forks.
Les autres éléments que l’exécution supprimera : le nombre de téléchargements d’archives en cache, d’entrées de restauration de branche et, si vous les incluez, d’objets LFS orphelins.
Pourquoi l’exécution ne peut pas démarrer, le cas échéant. Par exemple : une exécution est déjà en cours pour ce dépôt, ou le dépôt dépasse la limite de taille en libre-service.

La période de grâce de 30 minutes

Les objets créés ou actualisés au cours des 30 dernières minutes sont toujours conservés. Cela protège les push en cours pendant l’exécution : un push écrit ses objets avant de mettre à jour la branche et, pendant ce bref instant, les nouveaux objets semblent inaccessibles. La période de grâce est fixe et ne peut pas être raccourcie.

Si un commit que vous voulez supprimer apparaît en période de grâce, attendez que 30 minutes se soient écoulées depuis la suppression de ce qui le retenait, relancez l’aperçu, puis lancez l’exécution.

Ce qui est supprimé

Les objets Git inaccessibles : les commits, ainsi que les arbres et contenus de fichiers utilisés uniquement par ces commits, avec les entrées du reflog qui les retenaient encore.
Le commit dans le commit-graph, de sorte qu’il n’apparaît plus dans les vues d’historique, dans la recherche ni par son SHA.
Les téléchargements d’archives en cache (zip et tar) de ces commits.
Les copies en cache des packs de récupération du dépôt, que le serveur conserve pour répondre plus vite aux clonages et récupérations répétés.
Les entrées de restauration des branches supprimées qui pointaient vers ces commits, de sorte que la branche ne peut plus être restaurée depuis la liste des branches supprimées du dépôt.
En option, les objets LFS orphelins : les fichiers LFS qu’aucun commit du dépôt ne référence plus et qui ont été téléversés il y a plus de 24 heures. Vous faites ce choix au lancement de l’exécution.

Une fois l’exécution terminée, une URL qui affichait le commit renvoie introuvable, et un git fetch du SHA échoue.

Ce qui n’est pas supprimé

L’exécution supprime des objets de ce dépôt sur les serveurs de fremforge. Elle n’atteint pas les copies conservées ailleurs et ne modifie pas les enregistrements qui mentionnent le commit :

Les forks. Chaque fork est une copie distincte. Voir Forks.
Les clones et exports existants. Chaque clone, récupération et export de données effectué pendant que le commit était présent le contient encore. Demandez aux personnes concernées de supprimer leur copie ou de cloner à nouveau.
Les miroirs. Un miroir de ce dépôt, sur fremforge ou ailleurs, conserve sa propre copie.
Le wiki du dépôt. Le wiki est un dépôt Git distinct et n’est pas nettoyé.
Les journaux et artefacts Actions. Un workflow exécuté sur le commit peut avoir affiché ou stocké son contenu. Supprimez-les séparément.
Les contenus des livraisons de webhooks, qui incluent les SHA des commits, leurs messages et les informations sur les auteurs.
Le fil d’activité, les statuts de commit et les commentaires de la chronologie des pull requests qui mentionnent le commit.

Si l’un de ces éléments contient quelque chose que vous devez faire supprimer et que vous ne pouvez pas supprimer vous-même, contactez support@frem.sh.

Forks

Un fork est une copie complète et distincte du dépôt, contrôlée par son propriétaire. L’aperçu liste les forks par nom, pour que vous sachiez où d’autre le commit peut se trouver. Pour supprimer le commit d’un fork, le propriétaire du fork supprime la branche, le tag ou la pull request qui le contient et lance la suppression sur le fork, ou bien supprime le fork.

Sauvegardes

La suppression retire les objets du dépôt en service. Elle ne modifie pas les sauvegardes : les sauvegardes de fremforge ne sont pas modifiées pour retirer les données d’un client particulier, et elles ne servent qu’à restaurer la plateforme, jamais à fournir les données à qui que ce soit. Un objet supprimé reste donc dans les sauvegardes chiffrées jusqu’à leur expiration selon leur durée de conservation normale :

Contenu des dépôts (les objets Git) : jusqu’à 30 jours.
Copies dans le stockage objet (téléchargements d’archives en cache et objets LFS) : jusqu’à 13 mois, dans le stockage de reprise après sinistre.

Les enregistrements de la base de données, comme les entrées de restauration de branche, suivent les sauvegardes de la base de données. L’accord de traitement des données, §9 et annexe A.9, fait foi pour chaque niveau de sauvegarde et sa durée de conservation ; en cas de divergence entre cette page et le DPA en vigueur, le DPA prévaut.

La confirmation écrite

Chaque exécution terminée produit une confirmation téléchargeable au format PDF ou JSON. Elle consigne le dépôt, qui a lancé l’exécution et quand, le nombre d’objets avant et après l’exécution, le nombre de téléchargements d’archives, d’entrées de restauration de branche et d’objets LFS supprimés et, pour chaque SHA collé, s’il est désormais absent du dépôt ou ce qui le retient encore.

Conservez-la avec votre dossier d’incident. C’est votre preuve de la date à laquelle les données ont été retirées du service en production ; la section Sauvegardes ci-dessus indique combien de temps des copies subsistent ensuite.

Limites

Une exécution par dépôt et par heure, et 10 exécutions par organisation et par jour. Une demande refusée n’est pas comptée.
Limite de taille en libre-service : 5 Gio. Pour un dépôt plus volumineux, contactez support@frem.sh.
Jusqu’à 20 SHA peuvent être collés dans un même aperçu.

API

L’aperçu et les résultats d’une exécution peuvent être lus via l’API :

GET /_app/api/v1/orgs/{slug}/repos/{repo}/housekeeping/prune/preview?sha=<sha>[,<sha>...]

Le statut d’une exécution et sa confirmation écrite ont leurs propres points de terminaison GET, répertoriés dans la spécification OpenAPI.

Une exécution ne peut être lancée que depuis la console. L’API ne permet pas d’en lancer une.