chore: update outdated dependencies

[dobby-coder]

Routine dependency scan found outdated direct dependencies.

Outdated direct dependencies

Package	Current	Latest	Kind
rand_core	0.6	0.10.x	Normal
sha3	0.10	0.11.x	Normal
digest (transitive)	0.9	0.11.x	Normal
bincode	2 (already)	3.0	Dev
criterion	0.5	0.8.x	Dev
rand	0.8	0.10.x	Dev
rand_xorshift (lock)	0.3	0.5.x	Dev
csv (lock)	1.1	1.4.x	Dev
sha2 (lock)	0.9	0.11.x	Dev

These line up with RustCrypto's 2025/2026 trait revisions — digest, sha2, sha3 move together. rand 0.10 and rand_core 0.10 must move together. curve25519-dalek 4.1 may need a follow-up bump for rand_core 0.10 compat — verify before pinning.

Instructions for the worker

1. Read repos/ibs/ in the dobby memory repo if present.
2. Bump in Cargo.toml, then cargo update.
3. Apply API migrations (RustCrypto digest 0.11, rand 0.10) — keep the no_std feature combinations passing.
4. Run cargo build --all-features, cargo test --all-features, cargo bench --no-run (criterion 0.8 had API tweaks).
5. Open a draft PR chore: update outdated dependencies, reviewer @rubenhensen. Flip ready after CI.

Splitting into multiple PRs is fine if RustCrypto + rand cannot land together.

[dobby-coder]

/dobby

[dobby-coder]

The bot is on it! Updating outdated dependencies — RustCrypto 0.11 + rand 0.10 migrations. Will read memory notes for ibs first, then attempt the bumps.

[dobby-coder]

Opened #16 with the only bump that's safely landable right now: criterion 0.5 → 0.8 (CI green, marked ready).

Everything else in the table is blocked and grouped behind one upstream:

• bincode 3 is a compile_error! tombstone on crates.io — not a real upgrade target. Staying on 2.
• rand_core 0.6 → 0.10, sha3 0.10 → 0.11, rand 0.8 → 0.10 (and the related lockfile bumps for rand_xorshift, sha2, csv) all need curve25519-dalek 5.0. The latest stable is 4.1.3, which pins rand_core 0.6 and digest 0.10. The only curve25519-dalek release on rand_core 0.10 is 5.0.0-pre.6 — pre-release, not appropriate for a crypto lib's main branch.

Suggest: leave this issue open, retry once curve25519-dalek 5.0 ships stable, then do the RustCrypto + rand bumps in one cross-cutting PR.

[dobby-coder]

Looks like a likely duplicate of #13 (overlapping dependency bumps in this repo). Flagging for the maintainer to consolidate or close one of the two.

[rubenhensen]

/dobby research going to bincode-next

[dobby-coder]

Dobby is so happy to be asked! The bot will research migrating to bincode-next for ibs — checking what bincode is used for here (dev-only per issue table), cross-referencing the postguard PR #182 recipe, and reporting back with a concrete plan. No code changes yet, just research!

[dobby-coder]

Research: migrating ibs to bincode-next

Current state

bincode is a dev-dependency only in ibs (Cargo.toml line 26). The sole usage is one test, test_round in src/gg.rs:419-448, with 5 call sites:

• bincode::config::standard()
• bincode::serde::encode_to_vec(...) × 3
• bincode::serde::decode_from_slice(...) × 3

The test is an in-memory round-trip — there is no on-disk wire format to preserve, so the config::legacy() compat shim postguard needed in PR #182 is not required here.

Migration is mechanical (~10 minutes of work)

Cargo.toml:

[dev-dependencies]
bincode-next = { version = "3.0.0-rc.13", default-features = false, features = ["std", "serde"] }

src/gg.rs (test_round): rename bincode:: → bincode_next::. The bincode-next 3.0.0-rc.x API mirrors bincode v2 1:1 for the symbols ibs uses (config::standard(), serde::encode_to_vec, serde::decode_from_slice). No error-type split work because the test uses .unwrap().

No public API of ibs changes. No pg-core-style Error::Bincode split. No version bump beyond a normal patch.

MSRV impact: none for library consumers

bincode-next 3.0.0-rc.13 requires rustc 1.91.1. ibs declares rust-version = "1.65". Because Cargo does not propagate dev-dependency MSRV to downstream users of ibs, the library's MSRV stays at 1.65. CI is unaffected — dtolnay/rust-toolchain@stable already pulls a toolchain well past 1.91.

The only caveat: a contributor running cargo test locally on an old toolchain would fail. Worth a brief CONTRIBUTING note or a rust-toolchain.toml for the dev path, but not strictly required.

Trust caveats (important)

