fix(security): 存量 Dependabot 告警清零——setuptools 升级修复 + 3 条经实测定性的 dismiss

.github/workflows/negentropy-perceives-ci.yml

@@ -222,18 +222,11 @@ jobs:
             --ignore-vuln PYSEC-2026-139
 
             # torch 2.10.0 CVE-2025-3000：本地内存破坏 / DoS（需构造恶意 tensor；本项目仅
-            # 加载第一方模型 artifact，向量不可达）。upstream fix 2.13.0 已发布（原记录
-            # 「暂无 fix」已过时），但 torch 升级受 marker-pdf/surya/docling-ibm-models/
-            # torchvision 四方联动约束，随 transformers 同批评估——见 ISSUE-092 2026-09-06 增补
+            # 加载第一方模型 artifact，向量不可达）。upstream fix 2.13.0 已发布，但升级实测回归：
+            # torch>=2.13 强制 torchvision 0.25.0→0.29.0（其 0.25.0 硬钉 torch==2.10.0），而
+            # transformers 受 pillow 冲突钉死 4.57.6，二者在 docling engine worker 导入链上不兼容
+            #（实测 parse-pdf 由 Success 变 Failed: cannot import name AutoProcessor）——见 ISSUE-092
             --ignore-vuln CVE-2025-3000
-
-            # setuptools PYSEC-2026-3447（CVE-2026-59890，CVSS 6.1）：MANIFEST.in 排除规则在
-            # macOS APFS/HFS+ 上因缺 Unicode（NFD/NFC）归一化被绕过，构建 sdist 时可能误打包应
-            # 排除文件（本地向量、需在受影响 macOS 文件系统上构建 sdist）。本项目 CI 在 Linux
-            # 构建（非 APFS/HFS+）、产物不含敏感文件，攻击向量不可达；修复仅在 setuptools 83.0.0，
-            # 为保持既有 82.0.1 运行时 pin（见 pyproject setuptools 注释与 ISSUE-092 2026-09-06 增补）不变、
-            # 不为不可达低危 flaw 变更 build 后端版本，故此处 ignore 而不升级
-            --ignore-vuln PYSEC-2026-3447
           )
           uv run pip-audit "${ignore_args[@]}"
 

apps/negentropy-perceives/pyproject.toml

@@ -71,7 +71,7 @@ dependencies = [
     "pydantic-settings>=2.14.2",  # 修复 GHSA-4xgf-cpjx-pc3j（2.14.1 及以下）
     "pyyaml>=6.0.3",              # YAML 配置文件解析
     # --- 运行时基础设施 ---
-    "setuptools>=82.0.1",  # 历史运行时地板；原注释「undetected-chromedriver 依赖 pkg_resources」已证伪——上游早于 82 即移除 pkg_resources（82/83 实测皆无，ISSUE-092）。保持 82.0.1：不为不可达的 build-time 低危（CVE-2026-59890 需 macOS APFS+sdist+敏感产物三前提）变更 build 后端版本
+    "setuptools>=83.0.0",  # 历史运行时地板；原注释「undetected-chromedriver 依赖 pkg_resources」已证伪——上游早于 82 即移除（82/83 实测皆无，ISSUE-092）。抬至 83.0.0 修 CVE-2026-59890（Dependabot #555）：82↔83 对本项目零功能差异已隔离验证，直接消因优于 ignore
     "opendataloader-pdf>=2.4.3",
 ]
 

docs/.agents/issue.md

@@ -2198,6 +2198,17 @@
   - **setuptools 复核**：重跑 2026-07-20 的隔离验证（`uv run --no-project --with 'setuptools==82.0.1'/'==83.0.0' python -c 'import pkg_resources'`），确认 **82 与 83 皆无 `pkg_resources`**，结论不变。维持 82.0.1，并将 pyproject L74 已证伪的注释理由改写为事实陈述。
   - **ignore 清单季度 review（本次执行）**：fastmcp（`CVE-2025-64340` / `CVE-2026-27124`）与 litellm（`CVE-2026-35029` / `CVE-2026-35030` / `GHSA-69x8-hrgq-fjj8` / `CVE-2026-42271`）共 6 条注释停留在 3.1.1 / 1.80.0，实锁已 3.2.4 / 1.85.0。**实跑 `pip-audit` 确认两包零命中后删除**（未凭版本号推断——affected range 可能被上游修订）。裁剪后暴露新 advisory `CVE-2026-66007`（PYSEC-2026-3716，datasets folder-based builder 路径穿越），因 mlx-vlm 仅要求 `datasets>=2.19.1` 无上界，**直接升级 4.8.5→5.0.1 而非新增 ignore 债**。ignore 条目 34→28，`pip-audit` 退出 0（`No known vulnerabilities found, 10 ignored`）。
   - **dismiss 清单（4 条，全部 `tolerable_risk`）**：`#499` transformers（GHSA-fgcw-684q-jj6r / CVE-2026-5241，LightGlue 加载路径 RCE，fix 5.5.0）、`#678` transformers（GHSA-xrqw-3rrv-vx5w / CVE-2026-9856，save_pretrained 路径穿越，fix 5.10.0）、`#507` torch（GHSA-rrmf-rvhw-rf47 / CVE-2025-3000，fix **2.13.0 已存在**）、`#555` setuptools（GHSA-h35f-9h28-mq5c / CVE-2026-59890，fix 83.0.0）。
