Repository navigation
Conversation
aelmanaa
marked this pull request as ready for review
September 28, 2026 16:23
aelmanaa
requested review from
0xrusowsky,
DaniPopes,
figtracer,
grandizzy,
mablr,
mattsse,
onbjerg and
stevencartavia
as code owners
September 28, 2026 16:23
mablr
marked this pull request as draft
September 29, 2026 12:54
Member
|
converted to draft, pending alloy-rs/alloy#4267 |
This was referenced Sep 29, 2026
aelmanaa
added a commit
to aelmanaa/hardhat-kms
that referenced
this pull request
Oct 3, 2026
) Closes #218 Closes #221 ## What changes **Ignition guide (#218).** `docs/user/guides/deploy-with-ignition.md`: - Step 1's config adds `rehearsalCli: { type: "edr-simulated" }`, a network with no KMS keys, and step 3's `--kms` command passes `--network rehearsalCli`. The page says why it does not use `rehearsal`: that network already lists `deployer`, and the same key passed twice is an error (decision 0008). An earlier revision ran `--kms` without `--network`; that works but prints the plugin's warning against KMS keys on `default`, so review moved it to a named network. - `configuration.md`: the default-network warning sentence now says it also fires for `--kms` without `--network`. - Step 1 shows `contracts/Counter.sol`, byte for byte the same as `examples/ignition/contracts/Counter.sol`. - Step 1's config adds a `sepoliaFork` network (`forking: { url: configVariable("SEPOLIA_RPC_URL") }`), and step 3 shows the command that rehearses on it. Step 2's account-index sentence now names both simulated networks. **Foundry's Azure signer (#221).** Foundry has no released Azure Key Vault signer. Checked with `gh` on 2026-10-03: - foundry-rs/foundry#17120: open, draft. foundry-rs/foundry-core#228: open, draft. - Latest release: v1.8.4 (2026-10-01). Its notes do not mention Azure. The pages that said or implied a released `--azure` now say the Azure variable names and credential order follow the proposal in #17120, and link it: `migrate-from-foundry.md` (intro sentence plus a note under the variables table), `azure-key-vault-setup.md` (the one Foundry sentence in step 3), `configuration.md` (the `--kms` paragraph and the Azure credential chain) and `multiple-keys.md` (the `--kms` intro). The `--kms azure` behaviour is unchanged. Decision 0008 already qualifies the Azure names as following the open PRs, so it is unchanged. The same fix in code (second commit): - The `--kms` option's help text now reads: "Load KMS keys from environment variables for these providers: aws, gcp, azure (comma-separated). aws and gcp use Foundry's variables; azure uses the names proposed in foundry-rs/foundry#17120". `npx hardhat --help` shows the new text. No test or doc quotes it. A `hardhat-kms` patch changeset covers it. - The `KmsOption` TSDoc in `packages/hardhat-kms/src/type-extensions.ts` says the same. `pnpm run docs:api` regenerated no page, because the API reference does not include this global-option augmentation. - The comments in `packages/hardhat-kms-azure/src/internal/credential.ts` (credential order) now refer to the signer proposed in foundry-rs/foundry#17120. The `adapter.ts` comment on the `kid` check now names alloy's Azure signer (alloy-rs/alloy#4267, merged 2026-09-30), whose `sign` checks the response's key version (`crates/signer-azure/src/signer.rs:316` at `3834f7e`). Comment changes need no changeset. - The two "another order than Foundry's" comparisons (`hook-handlers/kms.ts:49`, `scripts/type-escapes.json`) are unchanged: they compare orders and claim no release. ## Evidence Run on 2026-10-03 from this branch: `pnpm run build`, then `pnpm pack` of `hardhat-kms` and `@hardhat-kms/aws` into a new Hardhat 3 project (hardhat 3.18.1, hardhat-ignition 3.1.8, hardhat-ignition-viem 3.1.6, Node 24). The project's `hardhat.config.ts`, `contracts/Counter.sol` and both Ignition modules were extracted from the guide's code blocks by a script. The one change was `keyId: "alias/deployer"`, replaced with a `configVariable` that names an existing AWS test key (a diff confirmed that this was the only difference). `--kms` runs set `AWS_KMS_KEY_ID` to the same key. Simulated networks only: no live broadcast, no funds. Addresses masked. | Command (guide step) | Result | | --- | --- | | `kms accounts --network rehearsal` | `deployer aws kms.keys 0x<addr>` | | `ignition deploy …Counter.ts --network rehearsal --default-sender 0x<addr>` (3) | exit 0, `[ Counter ] successfully deployed`, `Counter.add` executed | | `ignition deploy …Counter.ts --network sepoliaFork --default-sender 0x<addr>` (3), `SEPOLIA_RPC_URL` = a public keyless Sepolia endpoint | exit 0, deployed, `add` executed; a script on `sepoliaFork` read block 11836750, so the fork reads Sepolia | | `AWS_KMS_KEY_ID=… ignition deploy …Counter.ts --network rehearsalCli --kms aws --default-sender 0x<addr>` (3, new) | exit 0, deployed, `add` executed, no plugin warning | | `ignition deploy …CounterFromKms.ts --network rehearsal` (2, `m.getAccount(20)`) | exit 0, deployed | | The old step 3 command, `--network rehearsal --kms aws` | exit 1, as the page now says: `aws, load accounts: AWS_KMS_KEY_ID is already networks.rehearsal.kmsAccounts[0] ("deployer"); use one of them` | `Counter.add` requires `msg.sender == owner`, so each executed `add` shows that the KMS account deployed the contract and sent the call. The `sepolia` commands in steps 2 and 4, and the script in step 2, broadcast to Sepolia, so they were not run. CI already covers `--kms aws` on a network without `kmsAccounts`: the examples test (`packages/hardhat-kms-aws/test/examples/examples.test.ts`) runs `ignition deploy --network localhost --kms aws --default-sender` against LocalStack. No test change was needed. Gates: `pnpm run docs:check` (53 pages, snippets typecheck), `pnpm run check` and `pnpm test` (1,567 tests, 0 failures) pass. The prose slop gate reports 0 findings. ## AI use An AI coding agent (Claude Code) wrote the changes and ran the checks above. A maintainer reviews the PR before merge. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Add an `azure-key-vault` feature and an `--azure` wallet option backed by `alloy-signer-azure`. Keys are selected with `AZURE_KEY_VAULT_KEY_ID`, or `AZURE_KEY_VAULT_KEY_IDS` for multiple wallets. The Azure SDK has no default credential chain, so credentials are resolved from a client secret, workload identity, the Azure CLI, and then a managed identity with a timeout, since its endpoint may not answer outside Azure. The comma-separated key ID parsing is shared with AWS KMS and now ignores whitespace and empty entries. `alloy-signer-azure` is patched from git until it is released. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
aelmanaa
force-pushed
the
feat/azure-key-vault-signer
branch
from
October 18, 2026 15:05
30544e0 to
d110209
Compare
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.
Depends on alloy-rs/alloy#4267 (new
alloy-signer-azurecrate). Until it is merged and released,alloy-signer-azureis patched from my alloy fork via git, with a temporarydeny.tomlentry; both will be replaced by the release before merging.Adds an
azure-key-vaultfeature tofoundry-walletswith an--azureoption for single and multi-wallet signing, backed byalloy-signer-azure(alloy-rs/alloy#4267), as requested in foundry-rs/foundry#17112. The key is selected withAZURE_KEY_VAULT_KEY_ID, or the comma-separatedAZURE_KEY_VAULT_KEY_IDSfor multiple wallets, mirroringAWS_KMS_KEY_ID(S); the two now share one parser, which also ignores whitespace and empty entries in the AWS list.The Azure SDK for Rust has no default credential chain, so
from_azureresolves credentials once per process from a service principal secret, then workload identity, then the Azure CLI or Azure Developer CLI, then a managed identity. The managed identity is tried last with a 10 second timeout because its endpoint can accept connections without answering outside Azure, where the SDK would otherwise retry it for over a minute, and it is skipped where it is unsupported, such as Azure Cloud Shell. The first working source is reused for later token requests.I tested it end to end against a real Key Vault with both an Azure CLI login and a service principal, including
cast sendandforge script --broadcaston Sepolia (details in foundry-rs/foundry#17112).alloy-signer-azureis patched from git until it is released; the patch and the matchingdeny.tomlentry would be replaced by the release before merging. The change also adds the missing Google Cloud KMS entry to theMultiWalletOptsdoc list.This PR was written primarily with Claude Code; I reviewed it and ran the end-to-end test against a real Azure Key Vault.
Part of foundry-rs/foundry#17112.