maximus/Simpl-Resultat
1
0
Fork 0
Code Issues 19 Pull requests 8 Projects Releases 34 Packages Wiki Activity Actions

fix(deps): update h2 to 0.4.19 to clear RUSTSEC-2026-0258 #344

Merged
maximus merged 1 commit from issue-343-h2-rustsec-2026-0258 into main 2026-09-04 20:08:19 +00:00
Conversation 2 Commits 1 Files changed 3 +4 -2
maximus commented 2026-09-04 19:44:59 +00:00
Owner
Copy link

Resolves #343

audit.yml échouait tous les matins depuis le 2026-08-19 — 17 runs consécutifs (375 → 391), dernier vert le 08-18. Aucun push sur main dans l'intervalle : RUSTSEC-2026-0258 a été publiée le 08-17 et a atteint l'advisory-db deux jours plus tard. Les frames HTTP/2 DATA vides sont mises en file sans limite ; sur un flux non drainé la mémoire croît sans borne et la longueur peut déborder en panique. Déni de service, sévérité faible, corrigé en 0.4.16.

Ce que fait la PR

h2 0.4.13 → 0.4.19 dans le fichier de verrouillage. Cargo.toml intouché, 666 paquets avant et après, .cargo/audit.toml et le garde-fou de check-rust.yml inchangés.

Pourquoi corriger plutôt que supprimer

h2 est atteignable sur les deux cibles livrées — vérifié par triple explicite, jamais --target all, selon l'ADR 0018 :

h2 → 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, le second celui des appels de licence, d'authentification, de cours et de rétroaction. Correctif publié + crate atteignable = règle 1 de .cargo/audit.toml, donc on corrige.

Pourquoi le diff du lock ne fait que 2 lignes

cargo update -p h2 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 précisément ce que #321 a défait délibérément 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 la re-résolution s'appliquer régresserait cette décision en silence, trois semaines après l'avoir prise.

La strophe h2 est donc appliquée seule. cargo metadata --locked accepte le résultat sans le réécrire, ce qui prouve que le lock reste cohérent — h2 0.4.19 n'a pas changé son propre jeu de dépendances.

À revérifier en revue si vous voulez : git diff main -- src-tauri/Cargo.lock doit montrer exactement 2 lignes modifiées, toutes deux dans la strophe h2.

Vérifications

Vérification Résultat
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, 0 vulnérabilité
Contrôle : même binaire sur le lock d'avant exit 1, error: 1 vulnerability found!
Garde-fou rejoué à la main rsa absent des 2 cibles, canari tar trouvé

Le contrôle sur l'ancien lock compte : il montre que l'outil local reproduit le rouge de la CI, donc que le vert obtenu est un vrai changement d'état et pas un outil configuré autrement.

Suites

  • La release v0.15.0 peut suivre. Ce correctif touche le chemin de l'updater, il a sa place dans la release plutôt qu'après — au même titre que rustls-webpki et tar au cycle précédent.
  • #319 (déclencheur de retrait pour rsa) et #317 (react-router v8) restent ouvertes, sans lien avec celle-ci.
