fix(security): bump undici + js-yaml overrides to patched versions #109
No reviewers
Labels
No labels
autopilot:pending-human
source:analyste
source:defenseur
source:human
source:medic
status:approved
status:blocked
status:in-progress
status:needs-clarification
status:needs-fix
status:ready
status:review
status:triage
type:bug
type:feature
type:infra
type:refactor
type:schema
type:security
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: maximus/simpl-liste#109
Loading…
Reference in a new issue
No description provided.
Delete branch "issue-106-107-deps-overrides"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Fixes #106
Fixes #107
Changements
@expo/cli > undici^6.27.0->^6.28.0-- GHSA-8xcm-r25x-g524 / m8rv-5g2x-5cg5 / v3r7-h72x-cjcm (response desync, CRLF & cookie injection, vuln<6.28.0). Re-occurrence de #96.js-yaml->^3.15.1(3.x) +^4.3.1(4.x) -- CVE-2026-59870 / GHSA-5p4m-2wfm-xmqj (quadratic CPU!!omap, vuln3.x<3.15.1/4.x<4.3.1). Re-occurrence de #98.Note technique : nested -> version-scoped pour js-yaml
Les overrides js-yaml passent de parent-scoped (
@expo/xcpretty,@istanbuljs/load-nyc-config) a version-scoped (js-yaml@^3.0.0/js-yaml@^4.0.0). L'instance 4.x est atteinte via@expo/cli, lui-meme overridde : un override neste ne se propage pas a travers un parent overridde (npm laissaitjs-yaml@4.3.0invalidmalgre l'override^4.3.1, meme apresrm lock). Le ciblage par version resout independamment du chemin parent et couvre toute instance 3.x/4.x future.Build/dev-time uniquement, non bundle dans l'APK.
npm audit: 16 -> 14. Diff lock limite aux 3 packages bumpes (js-yaml, undici, +argparse re-hoisted meme version). Smoke test 11/11, patch widget reapplique.Hors scope
<=2.0.2vulnerables, bloque upstream). Entraine les 13 high transitives restantes (cascade metro/react-native), a lever au prochain bump SDK Expo.Hygiene notee (separee)
Le
package-lock.jsonde master est gonfle : unrm lock && npm installle reduit de ~960 lignes. Non traite ici (hors scope securite) -- candidat a une regeneration propre dediee.Verdict : APPROVE
Bump de sécurité propre et complet. Les 3 versions patchées sont présentes dans le lock, sans copie vulnérable résiduelle, et cohérentes avec
package.json. Fixes #106 + #107.Vérifications (arbre complet du lock inspecté, pas seulement le diff)
Lock cohérent avec les overrides :
js-yaml 3.15.1— nested sous@istanbuljs/load-nyc-config(dep^3.13.1), forcé par l'override version-scopedjs-yaml@^3.0.0 → ^3.15.1.js-yaml 4.3.1— hoisté top-level, consommé par@expo/xcpretty(dep^4.1.0), forcé parjs-yaml@^4.0.0 → ^4.3.1.undici 6.28.0— install unique top-level, consommé par@expo/cli(dep^6.18.2), forcé par@expo/cli > undici ^6.28.0.argparserelocalisé (2.0.1 sous le nouveau js-yaml top-level, 1.0.10 top-level inchangé), versions inchangées.Migration version-scoped justifiée : le passage de parent-scoped à
js-yaml@^N.0.0couvre toute instance 3.x/4.x indépendamment du chemin parent. L'empirie le confirme — le lock résout bien 3.15.1 et 4.3.1, preuve que npm applique la syntaxepkg@range.Pas de conflit direct-dep : ni
js-yamlniundicine figurent endependencies/devDependencies, donc aucun risque d'erreur d'override sur dépendance directe.Surface : deps build/dev-time (Expo CLI, xcpretty, istanbul), non bundlées dans l'APK ; bumps patch-level → risque de régression runtime nul.
Commit : conventionnel, unique, aligné sur le titre. Référence bien #106 + #107.
Suggestions (non bloquantes)
undicireste parent-scoped (@expo/cli) alors quejs-yamlest passé version-scoped. Ça marche aujourd'hui (undici unique hoisté top-level qui satisfait tous les consommateurs), mais si un futur transitif tire undici nested sous un parent overridé, tu retombes sur le même gap de propagation que la PR décrit pour js-yaml. Version-scoperundici@^6.0.0fermerait cet angle mort par symétrie — optionnel.