v0.1.3

New exit code 4: some file could not be read.

Until now, an unreadable file (not a zip, truncated, or an I/O failure) only produced a line on
stdout while the exit code stayed 0. The printed warning is for humans; CI and scripts read
the exit code — so "I could not read it" silently meant "pass" in automation. A corrupt,
encrypted or partially downloaded jar quietly turned into "nothing found".

"I could not read it" and "you are safe" must be two different sentences.

• 0 now means the scan finished and every file was actually read.
• 4 means at least one file could not be read.
• A legitimately empty jar (a bare 22-byte EOCD record) is a real empty zip, not a broken file,
  and does not trigger 4 — false alarms are what make real alarms get ignored.
• Finding an actual affected version still wins: a real verdict is never downgraded to 4.

No existing exit code changed its meaning, and no CVE judgement changed.
Verified end-to-end across all three cases (non-zip / truncated / legitimately empty jar).

v0.1.2

Fix: an unreadable archive was silently reported as "nothing found".

ZipInputStream does not throw on non-zip content - it simply yields zero entries. A corrupt,
encrypted or truncated .jar used to walk through the whole scan and come out as "nothing found",
which reads as "you are not affected". "I could not read it" and "you are safe" must be two
different sentences.

Two layers, both needed:

1. zip magic check - catches "not a zip at all";
2. entry count after the walk - catches "magic is right but the content is truncated", which
   the first layer lets through.

A legitimately empty zip (a bare 22-byte EOCD record) is flagged by neither - otherwise every empty
jar would become a false alarm.

Verified end-to-end against all three cases (non-zip / truncated / legitimately empty jar).

Also in this release: the version this tool prints is now checked against the POM version by a test,
so a release can no longer ship a jar that reports the wrong version number.

No change to any CVE judgement - the version numbers this tool reports are unchanged.

bc-check v0.1.1

修的是「说不清判定边界」

v0.1.0 报 OK 时，用户很容易理解成「我的 Bouncy Castle 完全没问题」。
实际上本工具只覆盖官方 wiki 上 2026 年的 37 条 CVE。

举个具体的：org.bouncycastle:bcprov-jdk18on:1.81 在 OSV 里能查到 CVE-2025-14813 和 CVE-2026-0636 —— 前者本工具不覆盖（2025 年的），后者覆盖。

说不清判定边界，和判定错了是一回事。 所以这版：

• 控制台报告末尾固定打出判定范围声明
• --json 输出新增 scope 字段（消费方拿到 severity=OK 时能看出这个 OK 覆盖了什么）
• README 补了「判定范围」一节

顺带修正一处措辞

不是「BC 的漏洞 Dependabot 全看不见」—— 同一批里的 CVE-2026-0636 就是 reviewed、有包信息、正常告警的。
看不见的是那 4 条 unreviewed、包数为 0 的 critical（CVE-2026-58062 / 8763 / 59650 / 59638，2026-08-05 复核仍然如此）。

判定逻辑本身没有改动，37 个测试全绿。

bc-check v0.1.0

离线排查你的 Java 应用受 Bouncy Castle 2026 年这批 CVE 的哪几条影响。零依赖、单个 jar、不联网。

java -jar bc-check.jar ./app.jar
java -jar bc-check.jar --gav bcprov-lts8on:2.73.5 --detail

为什么需要工具，而不是看一眼版本号

官方所有 CVE 描述统一写「Bouncy Castle for Java before 1.85」，但用 BC-LTS 的人版本号是 2.73.x、用 FIPS 的人是 1.0.x / 2.0.x / 2.1.x —— 三条线里有两条完全无从判断。

四个例子：

• CVE-2026-8149 压根不影响 BC 线，只影响 BC-LTS 2.73.0–2.73.10。盯着「1.85」的人永远发现不了它。
• CVE-2026-59650 完全不影响 FIPS 版，按「before 1.85」报是虚惊一场。
• CVE-2026-59638 在 FIPS 侧要查的 artifact 是 bctls-fips，不是 bc-fips —— 从加密核心换到了 TLS 模块。
• CVE-2026-58062 / 58060 官方只列了 2.0.2 和 2.1.3，没有 1.0.x（即 1.0.x 线不受影响），而 CVE-2026-8763 列了 1.0.2.7。同一个 artifact、同一个版本，不同 CVE 不同答案。

另有 10 条 CVE 带起始受影响版本（from 1.61 / from 1.66 / from 1.73 各不相同），4 条老 CVE 的受影响区间是断开的（1.74–1.80.1，1.81，1.82–1.83），修复版是 1.80.2 / 1.81.1 / 1.84 这样的分支版本。

顺带一提：这批 CVE 你的 Dependabot 大概率不告警

其中 4 条 CVSS critical 在 GitHub Advisory 里是 unreviewed、受影响包列表为空。没有包名就无法匹配依赖树 —— 不进 OSV，Dependabot 不告警，SCA 也扫不出来。

判定依据

全部来自官方 github.com/bcgit/bc-java wiki 上 2026 年 37 条 CVE 的逐条子页面原文，不是二手转述。一手数据 tools/data/bc_cves.json 随仓库发布，判定表由脚本生成而非手抄，报告里逐条附官方原文供你核对。

已知的口径问题（README 里没藏着）：官方说「1.85 修了 23 个」与 wiki 的 37 条不是同一集合；1.85.1 / 2.73.12.1 都是打包修正不是安全修复。

环境要求

Java 8+。编译目标是 Java 8 —— 应急排查工具要能直接丢到生产机器上跑。