L’article ne peut pas être activé avec JavaScript. Vous pouvez également activer JavaScript dans votre navigateur et sur la nouvelle page.
Un fichier de configuration dans la configuration ripgrep d’un développeur pourrait arrêter les fichiers de masquage du bac à sable Codex d’OpenAI qu’il lui avait été demandé de refuser, et Codex CLI 0.162.0 le ferme. L’entrée du journal des modifications du Codex datée du 8 octobre répertorie le changement comme « empêcher la configuration de ripgrep d’affaiblir les masques deny-glob », ainsi que trois autres réparations du bac à sable Linux.
Le mécanisme est décrit dans la demande d’extraction derrière, n° 51527 dans le référentiel de codex d’OpenAI, fusionné le 7 octobre. « La configuration utilisateur ripgrep peut supprimer la liste de fichiers utilisée pour construire les masques de refus du bac à sable Linux », indique-t-il. « Par exemple, --quiet dans RIPGREP_CONFIG_PATH peut laisser les fichiers correspondant aux globes de refus non masqués. » Le correctif passe --no-config à l’appel ripgrep qui développe les globs de fichiers refusés.
Le Codex construit ce masque en demandant à ripgrep quels fichiers correspondent à chaque global de refus, donc un paramètre qui fait taire la sortie de ripgrep fait taire la liste. Le test de régression ajouté avec le correctif alimente l’outil avec une configuration contenant --quiet et vérifie « que les fichiers refusés restent illisibles et illisibles tandis que les fichiers autorisés restent accessibles ».
Un bwrap inscriptible sur PATH pouvait être exécuté en dehors du bac à sable
La deuxième réparation concerne la manière dont le Codex trouve le binaire bubblewrap qui construit le bac à sable en premier lieu. #51211, fusionné le 6 octobre, énonce la faiblesse dans ses propres termes : « La découverte Bubblewrap sonde les exécutables avant le confinement. L’exclusion uniquement du répertoire actuel de la commande laisse les candidats dans d’autres racines inscriptibles éligibles pour s’exécuter en dehors du bac à sable. »
La version filtre désormais les candidats PATH canoniques en fonction de la politique du système de fichiers et des autorisations utilisateur effectives, y compris les ancêtres inscriptibles, les racines liées par lien symbolique et l’accès en écriture sur le disque complet, et conserve les installations système protégées tout en rejetant les chemins remplaçables. Il sélectionne également le lanceur avec les propres autorisations de la commande avant le contrôle en amont du montage et conserve le papier bulle fourni comme solution de secours. Ses tests couvrent l’écriture bwrap les candidats qui « ne sont ni sondés ni lancés », y compris lorsque la commande s’exécute dans un sous-répertoire de l’espace de travail ou utilise un réseau géré avec un accès en écriture complet au disque.
Les deux cas nécessitent déjà quelque chose sur la machine
Chacun repose sur un préalable local. Le cas ripgrep nécessite un fichier de configuration pointé par l’utilisateur RIPGREP_CONFIG_PATH à, et le boîtier en papier bulle est inscriptible bwrap binaire assis sur PATH avant un binaire protégé. Le test ripgrep est carrément ignoré lorsqu’il n’y a pas de protection rg l’exécutable est disponible sur la machine qui l’exécute.
Deux autres correctifs sandbox sont livrés avec eux. Les notes de publication d’OpenAI pour la version 0.162.0 répertorient le n° 50059 comme correctif pour le démarrage du sandbox Linux avec plusieurs fichiers refusés, qui est la condition sur laquelle le test ripgrep s’appuie, et le n° 51407 comme protection pour la recherche ripgrep que le Codex effectue pendant la construction du bac à sable.
La CLI est la moitié du Codex qui s’exécute sur la propre machine du développeur, où le bac à sable fait son travail, par opposition au côté cloud qui publie les commentaires de révision du code directement sur GitHub.
Windows a récupéré des correctifs dans la même version
0.162.0 restaure également l’accès ordinaire aux fichiers de lettre de lecteur sur Windows 10 et fait correspondre les autorisations temporaires du bac à sable Windows à l’environnement de processus enfant. OpenAI publie désormais un programme d’installation PowerShell signé avec les versions Windows et a corrigé la vérification de la somme de contrôle des archives lorsque les chemins du module PowerShell 7 sont présents, un cas où un lanceur natif s’est arrêté Get-FileHash chargement et a ainsi bloqué le chèque.
La version a atteint npm sous le nom @openai/codex 0.162.0 à 19h01 UTC le 8 octobre, environ 27 heures après la 0.161.0, les versions par plate-forme ayant suivi au cours des dix minutes suivantes. La propre ligne d’installation d’OpenAI est npm install -g @openai/[email protected].