Implement zstd compression and decompression

[derodero24]

Summary

Add zstd compression and decompression as the first core feature of zflate. This uses the zstd C library (v1.5.7) via the zstd Rust crate for maximum compatibility and performance across all compression levels.

Closes #4

API

import { zstdCompress, zstdDecompress } from 'zflate';

// Compress with default level (3)
const compressed = zstdCompress(data);

// Compress with specific level (1=fastest, 22=best)
const fast = zstdCompress(data, 1);

// Decompress
const original = zstdDecompress(compressed);

// Decompress with explicit capacity (for data > 256 MB)
const large = zstdDecompressWithCapacity(compressed, 500_000_000);

What's included

Rust core (crates/core/src/zstd.rs)

• zstd_compress(data, level?) — one-shot compression, levels 1-22
• zstd_decompress(data) — one-shot decompression with auto frame size detection
• zstd_decompress_with_capacity(data, capacity) — explicit capacity for large data
• 4 Rust unit tests (round-trip, empty, large, compression levels)

JS tests (__test__/zstd.spec.ts)

• 11 tests: round-trip at various sizes (0B, 1B, 1KB, 1MB), compression levels, error handling, ESM

Benchmarks (__test__/index.bench.ts)

• Compress/decompress at 150B, 10KB, 1MB

Other

• ESM exports updated (index.mjs)
• napi-rs generated files regenerated
• Changeset for minor version bump

Checklist

• Lint passes (pnpm run check)
• TypeScript type-check passes (pnpm run typecheck)
• JS tests pass (pnpm test) — 11 tests
• Rust tests pass (cargo test) — 4 tests
• Clippy passes (cargo clippy)
• Build succeeds (pnpm run build)
• Changeset included

Summary by CodeRabbit

リリースノート

• 新機能

  • Zstandard（zstd）による圧縮・展開機能を追加。圧縮レベル1–22（デフォルト3）と展開時の容量指定オプションを提供
  • パッケージのマイナーリリースへバージョン更新

• 公開API

  • 圧縮／展開関連の新しいエクスポートを追加（トップレベルで利用可能に）

• テスト

  • ユニット／ESMラウンドトリップテストと複数サイズのベンチマークを追加

• CI

  • wasm向けビルドにWASI SDKセットアップを導入するワークフロー改善

[coderabbitai]

Walkthrough

zstd 圧縮・解凍をネイティブ実装として追加。Rust コード、N-API エクスポート、TypeScript 宣言、JS バインディング、テスト、ベンチマーク、Changeset および Cargo 依存が含まれる。

Changes

Cohort / File(s)	Summary
Changeset \.changeset/zstd-compress.md	zflate のマイナーリリースを記録。zstdCompress() と zstdDecompress() 導入、圧縮レベル 1–22（デフォルト 3）を文書化。
ワークスペース依存 Cargo.toml	ワークスペース依存として zstd = { version = "0.13", default-features = false } を追加。
クレート依存 crates/core/Cargo.toml	crates/core に workspace 由来の zstd 依存を追加。
Rust 実装とエクスポート crates/core/src/lib.rs, crates/core/src/zstd.rs	新しい zstd モジュール追加。zstd_compress, zstd_decompress, zstd_decompress_with_capacity を N-API で公開。デフォルトレベル 3、最大解凍サイズ 256MB を実装。単体テストあり。
JS/TS バインディング index.js, index.mjs, index.d.ts	トップレベルで zstdCompress/zstdDecompress/zstdDecompressWithCapacity をエクスポートし、型定義を追加。
テスト __test__/zstd.spec.ts, __test__/esm-import.mjs	多サイズのラウンドトリップ、圧縮レベル比較、デフォルトレベル確認、無効データエラーハンドリング、容量指定デコードなどのテストを追加。ESM インポート検証を更新。
ベンチマーク __test__/index.bench.ts	150B、10KB、1MB 入力での圧縮・解凍ベンチマークを追加。固定バッファと事前圧縮データを使用。
CI / Release ワークフロー .github/workflows/ci.yml, .github/workflows/release.yml	wasm32-wasip1-threads 向けに WASI SDK をセットアップする条件付きステップと、sysroot を用いたビルドフローを追加・分岐。

Sequence Diagram

