maximus/Simpl-Resultat

Fork 0

deps: RUSTSEC-2026-0382 (rustls-webpki 0.103.15) et RUSTSEC-2026-0383 (webpki-root-certs 1.0.6), audit.yml rouge à partir du 2026-10-21 #484

New issue

Open

opened 2026-10-21 00:14:10 +00:00 by maximus · 2 comments

maximus commented

2026-10-21 00:14:10 +00:00

Owner

Contexte

Relevé par la revue indépendante de la PR #482 (commentaire 25974), dans l'étape cargo audit informative de check-rust (run 601, tête a17c1b7, 2026-10-20). Les deux avis sont parus après le dernier audit.yml vert (run 599, 2026-10-20 06:00 UTC) : le prochain run planifié (2026-10-21 06:00 UTC) rougira, et restera rouge jusqu'à un merge sur main.

Décision de Max (2026-10-20) : issue seulement pour l'instant, correctif plus tard ; pas de bump dans la pile planned-2026-10-16-lot-v018.

Avis (journal du run 601)

ID	Crate	Version	Titre	Correctif
RUSTSEC-2026-0382	`rustls-webpki`	0.103.15	Certificate verification may accept distrusted intermediates	`>=0.103.16, <0.104.0-alpha.1`
RUSTSEC-2026-0383	`webpki-root-certs`	1.0.6	Bundled root certificates allow trust in distrusted emSign intermediates	`>=1.0.10`

Atteignabilité par cible (`cargo tree --locked -i <crate> --target <triple> -e normal`, lock de `main` `6e8e157`, 2026-10-20)

rustls-webpki 0.103.15 : compilé pour x86_64-unknown-linux-gnu et x86_64-pc-windows-msvc, par rustls 0.23.46 → hyper-rustls / reqwest 0.13.2 → tauri-plugin-updater, et par rustls-platform-verifier 0.6.2. C'est le chemin TLS de la mise à jour automatique, le même que #447 et #455.
webpki-root-certs 1.0.6 : rien à imprimer pour ces deux cibles (non compilé pour Linux ni Windows) ; audit.yml le signale quand même, il lit tout le lock.

Correctif attendu

cargo update --manifest-path src-tauri/Cargo.toml -p rustls-webpki → 0.103.16 et -p webpki-root-certs → 1.0.10. cargo update --dry-run (2026-10-20) n'annonce aucun autre changement.
Règle 1 de .cargo/audit.toml (ADR 0018) : corriger plutôt que supprimer, aucune entrée ajoutée pour ces deux avis.
Garde windows-sys de check-rust rejouée sur le lock modifié (ADR 0023) ; cargo check --locked et cargo test --locked verts.
Montée de version d'un paquet déjà présent dans le lock : niveau normal selon REVIEW.md (décision de Max du 2026-10-17).

Critères d'acceptation

Lock à rustls-webpki 0.103.16 et webpki-root-certs 1.0.10, aucune autre ligne déplacée.
check-rust vert sur la PR (gardes et cargo audit sans ces deux avis).
Après le merge, audit.yml en workflow_dispatch sur main vert, run cité.
Le prochain tag déroule le cycle réel de mise à jour (le chemin TLS de l'updater change), comme pour #447.

Liens : PR #482 (commentaire 25974), run 601, #447, #455, ADR 0018, ADR 0023.

Analyse (`/analyze`, 2026-10-20, `main` `45d8493`)

Prémisse confirmée sur main après le merge du lot v0.18 : la pile n'a pas touché au lock.
Exposition précisée :
- rustls-webpki n'est atteint que par le reqwest 0.13.2 de tauri-plugin-updater (feature rustls-tls).
- Le code de l'app appelle un autre reqwest, en 0.12.28 (src-tauri/Cargo.toml, ligne reqwest = { version = "0.12", ... }, TLS du système par défaut), dans license_commands.rs, feedback_commands.rs, auth_commands.rs et balance_commands.rs : ces appels ne sont pas concernés.
- L'exposition réelle se limite à la vérification TLS des téléchargements de mise à jour. Chaque paquet y reste vérifié par sa signature (clé de l'updater), donc un faux certificat ne suffit pas à installer une mise à jour malveillante.
webpki-root-certs n'arrive que par rustls-platform-verifier, et sous aucune des deux cibles livrées (cargo tree --target all ne le montre que sous d'autres cibles).
Simulation du correctif dans un worktree jetable : cargo update -p rustls-webpki -p webpki-root-certs change 4 lignes de Cargo.lock (versions 0.103.16 et 1.0.10, sommes de contrôle), aucune autre.