Resolves #343 `audit.yml` échouait tous les matins depuis le **2026-08-19** — 17 runs consécutifs (375 → 391), dernier vert le 08-18. Aucun push sur `main` dans l'intervalle : [RUSTSEC-2026-0258](https://rustsec.org/advisories/RUSTSEC-2026-0258) a été publiée le 08-17 et a atteint l'advisory-db deux jours plus tard. Les frames HTTP/2 `DATA` vides sont mises en file sans limite ; sur un flux non drainé la mémoire croît sans borne et la longueur peut déborder en panique. Déni de service, sévérité faible, corrigé en 0.4.16. ## Ce que fait la PR `h2` 0.4.13 → **0.4.19** dans le fichier de verrouillage. `Cargo.toml` intouché, 666 paquets avant et après, `.cargo/audit.toml` et le garde-fou de `check-rust.yml` inchangés. ## Pourquoi corriger plutôt que supprimer `h2` est atteignable sur **les deux cibles livrées** — vérifié par triple explicite, jamais `--target all`, selon l'[ADR 0018](docs/adr/0018-suppression-advisories-non-atteignables.md) : ``` h2 → 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, le second celui des appels de licence, d'authentification, de cours et de rétroaction. Correctif publié + crate atteignable = règle 1 de `.cargo/audit.toml`, donc on corrige. ## Pourquoi le diff du lock ne fait que 2 lignes `cargo update -p h2` 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 précisément ce que **#321 a défait délibérément** 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 la re-résolution s'appliquer régresserait cette décision en silence, trois semaines après l'avoir prise. La strophe `h2` est donc appliquée seule. `cargo metadata --locked` accepte le résultat **sans le réécrire**, ce qui prouve que le lock reste cohérent — `h2 0.4.19` n'a pas changé son propre jeu de dépendances. À revérifier en revue si vous voulez : `git diff main -- src-tauri/Cargo.lock` doit montrer exactement 2 lignes modifiées, toutes deux dans la strophe `h2`. ## Vérifications | Vérification | Résultat | |---|---| | `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, 0 vulnérabilité | | Contrôle : même binaire sur le lock d'avant | exit 1, `error: 1 vulnerability found!` | | Garde-fou rejoué à la main | `rsa` absent des 2 cibles, canari `tar` trouvé | Le contrôle sur l'ancien lock compte : il montre que l'outil local reproduit le rouge de la CI, donc que le vert obtenu est un vrai changement d'état et pas un outil configuré autrement. ## Suites - La release `v0.15.0` peut suivre. Ce correctif touche le chemin de l'updater, il a sa place **dans** la release plutôt qu'après — au même titre que `rustls-webpki` et `tar` au cycle précédent. - #319 (déclencheur de retrait pour `rsa`) et #317 (`react-router` v8) restent ouvertes, sans lien avec celle-ci.
maximus added the
status:review
type:security
source:analyste
 labels 2026-09-04 19:44:59 +00:00
maximus added 1 commit 2026-09-04 19:45:00 +00:00
fix(deps): update h2 to 0.4.19 to clear RUSTSEC-2026-0258
All checks were successful
PR Check — Rust / rust (pull_request) Successful in 10m1s
Details
5154c5276b 
The daily audit has failed every morning since 2026-08-19 (runs 375 to
391, 17 consecutive reds). Nothing was pushed to main in that window:
RUSTSEC-2026-0258 was published on 08-17 and reached the advisory-db two
days later. Empty HTTP/2 DATA frames are queued without limit, so an
undrained stream grows memory without bound and can overflow into a
panic. Low severity, denial of service, patched in 0.4.16.

h2 is reachable on both shipped targets, checked per triple rather than
with --target all: through tauri-plugin-updater -> reqwest 0.13.2 for
the automatic updater, and through the app's own reqwest 0.12.28 for the
licence, auth, price and feedback calls. A published fix plus a
reachable crate is rule 1 of .cargo/audit.toml, so this gets fixed
rather than suppressed; the suppression list and the check-rust guard
are both untouched.

Only the h2 stanza moves. Running `cargo update -p h2` also re-resolves
seven windows-sys pointers from 0.61.2 down to 0.48/0.52/0.59, which is
what #321 deliberately reverted three weeks ago after proving 0.61.2 is
the state of the v0.14.0 tag and therefore the only windows-sys
configuration that has actually compiled under Windows. Letting the
re-resolution stand would regress that decision silently, so the bump is
applied to the lockfile as a two-line change instead. `cargo metadata
--locked` accepts the result without rewriting it.

Verified: cargo check and cargo test --all-targets green (111 passed),
cargo-audit 0.22.2 exits 0 with the same 22 allowed warnings as before,
and the same binary still exits 1 on the previous lockfile — so the
green is a real change of state, not a differently configured tool.

Resolves #343

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RhPofpLQTZUbkVYR3i2e2D
maximus commented 2026-09-04 19:56:52 +00:00
Author
Owner
Copy link

CI verte — run 392, étapes vérifiées dans le log

L'étape cargo audit de check-rust.yml est continue-on-error: true, donc un job vert ne prouve rien à lui seul sur l'audit. Trace lue dans le log plutôt que déduite :

Loaded 1239 security advisories (from /root/.cargo/advisory-db)
Scanning src-tauri/Cargo.lock for vulnerabilities (666 crate dependencies)
warning: 22 allowed warnings found

Aucune ligne error: dans tout le log, et la seule occurrence de « vulnerabilities » est celle du scan. Les 22 warnings autorisés sont le même compte qu'avant — rien d'autre n'a bougé.

Garde-fou des suppressions, exécuté et tracé :

ok: rsa absent from x86_64-unknown-linux-gnu
ok: rsa absent from x86_64-pc-windows-msvc
ok: canary 'tar' found for x86_64-unknown-linux-gnu
Suppression guard: 2 checks, exit 0