sequenceDiagram
    participant JS as JavaScriptコード
    participant NAPI as Nativeバインディング
    participant Rust as Rust実装\ \(zstd.rs\)
    participant ZSTDLib as Zstdライブラリ

    rect rgba(100,200,150,0.5)
    Note over JS,NAPI: 圧縮フロー
    JS->>NAPI: zstdCompress(data, level)
    NAPI->>Rust: zstd_compress(data, level)
    Rust->>ZSTDLib: zstd::bulk::compress()
    ZSTDLib-->>Rust: compressed bytes
    Rust-->>NAPI: Buffer(compressed)
    NAPI-->>JS: Buffer(compressed)
    end

    rect rgba(150,150,200,0.5)
    Note over JS,ZSTDLib: 解凍フロー
    JS->>NAPI: zstdDecompress(data)
    NAPI->>Rust: zstd_decompress(data)
    Rust->>Rust: get_frame_content_size()
    Rust->>ZSTDLib: zstd::bulk::decompress()
    ZSTDLib-->>Rust: decompressed bytes
    Rust-->>NAPI: Buffer(decompressed)
    NAPI-->>JS: Buffer(decompressed)
    end

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Poem

🐰 ぴょん、データが小さくなるよ
しゅっ、速く戻るよ、丸ごと一周
レベルいくつでも仲良く解凍
テストもベンチもぴょんぴょん合格
新しい zstd、草原を跳ねる 🌿

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	PR title clearly summarizes the primary change: adding zstd compression and decompression support.
Description check	✅ Passed	PR description comprehensively covers all required template sections with detailed implementation details, test results, and passing checklist items.
Linked Issues check	✅ Passed	PR implements core requirements from issue #4: zstd Rust functions, JS/TS APIs, round-trip tests, compression levels 1-22, and WASM build support. Dictionary support is deferred.
Out of Scope Changes check	✅ Passed	All changes are scoped to zstd implementation (Rust core, JS bindings, tests, benchmarks, CI/CD for WASM support). No extraneous modifications detected.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/issue-4-zstd-compress

📝 Coding Plan

• Generate coding plan for human review comments

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[codspeed]

Merging this PR will create unknown performance changes

🆕 6 new benchmarks
⏩ 1 skipped benchmark¹

Performance Changes

	Benchmark	BASE	HEAD	Efficiency
🆕	1MB	N/A	613 µs	N/A
🆕	10KB	N/A	282.6 µs	N/A
🆕	150B	N/A	47.8 µs	N/A
🆕	150B	N/A	71.6 µs	N/A
🆕	10KB	N/A	54.8 µs	N/A
🆕	1MB	N/A	2 ms	N/A

---

_{Comparing feat/issue-4-zstd-compress (6edde26) with develop (990a34e)}

Footnotes

1. 1 benchmark was skipped, so the baseline result was used instead. If it was deleted from the codebase, click here and archive it to remove it from the performance reports. ↩

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (5)

.changeset/zstd-compress.md (1)

5-5: zstdDecompressWithCapacity() の記載漏れ

チェンジセットの説明に zstdDecompressWithCapacity() 関数が含まれていません。公開APIの一部として追加することを検討してください。

📝 修正案

-Add zstd compression and decompression support via `zstdCompress()` and `zstdDecompress()` functions. Supports compression levels 1-22 (default: 3).
+Add zstd compression and decompression support via `zstdCompress()`, `zstdDecompress()`, and `zstdDecompressWithCapacity()` functions. Supports compression levels 1-22 (default: 3). Use `zstdDecompressWithCapacity()` for data larger than 256 MB.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.changeset/zstd-compress.md at line 5, The changeset description currently
lists zstdCompress() and zstdDecompress() but omits
zstdDecompressWithCapacity(); update the .changeset text to mention
zstdDecompressWithCapacity() as part of the public API, noting it provides
decompression with a user-provided output capacity parameter and behaves
consistently with the other functions (supports zstd levels 1–22, default level
3). Ensure the description references zstdCompress(), zstdDecompress(), and
zstdDecompressWithCapacity() by name so consumers know all exposed APIs.

__test__/index.bench.ts (1)

4-8: テストデータの初期化について

