Repository navigation
chore(deps): bump proxy-addr from 2.0.7 to 2.0.8 in /singleton-paymaster/lib/openzeppelin-contracts-v5.0.2 - #456
Conversation
Bumps [proxy-addr](https://github.com/jshttp/proxy-addr) from 2.0.7 to 2.0.8. - [Release notes](https://github.com/jshttp/proxy-addr/releases) - [Changelog](https://github.com/jshttp/proxy-addr/blob/master/HISTORY.md) - [Commits](jshttp/proxy-addr@v2.0.7...v2.0.8) --- updated-dependencies: - dependency-name: proxy-addr dependency-version: 2.0.8 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
clestons
left a comment
clestons
left a comment
There was a problem hiding this comment.
APPROVE — #456（head 7c5f7833f5aeb1426a543f1787d8d4133c6e4687）
dependabot 纯锁文件 bump：singleton-paymaster/lib/openzeppelin-contracts-v5.0.2/package-lock.json 里的 proxy-addr 2.0.7→2.0.8（devDependency），只新增 license/funding 元数据字段，依赖关系（forwarded/ipaddr.js）未变。registry/integrity 均指向官方 npmjs。
R1a：0 findings，GATE 全 NO，TRIAGE trivial。pre-pr-check：锁文件豁免。
CI 现查：两条失败（test/Stage 2 — forge test + fuzz）与本 PR 无关——与 #454/#455 相同，是 main 分支既有的 baseline 失败，不是这次 proxy-addr bump 导致。
结论：APPROVE。纯依赖锁文件 bump，无行为变化。
本评审只给结论，不做合并。
clestons
left a comment
clestons
left a comment
There was a problem hiding this comment.
✅ APPROVE — lockfile-only security bump, verified against the published artifact
Head under review: 7c5f7833f5aeb1426a543f1787d8d4133c6e4687
This PR is byte-identical to the tree I approved on 2026-10-09. It came back into my queue
only because my own watch table never recorded the reviewed sha (a bookkeeping gap on my
side, not a new commit). I re-ran the pipeline anyway, and this round adds two things the
prior round did not have: a behavioural check that the CVE is actually closed, and a
consumer analysis of what does — and does not — read this lockfile. Both are below.
Intent
The author (dependabot) intends to clear the proxy-addr advisory in this vendored tree —
bumping it 2.0.7 → 2.0.8 inside the openzeppelin-contracts-v5.0.2 lockfile.
Read from the PR body (which cites the CVE), the diff (exactly one lockfile block), and the
repo's own alert state (5 open alerts for one CVE, one per manifest) cross-read against each
other. The diff does achieve that intent. Note the scope honestly: that is 1 of the 5
alert-bearing manifests in this repo — openzeppelin-contracts-v4.8.3/package-lock.json and
the account-abstraction-v6/v7/v8 yarn.locks still pin 2.0.7. That is a note, not a
blocker: the narrower scope is the author's call, and it matches this repo's documented
position on vendored trees.
What I verified (mechanical, not read-off-the-diff)
| Check | Result |
|---|---|
| Registry flip | None — both sides registry.npmjs.org |
| Integrity hash | Real, not copied — sha512 over the actually-downloaded 2.0.8 tarball equals the lockfile value exactly; the 2.0.7 control differs and matches base |
| Semver range | The only declarer is express -> proxy-addr ~2.0.7 (= >=2.0.7 <2.1.0); 2.0.8 is inside the declared range, so no range edit was owed |
| Transitive set | Unchanged — forwarded 0.2.0, ipaddr.js 1.9.1 on both sides |
| Is it a real security fix? | Yes — the repo's own alerts API (state=open) returns 5 alerts, all GHSA-jqcg-44mw-7w3h / CVE-2026-90711, critical, first_patched_version: 2.0.8 |
| Is the CVE actually closed in the artifact? | Yes — probed, not assumed. On 2.0.7, proxyaddr.compile('::ffff:0:0/8')('1.2.3.4', 0) returns TRUE (an arbitrary IPv4 wrongly trusted); on 2.0.8 it returns FALSE. Controls separate the fix from blanket rejection: ::ffff:0:0/96 stays trusted on both, plain IPv4 subnets behave identically on both, and native IPv6 is not newly trusted |
| Is the lockfile ever installed? | No. See below |
Why the lockfile cannot reach a running process. The tree's only named consumers are
foundry.toml remappings (@openzeppelin/contracts/, @openzeppelin-v5.0.2/) and
slither.config.json — every one of them resolves to .../openzeppelin-contracts-v5.0.2/contracts/,
i.e. .sol sources only. Forge compiles Solidity and never invokes npm. The two
pnpm install --frozen-lockfile steps in this repo's CI (x402-facilitator-node.yml,
abi-docs.yml) target the root and packages/x402-facilitator-node/ pnpm-lock.yaml
files — a different package manager and a different file from this npm-format
package-lock.json. The repo's byte-exact provenance self-check pins only .sol files and
does not pin this lockfile, so this change neither is covered by nor breaks that pin.
The safety of this PR does not depend on that last paragraph, and it is worth saying why:
the change is a within-range move to a patched release. Even if some consumer I cannot
see were to install this tree, the move can only go vulnerable → patched.
Falsification attempt (this round's strongest finding was "there is nothing here")
Running a verdict round that only ratifies earlier rounds is worth little, so the final round
was tasked with breaking the approval rather than confirming it. Four candidate counter-arguments,
and their outcome:
| Attack | Outcome | Why it fails |
|---|---|---|
| (a) the integrity hash is a copy-paste lie | defeated | sha512 recomputed over the bytes actually served at that immutable version URL equals the lockfile value, and the 2.0.7 control matches base. For it to still be a lie, the registry would have to serve different bytes at an immutable version URL, or sha512 would have to collide — neither is reachable. |
| (b) the CVE is not really closed | defeated | The probe is honest as "the over-broad-CIDR behaviour flipped", not as a completeness proof — that distinction is fair. But the bump lands exactly on Dependabot's own first_patched_version, and a within-range move can only go vulnerable → patched. Residual: any other over-broad spec upstream did not cover stays wrongly trusted — that is upstream's scope, not this PR's. |
| (c) the tree is consumed, so this has runtime effects | defeated | Forge/slither reach the tree only through foundry remappings to .sol; the two pnpm install --frozen-lockfile steps target pnpm-lock.yaml files, and pnpm/solc ignore a package-lock.json regardless. |
| (d) something beyond the version bump is sneaking in | defeated | license / funding are descriptive entries; resolution keys on version+resolved+integrity, and npm ci reconciles package.json ↔ lockfile, not lockfile metadata. The comma-on-its-own-line is valid JSON. |
All four failed to defeat the approval. The round also returned no missed findings.
Coverage / round disclosure
compress_diff.pydropped the entire diff (it strips lockfiles), so the R1 context was
rebuilt by splicing the lockfile block back in. Coverage is therefore complete, not partial.- Codex R3 was not run. The post-R2 severity gate skips it when R2 surfaces nothing
Medium+; R2 surfaced nothing at all. Disclosed rather than concealed — this review carries
R1a + R1b + R2 + R4, with R3 deliberately skipped, not silently counted.
pre-pr-check
rules_version 1.3.4 (git_sha 23f3ae7e), 0 lines / 0 files in scope, band: normal,
exempt_files: ["singleton-paymaster/lib/openzeppelin-contracts-v5.0.2/package-lock.json"],
0 findings — block and review level both clean.
CI
preflight-report is red on this PR. I read the run log: its approval legs pass
(OK the approval body names this exact head, OK approved SHA == head) and it fails solely
on FAIL failing checks: Stage 2 — forge test + fuzz,test. Those two jobs are also red on
main itself — main's last three test.yml runs (2026-10-10 aaf4ca5/PR#457, 2026-10-09
601553d/PR#452, 2026-10-02 c05cdb8) all failed, with the last green back on 2026-09-08.
So this red is a standing repo-wide baseline, not something this diff caused, and no
approval can turn it green while those jobs are red.
Suggestions (non-blocking)
- The
fundingblock lands as}+ a bare,on its own line — a hand-splice/dependabot
signature rather than a cleannpm installrewrite. Valid JSON, zero parser impact. - Fixing 1 of 5 alert-bearing manifests is fine as a scoped PR; the other four are worth a
follow-up if you want the advisory actually cleared at the repo level. - Worth a decision, not just a cleanup: this lockfile is not in
VendoredProvenanceSelfCheck.t.sol's pin set (that self-check pins only.solfiles), so a
future re-vendor of v5.0.2 could silently reintroduce 2.0.7 with nothing going red. Adding
this lockfile to the pin set would make the fix durable rather than a one-time edit.
1 participant
Bumps proxy-addr from 2.0.7 to 2.0.8.
Release notes
Sourced from proxy-addr's releases.
Changelog
Sourced from proxy-addr's changelog.
Commits
a11ad822.0.8 (#70)780911dfix: reject IPv4 trust via mapped IPv6 subnets with a short prefix92e103efix(ci): use publised as release trigger event (#71)3e5ac75ci: merge coverage via artifacts, disable fail-fast, add Node.js 23-26 (#69)4b9db81chore(ci): npm-publish via workflows (#54)655e895build(deps-dev): bump eslint-plugin-import from 2.31.0 to 2.32.0 (#39)50ce4d0build(deps): bump ossf/scorecard-action from 2.4.2 to 2.4.3 (#45)0fd347fbuild(deps): bump actions/upload-artifact from 7.0.0 to 7.0.1 (#63)6a517fabuild(deps): bump github/codeql-action from 4.32.4 to 4.36.0 (#64)0d45e2aFix "arugment" typo in README (#61)Maintainer changes
This version was pushed to npm by GitHub Actions, a new releaser for proxy-addr since your current version.
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)You can disable automated security fix PRs for this repo from the Security Alerts page.