deps: declencheur de retrait pour la suppression rsa (RUSTSEC-2023-0071) dans .cargo/audit.toml #319

New issue

Open

opened 2026-07-28 01:29:38 +00:00 by maximus · 0 comments

maximus commented

2026-07-28 01:29:38 +00:00

Owner

Apres #312, RUSTSEC-2023-0071 (rsa 0.9.10, Marvin) est la seule entree restante de .cargo/audit.toml — et la seule sans issue de suivi portant sa condition de retrait.

ADR 0018 pose pourtant la regle explicitement : le garde-fou de check-rust.yml attrape la suppression devenue injustifiee (le crate redevient atteignable), mais rien ne signale la suppression devenue inutile (un correctif parait) — c'est le role d'une issue de suivi. #312 jouait ce role pour quick-xml, et l'a bien joue : le declencheur avait saute sans que personne le remarque.

Sans cette issue, la liste est desormais 100 % non suivie de ce cote.

Pourquoi elle est acceptee

Aucun correctif publie : la liste patched de l'advisory est vide. C'est ce qui rend la suppression inevitable plutot que choisie.
Inatteignable : seul parent dans le lock = sqlx-mysql, artefact du graphe multi-backend de sqlx ; le projet parle a SQLite via tauri-plugin-sql. cargo tree -i rsa --target all ne retourne rien.

Condition de fermeture

L'un ou l'autre :

Une version corrigee de rsa parait (surveiller RUSTSEC-2023-0071) → cargo update -p rsa, retirer l'entree, retirer rsa de CRATES dans check-rust.yml.
sqlx sort rsa de son graphe → l'entree devient sans objet, meme retrait.

Dans les deux cas, verifier ensuite que cargo audit --file src-tauri/Cargo.lock lance depuis la racine du depot reste a 0. Lance depuis src-tauri/, il ne lit pas .cargo/audit.toml et rapportera l'advisory — ce n'est pas une regression.

Si l'entree part, .cargo/audit.toml devient vide : le supprimer et retirer l'etape de garde plutot que de laisser une coquille.

Releve pendant #312.

Apres #312, `RUSTSEC-2023-0071` (`rsa` 0.9.10, Marvin) est la **seule** entree restante de `.cargo/audit.toml` — et la seule sans issue de suivi portant sa condition de retrait. [ADR 0018](docs/adr/0018-suppression-advisories-non-atteignables.md) pose pourtant la regle explicitement : le garde-fou de `check-rust.yml` attrape la suppression devenue **injustifiee** (le crate redevient atteignable), mais rien ne signale la suppression devenue **inutile** (un correctif parait) — c'est le role d'une issue de suivi. #312 jouait ce role pour `quick-xml`, et l'a bien joue : le declencheur avait saute sans que personne le remarque. Sans cette issue, la liste est desormais **100 % non suivie** de ce cote. ## Pourquoi elle est acceptee - **Aucun correctif publie** : la liste `patched` de l'advisory est vide. C'est ce qui rend la suppression inevitable plutot que choisie. - **Inatteignable** : seul parent dans le lock = `sqlx-mysql`, artefact du graphe multi-backend de sqlx ; le projet parle a SQLite via `tauri-plugin-sql`. `cargo tree -i rsa --target all` ne retourne rien. ## Condition de fermeture L'un ou l'autre : 1. Une version corrigee de `rsa` parait (surveiller [RUSTSEC-2023-0071](https://rustsec.org/advisories/RUSTSEC-2023-0071)) → `cargo update -p rsa`, retirer l'entree, retirer `rsa` de `CRATES` dans `check-rust.yml`. 2. `sqlx` sort `rsa` de son graphe → l'entree devient sans objet, meme retrait. Dans les deux cas, verifier ensuite que `cargo audit --file src-tauri/Cargo.lock` **lance depuis la racine du depot** reste a 0. Lance depuis `src-tauri/`, il ne lit pas `.cargo/audit.toml` et rapportera l'advisory — ce n'est pas une regression. Si l'entree part, `.cargo/audit.toml` devient vide : le supprimer et retirer l'etape de garde plutot que de laisser une coquille. Releve pendant #312.