Détection initiale

Le répertoire ~/.zcode occupait plus de 700 Mo. L’analyse du sous‑dossier v2/checkpoints a révélé un fichier .enc de 313 070 842 octets, accompagné d’un méta‑dossier indiquant workspaceSizeBytes = 345 549 173 octets et failureCount = 564. Le client ZCode avait donc empaqueté 345 Mo de données, puis les avait chiffrées en un fichier de 313 Mo en attente de nouvelle tentative d’envoi.

{
  "workspacePath": "/Users/ferstar/myprojects/",
  "lastCompressedSize": {
    "encryptedSizeBytes": 313070842,
    "workspaceSizeBytes": 345549173
  },
  "kind": "baseline",
  "failureCount": 564
}

Mécanisme d’enveloppe cryptographique

Le processus utilise une enveloppe standard : un clé symétrique AES‑256‑CTR générée aléatoirement chiffre le tar.gz du workspace, puis cette clé est enveloppée avec RSA‑OAEP‑SHA256. La clé publique RSA est fournie dynamiquement par le serveur zcode.z.ai lors de la requête d’obtention d’identifiants OSS. Aucun composant privé n’est jamais stocké localement, ce qui empêche le client ou l’utilisateur de déchiffrer le fichier .enc. Le flux d’échange se résume ainsi :

POST /api/v1/snapshot/upload-credential →
  { snapshot_id, publicKey, max_size, OSS form credentials }
→ tar.gz → AES‑256‑CTR → RSA‑OAEP wrap → POST to Aliyun OSS

Après le POST direct vers Aliyun OSS, le service OSS renvoie un callback au backend Zhipu, confirmant la réception du snapshot.

Contenu du snapshot et portée des données

Le manifeste généré localement recense 42 411 fichiers. La répartition montre que 86,6 % du volume (≈ 272 Mo) provient du répertoire .git :

.git/lfs/ = 196,1 Mo (56,8 %) – cache LFS contenant tous les actifs binaires téléchargés.
.git/objects/ = 102,2 Mo (29,6 %) – historique complet des commits, arbres et blobs.
.git/logs/ = 0,6 Mo (0,2 %) – reflogs et traces de branches locales.
Source code & docs ≈ 46,2 Mo (13,4 %).

En plus du code actuel, le snapshot transmet l’intégralité de l’historique du dépôt : clés API, configurations sensibles, noms de branches non poussées et chemins d’accès internes, même si ceux‑ci ont été supprimés dans les versions récentes. Un second manifeste (repo_snapshot_extra_manifest) ajoute les fichiers de configuration globale de ZCode, tels que settings.behavior.json, consolidés à travers tous les espaces de travail.

Implications sécuritaires et contre‑mesures

Le modèle d’enveloppe où la clé privée réside exclusivement sur le serveur constitue une exfiltration de données à l’insu de l’utilisateur. Aucun mécanisme de désactivation côté UI n’empêche la création du snapshot ; les bascules « UI Toggles » ne stoppent pas le processus. La politique de confidentialité de Zhipu mentionne la collecte de données, mais ne détaille pas la portée exacte du dépôt Git. Pour limiter le risque, il suffit de verrouiller le répertoire ~/.zcode (chmod 700) ou de supprimer le dossier pending avant chaque session. Une solution plus robuste serait d’intercepter les requêtes DNS/HTTPS vers zcode.z.ai ou les points de terminaison OSS, ou de désinstaller l’application si la synchronisation n’est pas requise.