Compilation et tests : cargo check terminé en 3m16, cargo test en 3m44, 111 passed, 0 failed. h2 v0.4.19 bien compilé (Downloaded / Checking / Compiling).

check-frontend ne s'est pas déclenché, ce qui est le comportement attendu : les trois fichiers modifiés sont src-tauri/** et *.md, tous deux dans sa paths-ignore.

Vérification indépendante de la décision windows-sys

Le choix de n'appliquer que la strophe h2 repose sur le fait que 0.61.2 est l'état du tag v0.14.0. Retracé depuis la source plutôt que repris de la note de #321, crate par crate contre git show v0.14.0:src-tauri/Cargo.lock :

crate v0.14.0 cette branche
colored 0.61.2 0.61.2
dirs-sys 0.61.2 0.61.2
errno 0.61.2 0.61.2
rustix 0.61.2 0.61.2
rustls-platform-verifier 0.61.2 0.61.2
tempfile 0.61.2 0.61.2
winapi-util 0.61.2 0.61.2

Les sept concordent. La branche préserve donc exactement la configuration windows-sys qui a compilé sous Windows pour la v0.14.0, et le seul écart avec main reste les deux lignes de h2.

## CI verte — run 392, étapes vérifiées dans le log L'étape `cargo audit` de `check-rust.yml` est `continue-on-error: true`, donc un job vert ne prouve rien à lui seul sur l'audit. Trace lue dans le log plutôt que déduite : ``` Loaded 1239 security advisories (from /root/.cargo/advisory-db) Scanning src-tauri/Cargo.lock for vulnerabilities (666 crate dependencies) warning: 22 allowed warnings found ``` Aucune ligne `error:` dans tout le log, et la seule occurrence de « vulnerabilities » est celle du scan. Les 22 warnings autorisés sont le même compte qu'avant — rien d'autre n'a bougé. Garde-fou des suppressions, exécuté et tracé : ``` ok: rsa absent from x86_64-unknown-linux-gnu ok: rsa absent from x86_64-pc-windows-msvc ok: canary 'tar' found for x86_64-unknown-linux-gnu Suppression guard: 2 checks, exit 0 ``` Compilation et tests : `cargo check` terminé en 3m16, `cargo test` en 3m44, **111 passed, 0 failed**. `h2 v0.4.19` bien compilé (`Downloaded` / `Checking` / `Compiling`). `check-frontend` ne s'est pas déclenché, ce qui est le comportement attendu : les trois fichiers modifiés sont `src-tauri/**` et `*.md`, tous deux dans sa `paths-ignore`. ## Vérification indépendante de la décision `windows-sys` Le choix de n'appliquer que la strophe `h2` repose sur le fait que `0.61.2` est l'état du tag `v0.14.0`. Retracé depuis la source plutôt que repris de la note de #321, crate par crate contre `git show v0.14.0:src-tauri/Cargo.lock` : | crate | v0.14.0 | cette branche | |---|---|---| | `colored` | 0.61.2 | 0.61.2 | | `dirs-sys` | 0.61.2 | 0.61.2 | | `errno` | 0.61.2 | 0.61.2 | | `rustix` | 0.61.2 | 0.61.2 | | `rustls-platform-verifier` | 0.61.2 | 0.61.2 | | `tempfile` | 0.61.2 | 0.61.2 | | `winapi-util` | 0.61.2 | 0.61.2 | Les sept concordent. La branche préserve donc exactement la configuration `windows-sys` qui a compilé sous Windows pour la v0.14.0, et le seul écart avec `main` reste les deux lignes de `h2`.
maximus commented 2026-09-04 20:07:02 +00:00
Author
Owner
Copy link

Revue adversariale — APPROVE

Correctif de dépendance à 4 lignes, dont 2 dans le fichier de verrouillage. J'ai retracé chaque affirmation depuis la source plutôt que de la relayer. Tout tient.

Ce qu'un lock édité à la main peut casser en silence — vérifié

Appliquer une strophe seule plutôt que laisser cargo update re-résoudre est le bon arbitrage ici, mais il déplace le risque : la strophe est écrite à la main, donc le checksum et la liste de dépendances ne sont plus garantis par l'outil. Les deux sont bons.

Contrôle Méthode Résultat
Checksum réel sha256sum du .crate en cache ef8e5e5a…bc16 — identique à la strophe
Jeu de dépendances diff des tables [dependencies.*] 0.4.13 vs 0.4.19 identique — les 11 entrées de la strophe restent exactes
Bornes de version diff des version = déclarées une seule bouge : http ^1 → ^1.1
Cohérence du lock cargo metadata --locked + git status exit 0, lock non réécrit