• bincode-next is published by panayang / Apich-Organization — a third-party fork, not the original bincode-org. Authors string copies the upstream names. RC-only since 2025-12-19; no stable release.
• Pulls in two same-org siblings: bincode_derive-next (gated on derive, not used here) and unty-next (unconditional, ~5-line lint fork of unty 0.0.5).
• Postguard's source audit (see memory: repos/postguard/bincode-next-audit.md) found no network clients, no Command::spawn, no env-exfil patterns, benign build.rs. The async-fiber and SIMD-prefetch features are not in the ["std","serde"] set we'd enable.
• Pin =3.0.0-rc.13 (not ^) to block surprise rc bumps.

Does this help with the dep-bump issue?

Mostly cosmetic for ibs:

• RUSTSEC-2025-0141: This is the bincode "Unmaintained" advisory. It covers all bincode versions, but bincode-next is a different crate name, so the advisory technically wouldn't flag it. That said, per bincode-unmaintained-covers-all-versions, framing this as a security fix would be wrong — it's swapping one unmaintained crate for an RC-only fork.
• Decouples from the curve25519-dalek 5.0 blocker: ✅ yes. Unlike rand_core / sha3 / digest, the bincode bump is dev-only and has zero entanglement with the RustCrypto stack. It can land before curve25519-dalek 5.0 ships stable.

Alternatives

1. Do nothing — stay on bincode 2.0.1. The README from bincode-org calls v1/v2 "complete, not in need of updates." Cheapest option.
2. Allowlist RUSTSEC-2025-0141 in .cargo/audit.toml — defensible if/when cargo audit becomes part of CI here. Currently ibs does not run cargo audit, so there is no advisory pressure.
3. Migrate to postcard — also a no_std-friendly serde format. Larger change, but maintained upstream. Overkill for a single round-trip test.
4. Adopt bincode-next as proposed — mechanical, but inherits fork-trust risk.

Recommendation

This is a low-urgency, low-risk bump. There is no production wire-format, no public API churn, no MSRV impact, and the blast radius is one test. If the maintainer wants to mirror the postguard direction for consistency across the org, the bot can open a small PR pinning =3.0.0-rc.13. Otherwise staying on bincode 2.0.1 is perfectly defensible and matches what bincode-org themselves recommend.

Happy to open the PR if you'd like — say the word.

---

Research only. No code changes made. Cross-references: postguard PR #182, bot memory repos/postguard/bincode-next-migration.md, rules/bincode-3-tombstone.md, rules/bincode-unmaintained-covers-all-versions.md.

[rubenhensen]

create a pr going to bincode-next /dobby

[dobby-coder]

Dobby is here! Dobby reads the request — bincode-next migration PR for the ibs repo. Dobby will check the memory notes from postguard PR #182 and prepare a draft PR right away!

[dobby-coder]

Plan: migrate dev-dep bincode 2 → bincode-next 3.0.0-rc.13

Scope is narrow: the only bincode use in this repo is the dev-only round-trip test test_round in src/gg.rs (lines 424–443). No on-disk/wire format is exposed by the library, so no compat shim or wire-bytes pin is required (unlike postguard PR #182).

Files

• Cargo.toml — replace bincode = { version = "2", features = ["serde"] } with bincode-next = { version = "=3.0.0-rc.13", default-features = false, features = ["std", "serde"] } under [dev-dependencies].
• src/gg.rs — rename the three bincode::serde::{encode_to_vec,decode_from_slice} and bincode::config::standard() call sites to bincode_next::…. No semantic change.

Trust caveat (will be in PR body)

bincode-next is a third-party fork (Apich-Organization, publisher panayang) — not bincode-org. Source audit was done for postguard PR #182 with conservative ["std","serde"] feature subset; same subset used here. Version pinned to =3.0.0-rc.13 to block surprise rc bumps.

MSRV

bincode-next 3.0.0-rc.13 requires rustc 1.91.1. Cargo.toml currently declares rust-version = "1.65". I'll bump rust-version to 1.91.1 so this is honest. CI uses dtolnay/rust-toolchain@stable and will pick it up automatically.

Verification

• cargo fmt --all -- --check
• cargo build --all-features
• cargo test --release --all-features (must pass test_round)
• cargo build --target wasm32-unknown-unknown --all-features --lib (no-std smoke)

PR

Draft chore(deps): bump dev-dep bincode 2 -> bincode-next 3.0.0-rc.13, branch chore/bincode-next, reviewer @rubenhensen, references issue #15.

Open to feedback if maintainer prefers the audit-allowlist route or postcard instead — see bincode-unmaintained-covers-all-versions context.

[dobby-coder]

/dobby please pick this up — chore: update outdated dependencies. Triggered as fan-out from encryption4all/dobby#78.