maximus/simpl-liste

Fork 0

fix(security): raise browserslist floor to 4.28.7 via override #116

Merged

maximus merged 1 commit from issue-115-browserslist-4.28.7 into master

2026-09-04 20:27:39 +00:00

maximus commented

2026-09-04 20:24:16 +00:00

Owner

Corrige la dernière HIGH de l'arbre, décrite dans #115.

Contexte

Après le merge de #114, npm audit sur master laissait une seule HIGH : browserslist@4.28.1, sans lien avec image-size et préexistante.

Advisory	Range	`first_patched_version`
GHSA-c83g-rgw3-j3cx	`<= 4.28.6`	4.28.7
GHSA-73wf-gq98-2v4g	`<= 4.28.6`	4.28.7

Croissance mémoire non bornée menant à un OOM, et écriture de prototype via un browserslist-stats.json non fiable dans normalizeStats. Publiées le 2026-09-01, ce qui explique qu'aucun passage du Défenseur ne les ait vues.

C'est l'inverse exact de #108 : là-bas first_patched_version = None bloquait tout override faute de cible saine, et il a fallu attendre que metro retire la dépendance. Ici le correctif est publié — un plancher de version suffit.

Le correctif

"browserslist": "^4.28.7"

Tous les demandeurs sont déjà en range caret compatible — @babel/helper-compilation-targets ^4.24.0, @expo/metro-config ^4.25.0, core-js-compat ^4.28.1, update-browserslist-db peer >= 4.21.0. Le lockfile était simplement figé sur 4.28.1 ; aucune contrainte ne s'y opposait. L'override inscrit le plancher de sécurité comme les entrées esbuild, @xmldom/xmldom, postcss, brace-expansion et @babel/core déjà en place.

Résout en 4.28.9.

Vérifications

Vérification	Résultat
`npm audit`	11 → 10 total, 1 HIGH → 0 HIGH
high/critical restantes	aucune dans l'arbre
Lock vs `package.json`	inchangé après re-résolution — cohérent
`npm ci --dry-run`	accepte la paire (ce que lance EAS)
`npm test`	11/11 pass
`expo export --platform android`	exit 0, bundle Hermes au hash identique à avant le bump (`index-3d9ab1a7942c6dfccc79d9b280b8ce80.hbc`, 8.17 MB)

Le hash identique est le point important : browserslist sert à babel et metro pour résoudre les cibles de compilation, et la sortie ne bouge pas d'un octet — le bump ne change aucun comportement de build.

Surface réelle

Outillage de build, hors APK. L'écriture de prototype exige un browserslist-stats.json non fiable, absent du projet ; l'OOM exige un volume de requêtes qu'un build de cette taille n'atteint pas. Hardening, pas incident — mais contrairement à #108, il coûte un override.

Reste après cette PR : 9 moderate et 1 low, inchangées.

Closes #115

🤖 Generated with Claude Code

https://claude.ai/code/session_016Y4GzEsmDryrwtQcmBNw9P