+  - **2026-09-06 第二轮（存量 alert 清零：4 条 open 逐条定性，2 条改判为「可升级」并实测复核）**：
+    - **背景**：首轮把 104 条消到 4 条 open，但 ISSUE-092 记录的「dismiss 清单」**只写进文档、从未在 GitHub 执行**，故 4 条仍挂 open。本轮逐条重新定性——不照单 dismiss，先问「能不能修」。
+    - **setuptools `#555` 由 dismiss 改判为升级（已落地）**：抬 `setuptools>=83.0.0`（实解 84.0.0）。依据：① 首轮隔离验证已证 82↔83 对本项目零功能差异；② negentropy / cognizes 两 app 早已跑 84.0.0，perceives 停在 82 反而是**不对称**；③ 实跑 `pip-audit` 对照——保留与剔除 `PYSEC-2026-3447` 两种配置**匹配数同为 8、均 exit 0**，证明该 ignore 在 84.0.0 下已是死配置。**教训：当「不可达低危」有零成本修复路径时，消因优于记账**，首轮「不为低危变更 build 后端版本」的最小干预判断在此处过于保守。
+    - **torch `#507`：推翻旧归因，但实测证明确实不能升（维持 dismiss）**——本轮最有价值的一条：
+      - **旧记载「受 marker-pdf / surya / docling-ibm-models / torchvision 四方联动约束」不成立**。以 `constraint-dependencies`（尊重上游声明、冲突即报错）解析 `torch>=2.13.0`：exit 0，前三者版本**纹丝不动**；上游 wheel METADATA 亦佐证 marker-pdf 1.10.2 声明 `torch<3,>=2.7.0`、docling-ibm-models 3.13.0 声明 `torch<3,>=2.2.2`，2.14.0 落在区间内。真正联动的**只有 torchvision**（其 0.25.0 硬钉 `torch==2.10.0`）。
+      - **真实阻断（实测得出，非推断）**：升级后 torchvision 0.25.0→0.29.0，而 transformers 受 pillow 冲突钉死在 4.57.6，二者在 **docling engine worker 的导入链**上不兼容。同一条 `perceives parse-pdf` 命令：torch 2.10.0 → `Status: Success`（757B，表格正常）；torch 2.14.0 → `Status: Failed`，worker 报 `cannot import name 'AutoProcessor' from 'transformers'`，**连续两次确定性复现**。据此回退升级、维持 2.10.0。
+      - **⚠️ 陷阱记录**：`DocumentConverter().convert()` **直接调用在 torch 2.14 下是成功的**（600B 正确 markdown），只有经 perceives engine worker 才失败。**只验证上游库本身会得出完全相反的结论**——运行时验证必须走本项目的真实调用路径。
+    - **transformers `#678` / `#499`：dismiss 依据经实测证实**。撤掉 `pillow>=12.3.0` override 并要求 `transformers>=5.10.0` 后 `uv lock` **exit 1**；上游 METADATA 确认 marker-pdf 2.0.0 与 surya-ocr 0.22.1 均声明 `pillow<11`。首轮结论成立。
+    - **附带订正**：marker-pdf **1.10.2（当前锁定版）本身也声明 `Pillow<11`**，现状已由 override 压过。故准确表述不是「升 marker 会把 pillow 降到 <11」，而是「会把一个**已验证**的 override 组合换成**未验证**的组合」——风险仍在，但归因需改写，勿沿用旧说法。
+    - **方法论增补（本轮新得，与下方三条并列）**：④ **`override-dependencies` 会静默压过上游声明，故不能用它验证「某约束是否可行」**——必须用 `constraint-dependencies`（冲突即报错）。首轮一度用 override 试 `transformers>=5.10.0` 得到「能解析」的假象，正是栽在这里。⑤ **两个扫描器判据会打架**：OSV 对多数 torch advisory 无 `fixed` 记录，Dependabot 却按 GHSA 判定已修复；**该删哪条 ignore 只能以 `pip-audit` 实跑为准，不可从版本号推断**。
+    - **收口**：CI ignore 条目 28→27（删 `PYSEC-2026-3447`）；`pip-audit` exit 0（`No known vulnerabilities found, 8 ignored`）；GitHub 侧 dismiss `#678` / `#499` / `#507`（均 `tolerable_risk`），并**刷新历史 dismiss `#492` / `#343` 的 comment**——二者原载「marker-pdf 1.10.2 crashes under 5.x (transformers.onnx removed)」「5.x upgrade breaks PDF pipeline」，正是已证伪口径，不刷新等于把刚清出仓库的腐化表述留在 GitHub 继续误导。
   - **方法论沉淀**：① **「上游已适配」不等于「可升级」**——须核对**全部**约束维度（本例 marker 的 transformers 已放开、pillow 仍封顶）；② **安全债决策应比较攻击面可达性而非 CVSS 分数**，否则会把可达高危换成不可达高危；③ **ignore 注释里的「阻断原因」会腐化**，其失效速度快于 CVE 本身——review 时须同时校验「原因是否仍成立」，而不只是「是否有新 fix」。
 
 ---