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

fix(deps): build the updater without its zip feature to clear RUSTSEC-2026-0367 to -0369 #459

Merged
maximus merged 1 commit from issue-455-updater-without-zip into main 2026-10-18 16:42:54 +00:00
Conversation 4 Commits 1 Files changed 9 +29 -47
maximus commented 2026-10-17 12:41:38 +00:00
Owner
Copy link

Refs #455

Retire zip 4.6.1 du graphe, et avec lui RUSTSEC-2026-0367 (7.3), -0368 et -0369 (9.1), qui rougissent audit.yml depuis le run 558 (2026-10-17 06:00 UTC) sans que le lock ait bougé. zip n'était compilé que pour Windows, par la feature par défaut zip de tauri-plugin-updater. Il n'est corrigé qu'en >= 9.0.0, et tauri-plugin-updater 2.14.0 exige toujours zip ^4 : aucun cargo update n'atteint le correctif. Analyse et décisions de Max (correctif, preuve Windows par cargo-xwin) dans #455.

Le changement

  • src-tauri/Cargo.toml : tauri-plugin-updater = { version = "2", default-features = false, features = ["rustls-tls"] }, avec un commentaire qui dit pourquoi, et quand rétablir la feature (createUpdaterArtifacts: "v1Compatible").
  • src-tauri/Cargo.lock : 33 lignes retirées. Paquets retirés : zip 4.6.1, arbitrary 1.4.2 et derive_arbitrary 1.4.2 (666 → 663), aucun ajouté ; la seule autre strophe touchée est celle de tauri-plugin-updater, qui perd "zip". tar reste dans le lock (dépendance macOS de l'updater) mais quitte les graphes Linux et Windows ; flate2 reste, tiré par tauri-codegen.
  • check-rust.yml : nouveau canari de la garde des suppressions (ci-dessous).
  • Docs : ADR 0018 (amendement daté, canari, Issues, Liens), architecture.md (table des plugins, section check-rust), qa-update-cycle.md (liste des dépendances, paragraphe « Non prouvé » réécrit sur ce que fait vraiment l'updater sans la feature), skill /release (même liste de dépendances), CHANGELOG (Security / Sécurité).

La feature zip ne sert qu'à décompresser des paquets de mise à jour archivés (.nsis.zip, .msi.zip, .AppImage.tar.gz), que seul createUpdaterArtifacts: "v1Compatible" produit. L'app est en createUpdaterArtifacts: true : l'installeur NSIS (.exe), le .deb et le .rpm sont servis tels quels, et la v0.17.1 ne publie rien d'autre.

Écart avec l'issue : le canari est webkit2gtk, pas tauri

tar était le canari de la garde, et il quitte le graphe Linux. L'analyse proposait tauri. Le contrôle du plan a relevé que tar était une dépendance conditionnelle de l'updater (cfg(target_os = "linux")) : le trouver prouvait aussi que cargo tree --target x86_64-unknown-linux-gnu résout les arêtes conditionnelles, propriété sur laquelle repose la règle 1 de l'ADR 0018. tauri est inconditionnel et ne prouverait que l'affichage de cargo tree. webkit2gtk, la webview Linux de Tauri (wry), garde la propriété : paquet unique dans le lock, présent sous Linux (arbre de 29 lignes) et absent sous Windows, et un build Linux de Tauri v2 ne peut pas le perdre.

Vérifications locales

Sur la branche, depuis la racine du dépôt, CARGO_TERM_COLOR=never. La CI ne rejoue ni les mutations du canari ni la vérification Windows.

Contrôle Commande Résultat
Audit, ancien lock (origin/main) cargo-audit audit --file <copie de l'ancien lock> (0.22.2, binaire de la CI) exit 1, RUSTSEC-2026-0367, -0368 et -0369 présents, 666 crates
Audit, nouveau lock cargo-audit audit --file src-tauri/Cargo.lock exit 0, 663 crates, 12 allowed warnings found, mêmes IDs qu'avant
Lock script par strophe sur l'ancien et le nouveau 3 paquets retirés, 0 ajouté, seule tauri-plugin-updater modifiée (- "zip")
Garde des suppressions étape extraite de check-rust.yml ok: canary 'webkit2gtk' found, 2 checks, exit 0
Mutation : canari interrogé = tar (dans le lock, hors du graphe Linux : rc 0, sortie vide) même étape exit 1
Mutation : canari interrogé = zip (hors du lock : rc 101) même étape exit 1
Garde windows-sys étape extraite de check-rust.yml 9 checks, exit 0
Linux cargo check --manifest-path src-tauri/Cargo.toml --locked --all-targets exit 0
Linux cargo test --manifest-path src-tauri/Cargo.toml --locked --all-targets 267 passed, 0 failed, 1 ignored
Windows, témoin origin/main cargo xwin check --manifest-path src-tauri/Cargo.toml --locked --target x86_64-pc-windows-msvc (cargo-xwin 0.23.1) exit 0, Compiling tauri-plugin-updater v2.10.0, Checking zip v4.6.1, Compiling simpl-result
Windows, branche même commande exit 0, Compiling tauri-plugin-updater v2.10.0, Compiling simpl-result, aucun zip

Pour les deux runs Windows, le dossier target était chaud, mais les artefacts Windows de tauri-plugin-updater (et de zip pour le témoin) ont été purgés avant chaque run : la recompilation de l'updater avec le nouveau jeu de features est visible dans le log.

check-rust doit tourner sur cette PR (src-tauri/** et le workflow) ; check-frontend doit être sauté (src-tauri/**, ce workflow, docs/**, .claude/** et les *.md de la racine sont dans sa liste d'exclusion).

Prochaine release

Pas de release corrective : aucun des trois avis n'est atteignable. Le cycle réel de mise à jour Windows de la prochaine release (docs/qa-update-cycle.md, §1), déjà dû pour #376 et #447, part de la v0.17.1 installée : téléchargement, vérification de signature et installation y sont faits par l'updater de la v0.17.1, encore compilé avec zip, et la nouvelle version n'exécute que le check() final. Le chemin d'installation sans zip ne tournera qu'à la mise à jour depuis la première release qui contient #455 vers la suivante. Ce cycle-là, dû même si cette release ne touche pas l'updater, sera la première preuve de bout en bout (revue 24757, suivi #463).

Post-merge checklist (hence Refs, not a closing keyword)

  • Hors de la fenêtre de 06:00 UTC : POST /api/v1/repos/maximus/simpl-resultat/actions/workflows/audit.yml/dispatches avec {"ref":"main"}, réponse 204 attendue.
  • Retrouver ce run workflow_dispatch sur le commit de merge, ou sur un commit ultérieur de main qui en descend si src-tauri/Cargo.lock et .cargo/audit.toml y sont identiques. Statut success exigé, puis lecture du log, codes ANSI retirés : version de cargo-audit installée, (663 crate dependencies), 18 allowed warnings found, aucune ligne error: N vulnerabilit…. 18 et non 12 : le run planifié 561 (2026-10-18, cargo-audit 0.22.2, 1338 avis chargés contre 1334 la veille) ajoute six avertissements unmaintained, RUSTSEC-2026-0370 à -0372 (zvariant, zbus_names, zvariant_derive, deux versions chacun), non bloquants. Si la version de cargo-audit ou la base d'avis a changé depuis, comparer les IDs des warnings à ceux du dernier run planifié plutôt que leur nombre.
  • Si ce run est rouge sur un avis paru après le merge et visant un autre crate : #455 reste ouverte, ou n'est fermée qu'avec l'accord de Max sur la preuve qu'aucun de RUSTSEC-2026-0367 à -0369 n'apparaît ; nouvelle issue pour le nouvel ID.
  • #455 est fermée à la main une fois ce run vert, avec le numéro du run, les comptes et la condition de réouverture (un des trois IDs qui réapparaît dans audit.yml).
  • Synchronisation de STATE.md : retrait du blocker zip. Dans « Vérifications dues à la prochaine release », le cycle Windows reste dû pour #376 et #447, sans valeur de preuve pour l'updater sans zip. Ajout, pour la release d'après, du cycle depuis la première version qui embarque #455 : c'est la première preuve de bout en bout de l'updater sans zip, due même si cette release ne touche pas l'updater.

🤖 Generated with Claude Code

Refs #455 Retire `zip` 4.6.1 du graphe, et avec lui RUSTSEC-2026-0367 (7.3), -0368 et -0369 (9.1), qui rougissent `audit.yml` depuis le run 558 (2026-10-17 06:00 UTC) sans que le lock ait bougé. `zip` n'était compilé que pour Windows, par la feature par défaut `zip` de `tauri-plugin-updater`. Il n'est corrigé qu'en `>= 9.0.0`, et `tauri-plugin-updater` 2.14.0 exige toujours `zip ^4` : aucun `cargo update` n'atteint le correctif. Analyse et décisions de Max (correctif, preuve Windows par `cargo-xwin`) dans #455. ## Le changement - `src-tauri/Cargo.toml` : `tauri-plugin-updater = { version = "2", default-features = false, features = ["rustls-tls"] }`, avec un commentaire qui dit pourquoi, et quand rétablir la feature (`createUpdaterArtifacts: "v1Compatible"`). - `src-tauri/Cargo.lock` : 33 lignes retirées. Paquets retirés : `zip` 4.6.1, `arbitrary` 1.4.2 et `derive_arbitrary` 1.4.2 (666 → 663), aucun ajouté ; la seule autre strophe touchée est celle de `tauri-plugin-updater`, qui perd `"zip"`. `tar` reste dans le lock (dépendance macOS de l'updater) mais quitte les graphes Linux et Windows ; `flate2` reste, tiré par `tauri-codegen`. - `check-rust.yml` : nouveau canari de la garde des suppressions (ci-dessous). - Docs : ADR 0018 (amendement daté, canari, Issues, Liens), `architecture.md` (table des plugins, section `check-rust`), `qa-update-cycle.md` (liste des dépendances, paragraphe « Non prouvé » réécrit sur ce que fait vraiment l'updater sans la feature), skill `/release` (même liste de dépendances), CHANGELOG (Security / Sécurité). La feature `zip` ne sert qu'à décompresser des paquets de mise à jour archivés (`.nsis.zip`, `.msi.zip`, `.AppImage.tar.gz`), que seul `createUpdaterArtifacts: "v1Compatible"` produit. L'app est en `createUpdaterArtifacts: true` : l'installeur NSIS (`.exe`), le `.deb` et le `.rpm` sont servis tels quels, et la v0.17.1 ne publie rien d'autre. ## Écart avec l'issue : le canari est `webkit2gtk`, pas `tauri` `tar` était le canari de la garde, et il quitte le graphe Linux. L'analyse proposait `tauri`. Le contrôle du plan a relevé que `tar` était une dépendance **conditionnelle** de l'updater (`cfg(target_os = "linux")`) : le trouver prouvait aussi que `cargo tree --target x86_64-unknown-linux-gnu` résout les arêtes conditionnelles, propriété sur laquelle repose la règle 1 de l'ADR 0018. `tauri` est inconditionnel et ne prouverait que l'affichage de `cargo tree`. `webkit2gtk`, la webview Linux de Tauri (`wry`), garde la propriété : paquet unique dans le lock, présent sous Linux (arbre de 29 lignes) et absent sous Windows, et un build Linux de Tauri v2 ne peut pas le perdre. ## Vérifications locales Sur la branche, depuis la racine du dépôt, `CARGO_TERM_COLOR=never`. La CI ne rejoue ni les mutations du canari ni la vérification Windows. | Contrôle | Commande | Résultat | |---|---|---| | Audit, ancien lock (`origin/main`) | `cargo-audit audit --file <copie de l'ancien lock>` (0.22.2, binaire de la CI) | exit 1, RUSTSEC-2026-0367, -0368 et -0369 présents, 666 crates | | Audit, nouveau lock | `cargo-audit audit --file src-tauri/Cargo.lock` | exit 0, 663 crates, `12 allowed warnings found`, mêmes IDs qu'avant | | Lock | script par strophe sur l'ancien et le nouveau | 3 paquets retirés, 0 ajouté, seule `tauri-plugin-updater` modifiée (`- "zip"`) | | Garde des suppressions | étape extraite de `check-rust.yml` | `ok: canary 'webkit2gtk' found`, `2 checks, exit 0` | | Mutation : canari interrogé = `tar` (dans le lock, hors du graphe Linux : rc 0, sortie vide) | même étape | `exit 1` | | Mutation : canari interrogé = `zip` (hors du lock : rc 101) | même étape | `exit 1` | | Garde `windows-sys` | étape extraite de `check-rust.yml` | `9 checks, exit 0` | | Linux | `cargo check --manifest-path src-tauri/Cargo.toml --locked --all-targets` | exit 0 | | Linux | `cargo test --manifest-path src-tauri/Cargo.toml --locked --all-targets` | 267 passed, 0 failed, 1 ignored | | Windows, témoin `origin/main` | `cargo xwin check --manifest-path src-tauri/Cargo.toml --locked --target x86_64-pc-windows-msvc` (cargo-xwin 0.23.1) | exit 0, `Compiling tauri-plugin-updater v2.10.0`, `Checking zip v4.6.1`, `Compiling simpl-result` | | Windows, branche | même commande | exit 0, `Compiling tauri-plugin-updater v2.10.0`, `Compiling simpl-result`, aucun `zip` | Pour les deux runs Windows, le dossier `target` était chaud, mais les artefacts Windows de `tauri-plugin-updater` (et de `zip` pour le témoin) ont été purgés avant chaque run : la recompilation de l'updater avec le nouveau jeu de features est visible dans le log. `check-rust` doit tourner sur cette PR (`src-tauri/**` et le workflow) ; `check-frontend` doit être sauté (`src-tauri/**`, ce workflow, `docs/**`, `.claude/**` et les `*.md` de la racine sont dans sa liste d'exclusion). ## Prochaine release Pas de release corrective : aucun des trois avis n'est atteignable. Le cycle réel de mise à jour Windows de la prochaine release (`docs/qa-update-cycle.md`, §1), déjà dû pour #376 et #447, part de la v0.17.1 installée : téléchargement, vérification de signature et installation y sont faits par l'updater de la v0.17.1, encore compilé avec `zip`, et la nouvelle version n'exécute que le `check()` final. Le chemin d'installation sans `zip` ne tournera qu'à la mise à jour depuis la première release qui contient #455 vers la suivante. Ce cycle-là, dû même si cette release ne touche pas l'updater, sera la première preuve de bout en bout (revue 24757, suivi #463). ## Post-merge checklist (hence `Refs`, not a closing keyword) - [ ] Hors de la fenêtre de 06:00 UTC : `POST /api/v1/repos/maximus/simpl-resultat/actions/workflows/audit.yml/dispatches` avec `{"ref":"main"}`, réponse 204 attendue. - [ ] Retrouver ce run `workflow_dispatch` sur le commit de merge, ou sur un commit ultérieur de `main` qui en descend si `src-tauri/Cargo.lock` et `.cargo/audit.toml` y sont identiques. Statut `success` exigé, puis lecture du log, codes ANSI retirés : version de cargo-audit installée, `(663 crate dependencies)`, `18 allowed warnings found`, aucune ligne `error: N vulnerabilit…`. 18 et non 12 : le run planifié 561 (2026-10-18, cargo-audit 0.22.2, 1338 avis chargés contre 1334 la veille) ajoute six avertissements `unmaintained`, RUSTSEC-2026-0370 à -0372 (`zvariant`, `zbus_names`, `zvariant_derive`, deux versions chacun), non bloquants. Si la version de cargo-audit ou la base d'avis a changé depuis, comparer les IDs des warnings à ceux du dernier run planifié plutôt que leur nombre. - [ ] Si ce run est rouge sur un avis paru après le merge et visant un autre crate : #455 reste ouverte, ou n'est fermée qu'avec l'accord de Max sur la preuve qu'aucun de RUSTSEC-2026-0367 à -0369 n'apparaît ; nouvelle issue pour le nouvel ID. - [ ] #455 est fermée à la main une fois ce run vert, avec le numéro du run, les comptes et la condition de réouverture (un des trois IDs qui réapparaît dans `audit.yml`). - [ ] Synchronisation de `STATE.md` : retrait du blocker `zip`. Dans « Vérifications dues à la prochaine release », le cycle Windows reste dû pour #376 et #447, sans valeur de preuve pour l'updater sans `zip`. Ajout, pour la release d'après, du cycle depuis la première version qui embarque #455 : c'est la première preuve de bout en bout de l'updater sans `zip`, due même si cette release ne touche pas l'updater. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
maximus added 1 commit 2026-10-17 12:41:39 +00:00
fix(deps): build the updater without its zip feature
All checks were successful
PR Check — Rust / rust (pull_request) Successful in 9m55s
Details
85b7ef94c6 
Clears RUSTSEC-2026-0367, RUSTSEC-2026-0368 and RUSTSEC-2026-0369 on
zip 4.6.1, which turned the daily audit.yml red at run 558 (2026-10-17)
without any lockfile change. zip was compiled only for Windows, through
the default `zip` feature of tauri-plugin-updater 2.10.0. It is fixed
only in zip >= 9.0.0, and tauri-plugin-updater 2.14.0 still requires
zip ^4, so no cargo update can reach a fix.

That feature only unpacks archived update packages (.nsis.zip,
.msi.zip, .AppImage.tar.gz, produced by createUpdaterArtifacts
"v1Compatible"); this app ships createUpdaterArtifacts: true, whose
packages are never archives. The updater is now declared without its
default features, keeping rustls-tls. The lockfile loses zip, arbitrary
and derive_arbitrary (666 -> 663 packages, nothing added), and tar
leaves the Linux graph.

tar was the canary of the suppression guard in check-rust.yml. It is
replaced by webkit2gtk, Tauri's Linux webview, which keeps the property
that made tar useful: a dependency present on x86_64-unknown-linux-gnu
only, so finding it also proves that --target resolves conditional
edges. ADR 0018, architecture.md, qa-update-cycle.md and the release
skill are updated to match.

Verified locally: cargo-audit 0.22.2 exits 1 on the old lock with the
three IDs and 0 on the new one (663 crates, the same 12 allowed
warnings); the suppression guard is green, and red with the canary
swapped for tar or zip; windows-sys guard 9/9; cargo check and cargo
test (267 passed) on Linux; cargo xwin check for x86_64-pc-windows-msvc
is green on main (zip compiled) and on this branch (zip gone).

Refs #455

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
maximus commented 2026-10-17 12:52:24 +00:00
Author
Owner
Copy link

CI lue ligne à ligne : PR Check — Rust, run 560, sur 85b7ef9 (pull/459/head), succès en 9 min 55, à froid (No cache found, rustc 1.99.1 en attendant la chauffe du lundi).

Ligne attendue Log du job
ok: canary 'webkit2gtk' found for x86_64-unknown-linux-gnu l. 3711
Suppression guard: 2 checks, exit 0 l. 3712
windows-sys pinning: 9 checks, exit 0 l. 3722
test result: ok. 267 passed; 0 failed; 1 ignored l. 4466
cargo-audit-audit 0.22.2 l. 4511
Scanning src-tauri/Cargo.lock for vulnerabilities (663 crate dependencies) l. 4516
warning: 12 allowed warnings found l. 4517

Zéro ligne error: N vulnerabilit…, vulnerabilit(y|ies) found, FAIL: ou FAILED, et aucune compilation de zip, recherches faites sur le log débarrassé des codes ANSI. check-frontend n'a pas tourné, comme prévu.

CI lue ligne à ligne : `PR Check — Rust`, run 560, sur `85b7ef9` (`pull/459/head`), succès en 9 min 55, à froid (`No cache found`, rustc 1.99.1 en attendant la chauffe du lundi). | Ligne attendue | Log du job | |---|---| | `ok: canary 'webkit2gtk' found for x86_64-unknown-linux-gnu` | l. 3711 | | `Suppression guard: 2 checks, exit 0` | l. 3712 | | `windows-sys pinning: 9 checks, exit 0` | l. 3722 | | `test result: ok. 267 passed; 0 failed; 1 ignored` | l. 4466 | | `cargo-audit-audit 0.22.2` | l. 4511 | | `Scanning src-tauri/Cargo.lock for vulnerabilities (663 crate dependencies)` | l. 4516 | | `warning: 12 allowed warnings found` | l. 4517 | Zéro ligne `error: N vulnerabilit…`, `vulnerabilit(y|ies) found`, `FAIL:` ou `FAILED`, et aucune compilation de `zip`, recherches faites sur le log débarrassé des codes ANSI. `check-frontend` n'a pas tourné, comme prévu.
maximus commented 2026-10-18 12:24:05 +00:00
Author
Owner
Copy link

Checklist d'après merge corrigée (corps de la PR, point 2) : le run planifié 561 d'audit.yml (2026-10-18 06:00 UTC) compte 18 avertissements autorisés au lieu de 12. Six avertissements unmaintained sont parus entre-temps : RUSTSEC-2026-0370 à -0372, sur zvariant, zbus_names et zvariant_derive. Le run reste rouge sur les trois seules vulnérabilités, RUSTSEC-2026-0367 à -0369 (zip), que retire cette PR. Le code de la PR ne change pas.

Checklist d'après merge corrigée (corps de la PR, point 2) : le run planifié 561 d'`audit.yml` (2026-10-18 06:00 UTC) compte 18 avertissements autorisés au lieu de 12. Six avertissements `unmaintained` sont parus entre-temps : RUSTSEC-2026-0370 à -0372, sur `zvariant`, `zbus_names` et `zvariant_derive`. Le run reste rouge sur les trois seules vulnérabilités, RUSTSEC-2026-0367 à -0369 (`zip`), que retire cette PR. Le code de la PR ne change pas.
maximus commented 2026-10-18 13:49:50 +00:00
Author
Owner
Copy link

Niveau : haut — src-tauri/Cargo.toml et src-tauri/Cargo.lock (Dépendances), .forgejo/workflows/check-rust.yml (CI et gardes : étape de verdict modifiée), .claude/skills/release/SKILL.md (Release et mise à jour)

Verdict : REQUEST_CHANGES

Revue de 85b7ef9. Le correctif est correct, et la revue l'a rejoué de bout en bout : la feature zip de tauri-plugin-updater 2.10.0 est la seule chose qui change dans le graphe résolu, l'audit passe de 3 vulnérabilités à 0, le nouveau canari sait échouer, et l'app compile pour Windows sans zip. Un seul point bloque, hors du diff : le corps de la PR présente le cycle Windows de la prochaine release comme la première preuve de bout en bout de l'updater sans zip, ce qu'il n'est pas, et sa checklist ferait écrire cette preuve dans STATE.md. La correction se fait dans le corps, sans commit.

Point bloquant

  1. Corps de la PR, section « Prochaine release » et point 5 de la checklist d'après merge. Le cycle de la prochaine release part de la v0.17.1 installée (prérequis de docs/qa-update-cycle.md : « La version précédente installée sur chaque machine »). Téléchargement, vérification de signature et installation y sont faits par l'updater de la v0.17.1, compilé avec zip. De l'updater compilé sans zip, ce cycle n'exécute que le check() final (« Re-cliquer → upToDate »), que la feature ne touche pas. Le chemin d'installation sans zip (extract, updater.rs:882-889 de la 2.10.0, qui passe alors directement à extract_exe) tourne pour la première fois lors d'une mise à jour depuis la première release qui contient #455 vers la suivante.

    Le risque pour le produit est faible : extract_exe (updater.rs:920-930) est la fonction qu'a prise chaque mise à jour Windows jusqu'ici, un .exe n'étant jamais un zip, et la compilation Windows est prouvée. Mais le point 5 consignerait une preuve qui n'en est pas une, et la vraie première exécution aurait lieu chez les utilisateurs sans cycle dédié : l'étape 10 de /release n'est exigée à la release d'après que si celle-ci touche elle-même l'updater.

    Correction attendue, dans le corps seulement : retirer l'affirmation de « Prochaine release », et réécrire le point 5 pour que STATE.md porte (a) le cycle de la prochaine release, déjà dû pour #376 et #447, sans cette preuve, et (b) pour la release d'après, le cycle depuis la première version qui embarque #455, première preuve de bout en bout de l'updater sans zip, dû même si cette release ne touche pas l'updater. La même phrase est à corriger dans « Travail à faire » de #455 (« le cycle réel de mise à jour Windows, déjà dû, couvre aussi le changement de features de l'updater »).

Suggestions (non bloquantes)

  • L'angle mort vaut pour toute modification du code ou des dépendances de l'updater : l'étape 10 de /release et l'en-tête de docs/qa-update-cycle.md, que cette PR retouche, rattachent le cycle à la release qui livre le changement, alors que ce cycle exécute l'updater de la version précédente (pour le rustls de #447, seul le check() final de la nouvelle version passe par la nouvelle couche TLS). Une issue de suivi qui distingue les deux cas (artefacts, release.yml, latest.json : cycle N-1 → N ; code ou features de l'updater : cycle N → N+1 en plus) évitera de reposer la question.
  • Le cas que décrit le commentaire de Cargo.toml (passer en "v1Compatible" sans rétablir la feature) est déjà bloqué avant publication : scripts/build-latest-json.sh:92 exige un seul -setup.exe avec son .sig, et scripts/check-latest-json.jq:26 refuse une URL windows-x86_64 qui ne finit pas par .exe. Aucune archive ne peut atteindre l'updater sans zip par latest.json ; le citer dans le commentaire ou dans qa-update-cycle.md mettrait la garde à côté de la règle.
  • Merge : la branche part de 589aee0 et main est à 54c48f4 (trois commits sur CLAUDE.md, REVIEW.md, STATE.md et scripts/review-levels.py, aucun fichier commun). Une avance rapide demandera un rebase, qui relancera check-rust sur la nouvelle tête.

Ce que la revue a rejoué

Copie hors dépôt (clone dans /tmp) de la tête 85b7ef9 et de 589aee0 (même src-tauri/ que main), CARGO_TERM_COLOR=never.

Contrôle Résultat
Source de tauri-plugin-updater 2.10.0 default = ["rustls-tls", "zip"], zip = ["dep:zip", "dep:tar", "dep:flate2"] : la déclaration ne retire que zip. Sans la feature, Windows passe à extract_exe (.exe → NSIS, .msi, sinon InvalidUpdaterFormat avant tout lancement), Linux garde install_deb/install_rpm (pkexec dpkg -i, pkexec rpm -U) et la branche « rewriting AppImage » (l. 1030). La signature est vérifiée dans download() (l. 712) avant install(). Les affirmations de qa-update-cycle.md, du CHANGELOG et du commentaire de Cargo.toml tiennent.
Lock, strophe par strophe Retirés : zip 4.6.1, arbitrary 1.4.2, derive_arbitrary 1.4.2 ; ajouté : rien ; modifiée : tauri-plugin-updater seule (- "zip") ; 666 → 663 paquets.
Graphe et features (cargo tree -e all -f '{p} [{f}]'), avant et après Windows : seuls zip et les features de l'updater changent. Linux : sortent tar, filetime, xattr et la copie runtime de miniz_oxide/simd-adler32 ; flate2 reste par png → ico → tauri-codegen. Aucune feature de reqwest ni de rustls ne bouge.
cargo tree -i --locked par cible 589aee0 : zip présent sous Windows, tar sous Linux. Tête : zip hors du lock (rc 101), tar absent des deux cibles, webkit2gtk présent sous Linux (29 lignes), absent sous Windows, unique dans le lock.
cargo-audit 0.22.2 depuis la racine (.cargo/audit.toml lu), 1338 avis 589aee0 : exit 1, error: 3 vulnerabilities found! (RUSTSEC-2026-0367, -0368, -0369), 666 crates. Tête : exit 0, 663 crates, 18 allowed warnings found, mêmes ID d'avertissements des deux côtés (dont RUSTSEC-2026-0370 à -0372, deux fois chacun).
Run 561 d'audit.yml (log, ANSI retirés) 1338 avis, 666 crates, les 3 vulnérabilités zip, 18 allowed warnings found : les comptes du point 2 de la checklist sont exacts.
Garde des suppressions, bloc run: extrait, bash --noprofile --norc -e -o pipefail Tête : 2 checks, exit 0, aussi sur le lock de 589aee0. Garde de main (canari tar) sur le nouveau lock : exit 1, le changement de canari est nécessaire.
Mutations du canari (copies du bloc) M1 tar : exit 1. M2 zip : exit 1. M3 webkit2gtk interrogé pour Windows : exit 1. M4 tauri interrogé pour Windows : exit 0. M3 contre M4 confirme l'écart avec l'analyse : un canari conditionnel détecte une cible mal résolue, tauri non.
M5, feature zip remise dans Cargo.toml cargo tree --locked : rc 101, le lock commité refuse. Sans --locked (forme du cargo check de la CI, #449) : cargo rajoute les trois paquets sans rien demander et zip revient sous Windows. Copie restaurée, arbre propre.
Garde windows-sys 9 checks, exit 0.
Windows, cargo-xwin 0.23.1 déjà installé, dossier target neuf Tête : exit 0 en 2 min 08 à froid, Compiling tauri-plugin-updater v2.10.0, Compiling simpl-result, ni zip ni tar. Témoin 589aee0 ensuite : exit 0, Checking zip v4.6.1.
CI de la tête, run 560 (log lu, ANSI retirés) cargo check vert, ok: canary 'webkit2gtk' found, Suppression guard: 2 checks, exit 0, windows-sys pinning: 9 checks, exit 0, 267 passed; 0 failed; 1 ignored, audit informatif à 663 crates sans ligne de vulnérabilité, aucune ligne Locking ni Removing (lock non réécrit). check-frontend sauté à bon droit : chaque fichier est dans son paths-ignore. cargo check et cargo test Linux non rejoués en local.
crates.io tauri-plugin-updater 2.14.0, dernière stable, exige toujours zip ^4 ; zip est en 9.0.5 : aucun cargo update n'atteint le correctif.

Passe sécurité

  • §1 secrets : aucune correspondance dans les 29 lignes ajoutées, aucune coordonnée de tiers.
  • §2 dépendances : cargo audit ci-dessus ; aucun paquet ajouté, aucune version montée, aucune source ni checksum modifiée.
  • §3 motifs : pas de code ; seul || true sur la ligne du canari, déjà sur main, qui fait tomber un échec de cargo tree dans la branche FAIL.
  • §4 configuration : ni secret, ni pull_request_target, ni action ajoutée.
  • Zones : .cargo/audit.toml intact, les avis sont retirés et non supprimés (règle 1 de l'ADR 0018) ; chaque ligne qui bouge dans le lock s'explique ; la garde affiche toujours chaque vérification et lit un canari ; aucun fait de REVIEW.md rendu faux. Zone Release : le point bloquant ci-dessus.

Autres vérifications

  • Commit fix(deps): … conventionnel, Refs #455 sans mot-clé de fermeture, corps de la PR idem ; timeline de #455 : commit_ref et pull_ref en ref_action: none, le merge ne fermera pas #455.
  • CHANGELOG : les deux entrées sont sous ### Security / ### Sécurité et disent la même chose ; RUSTSEC-2026-0367 (bits SUID/SGID) et -0369 (permissions appliquées à travers les liens) portent sur des permissions Unix.
  • ADR 0018 : amendement daté du jour du commit ; canari, Issues et Liens cohérents avec le workflow et architecture.md.

Actions faites

Label de #455 : status:review → status:needs-fix. Copies hors dépôt supprimées avant ce commentaire (/tmp/pr459-review avec son worktree, le dossier target Windows de 2,5 Go, les fichiers /tmp/pr459-*). Le dépôt local n'a pas été touché (main propre, aucun worktree ajouté).

Niveau : haut — `src-tauri/Cargo.toml` et `src-tauri/Cargo.lock` (Dépendances), `.forgejo/workflows/check-rust.yml` (CI et gardes : étape de verdict modifiée), `.claude/skills/release/SKILL.md` (Release et mise à jour) ## Verdict : REQUEST_CHANGES Revue de `85b7ef9`. Le correctif est correct, et la revue l'a rejoué de bout en bout : la feature `zip` de `tauri-plugin-updater` 2.10.0 est la seule chose qui change dans le graphe résolu, l'audit passe de 3 vulnérabilités à 0, le nouveau canari sait échouer, et l'app compile pour Windows sans `zip`. Un seul point bloque, hors du diff : le corps de la PR présente le cycle Windows de la prochaine release comme la première preuve de bout en bout de l'updater sans `zip`, ce qu'il n'est pas, et sa checklist ferait écrire cette preuve dans `STATE.md`. La correction se fait dans le corps, sans commit. ### Point bloquant 1. **Corps de la PR, section « Prochaine release » et point 5 de la checklist d'après merge.** Le cycle de la prochaine release part de la v0.17.1 installée (prérequis de `docs/qa-update-cycle.md` : « La version précédente installée sur chaque machine »). Téléchargement, vérification de signature et installation y sont faits par l'updater de la v0.17.1, compilé avec `zip`. De l'updater compilé sans `zip`, ce cycle n'exécute que le `check()` final (« Re-cliquer → `upToDate` »), que la feature ne touche pas. Le chemin d'installation sans `zip` (`extract`, `updater.rs:882-889` de la 2.10.0, qui passe alors directement à `extract_exe`) tourne pour la première fois lors d'une mise à jour **depuis** la première release qui contient #455 vers la suivante. Le risque pour le produit est faible : `extract_exe` (`updater.rs:920-930`) est la fonction qu'a prise chaque mise à jour Windows jusqu'ici, un `.exe` n'étant jamais un zip, et la compilation Windows est prouvée. Mais le point 5 consignerait une preuve qui n'en est pas une, et la vraie première exécution aurait lieu chez les utilisateurs sans cycle dédié : l'étape 10 de `/release` n'est exigée à la release d'après que si celle-ci touche elle-même l'updater. Correction attendue, dans le corps seulement : retirer l'affirmation de « Prochaine release », et réécrire le point 5 pour que `STATE.md` porte (a) le cycle de la prochaine release, déjà dû pour #376 et #447, sans cette preuve, et (b) pour la release d'après, le cycle depuis la première version qui embarque #455, première preuve de bout en bout de l'updater sans `zip`, dû même si cette release ne touche pas l'updater. La même phrase est à corriger dans « Travail à faire » de #455 (« le cycle réel de mise à jour Windows, déjà dû, couvre aussi le changement de features de l'updater »). ### Suggestions (non bloquantes) - L'angle mort vaut pour toute modification du code ou des dépendances de l'updater : l'étape 10 de `/release` et l'en-tête de `docs/qa-update-cycle.md`, que cette PR retouche, rattachent le cycle à la release qui livre le changement, alors que ce cycle exécute l'updater de la version précédente (pour le `rustls` de #447, seul le `check()` final de la nouvelle version passe par la nouvelle couche TLS). Une issue de suivi qui distingue les deux cas (artefacts, `release.yml`, `latest.json` : cycle N-1 → N ; code ou features de l'updater : cycle N → N+1 en plus) évitera de reposer la question. - Le cas que décrit le commentaire de `Cargo.toml` (passer en `"v1Compatible"` sans rétablir la feature) est déjà bloqué avant publication : `scripts/build-latest-json.sh:92` exige un seul `-setup.exe` avec son `.sig`, et `scripts/check-latest-json.jq:26` refuse une URL `windows-x86_64` qui ne finit pas par `.exe`. Aucune archive ne peut atteindre l'updater sans `zip` par `latest.json` ; le citer dans le commentaire ou dans `qa-update-cycle.md` mettrait la garde à côté de la règle. - Merge : la branche part de `589aee0` et `main` est à `54c48f4` (trois commits sur `CLAUDE.md`, `REVIEW.md`, `STATE.md` et `scripts/review-levels.py`, aucun fichier commun). Une avance rapide demandera un rebase, qui relancera `check-rust` sur la nouvelle tête. ### Ce que la revue a rejoué Copie hors dépôt (clone dans `/tmp`) de la tête `85b7ef9` et de `589aee0` (même `src-tauri/` que `main`), `CARGO_TERM_COLOR=never`. | Contrôle | Résultat | |---|---| | Source de `tauri-plugin-updater` 2.10.0 | `default = ["rustls-tls", "zip"]`, `zip = ["dep:zip", "dep:tar", "dep:flate2"]` : la déclaration ne retire que `zip`. Sans la feature, Windows passe à `extract_exe` (`.exe` → NSIS, `.msi`, sinon `InvalidUpdaterFormat` avant tout lancement), Linux garde `install_deb`/`install_rpm` (`pkexec dpkg -i`, `pkexec rpm -U`) et la branche « rewriting AppImage » (l. 1030). La signature est vérifiée dans `download()` (l. 712) avant `install()`. Les affirmations de `qa-update-cycle.md`, du CHANGELOG et du commentaire de `Cargo.toml` tiennent. | | Lock, strophe par strophe | Retirés : `zip` 4.6.1, `arbitrary` 1.4.2, `derive_arbitrary` 1.4.2 ; ajouté : rien ; modifiée : `tauri-plugin-updater` seule (`- "zip"`) ; 666 → 663 paquets. | | Graphe et features (`cargo tree -e all -f '{p} [{f}]'`), avant et après | Windows : seuls `zip` et les features de l'updater changent. Linux : sortent `tar`, `filetime`, `xattr` et la copie runtime de `miniz_oxide`/`simd-adler32` ; `flate2` reste par `png` → `ico` → `tauri-codegen`. Aucune feature de `reqwest` ni de `rustls` ne bouge. | | `cargo tree -i --locked` par cible | `589aee0` : `zip` présent sous Windows, `tar` sous Linux. Tête : `zip` hors du lock (rc 101), `tar` absent des deux cibles, `webkit2gtk` présent sous Linux (29 lignes), absent sous Windows, unique dans le lock. | | `cargo-audit` 0.22.2 depuis la racine (`.cargo/audit.toml` lu), 1338 avis | `589aee0` : exit 1, `error: 3 vulnerabilities found!` (RUSTSEC-2026-0367, -0368, -0369), 666 crates. Tête : exit 0, 663 crates, `18 allowed warnings found`, mêmes ID d'avertissements des deux côtés (dont RUSTSEC-2026-0370 à -0372, deux fois chacun). | | Run 561 d'`audit.yml` (log, ANSI retirés) | 1338 avis, 666 crates, les 3 vulnérabilités `zip`, `18 allowed warnings found` : les comptes du point 2 de la checklist sont exacts. | | Garde des suppressions, bloc `run:` extrait, `bash --noprofile --norc -e -o pipefail` | Tête : `2 checks, exit 0`, aussi sur le lock de `589aee0`. Garde de `main` (canari `tar`) sur le nouveau lock : `exit 1`, le changement de canari est nécessaire. | | Mutations du canari (copies du bloc) | M1 `tar` : exit 1. M2 `zip` : exit 1. M3 `webkit2gtk` interrogé pour Windows : exit 1. M4 `tauri` interrogé pour Windows : exit 0. M3 contre M4 confirme l'écart avec l'analyse : un canari conditionnel détecte une cible mal résolue, `tauri` non. | | M5, feature `zip` remise dans `Cargo.toml` | `cargo tree --locked` : rc 101, le lock commité refuse. Sans `--locked` (forme du `cargo check` de la CI, #449) : cargo rajoute les trois paquets sans rien demander et `zip` revient sous Windows. Copie restaurée, arbre propre. | | Garde `windows-sys` | `9 checks, exit 0`. | | Windows, `cargo-xwin` 0.23.1 déjà installé, dossier `target` neuf | Tête : exit 0 en 2 min 08 à froid, `Compiling tauri-plugin-updater v2.10.0`, `Compiling simpl-result`, ni `zip` ni `tar`. Témoin `589aee0` ensuite : exit 0, `Checking zip v4.6.1`. | | CI de la tête, run 560 (log lu, ANSI retirés) | `cargo check` vert, `ok: canary 'webkit2gtk' found`, `Suppression guard: 2 checks, exit 0`, `windows-sys pinning: 9 checks, exit 0`, `267 passed; 0 failed; 1 ignored`, audit informatif à 663 crates sans ligne de vulnérabilité, aucune ligne `Locking` ni `Removing` (lock non réécrit). `check-frontend` sauté à bon droit : chaque fichier est dans son `paths-ignore`. `cargo check` et `cargo test` Linux non rejoués en local. | | crates.io | `tauri-plugin-updater` 2.14.0, dernière stable, exige toujours `zip ^4` ; `zip` est en 9.0.5 : aucun `cargo update` n'atteint le correctif. | ### Passe sécurité - §1 secrets : aucune correspondance dans les 29 lignes ajoutées, aucune coordonnée de tiers. - §2 dépendances : `cargo audit` ci-dessus ; aucun paquet ajouté, aucune version montée, aucune `source` ni `checksum` modifiée. - §3 motifs : pas de code ; seul `|| true` sur la ligne du canari, déjà sur `main`, qui fait tomber un échec de `cargo tree` dans la branche `FAIL`. - §4 configuration : ni secret, ni `pull_request_target`, ni action ajoutée. - Zones : `.cargo/audit.toml` intact, les avis sont retirés et non supprimés (règle 1 de l'ADR 0018) ; chaque ligne qui bouge dans le lock s'explique ; la garde affiche toujours chaque vérification et lit un canari ; aucun fait de `REVIEW.md` rendu faux. Zone Release : le point bloquant ci-dessus. ### Autres vérifications - Commit `fix(deps): …` conventionnel, `Refs #455` sans mot-clé de fermeture, corps de la PR idem ; timeline de #455 : `commit_ref` et `pull_ref` en `ref_action: none`, le merge ne fermera pas #455. - CHANGELOG : les deux entrées sont sous `### Security` / `### Sécurité` et disent la même chose ; RUSTSEC-2026-0367 (bits SUID/SGID) et -0369 (permissions appliquées à travers les liens) portent sur des permissions Unix. - ADR 0018 : amendement daté du jour du commit ; canari, Issues et Liens cohérents avec le workflow et `architecture.md`. ### Actions faites Label de #455 : `status:review` → `status:needs-fix`. Copies hors dépôt supprimées avant ce commentaire (`/tmp/pr459-review` avec son worktree, le dossier `target` Windows de 2,5 Go, les fichiers `/tmp/pr459-*`). Le dépôt local n'a pas été touché (`main` propre, aucun worktree ajouté).
maximus force-pushed issue-455-updater-without-zip from 85b7ef94c6 to c5efc38e96 2026-10-18 16:37:56 +00:00 Compare
maximus commented 2026-10-18 16:38:12 +00:00
Author
Owner
Copy link

Point bloquant de la revue 24757 corrigé dans le texte, sans commit (choix de Max : corriger et merger, sans second tour).

  • Corps de cette PR : la section « Prochaine release » ne présente plus le cycle de la prochaine release comme une preuve de l'updater sans zip. Ce cycle part de la v0.17.1, dont l'updater est encore compilé avec zip. Le point 5 de la checklist d'après merge garde ce cycle (dû pour #376 et #447) et ajoute, pour la release d'après, le cycle depuis la première version qui embarque #455, vraie première preuve.
  • Corps de #455 : même correction du point « Prochaine release ».
  • Suivi #463 : l'angle mort de l'étape 10 de /release et de docs/qa-update-cycle.md (un changement de l'updater ne se prouve qu'au cycle N → N+1), avec la garde existante de build-latest-json.sh et check-latest-json.jq.
  • Rebase sur main (54c48f4), nouvelle tête c5efc38, poussée avec --force-with-lease sur 85b7ef9. Les neuf fichiers de la PR sont identiques à l'octet à la tête relue 85b7ef9 (git diff 85b7ef9 c5efc38 -- <fichiers de la PR> vide). check-rust tourne sur c5efc38 ; merge ff épinglé une fois ce run vert.
Point bloquant de la revue 24757 corrigé dans le texte, sans commit (choix de Max : corriger et merger, sans second tour). - **Corps de cette PR** : la section « Prochaine release » ne présente plus le cycle de la prochaine release comme une preuve de l'updater sans `zip`. Ce cycle part de la v0.17.1, dont l'updater est encore compilé avec `zip`. Le point 5 de la checklist d'après merge garde ce cycle (dû pour #376 et #447) et ajoute, pour la release d'après, le cycle depuis la première version qui embarque #455, vraie première preuve. - **Corps de #455** : même correction du point « Prochaine release ». - **Suivi #463** : l'angle mort de l'étape 10 de `/release` et de `docs/qa-update-cycle.md` (un changement de l'updater ne se prouve qu'au cycle N → N+1), avec la garde existante de `build-latest-json.sh` et `check-latest-json.jq`. - **Rebase sur `main`** (`54c48f4`), nouvelle tête `c5efc38`, poussée avec `--force-with-lease` sur `85b7ef9`. Les neuf fichiers de la PR sont identiques à l'octet à la tête relue `85b7ef9` (`git diff 85b7ef9 c5efc38 -- <fichiers de la PR>` vide). `check-rust` tourne sur `c5efc38` ; merge ff épinglé une fois ce run vert.
maximus merged commit c5efc38e96 into main 2026-10-18 16:42:54 +00:00
maximus deleted branch issue-455-updater-without-zip 2026-10-18 16:42:54 +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#459
No description provided.
Delete branch "issue-455-updater-without-zip"

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?