Finishes the workspace-wide dependency refresh on stable 1.98.0. Most crates
took the newest release cleanly; the ones below could not, and the reason is
worth recording because "latest" is the wrong answer for several of them.
rand is pinned to 0.8, not 0.10. rand 0.10 dropped `rand::RngCore` and
`rand::rngs::OsRng`, but the real blocker is that it ships rand_core 0.10
while every signature crate here (ed25519-dalek 2.x, bls12_381, k256/p256)
is built on rand_core 0.6 -- so a 0.10 RNG is not even the right *type* to
hand to `SigningKey::generate`. rand 0.8 re-exports rand_core 0.6, which is
exactly what those crates want. rand_chacha follows it to 0.3 for the same
reason. The RNG generation is pinned by the crypto ecosystem, not by recency.
aes is pinned to 0.8 (cipher 0.4) in smart-byte-nostr and op-mobile-wallets:
aes 0.9 moved to cipher 0.5, which removed `BlockEncryptMut`,
`encrypt_padded_vec_mut` and `StreamCipherCoreWrapper::new` that this code
uses, and aes-gcm 0.10 pulls cipher 0.4 anyway -- so 0.9 also put two aes and
two cipher versions in the graph. op-3ds2 declared aes/cbc for an encrypted
deviceInfo block it never implemented; dropping those unused deps removes the
last cipher 0.5 edge, leaving a single aes and a single cipher.
reqwest 0.13 moved `RequestBuilder::query` and `::form` behind new features,
which `default-features = false` was silently excluding. Enabled per crate.
Source changes are the matching API drift:
- hmac's `new_from_slice` lives on `KeyInit`, not `Mac`
- secp256k1 0.31 takes the array by value in `from_byte_array`, and its own
re-exported `rand` is used for keygen so the two can never drift again
- smart-byte-mdl reads OS entropy from getrandom directly. It was reaching
for a rand RNG only to get 32 bytes, and going to the primitive genuinely
removes the CryptoRng skew with p256 0.14-rc that the comment there
described dodging -- and drops rand from that crate entirely.
Verified: all 20 workspaces in the monorepo compile with
`cargo check --workspace --all-targets` on 1.98.0, zero errors.
Co-Authored-By: Claude Opus 5 <[email protected]>
84fc32449a