Décisions de Max (2026-10-20)

Le correctif est livré avec la prochaine release, celle qui porte le lot v0.18 : pas de release corrective, comme pour #447. Le cycle réel de mise à jour est dû à ce tag.
Une seule PR avec #483 (vite 6.4.3 → 6.4.4), un commit par issue. La PR porte Resolves #483 et Refs #484 : #484 a un critère après le merge.

Travail à faire

cargo update --manifest-path src-tauri/Cargo.toml -p rustls-webpki -p webpki-root-certs ; le diff du lock se limite à ces deux paquets.
Garde windows-sys rejouée sur le lock ; cargo check --locked et cargo test --locked verts.
Une puce Sécurité dans CHANGELOG.md et dans CHANGELOG.fr.md, à côté de celle de #483.
Un commit dédié, avec Refs #484 et sans mot-clé de fermeture.
Après le merge : workflow_dispatch d'audit.yml sur main, run vert cité, puis fermeture de #484 à la main.

Complexité

Simple. Niveau normal selon REVIEW.md (montée de version d'un paquet déjà présent dans le lock, décision de Max du 2026-10-17). Si la PR avec #483 touche package.json, voir le niveau que fixe REVIEW.md pour ce fichier.

Analyse (`/analyze`, 2026-10-20, `main` `6e8e157`)

Prémisse confirmée point par point ; le corps ci-dessus reste la référence. Décision de Max (2026-10-20, réponse à /analyze) : PR seule sur main, dès que possible, indépendante de la pile planned-2026-10-16-lot-v018 (aucun fichier commun : #469 touche check-rust.yml, pas le lock).

Sonde (worktree détaché, retiré ensuite)

Reproduit avec le binaire de la CI (cargo-audit 0.22.2, lancé depuis la racine, .cargo/audit.toml lu) : error: 2 vulnerabilities found!, exit 1, 663 crates, 18 avertissements autorisés (les mêmes que le run 564).
cargo update --manifest-path src-tauri/Cargo.toml -p rustls-webpki -p webpki-root-certs : 8 lignes du lock (version et checksum des deux paquets), rien d'autre. Index crates.io comparé : ni 0.103.16 ni 1.0.10 ne change ses dépendances, ses features ou son MSRV. cargo metadata --locked passe.
Audit après bump : exit 0, 663 crates, mêmes 18 avertissements. Garde windows-sys rejouée sur le lock modifié : 9 contrôles, exit 0.

Atteignabilité, nuance par cible

rustls-webpki est compilé pour Linux et Windows. Sous Linux, c'est lui qui valide la chaîne (rustls-platform-verifier 0.6.2, src/verification/others.rs, racines système) : RUSTSEC-2026-0382 est atteignable sur le chemin réel de l'updater Linux. Sous Windows, la validation passe par l'API système (windows.rs n'appelle pas webpki) : le crate est dans le graphe, pas sur le chemin.
webpki-root-certs n'est une dépendance de rustls-platform-verifier que pour wasm32 (et en dev-dependency) : jamais compilé pour nos cibles. Il serait éligible à une suppression selon la règle 1 de l'ADR 0018, mais le bump le corrige au même prix : aucune entrée dans .cargo/audit.toml.

Travail à faire

cargo update --manifest-path src-tauri/Cargo.toml -p rustls-webpki -p webpki-root-certs (0.103.16 et 1.0.10).
En local : garde windows-sys (extraire le run: de l'étape de check-rust.yml), cargo audit avec le binaire de la CI (rouge avant, vert après), cargo check --locked et cargo test --locked.
Une puce Sécurité sous [Unreleased] dans CHANGELOG.md et CHANGELOG.fr.md, « aucun changement » restreint au code de l'app (comme 9abf474 et #447).
PR en Refs #484 (critère post-merge, fermeture à la main), niveau normal selon REVIEW.md (deux paquets déjà présents, aucun ajouté ni retiré).
Après le merge : workflow_dispatch d'audit.yml sur main, run cité ici, puis fermeture.

Fichiers concernés

src-tauri/Cargo.lock — seul fichier de code touché.
CHANGELOG.md, CHANGELOG.fr.md — entrée Sécurité.

Surface de test

Aucun test ne porte sur ces crates ; les preuves sont cargo audit et la garde windows-sys.
Mutation inverse pour la revue : remettre 0.103.15 dans le lock, l'audit redevient rouge sur 0382.
La prochaine release déroule le cycle réel de mise à jour (critère 4 ci-dessus, règle de #463).

Complexité

Simple. Prochaine étape : /fix-issue 484.

## Contexte Relevé par la revue indépendante de la PR #482 (commentaire 25974), dans l'étape `cargo audit` informative de `check-rust` (run 601, tête `a17c1b7`, 2026-10-20). Les deux avis sont parus après le dernier `audit.yml` vert (run 599, 2026-10-20 06:00 UTC) : le prochain run planifié (2026-10-21 06:00 UTC) rougira, et restera rouge jusqu'à un merge sur `main`. **Décision de Max (2026-10-20)** : issue seulement pour l'instant, correctif plus tard ; pas de bump dans la pile `planned-2026-10-16-lot-v018`. ## Avis (journal du run 601) | ID | Crate | Version | Titre | Correctif | |---|---|---|---|---| | RUSTSEC-2026-0382 | `rustls-webpki` | 0.103.15 | Certificate verification may accept distrusted intermediates | `>=0.103.16, <0.104.0-alpha.1` | | RUSTSEC-2026-0383 | `webpki-root-certs` | 1.0.6 | Bundled root certificates allow trust in distrusted emSign intermediates | `>=1.0.10` | ## Atteignabilité par cible (`cargo tree --locked -i <crate> --target <triple> -e normal`, lock de `main` `6e8e157`, 2026-10-20) - `rustls-webpki` 0.103.15 : **compilé pour `x86_64-unknown-linux-gnu` et `x86_64-pc-windows-msvc`**, par `rustls` 0.23.46 → `hyper-rustls` / `reqwest` 0.13.2 → `tauri-plugin-updater`, et par `rustls-platform-verifier` 0.6.2. C'est le chemin TLS de la mise à jour automatique, le même que #447 et #455. - `webpki-root-certs` 1.0.6 : rien à imprimer pour ces deux cibles (non compilé pour Linux ni Windows) ; `audit.yml` le signale quand même, il lit tout le lock. ## Correctif attendu - `cargo update --manifest-path src-tauri/Cargo.toml -p rustls-webpki` → 0.103.16 et `-p webpki-root-certs` → 1.0.10. `cargo update --dry-run` (2026-10-20) n'annonce aucun autre changement. - Règle 1 de `.cargo/audit.toml` (ADR 0018) : corriger plutôt que supprimer, aucune entrée ajoutée pour ces deux avis. - Garde `windows-sys` de `check-rust` rejouée sur le lock modifié (ADR 0023) ; `cargo check --locked` et `cargo test --locked` verts. - Montée de version d'un paquet déjà présent dans le lock : niveau normal selon `REVIEW.md` (décision de Max du 2026-10-17). ## Critères d'acceptation - [ ] Lock à `rustls-webpki` 0.103.16 et `webpki-root-certs` 1.0.10, aucune autre ligne déplacée. - [ ] `check-rust` vert sur la PR (gardes et `cargo audit` sans ces deux avis). - [ ] Après le merge, `audit.yml` en `workflow_dispatch` sur `main` vert, run cité. - [ ] Le prochain tag déroule le cycle réel de mise à jour (le chemin TLS de l'updater change), comme pour #447. Liens : PR #482 (commentaire 25974), run 601, #447, #455, ADR 0018, ADR 0023. ## Analyse (`/analyze`, 2026-10-20, `main` `45d8493`) - Prémisse confirmée sur `main` après le merge du lot v0.18 : la pile n'a pas touché au lock. - Exposition précisée : - `rustls-webpki` n'est atteint que par le `reqwest` 0.13.2 de `tauri-plugin-updater` (feature `rustls-tls`). - Le code de l'app appelle un autre `reqwest`, en 0.12.28 (`src-tauri/Cargo.toml`, ligne `reqwest = { version = "0.12", ... }`, TLS du système par défaut), dans `license_commands.rs`, `feedback_commands.rs`, `auth_commands.rs` et `balance_commands.rs` : ces appels ne sont pas concernés. - L'exposition réelle se limite à la vérification TLS des téléchargements de mise à jour. Chaque paquet y reste vérifié par sa signature (clé de l'updater), donc un faux certificat ne suffit pas à installer une mise à jour malveillante. - `webpki-root-certs` n'arrive que par `rustls-platform-verifier`, et sous aucune des deux cibles livrées (`cargo tree --target all` ne le montre que sous d'autres cibles). - Simulation du correctif dans un worktree jetable : `cargo update -p rustls-webpki -p webpki-root-certs` change 4 lignes de `Cargo.lock` (versions 0.103.16 et 1.0.10, sommes de contrôle), aucune autre. ## Décisions de Max (2026-10-20) - Le correctif est livré avec la prochaine release, celle qui porte le lot v0.18 : pas de release corrective, comme pour #447. Le cycle réel de mise à jour est dû à ce tag. - Une seule PR avec #483 (`vite` 6.4.3 → 6.4.4), un commit par issue. La PR porte `Resolves #483` et `Refs #484` : #484 a un critère après le merge. ## Travail à faire - [ ] `cargo update --manifest-path src-tauri/Cargo.toml -p rustls-webpki -p webpki-root-certs` ; le diff du lock se limite à ces deux paquets. - [ ] Garde `windows-sys` rejouée sur le lock ; `cargo check --locked` et `cargo test --locked` verts. - [ ] Une puce Sécurité dans `CHANGELOG.md` et dans `CHANGELOG.fr.md`, à côté de celle de #483. - [ ] Un commit dédié, avec `Refs #484` et sans mot-clé de fermeture. - [ ] Après le merge : `workflow_dispatch` d'`audit.yml` sur `main`, run vert cité, puis fermeture de #484 à la main. ## Complexité Simple. Niveau normal selon `REVIEW.md` (montée de version d'un paquet déjà présent dans le lock, décision de Max du 2026-10-17). Si la PR avec #483 touche `package.json`, voir le niveau que fixe `REVIEW.md` pour ce fichier. ## Analyse (`/analyze`, 2026-10-20, `main` `6e8e157`) Prémisse confirmée point par point ; le corps ci-dessus reste la référence. Décision de Max (2026-10-20, réponse à `/analyze`) : **PR seule sur `main`, dès que possible, indépendante de la pile `planned-2026-10-16-lot-v018`** (aucun fichier commun : #469 touche `check-rust.yml`, pas le lock). ### Sonde (worktree détaché, retiré ensuite) - Reproduit avec le binaire de la CI (cargo-audit 0.22.2, lancé depuis la racine, `.cargo/audit.toml` lu) : `error: 2 vulnerabilities found!`, exit 1, 663 crates, 18 avertissements autorisés (les mêmes que le run 564). - `cargo update --manifest-path src-tauri/Cargo.toml -p rustls-webpki -p webpki-root-certs` : 8 lignes du lock (version et checksum des deux paquets), rien d'autre. Index crates.io comparé : ni 0.103.16 ni 1.0.10 ne change ses dépendances, ses features ou son MSRV. `cargo metadata --locked` passe. - Audit après bump : exit 0, 663 crates, mêmes 18 avertissements. Garde `windows-sys` rejouée sur le lock modifié : 9 contrôles, exit 0. ### Atteignabilité, nuance par cible - `rustls-webpki` est compilé pour Linux et Windows. Sous Linux, c'est lui qui valide la chaîne (`rustls-platform-verifier` 0.6.2, `src/verification/others.rs`, racines système) : RUSTSEC-2026-0382 est atteignable sur le chemin réel de l'updater Linux. Sous Windows, la validation passe par l'API système (`windows.rs` n'appelle pas webpki) : le crate est dans le graphe, pas sur le chemin. - `webpki-root-certs` n'est une dépendance de `rustls-platform-verifier` que pour `wasm32` (et en dev-dependency) : jamais compilé pour nos cibles. Il serait éligible à une suppression selon la règle 1 de l'ADR 0018, mais le bump le corrige au même prix : aucune entrée dans `.cargo/audit.toml`. ### Travail à faire - [ ] `cargo update --manifest-path src-tauri/Cargo.toml -p rustls-webpki -p webpki-root-certs` (0.103.16 et 1.0.10). - [ ] En local : garde `windows-sys` (extraire le `run:` de l'étape de `check-rust.yml`), `cargo audit` avec le binaire de la CI (rouge avant, vert après), `cargo check --locked` et `cargo test --locked`. - [ ] Une puce Sécurité sous `[Unreleased]` dans `CHANGELOG.md` et `CHANGELOG.fr.md`, « aucun changement » restreint au code de l'app (comme `9abf474` et #447). - [ ] PR en `Refs #484` (critère post-merge, fermeture à la main), niveau normal selon `REVIEW.md` (deux paquets déjà présents, aucun ajouté ni retiré). - [ ] Après le merge : `workflow_dispatch` d'`audit.yml` sur `main`, run cité ici, puis fermeture. ### Fichiers concernés - `src-tauri/Cargo.lock` — seul fichier de code touché. - `CHANGELOG.md`, `CHANGELOG.fr.md` — entrée Sécurité. ### Surface de test - Aucun test ne porte sur ces crates ; les preuves sont `cargo audit` et la garde `windows-sys`. - Mutation inverse pour la revue : remettre 0.103.15 dans le lock, l'audit redevient rouge sur 0382. - La prochaine release déroule le cycle réel de mise à jour (critère 4 ci-dessus, règle de #463). ### Complexité Simple. Prochaine étape : `/fix-issue 484`.

maximus added the

status:triage

type:security

source:human

labels 2026-10-21 00:14:10 +00:00

maximus referenced this issue

2026-10-21 00:17:25 +00:00

fix: follow-ups of the lot-v018 stack reviews #482

maximus referenced this issue

2026-10-21 00:17:36 +00:00

fix: follow-ups of the lot-v018 stack reviews #482

maximus referenced this issue

2026-10-21 00:23:20 +00:00

fix: follow-ups of the lot-v018 stack reviews #482

maximus added

status:ready

and removed

status:triage

labels 2026-10-21 00:42:50 +00:00

maximus referenced this issue

2026-10-21 00:42:50 +00:00

[security] deps: vulnerability in vite (high) #483

maximus commented

2026-10-21 01:02:50 +00:00

Author

Owner

En cours dans la session Coupure d'API (/fix-issue 484, 2026-10-20). Décision de Max, à l'instant, qui tranche entre les deux sections « Analyse » du corps : une seule PR pour #484 et #483, depuis main (45d8493), deux commits, Refs #484 et Resolves #483. Ne pas ouvrir de seconde branche pour ces deux issues.

**En cours dans la session `Coupure d'API`** (`/fix-issue 484`, 2026-10-20). Décision de Max, à l'instant, qui tranche entre les deux sections « Analyse » du corps : une seule PR pour #484 et #483, depuis `main` (`45d8493`), deux commits, `Refs #484` et `Resolves #483`. Ne pas ouvrir de seconde branche pour ces deux issues.

maximus added

status:in-progress

and removed

status:ready

labels 2026-10-21 01:02:51 +00:00

maximus referenced this issue

2026-10-21 01:02:51 +00:00

[security] deps: vulnerability in vite (high) #483

maximus commented

2026-10-21 01:04:33 +00:00

Author

Owner

Complément à l'analyse : la pile planned-2026-10-16-lot-v018 (PR #468 à #475, puis #482) a été mergée le 2026-10-21 à 00:30 UTC, avant l'écriture de l'analyse (main 6e8e157 → 45d8493). src-tauri/Cargo.lock, Cargo.toml et .cargo/ sont identiques entre les deux commits : la sonde et les huit lignes du bump restent exactes. La question de l'ordre (PR seule ou après la pile) ne se pose plus ; la PR du bump passera sous le --locked de check-rust posé par #469 (#449), ce que cargo metadata --locked a déjà validé sur le lock modifié.

Complément à l'analyse : la pile `planned-2026-10-16-lot-v018` (PR #468 à #475, puis #482) a été mergée le 2026-10-21 à 00:30 UTC, avant l'écriture de l'analyse (`main` `6e8e157` → `45d8493`). `src-tauri/Cargo.lock`, `Cargo.toml` et `.cargo/` sont identiques entre les deux commits : la sonde et les huit lignes du bump restent exactes. La question de l'ordre (PR seule ou après la pile) ne se pose plus ; la PR du bump passera sous le `--locked` de `check-rust` posé par #469 (#449), ce que `cargo metadata --locked` a déjà validé sur le lock modifié.

maximus referenced this issue from a commit

2026-10-21 01:33:51 +00:00

fix(deps): rustls-webpki 0.103.16 and webpki-root-certs 1.0.10 (RUSTSEC-2026-0382, RUSTSEC-2026-0383)

maximus referenced this issue

2026-10-21 01:34:39 +00:00

fix(deps): rustls-webpki 0.103.16, webpki-root-certs 1.0.10 and vite 6.4.4 (RUSTSEC-2026-0382/0383, launch-editor) #485

maximus referenced this issue

2026-10-21 01:41:39 +00:00

fix(deps): rustls-webpki 0.103.16, webpki-root-certs 1.0.10 and vite 6.4.4 (RUSTSEC-2026-0382/0383, launch-editor) #485

maximus added

status:review

and removed