Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#853 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
1/5
Tiempo estimado
Menos de una hora
Aptitud para principiantes
15/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
github-actions, rust, wasm
Área
build-system, ci-cd

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Rust
Estrellas
278
Forks
19
Merge medio
20 h 23 min
PR fusionados (30 d)
164

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de quarto-dev/q2

Todos los issues de quarto-dev/q2

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.