chore(deps): bump coset from 0.3.8 to 0.4.2 - #1494
Conversation
Bumps [coset](https://github.com/google/coset) from 0.3.8 to 0.4.2. - [Changelog](https://github.com/google/coset/blob/main/CHANGELOG.md) - [Commits](google/coset@v0.3.8...v0.4.2) --- updated-dependencies: - dependency-name: coset dependency-version: 0.4.2 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
tangletools
left a comment
tangletools
left a comment
There was a problem hiding this comment.
🟢 Value Audit — sound
| Verdict | sound |
| Concerns | 1 (1 weak-concern) |
| Heuristic | 0.0s |
| Duplication | 0.0s |
| Interrogation | 671.5s (2 bridge agents) |
| Total | 671.5s |
💰 Value — sound
Bumps coset 0.3.8→0.4.2 in the workspace manifest + the blueprint-remote-providers dev-deps; the repo only touches APIs that are unchanged across the 0.3→0.4 break, so it ships clean.
- What it does: Raises the coset dependency floor from 0.3 to 0.4 across two manifests (Cargo.toml:298 workspace entry, crates/blueprint-remote-providers/Cargo.toml:102 dev-dep) and regenerates Cargo.lock (5057-5061). No source changes.
- Goals it achieves: Keeps the COSE parsing library (used by the AWS Nitro attestation verifier in crates/tee/src/attestation/providers/aws_nitro.rs:15 and the synthetic-COSE test fixtures in crates/blueprint-remote-providers/tests/tee_attestation.rs:433) on a current release — pulls in the 0.4.1 MSRV bump, std Error impl, new IANA algorithm values, and the 0.4.2 ML-DSA key builder.
- Assessment: Coherent and minimal. The 0.4.0 breaking change is the type of Header.crit plus deprecation of verify_tag/decrypt; I grepped the repo's entire coset surface (rg 'coset' under crates/) and the only symbols used are CborSerializable, CoseSign1, TaggedCborSerializable, CoseSign1Builder, HeaderBuilder, and coset::iana::Algorithm::ES384 — none touched by the break. Both manifest edits move in lockstep
- Better / existing approach: none — this is the right approach. Verified the only two consumers and confirmed no usage of the 0.4.0 breaking surface; no existing in-repo COSE abstraction to reuse (coset is itself the canonical COSE library and is already the workspace choice).
- Model: opencode/zai-coding-plan/glm-5.2
- Bridge attempts: 2
- Bridge warning: opencode/kimi-for-coding/k2p7: opencode: opencode error
🎯 Usefulness — sound
Clean dependency bump of coset 0.3 -> 0.4 on a real, reachable path (AWS Nitro COSE attestation verifier); the 0.4 breaking changes do not touch any API surface used in this workspace.
- Integration: coset is consumed in exactly two places, both live and reachable: the production AWS Nitro verifier at crates/tee/src/attestation/providers/aws_nitro.rs:15 (imports CborSerializable, CoseSign1, TaggedCborSerializable) and its integration test at crates/blueprint-remote-providers/tests/tee_attestation.rs:433,505 (CoseSign1Builder, HeaderBuilder, iana::Algorithm::ES384). The verifier is wired into t
- Fit with existing patterns: This is a routine workspace-dependency bump, fully in the grain of the codebase. coset is already a workspace dep (Cargo.toml:298) and the bump simply moves the minimum-version floor from
0.3to0.4in two manifests. No competing pattern, no new abstraction introduced. - Real-world viability: Holds up: the coset 0.4.0 breaking change (type of the
critHeader field) and the deprecated methods (CoseMac::verify_tag, CoseEncrypt/CoseRecipient::decrypt) do not touch any symbol referenced in this workspace — confirmed by grepping the full tree for.crit,verify_tag, and coset-typed.decrypt((all.decrypt()matches are on chacha20poly1305/envelope types, not coset). The MSRV bump t - Model: opencode/zai-coding-plan/glm-5.2
- Bridge attempts: 1
🎯 Usefulness Audit
🟡 blueprint-remote-providers declares coset inline instead of via workspace = true [ergonomics] ``
crates/blueprint-remote-providers/Cargo.toml:102 uses
coset = { version = "0.4" }while the sibling tee crate usescoset = { workspace = true, optional = true }(crates/tee/Cargo.toml:56). The workspace already centralizes coset at Cargo.toml:298. This PR touched the inline line, so it could have folded it into the workspace dep for consistency (same applies to ciborium/p384/rcgen in that block). Pre-existing inconsistency, not introduced here, and does not gate shipping — just leaves two ve
What this audit checks
It judges the change on its merits — not whether it was tasked out in an issue. Unticketed, fast-moving work is fine; the question is whether the change is good and whether a better or existing approach should be used instead.
| Pass | What it asks |
|---|---|
| Heuristic | Vague title? Whitespace-only or cruft-bearing diff? (content signals only) |
| Duplication | Do added function/class names already exist elsewhere in the repo? |
| Value Audit | What does it do? What goal does it achieve? Is it good? Better architecture or already-exists? |
| Usefulness Audit | Does it integrate and fit? Will it hold up in real use and actually get used? |
Findings are concerns, not blocks — the human reviewer decides what to do with them.
|
| State | Detail |
|---|---|
| Interrupted | webhook restarted |
No review verdict was produced for this run. Trigger a fresh review on the current PR head if the PR is still open.
tangletools · #1494 · model: kimi-for-coding · updated 2026-08-03T12:51:30Z
tangletools
left a comment
tangletools
left a comment
There was a problem hiding this comment.
🟡 Value Audit — sound-with-nits
| Verdict | sound-with-nits |
| Concerns | 2 (2 weak-concern) |
| Heuristic | 0.0s |
| Duplication | 0.0s |
| Interrogation | 46.6s (2 bridge agents) |
| Total | 46.6s |
💰 Value — sound-with-nits
Routine, safe bump of coset 0.3.8 → 0.4.2; the 0.4.0 breaking changes don't touch any API this repo uses, and one small workspace-dep centralization opportunity was missed while editing these exact lines.
- What it does: Bumps the
cosetcrate (COSE/CBOR for TEE attestation) across the workspace: Cargo.lock 0.3.8→0.4.2, workspace Cargo.tomlversion = "0.3"→"0.4", and the blueprint-remote-providers dev-dep0.3→0.4. Gains ML-DSA post-quantum key helpers, new IANA COSE algorithm values, and core Error impl; MSRV moves to 1.81 (workspace is on 1.88). - Goals it achieves: Keep the TEE-attestation crypto dep current (maintenance/security hygiene) and pick up post-quantum (ML-DSA) and additional IANA algorithm support for future attestation work. The bump is the standard dependabot-style version-floor raise (
0.3→0.4) plus a lock refresh. - Assessment: Good change, low risk. I grepped every coset usage (crates/tee/src/attestation/providers/aws_nitro.rs:15 uses CborSerializable/CoseSign1/TaggedCborSerializable; crates/blueprint-remote-providers/tests/tee_attestation.rs:433,505 use CoseSign1Builder/HeaderBuilder/iana::Algorithm::ES384) and none of them touch the three breaking changes in 0.4.0: the
critHeader field type change, the deprecated ` - Better / existing approach: none — this is the right approach. Searched for whether an existing workspace or higher-level attestation crate already centralizes coset versioning; the workspace Cargo.toml:298 already defines
coset = { version = "0.4", default-features = false }and crates/tee/Cargo.toml:56 correctly consumes it viaworkspace = true. The only gap is the dev-dep in blueprint-remote-providers. - Model: opencode/zai-coding-plan/glm-5.2
- Bridge attempts: 2
- Bridge warning: opencode/kimi-for-coding/k2p7: opencode: opencode error
🎯 Usefulness — sound
Routine coset 0.3.8 → 0.4.2 bump; none of the 0.4.0 breaking changes touch the APIs the Nitro COSE verifier or its tests actually use, and both the workspace and test-crate version pins are updated consistently.
- Integration: Reachable and exercised. coset is consumed by the AWS Nitro attestation verifier (crates/tee/src/attestation/providers/aws_nitro.rs:15,100-101,443) and its integration test (crates/blueprint-remote-providers/tests/tee_attestation.rs:433,504-507). Both paths compile against the 0.4 API surface — the parsed/built types (CoseSign1, CoseSign1Builder, HeaderBuilder, iana::Algorithm) are unchanged acros
- Fit with existing patterns: Fits the codebase pattern exactly. The workspace Cargo.toml is the single source of truth for coset (crates/tee/Cargo.toml:56 references it via
workspace = true), and the bump keeps that contract. The one outlier is crates/blueprint-remote-providers/Cargo.toml:102 pinning coset directly instead of via workspace — but that predates this PR (was alreadyversion = "0.3") and is a test-only dep, s - Real-world viability: The 0.4.0 changelog lists three breaking changes: Header
critfield type change, and deprecation ofCoseMac[0]::verify_tag/CoseEncrypt[0]::decrypt/CoseRecipient::decrypt. Grep across the workspace shows zero usage ofcrit,verify_tag,.decrypt, ordecrypt_ciphertext— this codebase does its own signature verification via x509_parser+p384 and only uses coset for CBOR (de)seriali - Model: opencode/zai-coding-plan/glm-5.2
- Bridge attempts: 1
🎯 Usefulness Audit
🟡 Test-crate pins coset directly instead of via workspace [integration] ``
crates/blueprint-remote-providers/Cargo.toml:102 declares
coset = { version = "0.4" }directly rather thancoset = { workspace = true }like crates/tee/Cargo.toml:56 does. This is pre-existing (wasversion = "0.3"before this PR) and only affects test deps, so it does not gate the bump — but folding it into the workspace dep would prevent this exact two-line bump from being needed again on the next coset release.
💰 Value Audit
🟡 blueprint-remote-providers dev-dep could use workspace = true [maintenance] ``
crates/blueprint-remote-providers/Cargo.toml:102 declares
coset = { version = "0.4" }directly in [dev-dependencies] even though the workspace root (Cargo.toml:298) already declares coset. crates/tee/Cargo.toml:56 already follows the workspace pattern (coset = { workspace = true, optional = true }). Since this PR is editing exactly that line, it could centralize tocoset = { workspace = true }to avoid future version drift (the 0.3→0.4 bump had to be made in two places for exactly this rea
What this audit checks
It judges the change on its merits — not whether it was tasked out in an issue. Unticketed, fast-moving work is fine; the question is whether the change is good and whether a better or existing approach should be used instead.
| Pass | What it asks |
|---|---|
| Heuristic | Vague title? Whitespace-only or cruft-bearing diff? (content signals only) |
| Duplication | Do added function/class names already exist elsewhere in the repo? |
| Value Audit | What does it do? What goal does it achieve? Is it good? Better architecture or already-exists? |
| Usefulness Audit | Does it integrate and fit? Will it hold up in real use and actually get used? |
Findings are concerns, not blocks — the human reviewer decides what to do with them.
✅ No Blockers —
|
| glm | deepseek | deepseek-flash | aggregate | |
|---|---|---|---|---|
| Readiness | 92 | 95 | 95 | 92 |
| Confidence | 75 | 75 | 75 | 75 |
| Correctness | 92 | 95 | 95 | 92 |
| Security | 92 | 95 | 95 | 92 |
| Testing | 92 | 95 | 95 | 92 |
| Architecture | 92 | 95 | 95 | 92 |
Reviewer score is advisory once the run is complete and the verdict has no blockers.
Full multi-shot audit completed 3/3 planned shots over 3 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 3/3 planned shots over 3 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 3/3 planned shots over 3 changed files. Global verifier still owns final merge decision.
🟡 LOW Dev-dep not migrated to workspace = true (pre-existing inconsistency) — crates/blueprint-remote-providers/Cargo.toml
The dev-dep uses
coset = { version = "0.4" }(default features on) while the workspace dep at Cargo.toml:298 iscoset = { version = "0.4", default-features = false }. Cargo unifies them and pulls default features into the test build, which is intentional and harmless for test-only code (CoseSign1Builder requires default features). This matches the existing pattern in the same dev-deps block (rsa, p384, ciborium, rcgen all pin versions directly rather than via workspace). Not blocking; flagged only for awareness — if the intent is full workspace unification, a follow-up could convert the entire block. Out of scope for this PR.
tangletools · 2026-08-03T13:41:54Z · trace
tangletools
left a comment
tangletools
left a comment
There was a problem hiding this comment.
✅ Approved — 1 non-blocking finding — 210c24a8
Full multi-shot audit completed 3/3 planned shots over 3 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 3/3 planned shots over 3 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 3/3 planned shots over 3 changed files. Global verifier still owns final merge decision.
Full immutable report for this review: trace
Summary comment for this run: full summary
tangletools · 2026-08-03T13:41:54Z · immutable trace
1 participant
Bumps coset from 0.3.8 to 0.4.2.
Changelog
Sourced from coset's changelog.
Commits
dd45835Prep for 0.4.2 release (#128)2aeca36Add helper for ML-DSA public key creation (#127)4beb232Prep for 0.4.1 release (#124)e9f50b0ci: bump cargo-deny to 0.19.0 (#126)cc539b1Use core version of Error in new helper (#125)13f664eMove to use core version of Errord75003cMove MSRV to 1.8172a3dffTweak tests for more code coverage (#123)c3a8159Convert EC2 keys to/from SEC1 octet stringsaf95fb5ci: use fixed version of mdlDependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)