Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#853 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
1/5
見積もり時間
1時間未満
初心者へのやさしさ
15/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
github-actions, rust, wasm
領域
build-system, ci-cd

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
Rust
スター
283
フォーク
20
平均マージ
20時間 16分
マージ済み PR（30日）
170

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

quarto-dev/q2 のほかの issue

quarto-dev/q2 の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。