[security] deps: RUSTSEC-2026-0258 (h2) — l'audit quotidien est rouge depuis le 2026-08-19 #343

New issue

Closed

opened 2026-09-04 19:43:37 +00:00 by maximus · 0 comments

maximus commented

2026-09-04 19:43:37 +00:00

Owner

Constat

audit.yml échoue tous les jours depuis le 2026-08-19 06:00 UTC, soit 17 runs consécutifs (run_number 375 → 391). Dernier vert : le 2026-08-18 (run 374). Aucun push sur main dans cette fenêtre — le code n'a pas bougé, c'est une advisory publiée entre-temps.

Extrait du log du run 391 :

Crate:     h2
Version:   0.4.13
Title:     h2 unbounded empty DATA frames
Date:      2026-08-17
ID:        RUSTSEC-2026-0258
Solution:  Upgrade to >=0.4.16

error: 1 vulnerability found! / warning: 22 allowed warnings found — le compte de warnings est identique à celui du 2026-08-15, une seule vulnérabilité s'est ajoutée.

L'advisory est datée du 08-17 et le premier run rouge est le 08-19 : le délai correspond à la propagation dans l'advisory-db.

Au passage, ces 17 jours de rouge sont le mode d'échec que l'ADR 0018 visait à empêcher — « alarme permanente = alarme ignorée ». Le gate est bloquant par choix, et personne ne l'a vu crier.

L'advisory

RUSTSEC-2026-0258 / GHSA-q83h-524g-xf6h — catégorie déni de service, sévérité faible. h2 accepte et met en file des frames DATA vides sans aucune limite ; si les flux ne sont pas activement drainés, la mémoire croît sans borne, et la longueur peut déborder en panique. Corrigé en 0.4.16.

Atteignabilité

Vérifiée par la méthode de l'ADR 0018 — cargo tree -i par triple livré, jamais --target all. h2 est présent sur les deux cibles livrées, par deux chemins distincts :

h2 0.4.13 → hyper 1.8.1 → hyper-rustls → reqwest 0.13.2 → tauri-plugin-updater → simpl-result
                        → hyper-tls    → reqwest 0.12.28 → simpl-result   (dépendance directe)

Le premier chemin est celui de la mise à jour automatique (vérification et téléchargement). Le second est le reqwest que l'app déclare elle-même, utilisé par les commandes de licence, d'authentification, de cours et de feedback.

Par la règle 1 de .cargo/audit.toml : correctif publié + crate atteignable = advisory à corriger, jamais à supprimer. Aucune entrée n'est à ajouter au fichier des suppressions, et le garde-fou de check-rust.yml reste inchangé (CRATES="rsa").

Correctif

cargo update -p h2 → 0.4.19 (le correctif demande ≥ 0.4.16). Un seul paquet verrouillé, Cargo.toml intouché, 666 paquets avant et après.

Point de vigilance — la dérive `windows-sys`

cargo update re-résout et réaiguille au passage 7 pointeurs windows-sys de 0.61.2 vers 0.48/0.52/0.59 — colored, dirs-sys, errno, rustix, rustls-platform-verifier, tempfile, winapi-util. C'est la même dérive qu'en #310, dans le même sens.

Or c'est exactement ce que #321 a délibérément défait le 2026-08-15, après avoir vérifié crate par crate que 0.61.2 est l'état du tag v0.14.0 — donc la seule configuration windows-sys qui ait réellement compilé sous Windows. Laisser cargo update la refaire régresserait cette décision en silence, trois semaines après.

Le correctif ne porte donc que la strophe h2 : version + checksum, 2 lignes. cargo metadata --locked accepte ce fichier de verrouillage sans le réécrire, ce qui prouve sa cohérence.

Vérifications

cargo metadata --locked : exit 0, lock non réécrit
cargo check --locked --all-targets : exit 0
cargo test --locked --all-targets : 111 passed, 0 failed
cargo-audit 0.22.2 sur le lock corrigé : exit 0, 22 warnings autorisés, zéro vulnérabilité
Contrôle sur le lock d'avant : exit 1, error: 1 vulnerability found! sur RUSTSEC-2026-0258 — l'outil local reproduit bien le rouge de la CI, donc le vert obtenu veut dire quelque chose
Garde-fou des suppressions rejoué à la main : rsa absent des deux cibles, canari tar trouvé

