Repository navigation
chore: bump ic-management-canister-types to 0.11.0 - #11909
Merged
Merged
Conversation
Bump the workspace dependency from 0.8.0 to 0.11.0, the first version with `EcdsaCurve::Secp256r1`, so that `ic-pub-key` can use it instead of the in-repo crate. 0.9.0 to 0.11.0 only add items. The new `CanisterSettings` and `DefiniteCanisterSettings` fields `minimum_incoming_canister_call_cycles` and `status_visibility` need: - canister_test: set them in the struct literal that lists every field. - CMC: declare them in cmc.did. The CMC now forwards them in `create_canister` and `notify_create_canister` instead of dropping them, which unreleased_changelog.md records. - ckDOGE minter: declare them in ckdoge_minter.did, since `get_canister_status` returns them. `pocket-ic` and `ic-pub-key` re-export these types, so their changelogs record the bump. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
The dependency pins and interface updates are consistent, with no blocking issues identified in static review; builds and tests were not run.
No open issues 🎉
What changed in this PR
Upgrades the workspace management-canister types to 0.11.0, enabling the secp256r1 support needed by #11894.
Changes:
- Synchronizes Cargo and Bazel dependencies and lockfiles.
- Updates canister settings initialization and Candid interfaces for the new fields.
- Documents CMC behavior and public type changes.
| File | Description |
|---|---|
| rs/rust_canisters/canister_test/src/canister.rs | Initializes the two new optional settings. |
| rs/nns/cmc/unreleased_changelog.md | Documents forwarding the new settings. |
| rs/nns/cmc/cmc.did | Exposes the new optional settings. |
| rs/dogecoin/ckdoge/minter/ckdoge_minter.did | Extends returned canister settings. |
| packages/pocket-ic/CHANGELOG.md | Records the re-exported type changes. |
| packages/ic-pub-key/CHANGELOG.md | Records the dependency upgrade. |
| Cargo.toml | Bumps the workspace dependency. |
| Cargo.lock | Updates workspace dependency resolutions. |
| Cargo.Bazel.toml.lock | Locks the upgraded Bazel dependency. |
| Cargo.Bazel.json.lock | Updates Bazel crate metadata and resolution. |
| bazel/rust.MODULE.bazel | Matches the Cargo dependency version. |
Review effort: Balanced
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
This pull request changes code owned by the Governance team. Therefore, make sure that
you have considered the following (for Governance-owned code):
-
Update
unreleased_changelog.md(if there are behavior changes, even if they are
non-breaking). -
Are there BREAKING changes?
-
Is a data migration needed?
-
Security review?
How to Satisfy This Automatic Review
-
Go to the bottom of the pull request page.
-
Look for where it says this bot is requesting changes.
-
Click the three dots to the right.
-
Select "Dismiss review".
-
In the text entry box, respond to each of the numbered items in the previous
section, declare one of the following:
-
Done.
-
$REASON_WHY_NO_NEED. E.g. for
unreleased_changelog.md, "No
canister behavior changes.", or for item 2, "Existing APIs
behave as before.".
Brief Guide to "Externally Visible" Changes
"Externally visible behavior change" is very often due to some NEW canister API.
Changes to EXISTING APIs are more likely to be "breaking".
If these changes are breaking, make sure that clients know how to migrate, how to
maintain their continuity of operations.
If your changes are behind a feature flag, then, do NOT add entrie(s) to
unreleased_changelog.md in this PR! But rather, add entrie(s) later, in the PR
that enables these changes in production.
Reference(s)
For a more comprehensive checklist, see here.
GOVERNANCE_CHECKLIST_REMINDER_DEDUP
|
✅ No security or compliance issues detected. Reviewed everything up to abd0174. Security OverviewDetected Code Changes
|
basvandijk
approved these changes
Oct 21, 2026
|
✅ No security or compliance issues detected. Reviewed everything up to abd0174. Security OverviewDetected Code Changes
|
alin-at-dfinity
approved these changes
Oct 21, 2026
eichhorl
dismissed
github-actions[bot]’s stale review
October 21, 2026 08:57
🤖 1. Done: rs/nns/cmc/unreleased_changelog.md has an entry for the two new optional CanisterSettings fields.
2. No breaking changes: both fields are optional additions to the input record, so existing calls behave as before.
3. No data migration: the CMC does not store canister settings. It forwards them to create_canister within the same call.
4. No security review needed: the new canister's controllers can already set both settings with update_settings, and the management canister validates them.
Resolve the Cargo.Bazel.json.lock conflict with #11910. Cargo.lock and Cargo.Bazel.toml.lock are git's 3-way merges. Cargo.Bazel.json.lock is regenerated by `./bin/bazel-pin.sh ic-management-canister-types@0.11.0`, which leaves the toml lock unchanged. All three lock files differ from master exactly as this PR's commit did, apart from the json checksum. Repinning from master's locks instead also moves quinn, quinn-udp and hyper-util to socket2 0.6.5, and several crates to windows-sys 0.61.2, in the Bazel locks only. That is unrelated to this PR, so it's avoided. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Extend test_cmc_notify_create_with_settings and test_cmc_cycles_create_with_settings: create a canister with minimum_incoming_canister_call_cycles and status_visibility set, and assert both values in its status. The candid test only checks the schema, so it would not notice the CMC dropping them. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
daniel-wong-dfinity-org-twin
approved these changes
Oct 23, 2026
Resolve the Cargo.lock conflict with #11924, which added ic-nns-common next to the engine controller's ic-management-canister-types entry. Cargo.lock is master's with the bump re-applied by cargo, which adds only ic-management-canister-types 0.11.0 and switches the same 30 references. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
eichhorl
enabled auto-merge
October 23, 2026 12:14
eichhorl
added a commit
that referenced
this pull request
Oct 23, 2026
Resolve two conflicts with #11909: - CHANGELOG.md: keep #11909's line for ic-management-canister-types 0.5.0 -> 0.11.0 once, next to this PR's entries. - Cargo.lock: master's, with cargo re-applying this PR's change to the ic-pub-key entry. The ic-secp256r1 changes this branch carried from #11895 are identical to master's squash commit, so they drop out of the diff. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
eichhorl
added a commit
that referenced
this pull request
Oct 23, 2026
#11909 moved the workspace to ic-management-canister-types 0.11.0, which has EcdsaCurve::Secp256r1, so ic-pub-key no longer needs the in-repo crate. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
AleDema
pushed a commit
to AleDema/ic
that referenced
this pull request
Oct 24, 2026
…finity#11894) ### Why The mainnet ECDSA keys `key_1` and `test_key_1` now also exist over secp256r1 (P-256), the curve dfinity#11573 added, and PocketIC holds secp256r1 keys too (dfinity#11741). `ic-pub-key` derives canister public keys offline from hardcoded master keys, but for ECDSA only over secp256k1: any other curve returns `AlgorithmNotSupported`. `ic-secp256r1` 0.3.0 (dfinity#11895) has the secp256r1 master keys, and the workspace's `ic-management-canister-types` 0.11.0 (dfinity#11909) has `EcdsaCurve::Secp256r1`. Both are published. ### What * A new `secp256r1` feature, on by default, derives keys for `key_1`, `test_key_1`, `pocketic_key_1`, `pocketic_test_key_1` and `dfx_test_key`, following the secp256k1 code paths. It requires `ic-secp256r1` 0.3.0. * `TryFrom<&EcdsaKeyId>` checks each curve in its own feature-gated block, like `TryFrom<&SchnorrKeyId>`, instead of depending on the order of its checks. * `serialize` and `chain_code` share one implementation on `DerivedPublicKeyInner`, instead of one each in `CanisterMasterKey` and `DerivedPublicKey`. * The crate docs and README describe the features, including `default-features = false`, and `derive_ecdsa_key` names the feature each curve needs. * The changelog adds the secp256r1 support and the changes since the published 0.3.0 that weren't recorded yet: `ic-vetkeys` 0.6.0 → 0.7.0 and the `ic-cdk-management-canister` dependency of the `vetkeys` feature. dfinity#11909 already recorded `ic-management-canister-types` 0.5.0 → 0.11.0, which makes the next release a breaking one. ### Tests * Known-answer tests for all five secp256r1 keys, using the same canisters and path shape as the secp256k1 tests. * All ECDSA tests now also check the chain code, and that unknown key names are rejected. * All expected public keys and chain codes are what the replica's `derive_threshold_public_key`, the function that answers `ecdsa_public_key`, returns for these master keys. A one-off check, not committed, confirmed this for all 11 ECDSA vectors: * `ic-pub-key` matches the replica on both public key and chain code. * The replica reproduces the existing secp256k1 vectors. * The offline derivation also matches mainnet itself: for a canister on mainnet, `ecdsa_public_key` returned exactly the public keys `ic-pub-key` derives offline, for `key_1` and `test_key_1` on both curves, each with an empty and a 7-element path. Mainnet doesn't expose chain codes, so those rest on the replica check. * The test helpers follow the Schnorr ones and are feature-gated. With a single feature, the tests build without warnings, and so does the library, except with only `vetkeys`: the two warnings master already has in `CanisterMasterKey::derive_key` remain. This PR removes a third, in `TryFrom<&SchnorrKeyId>`. * Locally, in the dev container, all of these pass: `cargo check` (default and each single feature), `rust-lint.sh`, `bazel build //... --nobuild`, `//bazel:buildifier.check`, and the 3 affected tests. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.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
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.
Bump the workspace dependency
ic-management-canister-typesfrom 0.8.0 to 0.11.0. This is needed for #11894 (offline derivation of secp256r1 keys inic-pub-key).Between 0.8.0 and 0.11.0 nothing was removed or renamed. The additions still break Rust code in places, because none of these types is
#[non_exhaustive]:CanisterSettingsandDefiniteCanisterSettingsgained the fieldsminimum_incoming_canister_call_cyclesandstatus_visibility, along with the newStatusVisibilitytype.HttpRequestArgsgainedpricing_version, andHttpMethodgainedPATCH.EcdsaCurvegainedSecp256r1.Changes that follow from the bump:
canister_test: one struct literal lists everyCanisterSettingsfield, so it now sets the two new fields as well.cmc.diddeclares the two newCanisterSettingsfields, becausetest_candid_interface_compatibilityrequires it. The CMC now forwards these two settings increate_canisterandnotify_create_canister. Before, it dropped them.unreleased_changelog.mdrecords this. chore: bump ic-management-canister-types to 0.8.0 and agent-rs to 0.49.0 #10756 did the same forsnapshot_visibility.ckdoge_minter.diddeclares the two newDefiniteCanisterSettingsfields, whichget_canister_statusnow returns. The replica returns both fields unconditionally since feat: new canister settings minimum_incoming_canister_call_cycles #10398 and feat: new canister setting status_visibility #10667, and all mainnet GuestOS versions inmainnet-icos-revisions.jsoncontain both PRs. So decodingcanister_statuswith the new types also works on mainnet.pocket-icandic-pub-keyre-export these types, so both record the bump.The older copies left in
Cargo.lockcome fromic-utilsandevm_rpc_types, which have no newer release, and from the cdk, which a follow-up PR bumps.This does not yet remove the secp256r1 workarounds in the system tests (
cast_ecdsa_key_id, the signer canister) and in the PocketIC test canister. Those are cdk canisters, and the workspace'sic-cdk-management-canister0.1.1 re-exports the 0.7.1 types. Its 0.3.0 requiresic-management-canister-types^0.11, so this bump comes first.🤖 Generated with Claude Code