ZCode de Zhipu accusé d'envoyer tout l'historique Git

ZCode, l'outil de programmation IA de Zhipu, a été dénoncé le 18 septembre par un développeur pour avoir discrètement compressé et envoyé en arrière-plan l'ensemble de l'espace de travail de l'utilisateur, y compris l'historique Git complet, le cache de fichiers volumineux LFS et la configuration locale de la machine. Le soir même, ZCode a publié des excuses, reconnaissant que ces envois avaient bien eu lieu, en attribuant le problème à une fonction d'« indexation du dépôt » et en affirmant qu'il avait depuis été corrigé.

Ce que les développeurs ont découvert

C'est le blogueur tech Ferstar qui a le premier révélé les détails de l'affaire. Sur son blog, il a démonté le mécanisme d'instantanés locaux de ZCode : après connexion, un processus en arrière-plan lancé en même temps que le programme compresse l'ensemble de l'espace de travail, chiffre le contenu des fichiers en AES-256-CTR, puis enveloppe la clé avec une clé publique RSA fournie par le serveur, avant d'envoyer le tout directement vers Alibaba Cloud OSS via un envoi de formulaire. La clé privée nécessaire au déchiffrement ne se trouve que dans le cloud : l'utilisateur ne peut pas ouvrir lui-même ses fichiers .enc.

L'exemple qu'il a fourni est précis : l'espace de travail non compressé pesait 345 Mo, 313 Mo une fois chiffré, avec 42411 fichiers dans la liste. L'essentiel provient du répertoire .git, qui représente au total 86,6 %, dont 196,1 Mo de cache LFS et 102,2 Mo d'objets Git ; le code source et la configuration ne pèsent qu'environ 46 Mo. Deux moments déclenchent l'opération : avant chaque envoi d'un prompt, et après la fin d'une tâche lors de la mise à jour du Repo Wiki ; sur une seule session, jusqu'à 62 instantanés ont été enregistrés.

Le même jour, un développeur a ouvert un ticket sur le dépôt public de retours de Zhipu, avec un titre qui enchaîne trois « pourquoi » : pourquoi envoyer silencieusement tout l'historique Git, pourquoi le chiffrer au point que l'utilisateur lui-même ne puisse pas l'ouvrir, et pourquoi ne pas même proposer d'interrupteur pour désactiver la fonction. Le ticket mentionne aussi que l'instantané, après un échec d'envoi local, retentait l'opération à répétition, avec 564 tentatives enregistrées. Un autre développeur a reproduit le comportement sur sa propre machine : un instantané de projet de 748 Mio, dont 98,91 % occupés par .git, sous la version ZCode 3.12.3.

Un interrupteur sans effet est le point le plus sensible de cette controverse. Selon Ferstar, les interrupteurs « optimiser l'expérience » et « indexation des instantanés du dépôt » de l'interface ne contrôlent en réalité que l'usage ou non des données côté serveur pour entraîner les modèles : la compression et l'envoi locaux se poursuivent normalement, quel que soit leur réglage. L'historique Git peut contenir des clés supprimées depuis longtemps, d'anciennes configurations abandonnées, des enregistrements de branches jamais poussées et des noms de domaine internes — autant d'éléments invisibles dans le code actuel, mais toujours présents dans le .git.

Ce que dit Zhipu

Dans ses excuses, ZCode attribue ces envois à la fonction d'« indexation du dépôt » : la génération d'une page du Repo Wiki peut déclencher un envoi de données du dépôt, lesquelles sont détruites dans le cloud immédiatement après la génération du Wiki, sans être conservées. Cette fonction était activée par défaut au lancement, ce qui a affecté certains utilisateurs ; elle a depuis été corrigée.

Trois mesures correctives sont annoncées : ouvrir prochainement le code source du dépôt ZCode, inviter une évaluation externe et rendre publique l'avancée de cet examen ; et, le jour même, accorder à tous les utilisateurs une réinitialisation supplémentaire du quota hebdomadaire. Plusieurs points restent non précisés dans le communiqué et ne peuvent pour l'instant pas être vérifiés : combien d'utilisateurs et de dépôts ont été touchés, combien de temps les données sont réellement restées sur OSS, si la « destruction » a fait l'objet d'un audit indépendant, et quel est le numéro de version après correction. Le calendrier de l'ouverture du code reste lui aussi vague, limité à « prochainement ».

Le même jour, Zhipu a également présenté un nouveau modèle, GLM-5.3-FlashX, mis en avant pour sa vitesse de génération de 200 tokens par seconde. Un développeur a rapproché les deux événements sur son blog, ironisant sur le fait que tout le monde se demande où est passé le code pendant que Zhipu s'affaire à lancer un nouveau modèle.

Ce que peuvent faire les développeurs en Chine dès maintenant

Une bonne partie des utilisateurs de ZCode testent l'outil sur des projets d'entreprise, et l'historique Git est souvent plus sensible pour une entreprise que le code actuel lui-même. Pour ceux qui utilisent encore une ancienne version, trois étapes sont recommandées : d'abord mettre à jour vers la version corrigée ; ensuite vérifier si le dossier local ~/.zcode/v2/checkpoints contient encore des instantanés en attente d'envoi ; enfin faire tourner l'ensemble des clés et jetons ayant figuré dans l'historique, sans compter sur le fait que la prétendue « destruction » couvre ce qui a déjà été envoyé.

Ferstar propose une méthode encore plus radicale : sous macOS, utiliser chflags uchg, sous Linux chattr +i, pour verrouiller le dossier des instantanés en lecture seule et bloquer leur génération dès le niveau du système de fichiers. Le prix à payer : les fonctions de retour en arrière sur les points de contrôle et de chronologie cessent alors de fonctionner.

Ces agents de programmation ont besoin de lire le dépôt pour fonctionner, et l'indexation locale en elle-même n'a rien d'inhabituel. Le désaccord porte sur les limites : lire en local et envoyer vers le cloud sont deux choses différentes, tout comme envoyer le code actuel et envoyer l'historique complet en sont deux autres. Si l'ouverture du code promise par Zhipu se concrétise, le public pourra au moins vérifier par lui-même quels chemins le module d'instantanés emballait réellement, et où les interrupteurs sont véritablement raccordés.

Sources : analyse de rétro-ingénierie du blog tech Ferstar sur le mécanisme d'instantanés et la composition des fichiers, ticket public sur zai-org/feedback, Ifeng Tech, CocoLoop, Elliot's Harness Lab ; communiqué d'excuses de ZCode pour la vérification de l'attribution, de l'état de la correction et des mesures de compensation.