Nouveautés de zn-gate 1.12.0 : zn-gate reach, versions signées et un correctif de sécurité

Q: Quelles sont les nouveautés de zn-gate 1.12.0 ?

zn-gate reach, un rapport en lecture seule de ce que les agents de programmation de votre machine peuvent atteindre, aussi en SARIF pour le code scanning. Les versions sont construites et signées dans un workflow séparé (SLSA Build Level 3) et les tags de version sont signés avec gitsign. zn audit masque davantage de valeurs secrètes, les hooks des agents refusent de nouveau rapidement les longs patchs de shell et un correctif de sécurité referme GHSA-rccq-h3xc-j9qj.

Q: Comment mettre à jour vers zn-gate 1.12.0 ?

Exécutez npm install -g zn-gate@1.12.0 pour le paquet Node et pip install -U zn-gate pour le paquet Python. Pour réinstaller les hooks des agents, exécutez npx -y zn-gate@1.12.0 init. Si vous utilisez le plugin Claude Code, mettez-le à jour depuis le répertoire des plugins dès que la 1.12.0 y figure.

zn-gate 1.12.0 ajoute zn-gate reach, un rapport en lecture seule de ce que les agents de programmation de votre machine peuvent atteindre, avec la commande qui corrige chaque constat. Il déplace aussi la construction et la signature des versions vers un workflow séparé, fait masquer à zn audit davantage de valeurs secrètes et corrige un problème de sécurité dans les hooks des agents qui touche les versions 1.5.0 à 1.11.0. Mettez à jour avec npm install -g zn-gate@1.12.0 et pip install -U zn-gate.

Que montre zn-gate reach ?

Il répond à une seule question : que peuvent atteindre les agents de programmation de cette machine ? Lancez-le dans le dossier où vous travaillez :

npx -y zn-gate reach

Sur un seul écran, il liste :

les agents trouvés (Claude Code, Codex CLI, Cursor, OpenCode) et si zn les protège ;
les fichiers .env du dossier, avec les noms de leurs secrets et jamais les valeurs ;
les fichiers d'identifiants de votre dossier personnel, comme ~/.aws/credentials, les clés SSH et ~/.npmrc. Il vérifie seulement qu'ils existent et ne les ouvre jamais ;
les noms des variables d'environnement qui contiennent un secret ;
ce que zn audit trouve dans les serveurs MCP et les réglages des agents du dossier et de votre utilisateur.

Chaque constat est accompagné de la commande qui le corrige. Le rapport est en lecture seule : il n'affiche aucune valeur, n'envoie rien, ne démarre aucun hook et n'écrit rien sauf si vous le demandez avec --remember, qui conserve les compteurs de l'exécution (élevés, moyens, faibles et la date) dans ~/.zn/reach-last.json pour que l'exécution suivante puisse montrer ce qu'ils étaient. --json affiche le même rapport en JSON. La description complète se trouve dans la documentation de reach.

Le README et la page npm présentent désormais un parcours en quatre étapes : zn-gate reach, zn-gate init, zn-gate check et zn-gate env shadow.

Peut-on lancer reach en CI et l'envoyer au code scanning ?

Oui. zn-gate reach --sarif écrit le rapport en SARIF 2.1.0. Les constats concernant un fichier du dossier vérifié sont des résultats : les constats de zn audit gardent leurs règles, et un .env avec des secrets qu'un agent peut lire est ZNR002. Ce qui relève de la machine (agents non protégés, fichiers d'identifiants, variables d'environnement avec des secrets) et les fichiers de votre dossier personnel sont des notifications de l'exécution.

Par défaut, reach se termine avec le code 0 : il reste un rapport. --fail-on high|medium|low se termine avec 1 lorsqu'un constat de ce niveau ou d'un niveau supérieur est trouvé, et une erreur d'usage ou un échec se termine avec 2.

Qu'est-ce qui change dans la signature des versions ?

Deux choses, toutes deux pour ceux qui vérifient ce qu'ils installent.

Les versions sont désormais construites, attestées et signées par un workflow réutilisable séparé, build-release.yml. Le workflow de la version appelle ses jobs de construction et de signature mais ne peut pas y accéder. La provenance de construction des paquets npm et Python atteint ainsi le niveau SLSA Build Level 3.

Les tags de version sont créés et signés par un workflow, tag-release.yml, avec gitsign (signature sans clé de Sigstore) : la signature désigne ce workflow et l'identité d'aucune personne. Il ne s'exécute que depuis main, vérifie que le commit est la tête de sa branche de version, que toutes les versions concordent et que tous les contrôles ont réussi, et attend une approbation avant de signer. À partir de la 1.12.0, le workflow de version refuse de publier un tag qui ne porte pas une signature valide de tag-release.yml.

Si vous vérifiez les versions, notez qu'à partir de la 1.12.0 le workflow signataire des attestations GitHub et des signatures Sigstore est usezn/zn/.github/workflows/build-release.yml (versions précédentes : release.yml). La provenance npm et les attestations PyPI nomment toujours release.yml. La page de vérification du dépôt présente les deux et explique comment contrôler un tag.

Que masque désormais zn audit ?

zn audit cite la ligne d'un constat comme preuve. Il remplaçait déjà les secrets dans les formats connus. Dans la 1.12.0, il masque aussi :

