Context
The 2026-05-17 maintenance pass surfaced a persistent split in the workspace dependency tree across the RustCrypto stack:
| Crate |
Old line (via turso_core 0.5 / aes-gcm 0.10) |
New line (used directly by bashkit) |
crypto-common |
0.1.7 |
0.2.1 |
digest |
(transitive 0.10) |
0.11.3 |
sha1 |
(transitive 0.10) |
0.11.0 |
sha2 |
(transitive 0.10) |
0.11.0 |
hmac |
(transitive 0.12) |
0.13.0 |
aes |
0.8.4 |
— |
cipher |
0.4.4 |
— |
ctr |
0.9.2 |
— |
cpufeatures |
0.2.17 |
0.3.0 |
Verified via cargo tree --workspace --duplicates after a clean cargo update.
Why this matters
Bigger binaries (two builds of every common hash primitive), and a real source of confusion when someone tries to audit which version of, e.g., sha2 actually backs a given API. Not a correctness issue today — neither line is unsound — but the longer it persists, the more likely subtle divergence between hash implementations becomes a debugging hazard.
Why it's blocked
Both 0.10-line consumers in the tree are pulled by upstreams we don't control:
turso_core 0.5.3 depends on aes-gcm 0.10.3 (which transitively brings aes, cipher, ctr, cpufeatures 0.2, crypto-common 0.1, and the 0.10 digest/sha* line). The dependabot config explicitly excludes turso_* from group bumps because turso is BETA upstream; latest is 0.7.0-pre.1.
aes-gcm 0.10.3 has not yet released a 0.11 line that targets RustCrypto's 0.11 cohort.
We can't unify locally — every workaround (patch-target overrides, vendored forks) costs more than the duplication.
What to track
Not in scope
- Replacing
turso_core. Embedded SQLite via Turso is a core feature, not a candidate for swap.
- Adding
[patch.crates-io] overrides. Maintenance burden outweighs the duplicated-build cost.
Surfaced during PR #1632 deep-maintenance pass.
Context
The 2026-05-17 maintenance pass surfaced a persistent split in the workspace dependency tree across the RustCrypto stack:
turso_core 0.5/aes-gcm 0.10)bashkit)crypto-commondigestsha1sha2hmacaescipherctrcpufeaturesVerified via
cargo tree --workspace --duplicatesafter a cleancargo update.Why this matters
Bigger binaries (two builds of every common hash primitive), and a real source of confusion when someone tries to audit which version of, e.g.,
sha2actually backs a given API. Not a correctness issue today — neither line is unsound — but the longer it persists, the more likely subtle divergence between hash implementations becomes a debugging hazard.Why it's blocked
Both 0.10-line consumers in the tree are pulled by upstreams we don't control:
turso_core 0.5.3depends onaes-gcm 0.10.3(which transitively bringsaes,cipher,ctr,cpufeatures 0.2,crypto-common 0.1, and the 0.10digest/sha*line). The dependabot config explicitly excludesturso_*from group bumps because turso is BETA upstream; latest is0.7.0-pre.1.aes-gcm 0.10.3has not yet released a 0.11 line that targets RustCrypto's 0.11 cohort.We can't unify locally — every workaround (patch-target overrides, vendored forks) costs more than the duplication.
What to track
RustCrypto/AEADsforaes-gcm0.11.tursodatabase/tursofor a stable 0.7 or later that drops or replacesaes-gcm0.10.cargo updateand confirmcargo tree --workspace --duplicates | grep -E '^(aes|sha[12]|digest|hmac|cipher|crypto-common|ctr) 'returns nothing.specs/maintenance.mddeferred-items section when this is resolved.Not in scope
turso_core. Embedded SQLite via Turso is a core feature, not a candidate for swap.[patch.crates-io]overrides. Maintenance burden outweighs the duplicated-build cost.Surfaced during PR #1632 deep-maintenance pass.