curve25519-dalek pulls in zeroize, and zeroize 1.9.0 sets edition2024, which Cargo 1.75 cannot parse:
failed to parse manifest at .../zeroize-1.9.0/Cargo.toml
feature `edition2024` is required
Workaround: Cargo.lock pins zeroize to 1.8.2 (MSRV 1.60). Also curve25519-dalek is held at the 4.x line because 5.x requires Rust 1.85.
Why this is fragile: a lockfile pin only binds this repository. It works here because the crate is publish = false and CI builds the committed lockfile — a published library would leave downstreams to resolve zeroize themselves and break their 1.75 builds.
Options if this becomes annoying: raise MSRV to 1.85 and take curve25519-dalek 5.x; or add an explicit zeroize = ">=1, <1.9" dependency so the constraint travels with the manifest instead of the lockfile. Neither is worth doing while the profile is experimental.
CI covers it: the MSRV job builds --all-features on 1.75.0.
Update — still load-bearing after swapping to p256
The dependency changed but the pin did not become unnecessary. p256 reaches
zeroize transitively through elliptic-curve, so zeroize 1.9.0 and its
edition2024 manifest still break a 1.75 build. Verified by unpinning and
rebuilding:
$ cargo update -p zeroize --precise 1.9.0 && cargo +1.75.0 build --all-features --locked
The package requires the Cargo feature called `edition2024`, but that feature is
not stabilized in this version of Cargo (1.75.0)
Cargo.lock therefore still pins zeroize to 1.8.2. The version bounds that
matter are now:
p256 held at the 0.13 line — 0.14 requires Rust 1.85zeroize pinned to 1.8.2 in the lockfile — 1.9.0 requires edition2024
Same fragility as before: a lockfile pin only binds this repository, which is
acceptable while the crate is publish = false. Options if it becomes annoying are
unchanged — raise MSRV to 1.85 and take p256 0.14, or carry an explicit
zeroize = ">=1, <1.9" so the constraint travels with the manifest.
curve25519-dalekpulls inzeroize, andzeroize 1.9.0setsedition2024, which Cargo 1.75 cannot parse:Workaround:
Cargo.lockpinszeroizeto 1.8.2 (MSRV 1.60). Alsocurve25519-dalekis held at the4.xline because5.xrequires Rust 1.85.Why this is fragile: a lockfile pin only binds this repository. It works here because the crate is
publish = falseand CI builds the committed lockfile — a published library would leave downstreams to resolvezeroizethemselves and break their 1.75 builds.Options if this becomes annoying: raise MSRV to 1.85 and take
curve25519-dalek5.x; or add an explicitzeroize = ">=1, <1.9"dependency so the constraint travels with the manifest instead of the lockfile. Neither is worth doing while the profile is experimental.CI covers it: the MSRV job builds
--all-featureson 1.75.0.Update — still load-bearing after swapping to p256
The dependency changed but the pin did not become unnecessary.
p256reacheszeroizetransitively throughelliptic-curve, sozeroize 1.9.0and itsedition2024manifest still break a 1.75 build. Verified by unpinning andrebuilding:
Cargo.locktherefore still pinszeroizeto 1.8.2. The version bounds thatmatter are now:
p256held at the0.13line —0.14requires Rust 1.85zeroizepinned to 1.8.2 in the lockfile — 1.9.0 requiresedition2024Same fragility as before: a lockfile pin only binds this repository, which is
acceptable while the crate is
publish = false. Options if it becomes annoying areunchanged — raise MSRV to 1.85 and take
p2560.14, or carry an explicitzeroize = ">=1, <1.9"so the constraint travels with the manifest.