Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Monitor wasm-pack: cargo install broken by zip crate mass-yank; CI uses taiki-e prebuilt binary

Aperta
  • Qualcosa non va?
#853 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
1/5
Tempo stimato
Meno di un'ora
Idoneità per principianti
15/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
github-actions, rust, wasm
Ambito
build-system, ci-cd

Direzione di ricerca

Nothing in the repository needs a code change yet. Start by reading the upstream wasm-pack issue (wasm-bindgen/wasm-pack#1608) and the zip2 thread (zip-rs/zip2#1075) to see whether binary-install has been replaced. Done means the tracking note is current or the team has decided whether to revisit the taiki-e install-action step.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

testing

Summary

Our CI installs wasm-pack via taiki-e/install-action@wasm-pack (prebuilt binary) instead of cargo install wasm-pack, because cargo install wasm-pack stopped working on 2026-10-16. This issue tracks the upstream situation so we know when (and whether) to revisit.

Upstream tracking issue: https://github.com/wasm-bindgen/wasm-pack/issues/1608

What happened

On 2026-10-16 the zip crate maintainers yanked every published version except 9.0.3 and 9.0.4 (134 of 136 versions), ahead of publishing security advisories. See zip-rs/zip2#1075. The advisories cited so far:

The maintainer said more advisories will be published later this month.

wasm-pack 0.15.0 depends on binary-install 0.4.1, which requires zip ^2.1.3. No unyanked 2.x exists, so a fresh cargo install wasm-pack fails to resolve. binary-install is archived, so a fix has to come from wasm-pack itself.

Why the prebuilt binary is acceptable for now

The taiki-e binary is the same wasm-pack 0.15.0 source, built with zip 2.4.2 from wasm-pack's own lockfile, so the vulnerable zip code is present. Practical exposure in our CI is low:

  • binary-install never calls the high-level ZipArchive::extract API the advisories are about. It walks entries itself, filters with enclosed_name(), and writes only the specific binaries it wants with a fixed 0755 mode.
  • wasm-pack only reaches the zip code path for Windows binaryen downloads and chromedriver (wasm-pack test). Everything else it fetches is .tar.gz.
  • Our workflows preinstall both tools wasm-pack would otherwise download (wasm-bindgen-cli at the lockfile version via cargo, [email protected] via npm). wasm-pack prefers PATH copies when versions match, so in CI it downloads nothing.

What to watch for

  • A wasm-pack release that drops or replaces binary-install (resolving the upstream issue above). Once it ships, the taiki-e manifest picks it up automatically since we don't pin a version.
  • The additional zip advisories the maintainer said are coming. If any affect the entry-iteration path (not just extract()), re-evaluate the "low exposure" reasoning above.
  • Whether we want to pin taiki-e/install-action to a commit SHA for supply-chain hygiene (independent of the zip question).

Related

Our own zip dependency was bumped from 6.0.0 (also yanked) to 9.0.4 in the same change that switched the workflows.

Lingua principale
Rust
Stelle
273
Fork
18
Merge medio
22h 46m
PR unite (30g)
158

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di quarto-dev/q2

Tutte le issue di quarto-dev/q2

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.