安全审计

攻击面

lhasa 是 decoder。攻击面基本就是 LHA 格式解析器 + 紧的输出路径。 比 encoder+decoder（原版 lha）小很多。

• 无 encoder——输入归档没法让 lhasa spawn 子进程、写不可预期 路径、或代表用户做事。用户通过显式 lha x ... 控制解压。
• 静态构建——发布的二进制没动态依赖、没共享库 hook、 没 constructor/destructor 顺序 bug。
• lha l / lha t / lha p 无文件系统副作用——只在目录层做读。副作用只在显式 lha x。

CVE 历史

截至 2026-07-15，没有公开 CVE 针对 fraggle / lhasa 或其 vendored 版本。上游 NEWS 里记的几个：

• v0.6.0 (2026-06-17)——-pm2- 解码器 copy_decode[] 读越界修复。不可利用，但修了。 由 Yukimura (@damseleng) 报告。
• v0.5.0 (2025-08-01)——列表输出微调（避免 GUI 工具 解析出 bug）。

Fuzz 准备情况

上游 test/fuzzer.c 是 libFuzzer harness，对 liblhasa 入口 fuzz。 make check 跑的回归套件就是 fuzz corpus + 历史回归样本。

ljh-sh/lhasa 的 CI **还没** 接入持续 fuzz——下一步计划接 OSS-Fuzz （一旦上游同意加入）。当前 0.6.0 的越界修复是 fuzz 真的能影响产线的最新证据。

供应链

• Vendoring——upstream/lhasa/ 是 git subtree 快照。NOTICE.md 记 merge commit + re-vendor 命令。
• Patches——零。vendored 树与上游 75ed835 完全一致。
• 构建确定性——见 构建审计。 同源码 + 同 runner + 同 toolchain = 可重现 SHA256SUMS。

威胁模型 & 剩余风险

• 恶意 .lzh 归档——攻击面小（decoder-only， 无 shell 注入路径）。降险：解压前先 lha t。 有上游 hash 时再 SHA256 对照。
• lha x 路径穿越——现代 lhasa 处理常见情况（绝对路径、..）。解压不可信归档前 先 lha l 看一下。
• 压缩炸弹放大——LZH 本身不像 zip 会巨大放大， 解压比受格式约束。超大的还是建议先看 size。

decoder-only 是核心安全论证。lhasa **不发**任何有害内容， 只是渲染归档已有的东西。

漏洞披露

邮件：fragglet@gmail.com（上游维护者）。对 ljh-sh/lhasa 分发特有（CI、release artifact）的问题，开 GitHub issue。