Le seul écart réel est la borne http, qui se resserre de ^1 à ^1.1 en 0.4.19. C'est précisément le genre de changement qui invalide un lock épinglé à la main — ici il est satisfait, le lock porte http 1.4.0 (l. 1954-1955). MSRV et edition inchangés (1.63 / 2021).

À noter : cargo metadata --locked prouve la cohérence du graphe, pas le checksum — celui-ci n'est vérifié qu'au téléchargement. La preuve du checksum vient donc d'ailleurs : le log du run 392 montre Downloaded h2 v0.4.19 puis Checking puis Compiling, ce qui n'arrive pas si la somme ne correspond pas.

Le contrôle « avant/après » est réel, pas déclaratif

La règle vaut pour un correctif comme pour un test : un vert ne prouve rien sans le rouge correspondant. J'ai récupéré les deux logs.

  • Run 391 (dernier rouge, 09-04 06:00Z) : Crate: h2 / Version: 0.4.13 / ID: RUSTSEC-2026-0258 / Solution: Upgrade to >=0.4.16, sur 666 crates.
  • Run 392 (cette PR) : mêmes 666 crates, mêmes 22 allowed warnings, plus aucune ligne de vulnérabilité.

Warnings identiques des deux côtés (les atk, gdk, fxhash unmaintained) : le delta est donc exactement h2, rien d'autre n'a bougé dans le périmètre d'audit. Les 17 rouges consécutifs sont confirmés côté API (runs 380-391 tous en failure, event schedule).

L'advisory locale tranche la borne sans ambiguïté — patched = [">= 0.4.16"], aucune autre plage affectée, une seule strophe h2 dans le lock. 0.4.19 satisfait.

Atteignabilité — les deux chemins annoncés existent bien

Vérifié par triple explicite conformément à l'ADR 0018, sur les deux cibles livrées :

h2 v0.4.19
├── hyper 1.8.1 → hyper-rustls → reqwest 0.13.2 → tauri-plugin-updater → simpl-result
│               → hyper-tls    → reqwest 0.12.28 → simpl-result
└── reqwest 0.12.28 (direct)

Identique sur x86_64-unknown-linux-gnu et x86_64-pc-windows-msvc. Correctif publié + crate atteignable = règle 1, donc corriger et non supprimer : .cargo/audit.toml et le garde-fou sont bien intouchés (CRATES="rsa", Suppression guard: 2 checks, exit 0 tracé au run 392).

La claim user-facing du changelog est elle aussi exacte : reqwest est déclaré en dépendance directe (Cargo.toml:43) et consommé par exactement quatre modules — license_commands, auth_commands, balance_commands (/v1/prices) et feedback_commands. Soit « licence, authentification, cours et rétroaction », mot pour mot.

La dérive windows-sys est bien évitée

git diff ne montre aucun mouvement windows-sys : la décision de #321 (remontée à 0.61.2, seul état ayant réellement compilé sous Windows au tag v0.14.0) est préservée. C'est le bon choix, et c'est ce qui justifie la strophe appliquée seule.

