Hi — adding a note from a downstream user of the arkworks ecosystem. We use ark-std, ark-ff, ark-ec, ark-poly, ark-serialize, ark-bn254, and light-poseidon in a Rust platform we're building. The transitive rand 0.8.x pin surfaces in our downstream security scans as GHSA-cq8v-f236-94qc. In practice the soundness defect isn't reachable in our call graph — we use tracing rather than the log crate, so the advisory's trigger conditions aren't met — but we'd like to help move this along if a downstream contributor can usefully do so.

Reading the thread: PR #60 is open, the branch looks current, conversation is clean, and @driemworks flagged a downstream block back in June. The PR's required CI check ("Test (stable)") is showing "waiting for status to be reported" — I gather that can happen when a workflow run needs maintainer approval before it starts. If that's what's keeping #60 out of the review queue, a maintainer green-lighting the workflow may be the whole unlock.

Two offers if they'd be useful:

Testing PR rand: bump to 0.9 #60 against a real downstream. We can pull tcoratger:rand, build our tree against it, run our test suite, and report back. Useful as a downstream vouch once the PR is actually under review.
Downstream cascade work once ark-std merges. Even after rand: bump to 0.9 #60 lands, the crates in arkworks-rs/algebra (ark-ff, ark-ec, ark-poly, ark-serialize) and ark-bn254 will need their own rand 0.9 updates to consume the new ark-std. We have bandwidth for that cascade if it would be welcome; happy to coordinate with anyone already planning it.

Happy to follow whatever venue convention you prefer — this thread, the PR, Discord, somewhere else. I won't open speculative PRs without confirmation that the scope is what you'd want.

Thanks for the ecosystem — we're grateful for the work.

— Jeff Fazio, Sigra Technologies

Bump rand crate to 0.9 #59

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Bump `rand` crate to 0.9 #59