Ransomware de gitlab sur les dépôts volumineux

Bonjour,

La suite logicielle Regulatory Sequence Analysis Tools (RSAT) est distribuée en passant par une série de dépôts de l'organisation github rsa-tools

Le dépôt motif_databases contient des collections de motif de régulation importées de différentes sources (Jaspar, RegulonDB, FootprintDB ...) et reformatées en fichiers "plats" (fichiers textes avec syntaxe EMBL).

Ce dépôt a grandi au fil des ans, et les données pèsent actuellement ~650Mo, auxquelles il faut ajouter ~600Mo pour le dossier .git qui contient l'historique des modifications. Le dépôt inclut certains fichiers volumineux, et nous sommes donc passés il y a ~3 ans à git lfs.

Récemment, nous avons réalisé que chacun des fichiers du dépôt gitlab avait été remplacé par des fichiers de 130 octets de 3 lignes chacun :

  • version de git lfs
  • clé sha du fiochier initial
  • taille du fichier initial

Quand on essaie de cloner le dépôt ou de faire une mise à jour (git pull), on a un message d'erreur

git clone https://github.com/rsa-tools/motif_databases.git
Cloning into 'motif_databases'...
remote: Enumerating objects: 1272, done.
remote: Counting objects: 100% (1192/1192), done.
remote: Compressing objects: 100% (823/823), done.
remote: Total 1272 (delta 399), reused 1142 (delta 357), pack-reused 80
Receiving objects: 100% (1272/1272), 8.79 MiB | 5.46 MiB/s, done.
Resolving deltas: 100% (460/460), done.
Downloading ATtRACT/ATtRACT_2017_12.tf (790 KB)
Error downloading object: ATtRACT/ATtRACT_2017_12.tf (e1557a6): Smudge error: Error downloading ATtRACT/ATtRACT_2017_12.tf (e1557a634e2d154e21337be184f13bae5b398684c537a31372492cee9624cd49): batch response: This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs to restore access.

Errors logged to /Users/jvanheld/no_backup/rsat_github/rsa-tools/test/motif_databases/.git/lfs/logs/20230208T042546.0912.log
Use `git lfs logs last` to view the log.
error: external filter 'git lfs smudge %f' failed 2
error: external filter 'git lfs smudge %f' failed
fatal: ATtRACT/ATtRACT_2017_12.tf: smudge filter lfs failed
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry with 'git restore --source=HEAD :/'

Voir l'issue sur le dépôt gitlab pour les détails: File content disappeared · Issue #1 · rsa-tools/motif_databases · GitHub

Apparemment pour récupérer les données nous devons payer gitlab (ça flaire un peu le kidnapping de données).

J'ai deux questions

  1. Y a-t-il moyen de récupérer les données sur gitlab ? J'ai trouvé une discussion à ce propos, mais la solution proposée demande d'entrer dans la "Danger zone" de github, ça fait un peu peur;

  2. Y a-t-il des solutions alternatives qui permettraient de gérer des dépôts volumineux à des fins académiques ?

@hmenager , est-ce que vous traitez des dépôts de gros volumes dans le cadre de l'écosystème Tools d'ELIXIR ?

@julien , y a-t-il des solutions dataverse ou entrepôts institutionnels de données ?

Ou alors zenodo ?

@julien me signale cette liste française des forges :

Une autre possibilité serait Renater SourceSup (c'est d'ailleurs curieux qu'il n'apparaisse pas dans la liste code.gouve.fr)

@jvanhelden nous n'avons pas (encore) ce problème avec le dépôt du Tools Ecosystem, mais il est probable qu'à terme nous aurons à le traiter. Pour ton problème particulier, je me tournerais vers un hébergeur non commercial, il doit y avoir plusieurs options institutionnelles. A pasteur on a une instance gitlab locale, ce qui ne nous rend pas otages dans ces situations.

Tu peux aussi choisir de changer de solution, et de stocker les données non pas dans un dépôt git, mais chaque release dans un dépôt séparé sur Zenodo (gratuit et ouvert "pour toujours" en principe).
Mais ça dépend vraiment de l'utilisation de RSAT, et du cycle de maintenance/release, que je ne connais pas :wink:

Merci @hmenager

Après discussion avec @julien et @morganeTC , nous pourrions effectivement nous orienter vers des dépôts zenodo plutôt que l'utilisation de github.

Initialement je tenais à utiliser github pour disposer de l'historique des modifications, un peu comme dans l'écosystème ELIXIR Tools, mais je réalise que la granularité est très différente : dans l'écosystème Tools, les données stockées en format JSON (je crois) sont réellement celles qui sont édités au jour le jour, et on a la possibilité de modifier chaque ligne (champ) de chaque entrée, et de conserver une trace de la modification précise (qui l'a faite quand, ce qu'il y avait avant et après la modif), avec de plus un commentaire qui explique le pourquoi. C'est une solution géniale pour assurer la traçabilité de tout un projet de curation de base de données.

Par contre, les fichiers du dépôt RSAT motif_databases sont générés en exportant des collections de motifs de différentes sources (JASPAR, RegulonDB, ...) et on change donc de version pour une collection entière en un seul coup. Donc on peut avoir des versions sur zenodo qui correspondent aux nouvelles versions des bases de données-sources, et revenir à la version qu'on veut du dépôt RSAT.

Un autre intérêt de Zenodo est qu'on obtiendra un DOI générique pour motif_databases, plus un DOI spécifique de chaque release.

Mon collègue mexicain Alfredo, admin sys du centre où je donne cours, a constaté qu'il ne pouvait plus suivre le processus l'installation RSAT puisque les motifs ne téléchargent pas correctement.

De fait, nos données ont disparu de gitlab, et nous devons les payer pour retrouver les contenus du dépôt.

Il a qualifié cette pratique de gitlab de "ransomware", je pense que le procédé peut s'y apparenter, non ?

1 « J'aime »

Oui, je pense que dans ce cas là un Zenodo ou équivalent est bien adapté, et les dois "générique" et "release" ça donne un bon niveau de traçabilité pour des analyses se basant sur une DB...

En fait, ransomware ou pas, c'est légal dans le sens ou il y a des quotas documentés par gitlab.com. A mon avis, le mieux est de payer, pour récupérer les données ASAP et mettre sur pied une autre solution...

Même s'il y a des quotas documentés, une pratique acceptable serait d'empêcher de dépasser les quotas mais de laisser les données dans l'état où elles étaient juste avant d'atteindre ces quotas. Le fait que tous les fichiers aient été remplacés par un alias indiquant la taille des données me semble quand même relever de la prestidigitation.

1 « J'aime »

Par ailleurs je ne sais même pas comment on est censés faire pour payer, ni quel montant. Je vais quand même investiguer car en fonction du montant ça peut valoir la peine de payer la rançon pour récupérer le résultat du travail plutôt que de devoir le reconstituer.