fix(main): パッケージ ID を展開先パスに使う前に検証する

[hal-shu-sato]

内容

installPackageArchive は packageState.id をそのまま展開先フォルダ名に使っています。

return await unzip(archivePath, packageState.id);
// 非アーカイブ拡張子の場合
const newFolder = path.join(path.dirname(archivePath), packageState.id);

unzip の getTargetPath は path.resolve で組み立てるだけで、resolveInside を通していません。

同じ packageId を扱う openPackageFolder には既にガードがあります。

// packageId はリモート由来のため、データフォルダ外は拒否する
if (!isParent(dataDir, folderPath)) { … }

展開先だけがこの関門を通っていませんでした。

変更

既存の防御線に載せます。AGENTS.md が「境界で守るのはパス・コマンド・URL に到達するフィールドだけで、形の細部はサービス層(resolveInside / safeRemove / execFileSync)が二重に守る」と書いている設計に沿った形です。

場所	変更
unzip	基点を明示して resolveInside を通す
packageInstall	非アーカイブ経路も同じ関門へ
packages(tRPC 境界)	id を isSafeRelativePath で検証(files[].filename 等と同じ扱い)

unzip をファイル単位に作り替えず resolveInside を挟むだけにしたのは、Data 配下という基点が zipPath から決まるためです。基点の取り方(Data 配下なら 1 階層上、それ以外はその場)は変えていません。

テスト

unzip.test.ts に 2 件追加しました。

• 展開先の外へ出る folderName を拒否して展開しない — 修正前は落ちます
• Data フォルダ配下では 1 階層上を基点にしつつ、その外へは出さない — 実運用の配置(userData/Data/package/archive/x.zip)を模し、基点の取り方が変わっていないことも同時に確認

どちらも脱出先を後片付けの対象内に置いてあるので、テストが外部にファイルを残しません。

あわせて

これがマージされると、unzip の展開先を展開前に掃除する変更(前回のインストールの残骸が新しいインストールに混入する件)も安全に足せるようになります。いまは targetPath が関門を通っていないため、remove() を足すと「書ける」より危険な「消せる」を無検証のパスに対して行うことになるので保留していました。

---

調査と文面の作成に Claude Code を使用しています。