chore(deps): take vta-sdk 0.34 and TDK 0.12 so the consumer can move - #37
Merged
Conversation
`vta-sdk` is a 0.x crate, so `"0.32"` here excludes 0.34. OpenVTC depends on
both this crate and vta-sdk directly, and it is moving to the line VTI main
deploys — vta-sdk 0.34, vta-service 0.24, trust-tasks 0.18, TDK 0.12. Until
this requirement moves, its graph carries two sdks, and that is not merely
untidy: `vti-common` re-exports `vta_sdk::acl::{ActScope, ApproveScope,
ContextDirection}` as its own public API, so the copies carry types that
cannot unify and the workspace stops building.
That is the sixth consecutive time this edge has been the blocker (0.23,
0.25, 0.27, 0.31, 0.32, 0.34), so it is a standing obligation rather than an
incident.
Nothing here needs 0.34. What 0.33/0.34 change is the shape of the wire
bodies — VTI #1270/#1271 made `AclEntry` and `AppStateWrite`
`#[non_exhaustive]`, and #1280 replaced `create_acl`'s positional arguments
with `CreateAclParams` — and this workspace names none of those types. It
reaches the VTA through `connect_auto` and takes display names. No source
change; check, clippy, fmt and tests are green.
`affinidi-tdk` goes to 0.12 in the same step because that is what vta-sdk
0.34 declares, and `affinidi-messaging-sdk` follows to 0.22 in the lockfile
for the same reason.
One duplicate remains and it is the documented, bounded one: `trql-client`
is still pinned at the trust-registry PR head, which is built on
trust-tasks-rs 0.17.3, so the tree holds 0.17.3 beside 0.18.6. It reaches
only `verify-trust`, which passes no trust-tasks type across the trql-client
boundary, and `did-git-sign` — the crate OpenVTC consumes — has no
trql-client edge at all. So the check reverts from its unnarrowed form to
asserting the single expected parent, which the manifest comment now spells
out. It clears when the registry moves to 0.18 and publishes.
Signed-off-by: Glenn Gore <glenn.g@affinidi.com>
stormer78
added a commit
to OpenVTC/openvtc
that referenced
this pull request
Sep 8, 2026
* chore(deps): take the vta-sdk 0.34 line the VTA and VTC deploy Refreshes the dependency graph onto what `verifiable-trust-infrastructure` main actually builds against, rather than onto what is newest on crates.io: vta-sdk 0.32.4 -> 0.34.0, trust-tasks-rs / -capability-client 0.17 -> 0.18.5, affinidi-tdk 0.10 -> 0.12, affinidi-messaging-sdk 0.21 -> 0.22, dtg-credentials 0.5 -> 0.6, and the two dev-dependencies that have to move with them — vta-service 0.23 -> 0.24 (MockVta) and affinidi-messaging-test-mediator 0.4 -> 0.5.2. Those are not independent choices. `TrustTask` crosses the vta-sdk boundary in both directions, `vti-common` re-exports `vta_sdk::acl` as its own public API, and the messaging stack carries trust-tasks types in *its* API — so a crate left a line behind is a second, semver-incompatible copy whose types do not unify. The graph now holds exactly one vta-sdk, one trust-tasks-rs, one affinidi-tdk and one affinidi-messaging-sdk across `normal,build,dev`. ## The one source change vta-sdk 0.34 gave `persona_attribute_list` an `include_sensitive` argument, and `pool::list` passes `include_values` through to it. That preserves this client's behaviour exactly, and it is deliberate rather than expedient: the identity pane has one escalation (`show_values`) and this control needs two. `show_values` both asks the agent for values and reveals masked ones whole, so passing `false` would not narrow the read — it would make every `sensitivity: high` attribute come back valueless and render as "(no value)" under a reveal, which is a wrong answer about what the holder holds and one glance from "nothing is stored". `masked_is_not_the_same_state_as_absent` is the test that names that hazard. What this does close is a documentation defect: `claim_types`'s module header stated as fact that the sensitivity half of the registry "does not exist" because the task took `include_values` and nothing finer. It exists now. The header says so, and says what a client needs before it can use it — the `s` reveal fetching that one value on its own. ## Deliberate holds - `dirs` stays at 6 against a published 7. vta-sdk and did-git-sign both declare `^6` and this is the only line that could split them; 7's sole breaking change is `preference_dir` on Windows, and we call `home_dir` and `config_dir`. - `rand` 0.8 and `x25519-dalek` 2 stay where their existing notes put them: pgp 0.20 is still the latest release and still declares both. ## did-git-sign, for the sixth cycle running The published 0.4.6 requires `vta-sdk ^0.27`, which against 0.34 does not merely split the graph — it fails to build. VGI cannot cut 0.4.7 while its `trql-client` git pin stands, so the `[patch.crates-io]` rev moves to the head of OpenVTC/verifiable-git-infrastructure#37 (VGI onto vta-sdk 0.34 / TDK 0.12, no source change, green). The three-deep unwind back to a published 0.4.7 is unchanged and now written out in the patch block. ## cargo-deny Adds RUSTSEC-2026-0173 (proc-macro-error2 unmaintained) to the ignore list — a build-time proc-macro reaching only the dev graph, via vta-service 0.24's new vti-rooms -> openmls -> hpke-rs -> libcrux -> hax-lib chain. Removes RUSTSEC-2025-0134, which no longer matches anything and which cargo-deny warns about for that reason. Gate: fmt, clippy `-D warnings`, `RUSTDOCFLAGS=-D warnings cargo doc`, `cargo deny check` (all four sections), `cargo test --workspace`, and `cargo test --workspace -- --include-ignored` so the MockVta e2es actually run against vta-service 0.24. Default and `--no-default-features` both check. Signed-off-by: Glenn Gore <glenn.g@affinidi.com> * chore(deps): pin the did-git-sign patch to VGI main, now that #37 has merged The rev named the PR branch head. It has merged, tree-identical, as `5111dc1` on VGI main, so the pin moves to that — a commit on `main` rather than one on a branch that can be deleted under it. Nothing else changes: still a `rev` and never a `branch`, still resolving `did-git-sign` 0.4.6 to a tree that builds on vta-sdk 0.34, and the graph still holds one `vta-sdk` and one `trust-tasks-rs` across normal,build,dev. What the merge does *not* discharge is the publish chain, and the manifest comments now say which half moved. 0.4.7 still cannot be released while VGI's own `trql-client` git pin stands, so all three unwind steps — trust-registry #128 publishing `trql-client` 0.15, VGI swapping its pin back to a version and tagging, this workspace deleting the patch block — remain open. Signed-off-by: Glenn Gore <glenn.g@affinidi.com> --------- Signed-off-by: Glenn Gore <glenn.g@affinidi.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
vta-sdkis a 0.x crate, so"0.32"here excludes 0.34. OpenVTC depends on both this crate and vta-sdk directly, and it is moving to the line VTI main deploys — vta-sdk 0.34, vta-service 0.24, trust-tasks 0.18, TDK 0.12. Until this requirement moves, its graph carries two sdks, and that is not merely untidy:vti-commonre-exportsvta_sdk::acl::{ActScope, ApproveScope, ContextDirection}as its own public API, so the copies carry types that cannot unify and the workspace stops building.That is the sixth consecutive time this edge has been the blocker (0.23, 0.25, 0.27, 0.31, 0.32, 0.34), so it is a standing obligation rather than an incident.
Nothing here needs 0.34
What 0.33/0.34 change is the shape of the wire bodies — VTI #1270/#1271 made
AclEntryandAppStateWrite#[non_exhaustive], and #1280 replacedcreate_acl's positional arguments withCreateAclParams— and this workspace names none of those types. It reaches the VTA throughconnect_autoand takes display names. No source change; check, clippy, fmt and tests are green.affinidi-tdkgoes to 0.12 in the same step because that is what vta-sdk 0.34 declares, andaffinidi-messaging-sdkfollows to 0.22 in the lockfile for the same reason.The one remaining duplicate is the documented, bounded one
trql-clientis still pinned at the trust-registry PR head, which is built on trust-tasks-rs 0.17.3, so the tree holds 0.17.3 beside 0.18.6:It reaches only
verify-trust, which passes no trust-tasks type across the trql-client boundary, anddid-git-sign— the crate OpenVTC consumes — has no trql-client edge at all. So the check reverts from its unnarrowed form to asserting that single expected parent, which the manifest comment now spells out. It clears when affinidi-trust-registry-rs#128 moves to 0.18 and publishes.Consumer-side verification
OpenVTC was built against this branch by path-patch before it was pushed: one
vta-sdk, onetrust-tasks-rs, oneaffinidi-tdk, oneaffinidi-messaging-sdkacrossnormal,build,dev; fmt, clippy-D warnings, rustdoc-D warnings,cargo denyall four sections, and the full suite including the#[ignore]d MockVta e2e all green.