MEDIUMとLARGEのバッファはi % 256のパターンで初期化されています。これは適度に圧縮可能なデータを生成しますが、実際のユースケースによっては、ランダムデータや実際のファイル内容（JSON、テキストなど）でもベンチマークを取ることを検討してください。

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@__test__/index.bench.ts` around lines 4 - 8, The benchmark currently
initializes MEDIUM and LARGE with a repeating i % 256 pattern (constants SMALL,
MEDIUM, LARGE in __test__/index.bench.ts), which may not reflect real workloads;
update the test to include additional dataset variants: (a) a random-data
variant using crypto.randomFillSync for MEDIUM_RANDOM and LARGE_RANDOM, and (b)
a real-file/text variant by reading sample files (e.g., JSON/text fixtures) into
MEDIUM_REAL and LARGE_REAL via fs.readFileSync, and use these alongside the
existing patterned buffers in your benchmark runs so you can compare compression
behavior across patterned, random, and realistic inputs.

__test__/zstd.spec.ts (2)

1-76: テストカバレッジは良好ですが、境界値テストの追加を検討してください。

ラウンドトリップテスト、圧縮レベル、エラーハンドリングの基本的なカバレッジは十分です。オプションとして、以下のエッジケースのテスト追加を検討できます：

• 無効な圧縮レベル（0、23、負の値）に対するエラーハンドリング
• レベル22（最高圧縮）のテスト

💡 境界値テストの例

it('should handle compression level boundaries', () => {
  const input = Buffer.from('test data '.repeat(50));
  
  // Level 22 (maximum) should work
  const maxLevel = zstdCompress(input, 22);
  expect(zstdDecompress(maxLevel)).toEqual(input);
  
  // Invalid levels should throw
  expect(() => zstdCompress(input, 0)).toThrow();
  expect(() => zstdCompress(input, 23)).toThrow();
});

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@__test__/zstd.spec.ts` around lines 1 - 76, Add boundary-value tests for
zstdCompress/zstdDecompress: create a new it block that calls
zstdCompress(input, 22) and asserts zstdDecompress returns the original buffer,
and also asserts zstdCompress(input, 0) and zstdCompress(input, 23) (and a
negative level) throw. Locate tests near existing zstdCompress/zstdDecompress
usages in __test__/zstd.spec.ts (functions: zstdCompress, zstdDecompress) and
follow the same input setup and expect(...) patterns used in the file.

---

78-85: zstdDecompressWithCapacityのテストカバレッジ拡充を検討してください。

現在のテストは基本的な動作を検証していますが、以下のケースも考慮できます：

• 不十分なキャパシティでのエラーハンドリング
• 必要サイズより大きいキャパシティでの動作

💡 追加テストの例

it('should work with capacity larger than needed', () => {
  const input = Buffer.from('Hello with capacity!');
  const compressed = zstdCompress(input);
  const decompressed = zstdDecompressWithCapacity(compressed, input.length * 2);
  expect(decompressed).toEqual(input);
});

