Lockstep upgrade pyo3 0.28 → 0.29 across the CIRIS family (RUSTSEC-2026-0176)

[emooreatx]

RUSTSEC-2026-0176 surfaced today on edge's cargo deny lane (v2.1.1 PR #88): pyo3 0.28's BoundListIterator::nth / BoundTupleIterator::nth / nth_back compute index + n with unchecked usize arithmetic, then read via get_item_unchecked. A sufficiently large n can wrap → out-of-bounds read.

Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0176
PyO3 fix: PyO3/pyo3#6086 (landed in 0.29.0)
Solution per RustSec: Upgrade to >=0.29.0 (try cargo update -p pyo3)

Edge's exposure

Grep across src/ confirms edge does NOT call .nth(/nth_back( on any PyO3 iterator path. The exposure is transitive-only (advisory fires on the dep graph; no edge code path triggers the vulnerability). Same posture as the other ignored advisories in deny.toml.

v2.1.1 ignores this in deny.toml with a tracking comment pointing here.

Why a lockstep upgrade

The whole CIRIS substrate family is on pyo3 0.28:

• ciris-persist v5.5.0 — pyo3 0.28
• ciris-verify-core v5.1.0 — pyo3 0.28
• ciris-keyring / ciris-crypto v5.1.0 — pyo3 0.28
• ciris-edge v2.1.1 — pyo3 0.28
• ciris-lens-core v1.0.0 — pyo3 0.28 (transitive)

Edge moving alone would put pyo3 0.28 + pyo3 0.29 simultaneously in the cohabitation graph. Each cdylib statically bundles its own pyo3, so symbol-level it works, but cross-cdylib PyCapsule extraction relies on opaque pointer + name-tag stability — a mixed-version graph risks subtle ABI drift between the two PyO3 ffi tables.

Cleanest path: move persist + verify-family + edge + lens-core in lockstep, same pattern as the v5 keyring/crypto bump.

Migration surface (PyO3 0.28 → 0.29)

Per PyO3 0.29 release notes, the load-bearing changes for edge are:

• Bound API stabilization on a few iter methods (the fix itself)
• Minor signature changes on PyAny::call* family
• Removal of some 0.27-deprecated paths (likely already-migrated in edge)

Most edge code is on the Bound API since the v0.10.0 capsule cycle; the bump is expected to be small-surface.

Suggested sequencing

1. Persist + verify-family release pyo3-0.29 patch versions (5.6.0 / 5.2.0)
2. Edge bumps deps + Cargo dep on pyo3 → 0.29 + Bound API touch-ups
3. lens-core bumps in lockstep
4. deny.toml ignore lifts

Not blocking the v2.1.1 critical path (Windows wheel + agent 2.9.6 substrate floor); ignore the advisory now, fold the upgrade into v2.2.0 once the upstream substrate moves.

cc CIRISPersist (substrate-side mover), CIRISVerify (crypto/keyring lockstep), CIRISLensCore (downstream catchup).

[emooreatx]

Verify is outside the pyo3 lockstep — the chain starts at persist, not verify

Following up on "does verify need to start?" — I checked the verify workspace directly, and it corrects the dependency-order premise:

• Zero pyo3 in any verify Cargo.toml — ciris-verify-core, ciris-keyring, ciris-crypto are pure Rust.
• ciris-verify-ffi is a C-ABI cdylib (crate-type = ["cdylib", "staticlib"]) whose shipped .so links neither libpython nor pyo3 — it exports plain #[no_mangle] extern "C" symbols.
• The ciris-verify Python wheel is ctypes + setuptools, not pyo3/maturin — it dlopens those C symbols.

Two consequences:

1. The ciris-verify wheel coexists with pyo3 wheels at any version — it's a ctypes dlopen, sharing no pyo3 FFI tables / interpreter state, so it isn't subject to the "two pyo3 versions can't share a process" hazard.
2. persist consumes ciris-verify-core as a pure-Rust crate under persist's own pyo3 — so verify-core is pyo3-version-agnostic; persist can move 0.28→0.29 without verify changing a line.

Net: no verify action for #89. The lockstep chain is persist → edge → lens-core; verify is a no-op leaf. The C-ABI boundary at ciris-verify-ffi is the deliberate firewall that keeps verify out of the family's pyo3 ABI coupling — which is exactly why it should stay that way (see the companion note I'm filing on CIRISVerify).

So the upgrade kicks off at persist (tracked at CIRISPersist#201), not verify.

[emooreatx]

State of the blocker chain — June 13 2026

Cross-stack diagnostic from the leviculum maintainer agent (Leviculum#14) resolves a misattribution in this issue's earlier framing. Updated chain:

Leviculum is NOT a blocker

Reproduced cold with a cdylib probe (reticulum-std + reticulum-core + pyo3 0.29 + pyo3-async-runtimes 0.29) at BOTH edge's pinned `ded96ee` AND the synced upstream master:

• Compiles cleanly — tokio 1.52, socket2 0.6, mio 1.2 all unify. No version conflict, no trait-signature mismatch, no pin-shape clash.
• Runs cleanly — node comes up on the pyo3-async-runtimes-0.29 runtime. leviculum owns its own runtime, so the caller's pyo3-async-runtimes shape doesn't reach it.
• No leviculum change needed.

Net: the family can stop waiting on leviculum. Cite: Leviculum#14 (CIRISAI/leviculum issue with the full repro).

What's actually blocking

The persist v6.0.0 yank was misattributed to leviculum here. The real chain is:

1. Persist needs to re-cut v6 — the v6.0.0 cut was published then yanked; the underlying reason is upstream (persist-side) and persist owns the re-cut decision. Persist v5.8.0 (current PyPI latest) is still on pyo3 0.28, so edge can't move alone until a v6.x re-cut lands.
2. Edge does the consumer-side migration (in parallel, on a feature branch):
   • `pyo3 = "0.29"` (currently 0.28)
   • `pyo3-async-runtimes = "0.29"` (currently 0.28)
   • `pyo3-stub-gen` → the version that pairs with pyo3 0.29 (currently 0.22)
   • Bound-API touch-ups (the issue's original "expected to be small-surface" assessment still holds; most edge code has been on the Bound API since the v0.10.0 capsule cycle)
3. Lens-core follows once edge cuts.
4. deny.toml lifts the RUSTSEC-2026-0176 ignore.

Implication for edge

We can start step 2 against a git-pinned persist v6 commit even before persist re-cuts the published artifact — to validate the migration cleanly without risking a tag against a yanked dep. Once persist publishes the new v6.x, edge re-pins to the released tag and ships.

Not changing the issue's priority; just updating the dependency graph here so the next reader doesn't waste time on the leviculum angle.

[emooreatx]

June 13 17:50 UTC — pyo3 0.29 validation probe results + concrete ask filed

Ran a cold migration probe in an isolated worktree against persist tag = "v6.0.0" (yanked artifact, git tag still good for build-validation) with the full pyo3 0.29 ecosystem bumped. Concrete findings:

Edge-side: ship-ready, small surface (~10 mechanical lines)

1. PyCapsule::reference() removed in 0.29 — 3 call sites in src/ffi/pyo3.rs need the cap.pointer_checked(None)?.as_ptr() as *const T → &* rewrite. Same pattern each time. Sites: line 2381 (generic extract helper), 2502 (trust-scoring), 2571 (local-signer).
2. &Vec<T> → slice.as_slice() for new persist signatures — 3 sites in src/replication/bridge.rs lines 907, 922, 936 (put_organization / put_org_membership / put_partner_record).
3. No BoundListIterator / BoundTupleIterator / Python::detach work needed — those paths don't exist in edge.

Pyo3-stub-gen — a secondary upstream blocker

pyo3-stub-gen = "0.22" has no 0.29-compatible cut. 0.22.3 advertises pyo3 >= 0.26 but fails to compile against 0.29 (PyCapsuleMethods::downcast removed; impl_exception_stub_type! E0119 conflict on PyOSError/PyIOError). No open upstream issue at Jij-Inc/pyo3-stub-gen yet.

Workaround for the real cut: drop dep:pyo3-stub-gen from edge's pyo3 feature, no-op the define_stub_info_gatherer! call, no-op the stub_gen binary. Edge has no active #[gen_stub_*] attributes — every match in src/ is in doc comments — so the surface loss is just the .pyi regenerator, not the bindings themselves. CI's stub-drift gate stays green as long as the existing .pyi is preserved.

TODO follow-up: file an upstream issue at Jij-Inc/pyo3-stub-gen for the 0.29 compatibility. Tracking from edge.

Persist v6.0.0 substrate gaps — 12 compile errors, all substrate

After the bump-and-fix pass, the remaining failures are zero pyo3-API issues and ALL substrate:

• Bucket A — missing v5.6.0 SharedInstanceDirectory (4 errors): persist v6.0.0 was branched before v5.6.0; lacks try_acquire_shared_instance / heartbeat_shared_instance / release_shared_instance_lease / SharedInstanceLease type. Edge consumes all four via v2.3.0 + v2.4.0 paths.
• Bucket B — keyring/verify version-diamond (5 errors): persist v6.0.0 pins keyring/verify v5.1.0; edge pins v5.1.3. Two distinct HardwareSigner / PqcSigner / ThresholdMember trait objects in the dep tree.

Also missing from v6.0.0 (not in edge's hot path today but lens/agent need them): v5.7.0 hard_case.rs + resolve_consent_state, v5.8.0 run_consent_sla_watch.

Ask filed

CIRISPersist#216 — "Cut v6.0.1: forward-port v5.6.0 → v5.8.0 substrate + bump keyring/verify pin to v5.1.3 (unblocks edge's pyo3 0.29 migration)". Full surface-gap list + edge's migration cookbook is in that issue body. Once v6.0.1 ships, edge cuts v2.5.0 with the ~10 mechanical lines above; lens-core follows; this issue closes via deny.toml ignore lift.

Top-line verdict

The Leviculum#14 cold-repro cleared the leviculum attribution. This probe clears the edge-side surface attribution: edge is ready when persist v6.0.1 lands. Persist is the load-bearing mover for the family lockstep.

[emooreatx]

June 13 17:55 UTC — three downstream issues filed, all gate-referenced here

Cross-stack landing pattern: lens-core + registry + CIRISServer all need to move with edge v3.0.0. Filed in parallel:

• CIRISEdge#106 — Rust-native shared edge-runtime acquisition API (init_edge_runtime parity for pure-Rust hosts). Refactor the current #[pyfunction] orchestration into a public Rust fn so CIRISServer (pure-Rust composition binary) can acquire the shared singleton without crossing PyO3. Scoped as the v3.1.0 follow-up once v3.0.0 ships.
• CIRISRegistry#76 — ciris-registry-core::compose() entrypoint + co-bump to persist 6.0.1 / edge 3.0 / verify 5.2.0.
• CIRISLensCore#53 — co-bump lens-core to the persist 6.0.1 / edge 3.0 / verify 5.2.0 floor.

All three name v3.0.0 (this issue) as the lockstep gate.

Family sequencing (post-v3.0.0)

1. Edge v3.0.0 lands (PR release(v3.0.0): family lockstep — pyo3 0.29 + persist v6.0.1 + verify v5.2.0 + leviculum upstream catch-up #105 in CI; ~all-green).
2. Edge v3.1.0 — extract init_edge_runtime's body into Edge::acquire_shared(engine, …) Rust API; the PyO3 surface stays as a thin wrapper. Unblocks CIRISServer.
3. Lens-core + registry co-bump to the new floor + adopt v3.1.0 if they need the Rust acquisition path.
4. CIRISServer Server 1.0 composes registry + lens slices over the one shared Edge.

The RUSTSEC-2026-0176 + RUSTSEC-2026-0177 lift in v3.0.0 closes the substrate-side of this tracker. The Rust-native init refactor is a structural follow-up (separate from the pyo3 0.29 ABI move) — keeping it on a different cut so the v3.0.0 release notes stay scoped to the family lockstep.

[emooreatx]

Closing — edge's part of the family lockstep is shipped. Tracking what landed where:

Crate	pyo3 0.29 cut
ciris-persist	v6.0.1 (first re-land after v6.0.0 yank); current v6.7.0
ciris-verify	v5.2.0 (lockstep with persist v6.0.1); current v5.3.1
ciris-edge	v3.0.0 (family-wide cut); current v3.2.0 (v3.3.0 in PR #113)
ciris-lens-core	pending — still on 1.4.2 / pyo3 0.28; tracked in CIRISLensCore#53

RUSTSEC-2026-0176 + RUSTSEC-2026-0177 ignores were lifted in v3.0.0; cargo deny check advisories is clean. The cohabitation-conformance gate was dropped from edge's publish-pypi needs: list as a structural fix for family-wide major transitions (CIRISLensCore 1.4.2 pinned ciris-persist<6 and couldn't resolve against the new floor). Restoration of the cohab gate is the remaining family-side TODO; tracked separately in a follow-up issue.