Effet de bord utile : le glob src-tauri/** est enfin prouvé

STATE.md porte depuis #232 un point ouvert — « Reste non prouvé — le glob src-tauri/** lui-même », avec un mode d'échec silencieux (job de test jamais déclenché, rien pour le dire). Cette PR est le cas test isolé attendu : elle ne touche que src-tauri/Cargo.lock et deux *.md.

check-rust a bien tourné (run 392, cargo check + cargo test 111 passed), et check-frontend a été correctement sauté — ses trois fichiers matchent tous le paths-ignore (src-tauri/** et *.md). Le point de suivi peut être fermé.

Reste de la checklist

  • Commit : Resolves #343 présent dans le message de commit (vérifié en git log main..head, pas dans le corps de la PR), format conventionnel fix(deps):.
  • Changelog FR + EN symétriques, sous [Unreleased] → Security, à la suite des deux entrées d'advisories existantes. Les copies public/ sont gitignorées (.gitignore:49-51) et régénérées par syncChangelogs() — aucune péremption possible.
  • Aucun secret, aucune migration SQL, aucun .env. Pas de test ajouté, ce qui est correct : un bump de dépendance sans logique nouvelle n'a rien à tester au-delà de la suite existante.

Suggestion non bloquante — la contrainte windows-sys n'a pas de domicile durable

C'est la troisième fois que cette dérive se pose : #310 l'introduit, #321 la défait après vérification crate par crate, #344 l'évite à la main. Or grep -rn "windows-sys" hors Cargo.lock ne trouve la contrainte nulle part de durable — ni ADR, ni commentaire dans Cargo.toml, ni garde CI. Elle vit uniquement dans des messages de commit et la prose de STATE.md.

Le prochain cargo update -p <n'importe quoi> la régressera silencieusement, et le prochain à passer devra la redécouvrir — exactement la trajectoire des trois derniers cycles. Un commentaire dans Cargo.toml, une note dans l'ADR 0018, ou un garde CI comparant les strophes windows-sys au tag de référence donnerait à la décision un endroit où survivre. Hors périmètre de cette PR, à traiter comme un suivi.

Revue faite depuis la boucle principale, séquentiellement, sans fichier de travail partagé.

## Revue adversariale — APPROVE Correctif de dépendance à 4 lignes, dont 2 dans le fichier de verrouillage. J'ai retracé chaque affirmation depuis la source plutôt que de la relayer. **Tout tient.** ### Ce qu'un lock édité à la main peut casser en silence — vérifié Appliquer une strophe seule plutôt que laisser `cargo update` re-résoudre est le bon arbitrage ici, mais il déplace le risque : la strophe est écrite à la main, donc le checksum et la liste de dépendances ne sont plus garantis par l'outil. Les deux sont bons. | Contrôle | Méthode | Résultat | |---|---|---| | Checksum réel | `sha256sum` du `.crate` en cache | `ef8e5e5a…bc16` — **identique** à la strophe | | Jeu de dépendances | `diff` des tables `[dependencies.*]` 0.4.13 vs 0.4.19 | **identique** — les 11 entrées de la strophe restent exactes | | Bornes de version | `diff` des `version =` déclarées | **une seule bouge** : `http` `^1` → `^1.1` | | Cohérence du lock | `cargo metadata --locked` + `git status` | exit 0, **lock non réécrit** | Le seul écart réel est la borne `http`, qui se resserre de `^1` à `^1.1` en 0.4.19. C'est précisément le genre de changement qui invalide un lock épinglé à la main — ici il est satisfait, le lock porte `http 1.4.0` (l. 1954-1955). MSRV et edition inchangés (`1.63` / `2021`). À noter : `cargo metadata --locked` prouve la cohérence du graphe, **pas** le checksum — celui-ci n'est vérifié qu'au téléchargement. La preuve du checksum vient donc d'ailleurs : le log du run 392 montre `Downloaded h2 v0.4.19` puis `Checking` puis `Compiling`, ce qui n'arrive pas si la somme ne correspond pas. ### Le contrôle « avant/après » est réel, pas déclaratif La règle vaut pour un correctif comme pour un test : un vert ne prouve rien sans le rouge correspondant. J'ai récupéré les deux logs. - **Run 391** (dernier rouge, 09-04 06:00Z) : `Crate: h2 / Version: 0.4.13 / ID: RUSTSEC-2026-0258 / Solution: Upgrade to >=0.4.16`, sur 666 crates. - **Run 392** (cette PR) : mêmes **666 crates**, mêmes **22 allowed warnings**, plus aucune ligne de vulnérabilité. Warnings identiques des deux côtés (les `atk`, `gdk`, `fxhash` unmaintained) : le delta est donc **exactement** `h2`, rien d'autre n'a bougé dans le périmètre d'audit. Les 17 rouges consécutifs sont confirmés côté API (runs 380-391 tous en `failure`, event `schedule`). L'advisory locale tranche la borne sans ambiguïté — `patched = [">= 0.4.16"]`, aucune autre plage affectée, une seule strophe `h2` dans le lock. 0.4.19 satisfait. ### Atteignabilité — les deux chemins annoncés existent bien Vérifié par triple explicite conformément à l'ADR 0018, **sur les deux cibles livrées** : ``` h2 v0.4.19 ├── hyper 1.8.1 → hyper-rustls → reqwest 0.13.2 → tauri-plugin-updater → simpl-result │ → hyper-tls → reqwest 0.12.28 → simpl-result └── reqwest 0.12.28 (direct) ``` Identique sur `x86_64-unknown-linux-gnu` et `x86_64-pc-windows-msvc`. Correctif publié + crate atteignable = règle 1, donc corriger et non supprimer : `.cargo/audit.toml` et le garde-fou sont bien intouchés (`CRATES="rsa"`, `Suppression guard: 2 checks, exit 0` tracé au run 392). La claim user-facing du changelog est elle aussi exacte : `reqwest` est déclaré en dépendance directe (`Cargo.toml:43`) et consommé par exactement quatre modules — `license_commands`, `auth_commands`, `balance_commands` (`/v1/prices`) et `feedback_commands`. Soit « licence, authentification, cours et rétroaction », mot pour mot. ### La dérive `windows-sys` est bien évitée `git diff` ne montre **aucun** mouvement `windows-sys` : la décision de #321 (remontée à `0.61.2`, seul état ayant réellement compilé sous Windows au tag `v0.14.0`) est préservée. C'est le bon choix, et c'est ce qui justifie la strophe appliquée seule. ### Effet de bord utile : le glob `src-tauri/**` est enfin prouvé STATE.md porte depuis #232 un point ouvert — « **Reste non prouvé — le glob `src-tauri/**` lui-même** », avec un mode d'échec silencieux (job de test jamais déclenché, rien pour le dire). Cette PR est le cas test isolé attendu : elle ne touche que `src-tauri/Cargo.lock` et deux `*.md`. `check-rust` **a bien tourné** (run 392, `cargo check` + `cargo test` **111 passed**), et `check-frontend` a été **correctement sauté** — ses trois fichiers matchent tous le `paths-ignore` (`src-tauri/**` et `*.md`). Le point de suivi peut être fermé. ### Reste de la checklist - Commit : `Resolves #343` présent **dans le message de commit** (vérifié en `git log main..head`, pas dans le corps de la PR), format conventionnel `fix(deps):`. - Changelog FR + EN symétriques, sous `[Unreleased]` → `Security`, à la suite des deux entrées d'advisories existantes. Les copies `public/` sont gitignorées (`.gitignore:49-51`) et régénérées par `syncChangelogs()` — aucune péremption possible. - Aucun secret, aucune migration SQL, aucun `.env`. Pas de test ajouté, ce qui est correct : un bump de dépendance sans logique nouvelle n'a rien à tester au-delà de la suite existante. --- ### Suggestion non bloquante — la contrainte `windows-sys` n'a pas de domicile durable C'est la **troisième fois** que cette dérive se pose : #310 l'introduit, #321 la défait après vérification crate par crate, #344 l'évite à la main. Or `grep -rn "windows-sys"` hors `Cargo.lock` ne trouve la contrainte **nulle part de durable** — ni ADR, ni commentaire dans `Cargo.toml`, ni garde CI. Elle vit uniquement dans des messages de commit et la prose de STATE.md. Le prochain `cargo update -p <n'importe quoi>` la régressera silencieusement, et le prochain à passer devra la redécouvrir — exactement la trajectoire des trois derniers cycles. Un commentaire dans `Cargo.toml`, une note dans l'ADR 0018, ou un garde CI comparant les strophes `windows-sys` au tag de référence donnerait à la décision un endroit où survivre. Hors périmètre de cette PR, à traiter comme un suivi. *Revue faite depuis la boucle principale, séquentiellement, sans fichier de travail partagé.*
maximus merged commit 5154c5276b into main 2026-09-04 20:08:19 +00:00
maximus deleted branch issue-343-h2-rustsec-2026-0258 2026-09-04 20:08:19 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
autopilot:pending-human

PR produced by /autopilot — awaits human review/merge

  
source:analyste

Créée par le Super-Analyste

  
source:defenseur

Créée par l Escouade Défenseur

  
source:human

Créée par un humain

  
source:medic

Créée par le Medic (auto-détection)

  
status:approved

PR approuvée, prête à merger

  
status:blocked

Bloquée (question, dépendance, clarification)

  
status:in-progress

Un agent (Medic/Dev) travaille dessus

  
status:needs-clarification

Issue blocked by ambiguity — Max needs to clarify before re-running autopilot

  
status:needs-fix

Reviewer demande des corrections

  
status:ready

Analysée et documentée, prête à prendre

  
status:review

PR créée, en attente du Reviewer

  
status:triage

Nouvelle issue, pas encore analysée

  
type:bug

Correction de bug → Medic

  
type:feature

Nouvelle fonctionnalité → Dev

  
type:infra

Config, CI/CD, déploiement → Dev

  
type:refactor

Refactoring / amélioration technique → Dev

  
type:schema

Modèle de données / migrations → Dev

  
type:security

Issue de sécurité → Medic ou Dev

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
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: maximus/Simpl-Resultat#344
No description provided.
Delete branch "issue-343-h2-rustsec-2026-0258"

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?