it('should throw when capacity is insufficient', () => {
  const input = Buffer.alloc(1000, 'x');
  const compressed = zstdCompress(input);
  expect(() => zstdDecompressWithCapacity(compressed, 10)).toThrow();
});

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@__test__/zstd.spec.ts` around lines 78 - 85, Add two unit tests for
zstdDecompressWithCapacity in __test__/zstd.spec.ts: one that passes a capacity
larger than the original (use zstdCompress to create compressed data and call
zstdDecompressWithCapacity(compressed, input.length * 2) and assert equality
with the original) and another that asserts an error is thrown when capacity is
insufficient (create a large input, compress with zstdCompress, then expect
zstdDecompressWithCapacity(compressed, smallCapacity) to throw). Ensure tests
reference zstdDecompressWithCapacity and zstdCompress and use appropriate
expect(...).toEqual(...) and expect(...).toThrow() assertions.

crates/core/src/zstd.rs (1)

17-24: 圧縮レベルの検証提案は不完全です。

ドキュメント検索結果によると、zstdライブラリは正の値（1～22）だけでなく、負のレベル（-131072までの値）もサポートしています。負のレベルは速度を優先する場合に使用されます。提案されている検証（1..=22）は、この有効な負のレベルを拒否してしまい、実装を制限することになります。

現在のコードは検証なしでzstd::bulk::compressに直接レベルを渡しており、これはzstd側で有効性をチェックするため合理的です。ただし、ドキュメント（17行目のコメント）は負のレベルをサポートしていることを明示すべきです。

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/core/src/zstd.rs` around lines 17 - 24, Update the comment above
zstd_compress to explicitly state that zstd accepts both positive (1..=22) and
negative levels (down to -131072) and that negative values favor speed,
clarifying that this function currently forwards the level directly to
zstd::bulk::compress (so no additional validation is performed) and that
DEFAULT_LEVEL remains the fallback when level is None; reference the
zstd_compress function, DEFAULT_LEVEL, and the call to zstd::bulk::compress in
the comment to make the behavior and supported range clear.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@crates/core/src/zstd.rs`:
- Around line 59-71: Validate the capacity f64 in zstd_decompress_with_capacity
before casting: check that capacity.is_finite() and capacity >= 0.0 and capacity
<= (usize::MAX as f64) (or a project-defined max) and reject otherwise with an
appropriate Error (e.g., Status::InvalidArgument) so you don't cast
negative/NaN/Infinity into a huge usize; only after these checks convert to
usize (cap = capacity as usize) and proceed to call zstd::bulk::decompress.

---

Nitpick comments:
In `@__test__/index.bench.ts`:
- Around line 4-8: The benchmark currently initializes MEDIUM and LARGE with a
repeating i % 256 pattern (constants SMALL, MEDIUM, LARGE in
__test__/index.bench.ts), which may not reflect real workloads; update the test
to include additional dataset variants: (a) a random-data variant using
crypto.randomFillSync for MEDIUM_RANDOM and LARGE_RANDOM, and (b) a
real-file/text variant by reading sample files (e.g., JSON/text fixtures) into
MEDIUM_REAL and LARGE_REAL via fs.readFileSync, and use these alongside the
existing patterned buffers in your benchmark runs so you can compare compression
behavior across patterned, random, and realistic inputs.

In `@__test__/zstd.spec.ts`:
- Around line 1-76: Add boundary-value tests for zstdCompress/zstdDecompress:
create a new it block that calls zstdCompress(input, 22) and asserts
zstdDecompress returns the original buffer, and also asserts zstdCompress(input,
0) and zstdCompress(input, 23) (and a negative level) throw. Locate tests near
existing zstdCompress/zstdDecompress usages in __test__/zstd.spec.ts (functions:
zstdCompress, zstdDecompress) and follow the same input setup and expect(...)
patterns used in the file.
- Around line 78-85: Add two unit tests for zstdDecompressWithCapacity in
__test__/zstd.spec.ts: one that passes a capacity larger than the original (use
zstdCompress to create compressed data and call
zstdDecompressWithCapacity(compressed, input.length * 2) and assert equality
with the original) and another that asserts an error is thrown when capacity is
insufficient (create a large input, compress with zstdCompress, then expect
zstdDecompressWithCapacity(compressed, smallCapacity) to throw). Ensure tests
reference zstdDecompressWithCapacity and zstdCompress and use appropriate
expect(...).toEqual(...) and expect(...).toThrow() assertions.

In @.changeset/zstd-compress.md:
- Line 5: The changeset description currently lists zstdCompress() and
zstdDecompress() but omits zstdDecompressWithCapacity(); update the .changeset
text to mention zstdDecompressWithCapacity() as part of the public API, noting
it provides decompression with a user-provided output capacity parameter and
behaves consistently with the other functions (supports zstd levels 1–22,
default level 3). Ensure the description references zstdCompress(),
zstdDecompress(), and zstdDecompressWithCapacity() by name so consumers know all
exposed APIs.

In `@crates/core/src/zstd.rs`:
- Around line 17-24: Update the comment above zstd_compress to explicitly state
that zstd accepts both positive (1..=22) and negative levels (down to -131072)
and that negative values favor speed, clarifying that this function currently
forwards the level directly to zstd::bulk::compress (so no additional validation
is performed) and that DEFAULT_LEVEL remains the fallback when level is None;
reference the zstd_compress function, DEFAULT_LEVEL, and the call to
zstd::bulk::compress in the comment to make the behavior and supported range
clear.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: dcda9aed-de9a-44c5-9057-e3c59b218e80

📥 Commits

Reviewing files that changed from the base of the PR and between 990a34e and 690b2aa.

⛔ Files ignored due to path filters (1)

• Cargo.lock is excluded by !**/*.lock

📒 Files selected for processing (11)

• .changeset/zstd-compress.md
• Cargo.toml
• __test__/esm-import.mjs
• __test__/index.bench.ts
• __test__/zstd.spec.ts
• crates/core/Cargo.toml
• crates/core/src/lib.rs
• crates/core/src/zstd.rs
• index.d.ts
• index.js
• index.mjs

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

capacityパラメータの検証を追加してください。

f64からusizeへの変換は、負の値やNaN/Infinityで予期しない動作を引き起こす可能性があります。負のf64は非常に大きなusizeにラップし、メモリ割り当てエラーやDoSの原因となる可能性があります。

🛡️ 検証の追加案

 #[napi]
 pub fn zstd_decompress_with_capacity(data: Buffer, capacity: f64) -> Result<Buffer> {
+    if !capacity.is_finite() || capacity < 0.0 {
+        return Err(Error::new(
+            Status::InvalidArg,
+            "capacity must be a positive finite number",
+        ));
+    }
     let input = data.as_ref();
     let cap = capacity as usize;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/core/src/zstd.rs` around lines 59 - 71, Validate the capacity f64 in
zstd_decompress_with_capacity before casting: check that capacity.is_finite()
and capacity >= 0.0 and capacity <= (usize::MAX as f64) (or a project-defined
max) and reject otherwise with an appropriate Error (e.g.,
Status::InvalidArgument) so you don't cast negative/NaN/Infinity into a huge
usize; only after these checks convert to usize (cap = capacity as usize) and
proceed to call zstd::bulk::decompress.

