chore(deps): bump fast-uri to 3.1.7 to clear the high-severity audit gate - #10862
Conversation
…gate fast-uri 3.0.0-3.1.5 is a production transitive dependency of ajv, so the newly published advisories turned the previously clean high-severity baseline red for every PR and every push to main, not just for the change under review: - GHSA-5jgf-p345-68v8 host confusion via skipped IDN canonicalization - GHSA-f65p-4m7j-42xc SSRF via malformed IPv6 normalization - GHSA-fph4-wmhf-6fwf SSRF via repeated hostname percent-decoding - GHSA-jqff-g426-hqxp host confusion via percent-encoded scheme normalization 3.1.7 satisfies ajv's ^3.0.1 range, so this is a lockfile-only bump with no source changes. The root production audit exits 0 again; the remaining diff, qs and uuid findings are low and moderate, below the gate.
|
⏳ Approval still deferred — 1 PR CI workflow run(s) still in progress for ⏳ 审批仍在延迟中 —— |
|
Thanks for the PR! Template looks good ✓ Problem: observed failure, not theoretical hardening. The four Direction: aligned — this restores the clean baseline so the gate flags newly introduced findings again instead of a stale one. Size: N/A — no core paths touched; the whole diff is the root lockfile. Approach: minimal and correct. Exactly three lines change — version, tarball URL, integrity hash — for the single Risk: no elevated risk signals. Moving on to code review. 🔍 中文说明感谢贡献！ 模板完整 ✓ 问题：是已观测到的故障，不是理论性加固。 方向：对齐——恢复干净基线，让这道门重新只标记新引入的高危发现，而不是陈旧的一条。 规模：不适用——未触及核心路径，全部改动只在根 lockfile。 方案：最小且正确。只改了三行——版本号、tarball URL、integrity 哈希——对应唯一的 风险：无升级风险信号。 进入代码审查 🔍 — Qwen Code · qwen3.8-max Reviewed at |
Code reviewNothing to flag. The diff is three lines in
TestingUnattended CI run — evidence is this PR's own CI checks, read via the API; no PR code was built or executed here. The check that matters for this PR — Real-scenario testing: N/A — dependency lockfile change with no user-visible or TUI surface (and unattended CI runs never drive tmux). Not verified: the remaining sub-threshold findings ( CI results for
One row per check name (latest run); skipped checks omitted; failures sort first. / 每个检查名一行（取最新一次运行），省略 skipped，失败项排在最前。 中文说明代码审查没有需要指出的问题。diff 只有
测试无人值守 CI 运行——证据为本 PR 自己的 CI 检查，通过 API 读取；此处未构建或执行任何 PR 代码。对本 PR 最关键、也是它要修复的那个检查—— 真实场景测试：N/A——依赖 lockfile 改动，没有用户可见或 TUI 层面的表现（无人值守 CI 运行也不会驱动 tmux）。 未验证：剩余低于阈值的发现（ （CI 表格见上方标记区域，CI 结束后会自动更新。） — Qwen Code · qwen3.8-max Reviewed at |
|
Confidence: 5/5 — clean across every stage; the gate this PR targets is already green on the reviewed commit. This is the minimum change the problem admits: re-resolve one transitive entry to the patched version, touch nothing else. My independent take on "the audit gate is red repo-wide because of published advisories" would have been exactly this — bump the resolved Verdict: approve. Two workflow runs ( 中文说明Confidence: 5/5 —— 每个阶段都干净；本 PR 要修复的那道门在被审提交上已经转绿。 这是该问题所能允许的最小改动：把一个传递依赖重新解析到已修复的版本，其他一概不动。如果让我独立处理"审计门因公告发布而全仓库变红"，做法也正是如此——在现有 semver 范围内提升 结论：批准。被审提交上还有两个工作流（ — Qwen Code · qwen3.8-max Reviewed at |
yiliang114
left a comment
yiliang114
left a comment
There was a problem hiding this comment.
LGTM — minimal and correct: the lock entry moves fast-uri 3.1.5 → 3.1.7 (newest patch inside the existing ^3.0.1 range, no manifest changes), clearing the newly published HIGH advisories (GHSA-5jgf-p345-68v8 et al.) that trip the --audit-level=high gate. Verified on this head: Dependency CVE audit and Secret scan both green; the integrity hash matches the registry tarball. Note: #10805 carries the identical 3-line bump, so whichever lands second will need the rebase to resolve trivially.
qqqys
left a comment
qqqys
left a comment
There was a problem hiding this comment.
Critical: the lockfile bump needs a regenerated NOTICES.txt, and without it the Test (ubuntu-latest, Node 22.x) lane is red
Reviewed at head d7c7da6d3b752dbd2aea69896cef25fcdb1fc498.
This supersedes the bare qqqys APPROVED posted at 2026-09-03T01:16:29Z on this same head (that review carries an empty body and no evidence). The latest per-user review state wins, so the decision should now read CHANGES_REQUESTED.
Location
- Changed:
package-lock.json, the singlenode_modules/fast-urientry,3.1.5→3.1.7. - Missing:
packages/vscode-ide-companion/NOTICES.txt, which still reads at lines 4359-4360 on this head:
fast-uri@3.1.5
(git+https://github.com/fastify/fast-uri.git)
GET /pulls/10862/files returns exactly one filename (package-lock.json), so the notice file is definitively not part of the change.
Trigger
packages/vscode-ide-companion/scripts/generate-notices.js derives the notice text from the root lockfile — path.join(projectRoot, 'package-lock.json') (line 453) — and emits one name@version line per resolved dependency (line 490, deduped on `${packageName}@${packageInfo.version}` at line 424). With this lockfile the generator therefore emits fast-uri@3.1.7.
.github/workflows/ci.yml:567-581 runs the generator and then fails on any resulting diff:
- name: 'Generate VS Code companion notices'
run: 'npm run generate:notices --workspace=qwen-code-vscode-ide-companion'
- name: 'Check VS Code companion notices are up-to-date'
run: |-
if [[ -n $(git status --porcelain packages/vscode-ide-companion/NOTICES.txt) ]]; then
echo "Error: NOTICES.txt is out of date."
...
exit 1
Impact — observed, not inferred
On this head, job 100480587406 Test (ubuntu-latest, Node 22.x) = failure at step 32 Check VS Code companion notices are up-to-date, and step 36 Run tests and generate reports = skipped — so the unit suite never ran at all. Post Coverage Comment then failed downstream with No files were found with the provided path: packages/*/coverage.
The bump itself is not what is red: step 15 Install dependencies and step 18 Check lockfile both passed, so the new lockfile resolves and is consistent. The failure is purely the un-regenerated notice file.
Control: #10857 and #10841 both ran this same step to success at their own heads, so main is not drifted — the drift is specific to this PR's lockfile change.
Consequence: a lane is red and the unit suite is skipped, so this cannot merge as-is, and triage's deferred "approve on green" (<!-- qwen-triage approve-on-green sha=d7c7da6d... -->) will never fire. Triage reviewed at 00:57:33Z while Test (ubuntu-latest, Node 22.x) was still in progress, so it never saw step 32.
Fix direction
Regenerate and commit the notice file in this PR:
npm run generate:notices --workspace=qwen-code-vscode-ide-companion
The expected diff is the single line fast-uri@3.1.5 → fast-uri@3.1.7.
What does check out (no revision needed)
fast-uriis never imported by our own source — it is consumed only throughajv, whose 12 copies in the lockfile all ask for^3.0.1whilepackages/coredeclares^3.0.6. 3.1.7 satisfies every range, so no direct dependency has to move.- The new integrity hash matches the npm registry exactly:
npm view fast-uri@3.1.7 dist.integrity→sha512-dOvZVzjdZdz7phd9v6jCbwxrBW3fK6n8Rc0CtdmM4bumzMnxywBYhuph6J819RRw/ku+rLbelwfMunktuzVVHg==, byte-identical to the diff. This is the independent registry check triage said it could not perform from its environment. Dependency CVE auditis green on this head while it is red on PRs without the bump (e.g. #10861), which is direct before/after evidence that the bump clears the gate it targets.
中文说明
在 head d7c7da6d3b752dbd2aea69896cef25fcdb1fc498 上审查。
位置：本 PR 只改了 package-lock.json 里唯一的 node_modules/fast-uri 条目（3.1.5 → 3.1.7），但没有同步重新生成 packages/vscode-ide-companion/NOTICES.txt —— 该文件在这个 head 的第 4359-4360 行仍然写着 fast-uri@3.1.5。GET /pulls/10862/files 只返回一个文件名，可以确认通知文件不在改动范围内。
触发条件：generate-notices.js 从根 lockfile 读取依赖（第 453 行 path.join(projectRoot, 'package-lock.json')），并按 name@version 逐条输出（第 490 行，第 424 行以 name@version 去重），因此新的 lockfile 会生成 fast-uri@3.1.7。.github/workflows/ci.yml:567-581 先跑生成器，再用 git status --porcelain 检查 NOTICES.txt 是否有差异，有差异就 exit 1。
影响（已实测，非推断）：在该 head 上，job 100480587406 的 Test (ubuntu-latest, Node 22.x) 在第 32 步 Check VS Code companion notices are up-to-date 失败，第 36 步 Run tests and generate reports 被 skipped，也就是单元测试根本没有运行；Post Coverage Comment 随后因 No files were found with the provided path: packages/*/coverage 连带失败。变红的不是这个 bump 本身：第 15 步 Install dependencies 和第 18 步 Check lockfile 都是 passed，说明新 lockfile 能正常解析且一致，失败纯粹来自没有重新生成的通知文件。对照组：#10857 和 #10841 在各自 head 上跑同一步都是 success，所以 main 本身没有漂移，漂移是本 PR 的 lockfile 改动特有的。结果是必需通道变红、单元测试被跳过，当前状态无法合入，triage 留下的 "approve on green" 也永远不会触发（triage 在 00:57:33Z 审查时该通道还是 in progress，没看到第 32 步）。
修复方向：在本 PR 内执行 npm run generate:notices --workspace=qwen-code-vscode-ide-companion 并提交，预期 diff 就是 fast-uri@3.1.5 → fast-uri@3.1.7 这一行。
其余部分无需改动：fast-uri 在我们自己的源码中从未被直接 import，只通过 ajv 间接使用（lockfile 里 12 份 ajv 都要求 ^3.0.1，packages/core 声明 ^3.0.6），3.1.7 满足全部 range；新的 integrity 哈希与 npm registry 完全一致（npm view fast-uri@3.1.7 dist.integrity 返回的 sha512-dOvZVzjdZdz7phd9v6jCbwxrBW3fK6n8Rc0CtdmM4bumzMnxywBYhuph6J819RRw/ku+rLbelwfMunktuzVVHg== 与 diff 逐字节相同），补上了 triage 无法在其环境里做的独立校验；Dependency CVE audit 在本 head 为绿、在没有该 bump 的 PR（如 #10861）上为红，正是这个 bump 达成目标的 before/after 证据。
本条 REQUEST_CHANGES 取代 2026-09-03T01:16:29Z 在同一 head 上提交的 qqqys APPROVED（该 review 正文为空，未附任何证据）。同一用户的最新 review 状态生效，因此结论应转为 CHANGES_REQUESTED。
Follow-up: this merged without the regenerated
|
| File | Value |
|---|---|
package-lock.json → packages["node_modules/fast-uri"].version |
3.1.7 |
packages/vscode-ide-companion/NOTICES.txt line 4359 |
fast-uri@3.1.5 |
Those two are inconsistent, and .github/workflows/ci.yml:571-581 fails on exactly that:
if [[ -n $(git status --porcelain packages/vscode-ide-companion/NOTICES.txt) ]]; then
echo "Error: NOTICES.txt is out of date."
... exit 1
generate-notices.js reads the root lockfile (line 453) and emits ${dep.name}@${dep.version} (line 490), so it now produces fast-uri@3.1.7 against a committed fast-uri@3.1.5.
Impact: step 32 Check VS Code companion notices are up-to-date fails before step 36 Run tests and generate reports, which is then skipped — so the whole unit suite stops running on the Test (ubuntu-latest, Node 22.x) lane, on main and on every open PR that rebases onto it. This is precisely what job 100480587406 already showed on this PR's head (step 32 failure, step 36 skipped, Post Coverage Comment failing downstream on No files were found with the provided path: packages/*/coverage).
Controls confirming the gate is not inherently broken: #10857 and #10841 both ran step 32 to success at their own heads, while main's lockfile still resolved fast-uri to 3.1.5.
Not yet observed: main's own run for 2a428054c4 (33703006312, created 01:16:55Z) still had 0 jobs queued when I checked at ~01:30Z, so I could not watch it fail — the conclusion above rests on the two committed files plus the workflow and generator source, and on the identical observed failure on this PR's head.
Fix (one line, and it should go in as soon as possible):
npm run generate:notices --workspace=qwen-code-vscode-ide-companion
then commit packages/vscode-ide-companion/NOTICES.txt. Expected diff: fast-uri@3.1.5 → fast-uri@3.1.7.
To be clear, the dependency bump itself was correct and needed no revision — Dependency CVE audit went from red to green on it, the ^3.0.1/^3.0.6 ranges all accept 3.1.7, and the integrity hash matches the npm registry exactly. Only the generated notice file was missed.
Suggested process note for whoever merges on the "approve-on-green" path: triage's own comment here deferred approval until CI landed green, and Test (ubuntu-latest, Node 22.x) never went green — it went red at step 32. The lane that caught this was still in progress when triage reviewed at 00:57:33Z, so a step-level read of that job would have been the only way to see it before merge.
中文说明
时间线（均为 UTC，head 都是 d7c7da6d3b）：01:16:29Z 一条正文为空的 qqqys APPROVED 落地；01:16:53Z 以 2a428054c4 合入，该合并提交只含 package-lock.json 一个文件；01:23:35Z 我的 REQUEST_CHANGES 才落地，比合入晚约 7 分钟，因此没能拦住。
main 当前状态（直接从 raw 读取）：package-lock.json 里 node_modules/fast-uri 是 3.1.7，而 packages/vscode-ide-companion/NOTICES.txt 第 4359 行仍是 fast-uri@3.1.5。两者不一致，.github/workflows/ci.yml:571-581 正是对这种不一致 exit 1；生成器从根 lockfile 读取（第 453 行）并按 name@version 输出（第 490 行），所以现在会生成 fast-uri@3.1.7，与已提交的 fast-uri@3.1.5 产生 diff。
影响：第 32 步失败发生在第 36 步 Run tests and generate reports 之前，导致后者被 skipped，也就是 Test (ubuntu-latest, Node 22.x) 通道上的整套单元测试在 main 以及所有 rebase 到 main 的开放 PR 上都不再运行。这与本 PR head 上 job 100480587406 已经观测到的现象完全一致（第 32 步 failure、第 36 步 skipped、Post Coverage Comment 因找不到 packages/*/coverage 连带失败）。对照组 #10857 与 #10841 在各自 head 上第 32 步均为 success（当时 main 的 lockfile 还解析到 3.1.5），说明这道门本身没坏。
尚未观测到的部分：main 上 2a428054c4 对应的 run 33703006312（创建于 01:16:55Z）在我 01:30Z 左右检查时仍是 0 个 job，所以没能看到它实际失败；上面的结论依据是两个已提交文件加上 workflow 与生成器源码，以及本 PR head 上完全相同的已观测失败。
修复（一行，且应尽快合入）：执行 npm run generate:notices --workspace=qwen-code-vscode-ide-companion 并提交 NOTICES.txt，预期 diff 就是 fast-uri@3.1.5 → fast-uri@3.1.7。
需要说明的是，依赖 bump 本身是正确且必要的，无需改动：Dependency CVE audit 由红转绿、^3.0.1/^3.0.6 各 range 都接受 3.1.7、integrity 哈希与 npm registry 完全一致。只是漏了生成物文件。
给走 "approve-on-green" 路径的合并者的建议：本 PR 里 triage 自己声明"推迟到 CI 全绿再批准"，而 Test (ubuntu-latest, Node 22.x) 从未变绿，是在第 32 步变红的。triage 在 00:57:33Z 审查时该通道还是 in progress，因此合入前唯一能看到这一点的方式，是去读那个 job 的分步结论。
Pick up the fast-uri 3.1.7 audit-gate fix (#10862) so the Dependency CVE audit required check goes green on this branch. Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> Patrol-Run: qwen-pr-closeout/jmtkyp44iep
|
Released in v0.23.0. |
4 participants
What this PR does
Bumps the resolved version of a transitive production dependency,
fast-uri, from 3.1.5 to 3.1.7 in the root lockfile. Three lines change — the version, the tarball URL, and the integrity hash. No source code, no dependency range, and no direct dependency is touched: 3.1.7 already satisfies the^3.0.1range thatajvasks for, so this is purely a re-resolution of the lockfile.Why it's needed
The dependency audit in the Security Checks workflow is a hard gate on high-severity findings, on the assumption that the high-severity baseline is clean. That assumption broke on 2026-09-02 when four advisories were published against
fast-uri3.0.0 through 3.1.5, one of them rated high:fast-urireaches the production tree throughajv, which is pulled in by the MCP SDK, byajv-formats, and by the core package. Because the exposure is in the committed lockfile rather than in any one change, the gate went red for the whole repository at once — every open PR and every push to main, regardless of what they touch. On main the check was still green at 14:23 UTC and failing by 19:50 UTC on 2026-09-02, with no dependency change in between.This PR restores the clean baseline so the gate can do its actual job again: flagging newly introduced high-severity findings instead of a stale one.
Reviewer Test Plan
How to verify
Run the exact command the gate runs, from the repository root, and check the real exit code rather than a piped one:
Before this PR the exit code is
1and the report containsfast-uri 3.0.0 - 3.1.5withSeverity: high, alongside4 vulnerabilities (1 low, 2 moderate, 1 high). After this PR the exit code is0,fast-urino longer appears, and the report reads3 vulnerabilities (1 low, 2 moderate)— thediff,qs, anduuidfindings sit below the gate's threshold and are unchanged by this PR.The lockfile also still installs:
npm ci --ignore-scripts --dry-runsucceeds and reports exactly one relevant change,change fast-uri 3.1.5 => 3.1.7.The authoritative confirmation is the Security Checks workflow on this PR itself going green, and then main going green on the next push.
Evidence (Before & After)
N/A — dependency lockfile change with no user-visible or TUI surface. The audit exit codes above are the evidence.
Tested on
The audit resolves against the committed lockfile, so its result is platform-independent; the Linux Security Checks job is the authoritative gate.
Environment (optional)
N/A — no runtime exercised. Verification was
npm auditandnpm ci --dry-runagainst the lockfile.Risk & Scope
fast-uri3.1.6 and 3.1.7 are the upstream fixes for these advisories, so the behavioural delta is the corrected host and scheme normalization itself. Anything that relied on the previous, more permissive parsing of malformed hosts could in principle observe a change; the range stays within^3.0.1, so no dependent needs to move.qs(moderate) does have a non-breaking in-range fix, but it sits below the gate's threshold, so bundling it would widen a three-line gate fix;diff(low) anduuid(moderate) would neednpm audit fix --forceand a breaking major bump. Also out of scope:packages/mobile-mcpcarries its own self-contained vendored lockfile that still pinsfast-uri@3.1.5as a production dependency. The audit step skips that lockfile, but the mobile-mcp release workflow does install from it and publishes the result, so the skip rationale no longer matches reality. That needs its own change rather than being folded into a three-line gate fix, and is tracked separately.Linked Issues
Reported in #10850, which tracks the repo-wide audit failure. This PR clears the single high-severity finding that actually trips the gate, so the check goes green again; it deliberately does not use a closing keyword, because #10850 also lists the moderate
qsanduuidfindings, which stay open here. The same failure is visible on main runs 33675732009 and 33675704735, and on unrelated open PRs such as #10861.中文说明
这个 PR 做了什么
把根 lockfile 里一个传递性生产依赖
fast-uri的解析版本从 3.1.5 提升到 3.1.7。改动只有三行——版本号、tarball URL 和 integrity 哈希。没有动任何源码、没有动依赖 range、也没有动直接依赖：3.1.7 本身就满足ajv要求的^3.0.1，所以这只是 lockfile 的重新解析。为什么需要
Security Checks 工作流里的依赖审计是一道针对高危发现的硬门，前提是「高危基线是干净的」。这个前提在 2026-09-02 被打破了：针对
fast-uri3.0.0 到 3.1.5 的四条公告被发布，其中一条评级为 high：fast-uri是通过ajv进入生产依赖树的，而ajv由 MCP SDK、ajv-formats和 core 包引入。由于暴露点在已提交的 lockfile 里、而不在某个具体改动里，这道门是整个仓库同时变红的——所有开着的 PR 和所有推到 main 的提交都一样，与它们改了什么无关。在 main 上，这个检查在 2026-09-02 14:23 UTC 还是绿的，到 19:50 UTC 就已经失败，而这段时间里没有任何依赖变更。这个 PR 恢复干净基线，让这道门重新能干它本该干的事：标记新引入的高危发现，而不是一条陈旧的高危发现。
Reviewer 测试计划
如何验证
在仓库根目录跑这道门跑的原始命令，并检查真实退出码而不是管道之后的退出码：
在这个 PR 之前，退出码是
1，报告里含fast-uri 3.0.0 - 3.1.5且Severity: high，总计4 vulnerabilities (1 low, 2 moderate, 1 high)。在这个 PR 之后，退出码是0，fast-uri不再出现，报告为3 vulnerabilities (1 low, 2 moderate)——diff、qs、uuid三条都在这道门的阈值之下，本 PR 不改变它们。lockfile 也依然可以正常安装：
npm ci --ignore-scripts --dry-run成功，并且只报告一处相关变化，即change fast-uri 3.1.5 => 3.1.7。权威的确认是这个 PR 自己的 Security Checks 工作流转绿，以及随后 main 上第一次 push 转绿。
证据（Before & After）
N/A——依赖 lockfile 改动，没有用户可见或 TUI 层面的表现。上面的审计退出码就是证据。
测试平台
审计是针对已提交的 lockfile 做解析的，因此结果与平台无关；Linux 上的 Security Checks job 才是权威门。
环境（可选）
N/A——没有运行任何运行时。验证手段是针对 lockfile 的
npm audit与npm ci --dry-run。风险与范围
fast-uri3.1.6 与 3.1.7 正是上游针对这些公告的修复版本，所以行为差异就是被修正后的 host 与 scheme 规范化本身。原则上，任何依赖此前那种对畸形 host 更宽松解析的代码都可能观察到变化；range 保持在^3.0.1内，所以没有哪个依赖方需要跟着动。qs（moderate）确实有一个非破坏性、range 内的修复版本，但它在门的阈值之下，捆进来会让一个三行的门修复变宽；diff（low）与uuid（moderate）则需要npm audit fix --force和一次 breaking 的大版本提升。同样不在范围内：packages/mobile-mcp带着自己那份自包含的 vendored lockfile，其中fast-uri@3.1.5仍是生产依赖。审计步骤会跳过那份 lockfile，但 mobile-mcp 的发布工作流确实会从它安装并把结果发布出去，所以那条跳过理由已经与现实不符。这需要单独一个改动，而不是塞进一个三行的门修复里，已另行跟踪。关联 Issue
由 #10850 报告，该 issue 跟踪的是这次仓库范围内的审计失败。本 PR 清掉的是唯一一条真正触发这道门的高危发现，因此检查会重新转绿；这里刻意不使用自动关闭关键字，因为 #10850 还列了 moderate 级的
qs与uuid，这两条在本 PR 中仍然是未解决状态。同样的失败在 main 的 run 33675732009 与 33675704735 上可见，也在与依赖无关的开放 PR（例如 #10861）上可见。