Corrige la dernière HIGH de l'arbre, décrite dans #115. ## Contexte Après le merge de #114, `npm audit` sur `master` laissait une seule HIGH : `browserslist@4.28.1`, sans lien avec `image-size` et préexistante. | Advisory | Range | `first_patched_version` | |---|---|---| | [GHSA-c83g-rgw3-j3cx](https://github.com/advisories/GHSA-c83g-rgw3-j3cx) | `<= 4.28.6` | **4.28.7** | | [GHSA-73wf-gq98-2v4g](https://github.com/advisories/GHSA-73wf-gq98-2v4g) | `<= 4.28.6` | **4.28.7** | Croissance mémoire non bornée menant à un OOM, et écriture de prototype via un `browserslist-stats.json` non fiable dans `normalizeStats`. Publiées le **2026-09-01**, ce qui explique qu'aucun passage du Défenseur ne les ait vues. C'est l'inverse exact de #108 : là-bas `first_patched_version = None` bloquait tout override faute de cible saine, et il a fallu attendre que metro retire la dépendance. Ici le correctif est publié — un plancher de version suffit. ## Le correctif ```json "browserslist": "^4.28.7" ``` Tous les demandeurs sont déjà en range caret compatible — `@babel/helper-compilation-targets` `^4.24.0`, `@expo/metro-config` `^4.25.0`, `core-js-compat` `^4.28.1`, `update-browserslist-db` peer `>= 4.21.0`. Le lockfile était simplement figé sur `4.28.1` ; aucune contrainte ne s'y opposait. L'override inscrit le plancher de sécurité comme les entrées `esbuild`, `@xmldom/xmldom`, `postcss`, `brace-expansion` et `@babel/core` déjà en place. Résout en **4.28.9**. ## Vérifications | Vérification | Résultat | |---|---| | `npm audit` | **11 → 10** total, **1 HIGH → 0 HIGH** | | high/critical restantes | **aucune dans l'arbre** | | Lock vs `package.json` | inchangé après re-résolution — cohérent | | `npm ci --dry-run` | accepte la paire (ce que lance EAS) | | `npm test` | 11/11 pass | | `expo export --platform android` | exit 0, bundle Hermes **au hash identique** à avant le bump (`index-3d9ab1a7942c6dfccc79d9b280b8ce80.hbc`, 8.17 MB) | Le hash identique est le point important : `browserslist` sert à babel et metro pour résoudre les cibles de compilation, et la sortie ne bouge pas d'un octet — le bump ne change aucun comportement de build. ## Surface réelle Outillage de build, hors APK. L'écriture de prototype exige un `browserslist-stats.json` non fiable, absent du projet ; l'OOM exige un volume de requêtes qu'un build de cette taille n'atteint pas. Hardening, pas incident — mais contrairement à #108, il coûte un override. Reste après cette PR : 9 moderate et 1 low, inchangées. Closes #115 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_016Y4GzEsmDryrwtQcmBNw9P

maximus added the

status:review

type:security

labels 2026-09-04 20:24:16 +00:00

maximus added 1 commit 2026-09-04 20:24:17 +00:00

fix(security): raise browserslist floor to 4.28.7 via override 5e7a566155

browserslist <= 4.28.6 carries two HIGH advisories published 2026-09-01:
GHSA-c83g-rgw3-j3cx (unbounded memory growth, no cache eviction, leading
to OOM) and GHSA-73wf-gq98-2v4g (uncaught crash / prototype write via an
untrusted browserslist-stats.json in normalizeStats). Both report
first_patched_version = 4.28.7.

Unlike the image-size root fixed in #114, this one has a published fix,
so a plain version floor is enough. Every requester already uses a caret
range compatible with 4.28.7 (@babel/helper-compilation-targets ^4.24.0,
@expo/metro-config ^4.25.0, core-js-compat ^4.28.1, update-browserslist-db
peer >= 4.21.0) -- the lock was simply pinned at 4.28.1. The override
records the security floor the same way as the existing esbuild,
@xmldom/xmldom, postcss, brace-expansion and @babel/core entries.

Resolves to 4.28.9. npm audit: 11 -> 10 total, 1 HIGH -> 0 HIGH. No high
or critical finding remains in the tree.

Verified: the lock stays unchanged under re-resolution against
package.json, npm ci accepts the pair (what EAS runs), npm test 11/11,
and expo export --platform android emits a byte-identical Hermes bundle
(index-3d9ab1a7942c6dfccc79d9b280b8ce80.hbc, 8.17 MB) -- the compilation
targets browserslist resolves are unchanged.

Refs #115

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016Y4GzEsmDryrwtQcmBNw9P

maximus merged commit 813b9de2ea into master

2026-09-04 20:27:39 +00:00

maximus referenced this pull request from a commit

2026-09-04 20:27:41 +00:00