[coderabbitai]

Actionable comments posted: 4

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.github/workflows/ci.yml:
- Around line 166-170: The workflow extracts the WASI SDK to /opt which can be
unwritable on GitHub runners; change extraction to use $RUNNER_TEMP by
creating/using a temp dir and extracting the tarball there, then set
WASI_SDK_PATH and WASI_SYSROOT to point into that temp location (update
references to WASI_SDK_VERSION, WASI_SDK_DIR, WASI_SDK_PATH, and WASI_SYSROOT).
Ensure the directory exists before extraction and retain the same archive URL
and tar extraction flags, only replacing /opt with the chosen $RUNNER_TEMP path
so CI no longer fails due to permission issues.
- Line 168: 現在の curl | tar 解凍ステップは配布物の完全性検証を行っていないため、WASI_SDK のリリース SHA256
ダイジェストを取得して検証するように変更してください: 使用している変数 WASI_SDK_VERSION と WASI_SDK_DIR
をそのまま使い、まず該当リリースの .tar.gz とともに提供される SHA256 値（または GitHub Releases
の署名付きハッシュ）をダウンロードまたは取得し、ダウンロードしたアーカイブの sha256 を確認（sha256sum -c あるいは echo
"<expected>  ${WASI_SDK_DIR}.tar.gz" | sha256sum -c
-）して不一致ならジョブを失敗させる処理を追加してから安全に tar xz -C /opt で展開するようにしてください。

In @.github/workflows/release.yml:
- Around line 155-159: Replace the hard-coded /opt extraction with a
runner-writable directory: use WASI_SDK_DIR and WASI_SDK_VERSION but extract
into $RUNNER_TEMP (create the target dir with mkdir -p) and then set
WASI_SDK_PATH and WASI_SYSROOT to point under $RUNNER_TEMP/${WASI_SDK_DIR};
update the curl | tar command to use tar -C "$RUNNER_TEMP" and ensure the
environment echoes reference "$RUNNER_TEMP/${WASI_SDK_DIR}" so the workflow no
longer depends on writing to /opt.
- Line 157: The workflow is downloading the wasi-sdk tarball via the curl | tar
pipeline (see the curl command using WASI_SDK_VERSION and WASI_SDK_DIR) without
integrity checks; change it to download the archive to a file, verify its SHA256
against a pinned hash (either stored in-repo or passed as a workflow
secret/variable) using sha256sum -c (or equivalent) and only extract with tar
after verification succeeds; reference the variables WASI_SDK_VERSION and
WASI_SDK_DIR when locating the downloaded file and the checksum entry so the
verification step fails the job on mismatch.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: a5be5560-e191-45d6-9181-21c5bc79def0

📥 Commits

Reviewing files that changed from the base of the PR and between 690b2aa and 6edde26.

📒 Files selected for processing (2)

• .github/workflows/ci.yml
• .github/workflows/release.yml

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

/opt 展開は権限不足で失敗する可能性があります

GitHub Actions ランナーでは /opt が書き込み不可のケースがあり、WASM ターゲットだけ CI が落ちるリスクがあります。$RUNNER_TEMP 配下へ展開してください。

修正例

-          curl -sL "https://github.com/WebAssembly/wasi-sdk/releases/download/wasi-sdk-${WASI_SDK_VERSION}/${WASI_SDK_DIR}.tar.gz" | tar xz -C /opt
-          echo "WASI_SDK_PATH=/opt/${WASI_SDK_DIR}" >> $GITHUB_ENV
-          echo "WASI_SYSROOT=/opt/${WASI_SDK_DIR}/share/wasi-sysroot" >> $GITHUB_ENV
-          echo "CC_wasm32_wasip1_threads=/opt/${WASI_SDK_DIR}/bin/clang" >> $GITHUB_ENV
-          echo "AR_wasm32_wasip1_threads=/opt/${WASI_SDK_DIR}/bin/llvm-ar" >> $GITHUB_ENV
+          WASI_SDK_ROOT="${RUNNER_TEMP}/wasi-sdk"
+          mkdir -p "${WASI_SDK_ROOT}"
+          curl -fsSL "https://github.com/WebAssembly/wasi-sdk/releases/download/wasi-sdk-${WASI_SDK_VERSION}/${WASI_SDK_DIR}.tar.gz" -o "${RUNNER_TEMP}/${WASI_SDK_DIR}.tar.gz"
+          tar xzf "${RUNNER_TEMP}/${WASI_SDK_DIR}.tar.gz" -C "${WASI_SDK_ROOT}"
+          echo "WASI_SDK_PATH=${WASI_SDK_ROOT}/${WASI_SDK_DIR}" >> $GITHUB_ENV
+          echo "WASI_SYSROOT=${WASI_SDK_ROOT}/${WASI_SDK_DIR}/share/wasi-sysroot" >> $GITHUB_ENV
+          echo "CC_wasm32_wasip1_threads=${WASI_SDK_ROOT}/${WASI_SDK_DIR}/bin/clang" >> $GITHUB_ENV
+          echo "AR_wasm32_wasip1_threads=${WASI_SDK_ROOT}/${WASI_SDK_DIR}/bin/llvm-ar" >> $GITHUB_ENV

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/ci.yml around lines 166 - 170, The workflow extracts the
WASI SDK to /opt which can be unwritable on GitHub runners; change extraction to
use $RUNNER_TEMP by creating/using a temp dir and extracting the tarball there,
then set WASI_SDK_PATH and WASI_SYSROOT to point into that temp location (update
references to WASI_SDK_VERSION, WASI_SDK_DIR, WASI_SDK_PATH, and WASI_SYSROOT).
Ensure the directory exists before extraction and retain the same archive URL
and tar extraction flags, only replacing /opt with the chosen $RUNNER_TEMP path
so CI no longer fails due to permission issues.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

