-
Notifications
You must be signed in to change notification settings - Fork 5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Migrate eth_accounts and permittedChains to CAIP-25 endowment #27847
base: main
Are you sure you want to change the base?
Conversation
CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes. |
New and removed dependencies detected. Learn more about Socket for GitHub ↗︎
🚮 Removed packages: npm/@json-schema-spec/[email protected], npm/@json-schema-tools/[email protected], npm/@metamask/[email protected], npm/@open-rpc/[email protected] |
👍 Dependency issues cleared. Learn more about Socket for GitHub ↗︎ This PR previously contained dependency changes with security issues that have been resolved, removed, or ignored. |
@metamask-bot update-policies |
.yarn/patches/@json-schema-tools-reference-resolver-npm-1.2.6-4e1497c16d.patch
Show resolved
Hide resolved
@metamaskbot update-policies |
Policies updated. 🧠 Learn how: https://lavamoat.github.io/guides/policy-diff/#what-to-look-for-when-reviewing-a-policy-diff |
…o caip25-permission-migration
…ge.test.js snapshot
|
||
const isSnap = snapsPrefixes.some((prefix) => origin.startsWith(prefix)); | ||
const scopes: InternalScopesObject = {}; | ||
const scopeStrings: CaipChainId[] = isSnap |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't entirely follow the reasoning here, what about Snaps that have accounts created?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They'll still be stored under the wallet:eip155
scope a few lines below this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I don't follow that either, what is that scope supposed to represent?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that scope represents evm wallet methods, i.e. methods that do not belong to a particular evm chain, so something like personal_sign
would belong here . It's kind of awkward right now because our current Signing UI implementation does require chainId context and so some signing methods do belong to a chain specific scope (i.e. eip155:1
etc) and so personal_sign
does not exist in wallet:eip155
like in my example above, but I won't go into the specifics there
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
basically, it's a scope for evm stuff, but not chain specific
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand that, I'm just having trouble following whether the permissions are being migrated correctly.
Is granting wallet:eip155
the same as granting access to all chains by default? E.g. the old eth_accounts behaviour? If not, then I don't understand fully how the migration works for Snaps.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only reason is that snaps currently do not have permittedChains permissions and so granting permissions to eip155:<chainId>
scopes would effectively be giving snaps permittedChains permissions. My understanding was that we wanted to hold off on doing this until we are ready to release snap selected networks and chain switching
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's fine, but it still doesn't answer my question as to what permission are we then actually granting. What does giving them wallet:eip155
grant them permission to do?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
permission to call any EIP-1193 window.ethereum exposed method, incl signing methods for the accounts specified in the wallet:eip155
scope, on the globally selected network
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK sorry obviously I misunderstood your line of questioning here in my previous answer.
So given that Snaps may already have eth_accounts permissions on technically all chains, why aren't we granting that permission in the same way as for dapps?
I think (?) I understand the question better now.
So the new permission format (modeled closely after CAIP-25 request structure) nests accounts under specific chain permissions:
"eip155:10": {
"accounts:" ["eip155:10:0x0910e12C68d02B561a34569E1367c9AAb42bd810"
,"eip155:10:0x806627172aF48bD5B0765D3449A7DEf80d6576ff"]
},
"eip155:42161": {
"accounts":["eip155:42161:0x0910e12C68d02B561a34569E1367c9AAb42bd810", "eip155:42161:0x806627172aF48bD5B0765D3449A7DEf80d6576ff"],
},
so if we were to grant permissions to snaps in the same way we would necessarily be constraining these account permissions to the enumerated chains.
Putting snaps account permissions into wallet:eip155
is a temporary way to get around this entanglement of chain and account permissions. Really in the new permissions structure accounts permissions shouldn't really be separable from chain permissions.
Now its also the case we currently don't have any cases enabled where any accounts are not included in all the chain scopes so, until we do, the way it works is all permissioned accounts are permissioned on all permissioned chains. But this still doesn't lead to as broad of a permission as the legacy eth_accounts
permission (before chain Permissions) since it was unconstrained by what subset of enabled chains the dapp has been granted. That's why we've carved out this temporary solution for snaps until they have chain permissions as well.
updatedEthAccounts, | ||
); | ||
|
||
permissionController.updateCaveat( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it not simpler to do this via grantPermissionsIncremental
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mark, Alex, and I discussed a path to get to potentially get to that point, but prerequisite work would involve making a lot more component level changes that we are opting not to do at this time
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At the very least we should create a ticket to follow-up on this!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Making a ticket for this now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
# Conflicts: # app/scripts/controllers/permissions/specifications.js # lavamoat/browserify/beta/policy.json # lavamoat/browserify/flask/policy.json # lavamoat/browserify/main/policy.json
@metamaskbot update-policies |
Policies updated. 🧠 Learn how: https://lavamoat.github.io/guides/policy-diff/#what-to-look-for-when-reviewing-a-policy-diff |
Builds ready [059ecad]
Page Load Metrics (1969 ± 74 ms)
Bundle size diffs [🚨 Warning! Bundle size has increased!]
|
One thing I remembered is that the |
Builds ready [a7ba043]
Page Load Metrics (1768 ± 64 ms)
Bundle size diffs [🚨 Warning! Bundle size has increased!]
|
Builds ready [352f964]
Page Load Metrics (1711 ± 78 ms)
Bundle size diffs [🚨 Warning! Bundle size has increased!]
|
Builds ready [e749a8a]
Page Load Metrics (1887 ± 60 ms)
Bundle size diffs [🚨 Warning! Bundle size has increased!]
|
Description
This PR replaces the replaces the internal
eth_accounts
andendowment:permittedChains
permission structure with a CAIP-25 endowment. It adds adapter logic to translate to and from the new internal CAIP-25 permissions. This change should be transparent to wallet users and to dapps except foronetwo cases, see below. This change is required in order to support CAIP-25 and CAIP-27 requests in a follow-up PR that enables the Multichain API.Related issues
Related: MetaMask/core#4784
Manual testing steps
There should be no user or dapp facing difference in behavior except:
wallet_revokePermissions
and specifying eithereth_accounts
orendowment:permitted-chains
, the entire CAIP-25 permission will be revoked. It will appear to the dapp as if botheth_accounts
andendowment:permitted-chains
were revoked.wallet_getPermissions
for a permitted dapp when the wallet is locked,eth_accounts
should be returned in addition toendowment:permitted-chains
. Currently there is a regression onmain
where onlyendowment:permitted-chains
gets returned when the wallet is locked.Locked Wallet Behavior with dapp connected
Other than the one noted item below, this behavior matches that in
main
eth_accounts
returns []wallet_getPermissions
returns permissions incl eth_accountswallet_revokePermissions
works as usual and revokes eth_accounts and revoke permitted-chains togethermain
where eth_accounts and permitted-chains aren't revoked as a pair if either is revokedeth_requestAccounts
prompts for unlock, after unlock returns accounts if any are permitted, otherwise shows connection promptwallet_requestPermissions
prompts for unlockaccountsChanged
empty array on lock. no event after revokePermissions which makes sense since the dapp was told empty array on lock and now it's actually empty array so no changes have occurred as far as the dapp should be concerned.Screenshots/Recordings
Before
After
Pre-merge author checklist
Pre-merge reviewer checklist