## Constat `audit.yml` échoue tous les jours depuis le **2026-08-19 06:00 UTC**, soit 17 runs consécutifs (`run_number` 375 → 391). Dernier vert : le 2026-08-18 (run 374). Aucun push sur `main` dans cette fenêtre — le code n'a pas bougé, c'est une advisory publiée entre-temps. Extrait du log du run 391 : ``` Crate: h2 Version: 0.4.13 Title: h2 unbounded empty DATA frames Date: 2026-08-17 ID: RUSTSEC-2026-0258 Solution: Upgrade to >=0.4.16 ``` `error: 1 vulnerability found!` / `warning: 22 allowed warnings found` — le compte de warnings est identique à celui du 2026-08-15, une seule vulnérabilité s'est ajoutée. L'advisory est datée du 08-17 et le premier run rouge est le 08-19 : le délai correspond à la propagation dans l'advisory-db. Au passage, ces 17 jours de rouge sont le mode d'échec que l'ADR 0018 visait à empêcher — « alarme permanente = alarme ignorée ». Le gate est bloquant par choix, et personne ne l'a vu crier. ## L'advisory [RUSTSEC-2026-0258](https://rustsec.org/advisories/RUSTSEC-2026-0258) / [GHSA-q83h-524g-xf6h](https://github.com/hyperium/hyper/security/advisories/GHSA-q83h-524g-xf6h) — catégorie déni de service, sévérité **faible**. `h2` accepte et met en file des frames `DATA` vides sans aucune limite ; si les flux ne sont pas activement drainés, la mémoire croît sans borne, et la longueur peut déborder en panique. Corrigé en 0.4.16. ## Atteignabilité Vérifiée par la méthode de l'[ADR 0018](docs/adr/0018-suppression-advisories-non-atteignables.md) — `cargo tree -i` par triple livré, jamais `--target all`. `h2` est présent sur **les deux cibles livrées**, par deux chemins distincts : ``` h2 0.4.13 → hyper 1.8.1 → hyper-rustls → reqwest 0.13.2 → tauri-plugin-updater → simpl-result → hyper-tls → reqwest 0.12.28 → simpl-result (dépendance directe) ``` Le premier chemin est celui de la mise à jour automatique (vérification et téléchargement). Le second est le `reqwest` que l'app déclare elle-même, utilisé par les commandes de licence, d'authentification, de cours et de feedback. Par la **règle 1** de `.cargo/audit.toml` : correctif publié + crate atteignable = advisory à corriger, jamais à supprimer. Aucune entrée n'est à ajouter au fichier des suppressions, et le garde-fou de `check-rust.yml` reste inchangé (`CRATES="rsa"`). ## Correctif `cargo update -p h2` → **0.4.19** (le correctif demande ≥ 0.4.16). Un seul paquet verrouillé, `Cargo.toml` intouché, 666 paquets avant et après. ## Point de vigilance — la dérive `windows-sys` `cargo update` re-résout et réaiguille au passage 7 pointeurs `windows-sys` de `0.61.2` vers 0.48/0.52/0.59 — `colored`, `dirs-sys`, `errno`, `rustix`, `rustls-platform-verifier`, `tempfile`, `winapi-util`. C'est la même dérive qu'en #310, dans le même sens. Or c'est exactement ce que #321 a **délibérément défait** le 2026-08-15, après avoir vérifié crate par crate que `0.61.2` est l'état du tag `v0.14.0` — donc la seule configuration `windows-sys` qui ait réellement compilé sous Windows. Laisser `cargo update` la refaire régresserait cette décision en silence, trois semaines après. Le correctif ne porte donc **que la strophe `h2`** : version + checksum, 2 lignes. `cargo metadata --locked` accepte ce fichier de verrouillage sans le réécrire, ce qui prouve sa cohérence. ## Vérifications - `cargo metadata --locked` : exit 0, lock non réécrit - `cargo check --locked --all-targets` : exit 0 - `cargo test --locked --all-targets` : **111 passed, 0 failed** - `cargo-audit 0.22.2` sur le lock corrigé : **exit 0**, 22 warnings autorisés, zéro vulnérabilité - Contrôle sur le lock d'avant : exit 1, `error: 1 vulnerability found!` sur RUSTSEC-2026-0258 — l'outil local reproduit bien le rouge de la CI, donc le vert obtenu veut dire quelque chose - Garde-fou des suppressions rejoué à la main : `rsa` absent des deux cibles, canari `tar` trouvé