# First, let's look at the CI workflow file around line 168
cat -n .github/workflows/ci.yml | sed -n '160,180p'

Repository: derodero24/zflate

Length of output: 1298

---

🏁 Script executed:

# Check if there's a WASI_SDK_VERSION variable defined
grep -n "WASI_SDK_VERSION" .github/workflows/ci.yml

Repository: derodero24/zflate

Length of output: 321

---

🏁 Script executed:

# Look for any SHA256 or checksum verification in the file
grep -n -i "sha256\|checksum\|integrity\|verify" .github/workflows/ci.yml

Repository: derodero24/zflate

Length of output: 123

---

🏁 Script executed:

# Let's check if official checksums are published for WASI SDK 25.0
# Check the GitHub releases page for WASI SDK
curl -sL "https://api.github.com/repos/WebAssembly/wasi-sdk/releases" | python3 << 'EOF'
import json
import sys

data = json.load(sys.stdin)
# Find release 25
for release in data:
    if release.get('tag_name') == 'wasi-sdk-25':
        print(f"Release: {release.get('tag_name')}")
        print(f"Body:\n{release.get('body', 'No body')}")
        print("\n--- Assets ---")
        for asset in release.get('assets', []):
            print(f"  {asset['name']}")
        break
EOF

Repository: derodero24/zflate

Length of output: 781

---

🏁 Script executed:

# Let's also check if there's a checksums file in the WASI SDK releases
curl -sL "https://github.com/WebAssembly/wasi-sdk/releases/download/wasi-sdk-25/" 2>/dev/null | grep -i "sha256\|checksum\|asc\|sig" || echo "No checksum files found in directory listing"

Repository: derodero24/zflate

Length of output: 105

---

🏁 Script executed:

# Check if there are any security/integrity-related files in WASI SDK releases
# by looking at a known WASI SDK release page
curl -sL "https://api.github.com/repos/WebAssembly/wasi-sdk/releases/tags/wasi-sdk-25" | python3 << 'EOF'
import json
import sys

try:
    data = json.load(sys.stdin)
    print(f"Release Tag: {data.get('tag_name')}")
    print(f"Release Body:\n{data.get('body', 'N/A')}\n")
    print("Assets:")
    for asset in data.get('assets', []):
        print(f"  - {asset['name']}")
except json.JSONDecodeError:
    print("Could not parse JSON response")
EOF

Repository: derodero24/zflate

Length of output: 90

---

🌐 Web query:

WASI SDK official releases SHA256 checksums verification

💡 Result:

The official WASI SDK releases are hosted on GitHub at https://github.com/WebAssembly/wasi-sdk/releases. Pre-built binary tarballs (e.g., wasi-sdk-32.0-x86_64-linux.tar.gz) are available for download from each release page. No separate SHA256 checksums.txt file is provided in the releases. However, since June 2025, GitHub automatically computes and exposes SHA256 digests for all release assets. These can be viewed: - On the release page UI next to each asset (SHA256 checksum displayed). - Via GitHub CLI: gh release download --include-assets , then gh release verify-asset to verify using signed attestations. - Via REST API: GET /repos/WebAssembly/wasi-sdk/releases/assets/{asset_id} returns "digest" field (SHA256 hex prefixed with "sha256:"). To verify manually: 1. Download the asset tarball from the release page. 2. View the digest on the GitHub release asset page or API. 3. Compute local SHA256: sha256sum <downloaded-file.tar.gz>. 4. Compare the hex digest (remove "sha256:" prefix if present). Example for latest (wasi-sdk-32 as of 2026-03-20): - Navigate to https://github.com/WebAssembly/wasi-sdk/releases/tag/wasi-sdk-32 - Find asset e.g. "wasi-sdk-32.0-x86_64-linux.tar.gz", note its SHA256 next to download button. - After download: sha256sum wasi-sdk-32.0-x86_64-linux.tar.gz and match. Releases are GPG-signed commits (verified signature shown). For full integrity, check GitHub's signed attestations via gh release verify-asset. Latest release: wasi-sdk-32 (2026-03-11, 12 assets including Linux/x86_64, macOS, Windows, sysroot, etc.).