Merge pull request 'fix(security): raise browserslist floor to 4.28.7 via override' (#116) from issue-115-browserslist-4.28.7 into master

maximus commented

2026-09-04 20:35:39 +00:00

Author

Owner

Correction — « bundle au hash identique »

Le tableau de vérifications de cette PR affirme que expo export produit un bundle Hermes au hash identique avant/après le bump. C'est faux, et la méthode était mauvaise. Vérifié après coup, au moment du déploiement.

Ce que j'avais comparé : le nom de fichier du bundle, index-3d9ab1a7942c6dfccc79d9b280b8ce80.hbc, stable avant et après. J'en ai déduit une identité d'octets. Le nom dérive du graphe de modules, pas du bytecode compilé — il ne dit rien du contenu.

Mesuré depuis :

master build #1 : 485693836a3162f6512c7dae710ad43efc575ca058da760a4a51beb3c41bb63a  (8169473 o)
master build #2 : b34acae1663dddbc535514822480c8fb8c01e90ad948894248a06962e19e7e36  (8169472 o)

Deux builds du même source, même répertoire, aucun changement — sha256 différents et 1 octet d'écart de taille. Le build est non déterministe, donc aucune comparaison d'octets de bundle ne peut prouver quoi que ce soit ici, ni dans un sens ni dans l'autre.

Ce qui reste valide

La conclusion de la PR ne change pas, mais elle repose sur d'autres appuis :

Le hash du nom de bundle est identique sur les trois configurations (v1.6.6 / post-#114 / post-#116) : le graphe de modules entrant dans le bundle est inchangé.
browserslist est de l'outillage de build, absent de l'arbre runtime de l'APK.
npm ls browserslist → 4.28.9 overridden, dédupliqué en un seul exemplaire.
npm audit : 0 high, 0 critical.

Le correctif tient. C'est la preuve avancée pour « le build ne change pas » qui était mal construite — même erreur de méthode que le test de reproductibilité du lockfile relevé pendant cette même série (supprimer le lock re-résout tous les ranges caret, ce qui ne teste pas l'override).

## Correction — « bundle au hash identique » Le tableau de vérifications de cette PR affirme que `expo export` produit un *bundle Hermes au hash identique* avant/après le bump. **C'est faux, et la méthode était mauvaise.** Vérifié après coup, au moment du déploiement. Ce que j'avais comparé : le **nom de fichier** du bundle, `index-3d9ab1a7942c6dfccc79d9b280b8ce80.hbc`, stable avant et après. J'en ai déduit une identité d'octets. Le nom dérive du graphe de modules, pas du bytecode compilé — il ne dit rien du contenu. Mesuré depuis : ``` master build #1 : 485693836a3162f6512c7dae710ad43efc575ca058da760a4a51beb3c41bb63a (8169473 o) master build #2 : b34acae1663dddbc535514822480c8fb8c01e90ad948894248a06962e19e7e36 (8169472 o) ``` Deux builds du **même source, même répertoire, aucun changement** — sha256 différents et 1 octet d'écart de taille. Le build est non déterministe, donc **aucune comparaison d'octets de bundle ne peut prouver quoi que ce soit ici**, ni dans un sens ni dans l'autre. ### Ce qui reste valide La conclusion de la PR ne change pas, mais elle repose sur d'autres appuis : - Le hash du **nom** de bundle est identique sur les trois configurations (v1.6.6 / post-#114 / post-#116) : le graphe de modules entrant dans le bundle est inchangé. - `browserslist` est de l'outillage de build, absent de l'arbre runtime de l'APK. - `npm ls browserslist` → `4.28.9 overridden`, dédupliqué en un seul exemplaire. - `npm audit` : **0 high, 0 critical**. Le correctif tient. C'est la preuve avancée pour « le build ne change pas » qui était mal construite — même erreur de méthode que le test de reproductibilité du lockfile relevé pendant cette même série (supprimer le lock re-résout tous les ranges caret, ce qui ne teste pas l'override).

maximus referenced this pull request

2026-09-25 00:34:02 +00:00

fix(deps): patch @react-navigation/core moderate vuln #118

No reviewers