chore(deps): take vta-sdk 0.32, TDK 0.10 and the trust-tasks 0.17 trql-client - #33
Merged
Conversation
…l-client Follows the published VTA line, which is the standing obligation this workspace carries: OpenVTC depends on both did-git-sign and vta-sdk directly, so a stale requirement here puts a second vta-sdk — and with it a second copy of the `vti-common`-re-exported ACL types — in its binary. Four minors, no source change. trql-client moves with it, to the head of affinidi-trust-registry-rs#128 rather than to a crates.io version. 0.14.0 is still the registry's latest published crate and declares trust-tasks-rs ^0.9 while vta-sdk 0.31 declares ^0.17, so taking it would have put 0.9.0 and 0.17.3 in the tree together and left the duplicate-copy check narrowed for a third release running. #128 is the move that ends that — the whole registry workspace onto trust-tasks 0.17, TDK 0.10 and vta-sdk 0.31, the same line as here — and it is green on the registry's own pipeline, so the branch head is a better dependency than the stale release. Pinned by rev, not branch. The check is unnarrowed again and passes: `cargo tree -d -e normal,build` lists no trust-tasks-rs and no vta-sdk, and `cargo tree -i vta-sdk` resolves a single node. Remaining duplicates are the pre-existing RustCrypto 0.x/1.0 split under pgp 0.20. The one cost is that `cargo publish` rejects git dependencies, so a `vX.Y.Z` tag would fail publish.yml while this stands. CI on the PR path is unaffected. Swap back to `trql-client = "0.15"` once the registry publishes it, and release from there. Testing. cargo check --workspace --all-targets --all-features clean, clippy clean, fmt clean, cargo test --workspace — 116 passing. Signed-off-by: Glenn Gore <glenn.g@affinidi.com>
stormer78
force-pushed
the
chore/deps-refresh-2026-08
branch
from
August 28, 2026 14:38
a6fd987 to
462032c
Compare
stormer78
changed the title
stormer78
added a commit
to OpenVTC/openvtc
that referenced
this pull request
Aug 28, 2026
Takes the newly published stack: affinidi-tdk 0.8.5 -> 0.10, affinidi-messaging-sdk 0.19 -> 0.21, trust-tasks-rs 0.11 -> 0.17, trust-tasks-capability-client 0.9 -> 0.17, vta-sdk 0.27 -> 0.31, and the dev-only vta-service 0.19 -> 0.22 (0.19 pins vta-sdk 0.28 and vta-keys 0.2, which is what the dev graph's second vta-sdk was made of; the note against that requirement is a standing obligation, and this discharges it again). Two source changes: - `parse_envelope_reply` in trust-tasks-capability-client 0.17 folded the SPEC §4.9 correlation check into the parse and now takes the thread id the caller is waiting on. The inbound dispatch is a fan-in point that waits on nothing in particular, so it reads the document first and classifies against the document's own `threadId`. The correlation that matters is unchanged: `apply_capability_replies` still matches the reply to the open view's `pending_thid` and drops anything else. - `JoinRequestStatusResponseBody` gained `code`, `reason` and `decided_at` (vta-sdk 0.31) — refusal detail carried on a `rejected` status. The e2e helper does not exercise a rejection, so it sends none. NOT MERGEABLE until did-git-sign publishes on vta-sdk 0.31 (OpenVTC/verifiable-git-infrastructure#33): 0.4.6 pins vta-sdk 0.27, and that edge alone re-splits vta-sdk, affinidi-tdk, affinidi-messaging-sdk and trust-tasks-rs into two copies each. Verified green against a local path patch of did-git-sign: workspace checks clean, 910 tests passing. Claude-Session: https://claude.ai/code/session_01H6NJ4J9ngaNUXgRd4BFjVz Signed-off-by: Glenn Gore <glenn.g@affinidi.com>
stormer78
added a commit
to OpenVTC/openvtc
that referenced
this pull request
Aug 28, 2026
Takes the newly published stack: affinidi-tdk 0.8.5 -> 0.10, affinidi-messaging-sdk 0.19 -> 0.21, trust-tasks-rs 0.11 -> 0.17, trust-tasks-capability-client 0.9 -> 0.17, vta-sdk 0.27 -> 0.31, and the dev-only vta-service 0.19 -> 0.22 (0.19 pins vta-sdk 0.28 and vta-keys 0.2, which is what the dev graph's second vta-sdk was made of; the note against that requirement is a standing obligation, and this discharges it again). Two source changes: - `parse_envelope_reply` in trust-tasks-capability-client 0.17 folded the SPEC §4.9 correlation check into the parse and now takes the thread id the caller is waiting on. The inbound dispatch is a fan-in point that waits on nothing in particular, so it reads the document first and classifies against the document's own `threadId`. The correlation that matters is unchanged: `apply_capability_replies` still matches the reply to the open view's `pending_thid` and drops anything else. - `JoinRequestStatusResponseBody` gained `code`, `reason` and `decided_at` (vta-sdk 0.31) — refusal detail carried on a `rejected` status. The e2e helper does not exercise a rejection, so it sends none. NOT MERGEABLE until did-git-sign publishes on vta-sdk 0.31 (OpenVTC/verifiable-git-infrastructure#33): 0.4.6 pins vta-sdk 0.27, and that edge alone re-splits vta-sdk, affinidi-tdk, affinidi-messaging-sdk and trust-tasks-rs into two copies each. Verified green against a local path patch of did-git-sign: workspace checks clean, 910 tests passing. Signed-off-by: Glenn Gore <glenn.g@affinidi.com>
stormer78
added a commit
to OpenVTC/openvtc
that referenced
this pull request
Aug 28, 2026
Takes the newly published stack: affinidi-tdk 0.8.5 -> 0.10, affinidi-messaging-sdk 0.19 -> 0.21, trust-tasks-rs 0.11 -> 0.17, trust-tasks-capability-client 0.9 -> 0.17, vta-sdk 0.27 -> 0.31, the dev-only vta-service 0.19 -> 0.22 and affinidi-messaging-test-mediator 0.2 -> 0.4, plus argon2 0.5 -> 0.6 — after which no direct requirement in this workspace is behind its latest release except the two that are held deliberately (x25519-dalek at 2.x by the OpenPGP stack, rand at 0.8 by the crypto stack), both with the reason written against the line. argon2 derives key material, so it is worth saying why the bump is safe: Argon2id is a specified KDF and `derive_argon2_key` calls `hash_password_into`, its plain implementation. Same algorithm, version and params in, same 32 bytes out — the unlock code and the `ProtectedConfig` seed are byte-identical across it and every existing config still opens. What 0.6 breaks is the `password-hash` 0.6 PHC-string surface, which we do not touch. ## did-git-sign comes from VGI#33's head, not from crates.io `did-git-sign` 0.4.6 is the latest published release and requires `vta-sdk ^0.27`. That single edge re-splits vta-sdk, affinidi-tdk, affinidi-messaging-sdk and trust-tasks-rs into two copies each — and it does not merely fail to unify types, it fails to compile: vta-keys 0.2.9 does not build against vti-common 0.15. OpenVTC/verifiable-git-infrastructure#33 is the move that ends it — the VGI workspace onto vta-sdk 0.31 and TDK 0.10, no source change, green on its own pipeline. Rather than block on the publish, a `[patch.crates-io]` entry redirects `did-git-sign` (and its path-dep `vgi-core`) to that PR's head. The requirement in `openvtc/Cargo.toml` still names 0.4.6, which is the version VGI carries at that rev; the patch decides only where 0.4.6 comes from. Pinned by rev, never by branch, so a further push to that PR cannot silently change what this builds against — the same discipline VGI itself applies to `trql-client`. Both git sources are allow-listed in `deny.toml`, and `publish = false` here, so a git source costs this workspace nothing on its own release path. Delete the patch block and raise the floor to 0.4.7 once VGI publishes. That is the fourth consecutive cycle this obligation has come due, so the note is written as the rule rather than as this version's incident. With it, `cargo tree -i vta-sdk` and `cargo tree -i trust-tasks-rs` each resolve a single node. Remaining duplicates are upstream RustCrypto 0.x / 1.0 splits no line here controls. ## Source changes - `parse_envelope_reply` in trust-tasks-capability-client 0.17 folded the SPEC §4.9 correlation check into the parse and now takes the thread id the caller is waiting on. The inbound dispatch is a fan-in point that waits on nothing in particular, so it reads the document first and classifies against the document's own `threadId`. The correlation that matters is unchanged: `apply_capability_replies` still matches the reply to the open view's `pending_thid` and drops anything else. - `JoinRequestStatusResponseBody` gained `code`, `reason` and `decided_at` (vta-sdk 0.31) — refusal detail carried on a `rejected` status. The e2e helper does not exercise a rejection, so it sends none. - vta-sdk 0.31 stopped accepting `VtaClient::new` + `set_token` for a client that dispatches Trust Tasks. A bearer token authenticates the *connection*; SPEC §7.2 items 5b and 7a want an in-band `recipient` and a document `proof`, which the client can only produce from a `ClientIdentity`. The setup wizard's REST arm was hand-rolling exactly that shape — it authenticates separately because it needs the token itself to cache — so the very next dispatch on that client, the context probe, would have failed with "authenticated but carries no ClientIdentity". It now builds the client the way `connect_auto`'s REST arm does. The two `mockvta_bootstrap_e2e` clients had the same shape and are the reason this was caught: they are `#[ignore]`d, so only the coverage job (`--include-ignored`) runs them, and they now authenticate as a real `did:key` whose token is minted for that same DID — item 6 rejects a document whose in-band issuer disagrees with the identity the transport authenticated as. - Rust 1.98's clippy flags the nested `if let` in the envelope dispatch as `collapsible_if`; it is a let chain now, which edition 2024 has had since well before the 1.95 MSRV. ## Testing cargo fmt / clippy (on 1.98, the toolchain that flagged the lint) / doc with `-D warnings` / cargo-deny (advisories, licenses, bans, sources) / `cargo check` on the 1.95 MSRV / `cargo bench --no-run` all clean. `cargo test --workspace --tests -- --include-ignored` — 921 passing, 0 failed, including the three MockVta bootstrap e2es that the coverage job runs. `cargo test --workspace --no-default-features` clean. Signed-off-by: Glenn Gore <glenn.g@affinidi.com> Claude-Session: https://claude.ai/code/session_016rR4AnzuwoVXX1MU8aaRKB
stormer78
added a commit
to OpenVTC/openvtc
that referenced
this pull request
Aug 28, 2026
Takes the newly published stack: affinidi-tdk 0.8.5 -> 0.10, affinidi-messaging-sdk 0.19 -> 0.21, trust-tasks-rs 0.11 -> 0.17, trust-tasks-capability-client 0.9 -> 0.17, vta-sdk 0.27 -> 0.31, the dev-only vta-service 0.19 -> 0.22 and affinidi-messaging-test-mediator 0.2 -> 0.4, plus argon2 0.5 -> 0.6 — after which no direct requirement in this workspace is behind its latest release except the two that are held deliberately (x25519-dalek at 2.x by the OpenPGP stack, rand at 0.8 by the crypto stack), both with the reason written against the line. argon2 derives key material, so it is worth saying why the bump is safe: Argon2id is a specified KDF and `derive_argon2_key` calls `hash_password_into`, its plain implementation. Same algorithm, version and params in, same 32 bytes out — the unlock code and the `ProtectedConfig` seed are byte-identical across it and every existing config still opens. What 0.6 breaks is the `password-hash` 0.6 PHC-string surface, which we do not touch. ## did-git-sign comes from VGI#33's head, not from crates.io `did-git-sign` 0.4.6 is the latest published release and requires `vta-sdk ^0.27`. That single edge re-splits vta-sdk, affinidi-tdk, affinidi-messaging-sdk and trust-tasks-rs into two copies each — and it does not merely fail to unify types, it fails to compile: vta-keys 0.2.9 does not build against vti-common 0.15. OpenVTC/verifiable-git-infrastructure#33 is the move that ends it — the VGI workspace onto vta-sdk 0.31 and TDK 0.10, no source change, green on its own pipeline. Rather than block on the publish, a `[patch.crates-io]` entry redirects `did-git-sign` (and its path-dep `vgi-core`) to that PR's head. The requirement in `openvtc/Cargo.toml` still names 0.4.6, which is the version VGI carries at that rev; the patch decides only where 0.4.6 comes from. Pinned by rev, never by branch, so a further push to that PR cannot silently change what this builds against — the same discipline VGI itself applies to `trql-client`. Both git sources are allow-listed in `deny.toml`, and `publish = false` here, so a git source costs this workspace nothing on its own release path. Delete the patch block and raise the floor to 0.4.7 once VGI publishes. That is the fourth consecutive cycle this obligation has come due, so the note is written as the rule rather than as this version's incident. With it, `cargo tree -i vta-sdk` and `cargo tree -i trust-tasks-rs` each resolve a single node. Remaining duplicates are upstream RustCrypto 0.x / 1.0 splits no line here controls. ## Source changes - `parse_envelope_reply` in trust-tasks-capability-client 0.17 folded the SPEC §4.9 correlation check into the parse and now takes the thread id the caller is waiting on. The inbound dispatch is a fan-in point that waits on nothing in particular, so it reads the document first and classifies against the document's own `threadId`. The correlation that matters is unchanged: `apply_capability_replies` still matches the reply to the open view's `pending_thid` and drops anything else. - `JoinRequestStatusResponseBody` gained `code`, `reason` and `decided_at` (vta-sdk 0.31) — refusal detail carried on a `rejected` status. The e2e helper does not exercise a rejection, so it sends none. - vta-sdk 0.31 stopped accepting `VtaClient::new` + `set_token` for a client that dispatches Trust Tasks. A bearer token authenticates the *connection*; SPEC §7.2 items 5b and 7a want an in-band `recipient` and a document `proof`, which the client can only produce from a `ClientIdentity`. The setup wizard's REST arm was hand-rolling exactly that shape — it authenticates separately because it needs the token itself to cache — so the very next dispatch on that client, the context probe, would have failed with "authenticated but carries no ClientIdentity". It now builds the client the way `connect_auto`'s REST arm does. The two `mockvta_bootstrap_e2e` clients had the same shape and are the reason this was caught: they are `#[ignore]`d, so only the coverage job (`--include-ignored`) runs them, and they now authenticate as a real `did:key` whose token is minted for that same DID — item 6 rejects a document whose in-band issuer disagrees with the identity the transport authenticated as. - Rust 1.98's clippy flags the nested `if let` in the envelope dispatch as `collapsible_if`; it is a let chain now, which edition 2024 has had since well before the 1.95 MSRV. ## Testing cargo fmt / clippy (on 1.98, the toolchain that flagged the lint) / doc with `-D warnings` / cargo-deny (advisories, licenses, bans, sources) / `cargo check` on the 1.95 MSRV / `cargo bench --no-run` all clean. `cargo test --workspace --tests -- --include-ignored` — 921 passing, 0 failed, including the three MockVta bootstrap e2es that the coverage job runs. `cargo test --workspace --no-default-features` clean. Claude-Session: https://claude.ai/code/session_016rR4AnzuwoVXX1MU8aaRKB Signed-off-by: Glenn Gore <glenn.g@affinidi.com>
|
🛡️ AI Agentic Security Code Review — all clear. We checked this change and found nothing to report. Keep shipping secure code! Note: for major, breaking, or feature-introducing changes, you can always request an in-depth review from the security team. |
A *follow*, not a choice. `vta-sdk` is 0.x, so `"0.31"` excludes 0.32, and a consumer that takes 0.32 while this crate asks for 0.31 ends up with two copies of `vta-sdk` in one graph — which do not unify, so the workspace stops building. This crate is the edge that decides when OpenVTC may move, and it has now been the thing in the way five times: 0.23, 0.25, 0.27, 0.31, 0.32. Nothing here needs anything 0.32 added. `did-git-sign` reaches the VTA through `connect_auto` and takes display names; `ClientIdentity` grew a `verification_method` member (VTI #1193) and nothing in this workspace names that type, so the bump is the manifest and the lockfile. No other requirement moves with it: vta-sdk 0.32 keeps trust-tasks-rs 0.17, affinidi-tdk 0.10 and affinidi-messaging-sdk 0.21 — the same line this workspace already resolves — and `trql-client` does not depend on `vta-sdk` at all, so the pinned trust-registry rev stays where it is. `cargo tree -i vta-sdk` reports one row (0.32.0, from did-git-sign and verify-trust). fmt, `clippy --workspace --all-targets -D warnings` and `cargo test --workspace` all clean. Signed-off-by: Glenn Gore <glenn.g@affinidi.com>
stormer78
force-pushed
the
chore/deps-refresh-2026-08
branch
2 times, most recently
from
August 29, 2026 02:10
f4604bf to
d2c091d
Compare
stormer78
changed the title
Merged
stormer78
added a commit
that referenced
this pull request
Aug 30, 2026
Releases the `vta-sdk` 0.32 / TDK 0.10 / trust-tasks 0.17 move from #33. The reason to cut it now is the one 0.4.5 and 0.4.6 both had. OpenVTC is on `vta-sdk` 0.32.1 and `trust-tasks-rs` 0.17, while the published `did-git-sign` 0.4.6 requires `vta-sdk ^0.27` — one edge that pulls a second `vta-sdk` back into OpenVTC's graph. OpenVTC has been working around exactly that with a `[patch.crates-io]` block pinning `did-git-sign` and `vgi-core` to a VGI commit, which until #33 landed was a commit on an unmerged branch. Publishing 0.4.7 is what lets that block be deleted rather than re-pointed, which is what its own comment asks for. Version bump only; `cargo test --workspace` is green (116 tests). 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
2 participants
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.
Part of the stack-wide refresh onto the newly published trust-tasks / TDK / VTA-SDK releases.
vta-sdkaffinidi-tdktrql-clientNo source change in this workspace.
vta-sdk
A follow, not a choice.
vta-sdkis 0.x, so"0.31"excludes 0.32, and a consumer that takes 0.32 while this crate asks for 0.31 ends up with two copies ofvta-sdkin one graph — which do not unify, so the workspace stops building.vti-commonre-exportsvta_sdk::acl::*as its own public API, so this is where that bites.This crate is the edge that decides when OpenVTC may move, and it has now been the thing in the way five times: 0.23, 0.25, 0.27, 0.31, 0.32. The bump exists so the ceiling moves.
Nothing here needs anything 0.32 added —
did-git-signreaches the VTA throughconnect_autoand takes display names;ClientIdentitygrew averification_methodmember (VTI #1193) and nothing in this workspace names that type — so the change is the manifest and the lockfile.No other requirement moves with it: vta-sdk 0.32 keeps
trust-tasks-rs0.17,affinidi-tdk0.10 andaffinidi-messaging-sdk0.21, the same line this workspace already resolves.trql-client goes to a git rev, not to 0.14
0.14.0 is still the registry's latest published crate and it declares
trust-tasks-rs ^0.9, while vta-sdk declares^0.17. Taking it would have put 0.9.0 and 0.17.3 in the tree together and kept the duplicate-copy check narrowed for a third release running.affinidi/affinidi-trust-registry-rs#128 is the move that ends that — the whole registry workspace onto trust-tasks 0.17, TDK 0.10 and vta-sdk 0.31 — and it is green on the registry's own pipeline, so its head is a better dependency than the stale release. Pinned by
rev(22bb9a3), never bybranch, so a further push to that PR cannot silently change what this builds against.That PR has since moved to
ec0030f(taking vta-sdk 0.31.1 for a DIDComm client-identity fix), and the rev here deliberately stays put:trql-clientdoes not depend onvta-sdkat all, and that commit touches only the registry workspace's own manifest and lockfile, sotrql-clientis identical at both revs and re-pinning would be churn with no effect on the resolved graph.Checks
cargo tree -i vta-sdk→ one row,0.32.0, fromdid-git-signandverify-trustcargo tree -d -e normal,build→ notrust-tasks-rs, novta-sdk, notrql-client, noaffinidi-*cargo tree -i trust-tasks-rs→ single0.17.3, withtrql-client,vta-sdkandaffinidi-messaging-sdkall under itRemaining duplicates in the tree are the pre-existing RustCrypto 0.x/1.0 split under
pgp0.20.The one cost, and how it unwinds
cargo publishrejects git dependencies, so avX.Y.Ztag would failpublish.ymlwhile this line stands. Nothing on the PR path is affected — CI here runs fmt/clippy/check/MSRV/test only, and there is nocargo-denysourcescheck to trip on a git source.Do not cut a release until #128 is merged and published. At that point this becomes a one-line change back to
trql-client = "0.15", and release proceeds normally. The requirement comment says so in place.Testing
cargo check --workspace --all-targets --all-featuresclean;cargo clippy --workspace --all-targets -D warningsclean;cargo fmt --all --checkclean;cargo test --workspace— 116 passing.