Citations:

• 1: https://github.com/WebAssembly/wasi-sdk/releases
• 2: https://github.com/webassembly/wasi-sdk
• 3: https://github.blog/changelog/2025-06-03-releases-now-expose-digests-for-release-assets
• 4: https://docs.github.com/en/rest/releases/assets
• 5: https://cli.github.com/manual/gh_release_verify-asset

---

🌐 Web query:

WebAssembly WASI SDK 25 release checksums security

💡 Result:

The WebAssembly WASI SDK version 25 (wasi-sdk-25) was released on December 12, 2024. Download official tarballs from https://github.com/WebAssembly/wasi-sdk/releases/tag/wasi-sdk-25. There are 11 assets (e.g., wasi-sdk-25.0-x86_64-linux.tar.gz for various platforms/architectures). Releases are signed with GitHub's GPG key (ID: B5690EEEBB952194), verifiable via GitHub's "verified" badge for integrity. No separate SHA256 checksum files are published by the project; verify downloads using GitHub's signature and commit verification. No security vulnerabilities, advisories, or compromises specific to WASI SDK 25 were found in official sources, GitHub security tabs, or related runtimes like Wasmtime. The release updates LLVM/Clang to 19, wasi-libc, and wasm-component-ld with bugfixes; prior issues (e.g., VERSION file in v24) were resolved in v25.

Citations:

• 1: Release wasi-sdk-25 WebAssembly/wasi-sdk#497
• 2: https://github.com/WebAssembly/wasi-sdk/releases
• 3: https://github.com/webassembly/wasi-sdk
• 4: https://github.com/WebAssembly/wasi-sdk/releases/tag/wasi-sdk-14
• 5: wasi-sdk/25 package update wolfi-dev/os#36444
• 6: Binary assets for Release 17 WebAssembly/wasi-sdk#268

---

🏁 Script executed:

# Check if there's any documentation or best practices about WASI SDK verification
# Let's also check what other CI/CD workflows do for similar tools
grep -r "wasi-sdk" . --include="*.yml" --include="*.yaml" 2>/dev/null | head -20

Repository: derodero24/zflate

Length of output: 612

---

🏁 Script executed:

# Let's check the WASI SDK GitHub repository directly for security/checksum info
# by examining if there are checksums published in release notes or elsewhere
curl -s "https://api.github.com/repos/WebAssembly/wasi-sdk/releases" --max-time 5 2>/dev/null | head -100 || echo "API call failed - checking alternative sources"

Repository: derodero24/zflate

Length of output: 5684

---

WASI SDK のダウンロードに完全性検証がありません

外部配布物をそのまま展開しているため、改ざん検知ができません。GitHub が公開する SHA256 ダイジェストを取得して検証してから解凍してください。

修正例

+          curl -sL "https://github.com/WebAssembly/wasi-sdk/releases/download/wasi-sdk-${WASI_SDK_VERSION}/${WASI_SDK_DIR}.tar.gz" -o "${RUNNER_TEMP}/${WASI_SDK_DIR}.tar.gz"
+          EXPECTED_SHA256=$(curl -sL "https://api.github.com/repos/WebAssembly/wasi-sdk/releases/latest" | jq -r '.assets[] | select(.name == "'${WASI_SDK_DIR}'.tar.gz") | .digest' | cut -d: -f2)
+          echo "${EXPECTED_SHA256}  ${RUNNER_TEMP}/${WASI_SDK_DIR}.tar.gz" | sha256sum -c -
+          tar xz -C /opt -f "${RUNNER_TEMP}/${WASI_SDK_DIR}.tar.gz"

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/ci.yml at line 168, 現在の curl | tar
解凍ステップは配布物の完全性検証を行っていないため、WASI_SDK のリリース SHA256 ダイジェストを取得して検証するように変更してください:
使用している変数 WASI_SDK_VERSION と WASI_SDK_DIR をそのまま使い、まず該当リリースの .tar.gz とともに提供される
SHA256 値（または GitHub Releases の署名付きハッシュ）をダウンロードまたは取得し、ダウンロードしたアーカイブの sha256
を確認（sha256sum -c あるいは echo "<expected>  ${WASI_SDK_DIR}.tar.gz" | sha256sum -c
-）して不一致ならジョブを失敗させる処理を追加してから安全に tar xz -C /opt で展開するようにしてください。

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

