Repository navigation
fix(deps): bump openssl, tar, serde_with + friends past open advisories (Rust lockfiles) - #366
Merged
Merged
Conversation
…ries (Rust lockfiles) cargo audit reports these lockfiles clean, but osv-scanner (which also reads GitHub advisories that RustSec does not carry) flags: - openssl 0.10.76/0.10.78 -> 0.10.81: GHSA-phqj-4mhp-q6mq, GHSA-xp3w-r5p5-63rr, GHSA-xv59-967r-8726 (and in ffi/rust also GHSA-8c75-8mhr-p7r9, -ghm9-cr32-g9qj, -hppc-g8h3-xhp3, -pqf5-4pqq-29f5, -xmgf-hq76-4vx2). Vendored into the Linux antd and ant-ffi builds via ant-core. - tar 0.4.45 -> 0.4.46: GHSA-3pv8-6f4r-ffg2 (PAX header desync). - serde_with -> 3.21.0: GHSA-7gcf-g7xr-8hxj. Pinned to the first fixed release; 3.24 pulls ~20 new crates (syn 3, jiff, defmt). - anyhow 1.0.102 -> 1.0.104: RUSTSEC-2026-0190 (unsound). - rand 0.8.5/0.9.2 -> 0.8.8/0.9.5 (ffi/rust): RUSTSEC-2026-0097. - chacha20 0.10.0 -> 0.10.2, spin 0.9.8 -> 0.9.9: yanked releases. Lockfile-only: antd/, antd-rust/, ffi/rust/. ffi/node already carries these versions. Left as-is: lru 0.16 (RUSTSEC-2026-0253, fix needs lru 0.18 via an alloy-provider upgrade upstream) and the unmaintained warnings, none of which have a drop-in replacement. Refs V2-1582. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
antd/Cargo.lock conflicted with main's ant-core 0.13.0 repin. Resolved by taking main's lock and re-applying this PR's bumps with cargo update --precise: anyhow 1.0.104, chacha20 0.10.2, openssl 0.10.81, openssl-sys 0.9.117, serde_with(+macros) 3.21.0, spin 0.9.9, tar 0.4.46 (+ bs58 0.5.1). Against main the lock moves only those. All three lockfiles pass cargo metadata --locked; cargo audit 0 vulnerabilities.
dirvine
requested changes
Oct 19, 2026
dirvine
left a comment
dirvine
left a comment
Member
There was a problem hiding this comment.
Review — 7ad254d42e7ddef7192d0b96f08012f49db11953
REQUEST_CHANGES: Windows validation is still missing for the changed dependency graph. No introduced code defect was found.
Required before approval: validate the affected Windows lockfiles
antd/Cargo.lock and ffi/rust/Cargo.lock also change Windows dependency edges. For example, unchanged parent crates now resolve to windows-sys 0.52/0.60 instead of 0.61, and iana-time-zone selects windows-core 0.57 instead of 0.62. This is reproducible Cargo output, not evidence of a hand-edited or invalid lockfile. It is nevertheless a Windows-specific change that Linux compilation cannot exercise.
The exact-head Check (antd), Check (antd-rust) and Check (ant-ffi) jobs pass on Linux. The green Windows Node FFI matrix uses ffi/node/Cargo.lock, not either changed lockfile. The PR's Windows checklist is author-reported; I have not verified current-head Windows build/test logs for these two workspaces.
Minimum to clear this gate: provide successful Windows logs at this exact head for:
cargo test --locked --manifest-path antd/Cargo.toml
cargo test --locked --manifest-path ffi/rust/Cargo.toml
Existing retained run logs are sufficient if they identify this head and these lockfiles; a source change or new CI workflow is not required just to satisfy this request. My macOS-to-Windows cross-check could not complete because the host lacks Windows C SDK headers required by unchanged native crypto dependencies. That is a toolchain limit, not a demonstrated product failure.
Verified
- Exactly three lockfiles changed; no source, manifest, test or CI changes. Git dependency pins are unchanged.
- All three head lockfiles reproduce byte-for-byte from the frozen main/base
b2051ea2811dc39c0207e652e0fe2868692e8d3ewith targetedcargo update -p ... --precise ...operations. The two additional replay checks were parent-executed after the panel evidence freeze. - All 11 added/replaced registry versions are published, non-yanked, and have matching crates.io checksums.
- All nine
cargo metadata --locked --all-featureschecks pass: three workspaces across macOS, Linux and Windows targets. This proves resolution, not native compilation. - Baseline/head OSV comparison removes the targeted findings and adds no new advisory findings.
- Exact-head Linux logs: antd: 149 passed; antd-rust: 170 + 11 passed; ant-ffi: 23 passed, 1 ignored. The three jobs also pass locked Clippy; FFI binding-generation checks pass.
Non-blocking corrections and inherited issues
- Please refresh the PR's clean-audit claim. Current
cargo auditexits nonzero forantdandffi/rust: unchangedzip2.4.2 has RUSTSEC-2026-0367, RUSTSEC-2026-0368 and RUSTSEC-2026-0369. These findings are already present at base. They are not regressions from this PR; their fix requires a semver-incompatible dependency upgrade. Existinglru/unmaintained warnings also remain inherited. antd-rustdeclares Rust 1.82, while its already-lockedserde_withrequired 1.88 before this PR. Version 3.21.0 still requires 1.88. This PR does not introduce that MSRV mismatch. Rust 1.82 compilation was not tested.openssl-srcis unchanged. The Rust binding update must not be described as an OpenSSL C library version upgrade.
Review participation and adjudication
6/6 reviewed — 3/3 named models, each with independent correctness and adversarial roles: GLM 5.3 (z-ai/glm-5.3), Qwen 3.8 (qwen38-27b), and DS4 Flash (deepseek-v4-flash). All six receipts cover the complete frozen diff and recommend approval of the code change; none identifies an introduced code blocker. No seat is missing.
Parent adjudication differs on the validation gate: those opinions, reproducible resolution, and green Linux jobs do not establish a successful Windows build with the changed locks. I am holding formal approval until the Windows evidence above is available. This is not a claim of panel consensus on REQUEST_CHANGES.
No merge, release, live-network test or deployment was performed.
Member
Author
|
Windows validation for the review gate, at exactly
The logs below are verbatim except that the antd: cargo test --locked (Windows)ffi/rust: cargo test --locked (Windows) |
dirvine
approved these changes
Oct 19, 2026
dirvine
left a comment
dirvine
left a comment
Member
There was a problem hiding this comment.
Re-review — 7ad254d42e7ddef7192d0b96f08012f49db11953
APPROVE. The retained Windows logs now satisfy the evidence requirement in my earlier review. No introduced blocker was found.
The head is unchanged. This verdict replaces my earlier REQUEST_CHANGES; the new inputs are comment 6273225290 and the updated PR description.
Windows evidence checked
cargo test --locked --manifest-path antd/Cargo.toml: the retained output reports 149 passed, 0 failed, 0 ignored, withexit=0.cargo test --locked --manifest-path ffi/rust/Cargo.toml: the retained output reports 23 passed, 0 failed, 1 ignored, withexit=0. The ignored test requires a running devnet. The additional binding-generator and doc-test groups report zero tests and success.- Both logs identify this exact head, the requested manifests, a Windows MSVC host and Windows test executables. I checked every named test result against the summaries and exact-head Linux test output.
- The reported Git blob IDs match the committed lockfiles. The
antdSHA-256 matches the committed bytes. The FFI SHA-256 matches the exact CRLF representation of the committed LF file; this is a line-ending difference, not different dependency content.
Provenance limit: these are retained author-supplied logs, not Windows tests I ran or authenticated CI output. Hash checks establish that the reported identifiers are consistent with the committed files; they do not independently attest execution. My earlier requirement explicitly allowed retained logs. I accept this evidence for this dependency PR. The separate Windows Node FFI matrix still uses ffi/node/Cargo.lock and is not a substitute for these logs.
Other checks and scope
- The complete diff still contains exactly three lockfiles. No source, manifest, test or CI changes were added. All three locks reproduce byte-for-byte from the frozen base with targeted Cargo updates; Git dependency pins are unchanged.
- The exact-head Linux checks and the first review's registry-checksum and baseline/head advisory comparisons remain applicable to the unchanged head. The registry/advisory comparison is the retained first-review snapshot, not a claim that no new advisory can appear later.
- Audit clarification to my earlier review: that nonzero scan ran from the repository root without the workspace ignore configuration. I now ran
cargo audit --no-fetch --jsonfrom each ofantd,antd-rustandffi/rust. All three exit 0 against the cached database and report zero unignored vulnerabilities. Existing warnings remain. The configured result does not mean the inheritedlruandzipadvisories were fixed; the PR now explains these limits. - The inherited minimum-Rust mismatch remains:
antd-rustdeclares 1.82, while its existingserde_withdependency already required 1.88 before this PR. Rust 1.82 compilation was not tested. - The OpenSSL clarification is sound: target-specific locked feature trees show vendored OpenSSL enabled through
ant-coreon Linux and noopenssl-sysselection on Windows. This PR updates the Rust bindings;openssl-srcand the vendored C-library version do not change. The author's assessment that affected APIs are unlikely to be used is not a guarantee of non-use.
Panel and adjudication
6/6 reviewed — 3/3 named models. GLM 5.3 (z-ai/glm-5.3), Qwen 3.8 (qwen38-27b) and DS4 Flash (deepseek-v4-flash) each completed independent correctness and adversarial reviews of the complete frozen diff and new Windows evidence. All six recommend APPROVE; there is no material dissent and no missing seat. DS4 correctness and Qwen adversarial completed on one same-model retry after initial queue timeouts.
I checked each receipt's actual provider/model, revision and evidence digest. I agree with approval, subject to the provenance and inherited limits above. Matching hashes and matching Linux totals are not independent proof of Windows execution.
No merge, release, live-network test or deployment was performed.
Merged
7 of 8 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Lockfile-only bumps in
antd/,antd-rust/andffi/rust/that clear every open advisory with a semver-compatible fix. NoCargo.tomlor source changes.osv-scanner found these. It also reads GitHub advisories that the RustSec database doesn't carry, so
cargo auditdoesn't list most of them. The 2026-10-15 baseline for V2-1582 found them.openssltarserde_withanyhowrandchacha20,spinThe
openssladvisories are in the Rust bindings (theopensslcrate, rust-openssl), not in the OpenSSL C library.openssl-src, the vendored C library, is unchanged; this is not an OpenSSL version upgrade. ant-core depends onopensslwithfeatures = ["vendored"], so the bindings are statically linked into the Linux antd and ant-ffi builds (Windows uses schannel). The affected functions (AES key-wrap, OCSP responders, PSK/cookie callbacks, PEM password callbacks) are unlikely to be used by our TLS client paths, but the fix is a patch-level lockfile bump.serde_withis pinned to 3.21.0, the first fixed release. Plaincargo updatewould take 3.24, which adds ~20 new crates (syn 3, jiff, defmt, darling 0.24), too much churn for a security bump. ffi/node's lockfile already carries the fixed versions of all of these.Not addressed here
lru0.16 (RUSTSEC-2026-0253, unsound): the fix is lru 0.18, which is semver-incompatible and comes in throughalloy-provider→ evmlib, so it needs an upgrade upstream.zip2.4.2 (RUSTSEC-2026-0367, -0368, -0369) inantdandffi/rust. These were already on main, and nothing here touches them. The fix is zip >= 9, which is semver-incompatible and comes in through ant-core (V2-1632, then V2-1634). Until then each crate's.cargo/audit.tomlignores them, with the reasons written down (ci(deps): ignore zip extract() advisories until ant-core moves to zip 9 (RUSTSEC-2026-0367, -0368, -0369) #372). Run without that config,cargo auditexits non-zero on them.antd-rustdeclaresrust-version = "1.82", butserde_withalready needed Rust 1.88 before this PR, and 3.21.0 still does. The mismatch is inherited, not introduced here, and Rust 1.82 isn't tested.Test plan
Refreshed against main on 2026-10-19 (7ad254d).
antd/Cargo.lockconflicted with main's ant-core 0.13.0 repin. I took main's lockfile and re-applied the same bumps withcargo update -p … --precise …. Against main it moves only the crates in the table above, plusbs580.5.1, which the bumps pull in. Theantd-rustandffi/rustlockfiles are byte-identical to this PR's originals.cargo test --locked, antd 149 passed, ffi/rust 23 passed (1 ignored). Logs are in the PR comment.cargo metadata --locked: all three lockfiles are consistent with main's manifestscargo auditwith each crate's.cargo/audit.toml: 0 vulnerabilities. Remaining warnings arelruand the unmaintained crates; zip is ignored, see above.osv-scanner scan source -L <Cargo.lock>against main's lockfiles: antd 16 → 10, antd-rust 6 → 4, ffi/rust 24 → 11. Everything left is listed under "Not addressed here".Refs V2-1582.
🤖 Generated with Claude Code