une valeur secrète dans un format qu'il ne connaît pas lorsqu'elle suit une option d'identifiant (--token, --api-key, --password), un en-tête d'authentification (Authorization: Bearer ..., x-api-key: ...) ou un nom tel que API_TOKEN= ;
un secret donné comme élément suivant d'un tableau JSON après une option d'identifiant, comme dans les arguments d'un serveur MCP.

Les références telles que $TOKEN ou ${API_KEY} sont conservées. Les versions précédentes pouvaient citer une telle valeur dans la preuve d'un constat. Si un constat vous en a déjà montré une, changez cet identifiant.

Qu'est-ce qui est encore corrigé ?

Un long patch envoyé comme commande de shell (apply_patch dans Codex) est de nouveau refusé en une fraction de seconde. Pour nommer un fichier secret dans le message, zn ne vérifie plus que les 32 premiers fichiers du patch au lieu de tous ceux présents sur le disque, ce qui prenait plusieurs secondes pour un patch proche de la limite de 100 Ko et pouvait atteindre le délai du hook de l'agent sur une machine lente. La décision ne change pas.
Sous Windows, une commande PowerShell qui passe déjà par zn-gate run -- ... avec un espace réservé de secret n'est plus refusée à tort.
zn-gate check et zn hooks install codex signalent désormais quand Codex n'exécutera pas les hooks de zn, parce qu'ils sont désactivés dans requirements.toml, managed_config.toml ou dans votre propre config.toml, ou allow_managed_hooks_only dans requirements.toml sans zn parmi les hooks gérés. Codex n'en donne aucun signe.

Quel est le correctif de sécurité ?

GHSA-rccq-h3xc-j9qj est de gravité moyenne et concerne zn-gate 1.5.0 à 1.11.0. Dans ces versions, la protection en lecture des hooks des agents pouvait laisser lire un fichier protégé, tel qu'un .env avec des valeurs ou un fichier d'identifiants, sans le refuser lorsqu'une commande l'atteignait de façon indirecte ou lorsque la commande était très longue ou lente à vérifier. La 1.12.0 résout ces formes avant de décider, vérifie chaque commande d'une chaîne et refuse une commande qu'elle ne peut pas vérifier dans une limite de temps bien inférieure au délai du hook de l'agent. Elle refuse aussi les clés privées conservées hors de ~/.ssh, par exemple dans un projet.

L'équipe zn l'a trouvé lors d'une revue interne. Nous décrivons les classes de chemins et la conception du correctif dans un article séparé : comment un agent de programmation pouvait lire votre fichier .env de façon indirecte, et comment la 1.12.0 referme ces chemins.

Ce qu'il faut faire :

Mettez à jour les paquets et réinstallez les hooks :

npm install -g zn-gate@1.12.0
pip install -U zn-gate
npx -y zn-gate@1.12.0 init

Dans chaque dossier qui contient un fichier .env avec des valeurs, exécutez zn env shadow .env. Un fichier masqué ne contient que des marqueurs : le lire par n'importe quel chemin ne révèle aucune valeur.
Exécutez zn-gate check pour voir quels agents ont les hooks installés.

Si vous utilisez le plugin Claude Code, mettez-le à jour depuis le répertoire des plugins dès que la 1.12.0 y figure. Les formes de longue chaîne et de délai dépassé n'ont pas de contournement dans les versions plus anciennes : la mise à jour est donc le seul correctif pour elles.

Questions fréquentes

Quelles sont les nouveautés de zn-gate 1.12.0 ?

zn-gate reach, un rapport en lecture seule de ce que les agents de programmation de votre machine peuvent atteindre, aussi en SARIF pour le code scanning. Les versions sont construites et signées dans un workflow séparé (SLSA Build Level 3) et les tags de version sont signés avec gitsign. zn audit masque davantage de valeurs secrètes, les hooks des agents refusent de nouveau rapidement les longs patchs de shell et un correctif de sécurité referme GHSA-rccq-h3xc-j9qj.

Comment mettre à jour vers zn-gate 1.12.0 ?

Exécutez npm install -g zn-gate@1.12.0 pour le paquet Node et pip install -U zn-gate pour le paquet Python. Pour réinstaller les hooks des agents, exécutez npx -y zn-gate@1.12.0 init. Si vous utilisez le plugin Claude Code, mettez-le à jour depuis le répertoire des plugins dès que la 1.12.0 y figure.

zn-gate reach envoie-t-il mes secrets quelque part ?

Non. Il est en lecture seule : il n'affiche jamais de valeur, n'envoie rien, ne démarre aucun hook et n'écrit rien sauf si vous passez --remember. Il liste les noms des secrets de vos fichiers .env, vérifie si des fichiers d'identifiants comme ~/.aws/credentials existent sans les ouvrir, et montre ce que zn audit trouve dans vos serveurs MCP et les réglages de vos agents.

Quelles versions GHSA-rccq-h3xc-j9qj concerne-t-il ?

zn-gate 1.5.0 à 1.11.0. Il est corrigé dans la 1.12.0. L'avis est de gravité moyenne.

Que change-t-il si je vérifie les versions de zn-gate ?

À partir de la 1.12.0, le workflow signataire des attestations GitHub et des signatures Sigstore est build-release.yml, et non release.yml. La page de vérification du dépôt présente les deux, ainsi que la façon de contrôler un tag signé.

La liste complète des changements figure dans les notes de la version 1.12.0. zn-gate est sous licence MIT, s'exécute en local et ne demande aucun compte : commencez par npx -y zn-gate reach, ou consultez Installation pour chaque agent.