リリースワークフローでも /opt 展開は失敗リスクがあります

CI と同様に、/opt への展開は権限依存です。公開パイプラインの安定性のため、$RUNNER_TEMP などユーザー書き込み可能な場所へ展開してください。

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/release.yml around lines 155 - 159, Replace the hard-coded
/opt extraction with a runner-writable directory: use WASI_SDK_DIR and
WASI_SDK_VERSION but extract into $RUNNER_TEMP (create the target dir with mkdir
-p) and then set WASI_SDK_PATH and WASI_SYSROOT to point under
$RUNNER_TEMP/${WASI_SDK_DIR}; update the curl | tar command to use tar -C
"$RUNNER_TEMP" and ensure the environment echoes reference
"$RUNNER_TEMP/${WASI_SDK_DIR}" so the workflow no longer depends on writing to
/opt.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

cat -n .github/workflows/release.yml | sed -n '150,165p'

Repository: derodero24/zflate

Length of output: 1030

---

🏁 Script executed:

grep -n "sha256\|checksum\|hash" .github/workflows/release.yml

Repository: derodero24/zflate

Length of output: 43

---

🌐 Web query:

wasi-sdk GitHub releases checksums sha256

💡 Result:

The official wasi-sdk GitHub releases page is https://github.com/WebAssembly/wasi-sdk/releases. The latest release is wasi-sdk-32 (prerelease, March 2026). Each release lists downloadable assets (e.g., wasi-sdk-32.0-x86_64-linux.tar.gz) under the Assets section, typically 11-12 files per release for different platforms (Linux x86_64/aarch64, macOS, Windows, deb packages). GitHub does not provide official SHA256 checksums for release assets directly on the releases page. Users must compute checksums themselves after downloading using tools like sha256sum (Linux/macOS) or certutil (Windows). To verify a specific asset: 1. Download from https://github.com/WebAssembly/wasi-sdk/releases/download/wasi-sdk-VERSION/wasi-sdk-VERSION.0-PLATFORM.tar.gz 2. Compute SHA256: sha256sum wasi-sdk-VERSION.0-PLATFORM.tar.gz No separate checksum files (e.g., .sha256sum) or GPG signatures are provided in releases. Assets are generated by GitHub Actions (signed commits visible). For verification, rely on GitHub's integrity guarantees or self-computed checksums. Some downstream projects (e.g., FreeBSD ports) maintain their own checksums for specific versions.

Citations:

• 1: https://github.com/WebAssembly/wasi-sdk/releases
• 2: https://github.com/WebAssembly/wasi-sdk/releases/tag/wasi-sdk-14
• 3: https://github.com/webassembly/wasi-sdk
• 4: https://github.com/WebAssembly/wasi-sdk/releases/tag/wasi-sdk-12
• 5: https://github.com/WebAssembly/wasi-sdk/releases/tag/wasi-sdk-16
• 6: VERSION file missing from WASI SDK 24 WebAssembly/wasi-sdk#471
• 7: Release wasi-sdk-25 WebAssembly/wasi-sdk#497
• 8: Release of wasi-sdk 24 WebAssembly/wasi-sdk#469
• 9: Release tag/name version and released file versions differ by a .0 WebAssembly/wasi-sdk#360

---

リリース用 SDK ダウンロードにハッシュ検証を追加してください

外部バイナリの検証なし取得はサプライチェーン上の弱点です。wasi-sdk は公式チェックサムを提供していないため、以下のいずれかを実装してください：

• リポジトリ内でチェックサム値を固定し、curl で取得後に sha256sum -c で検証する
• リリース時に検証済みの SHA256 ハッシュをドキュメントに記載し、ワークフロー内で確認する

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/release.yml at line 157, The workflow is downloading the
wasi-sdk tarball via the curl | tar pipeline (see the curl command using
WASI_SDK_VERSION and WASI_SDK_DIR) without integrity checks; change it to
download the archive to a file, verify its SHA256 against a pinned hash (either
stored in-repo or passed as a workflow secret/variable) using sha256sum -c (or
equivalent) and only extract with tar after verification succeeds; reference the
variables WASI_SDK_VERSION and WASI_SDK_DIR when locating the downloaded file
and the checksum entry so the verification step fails the job on mismatch.