-
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
Bump keyring-controller
and browser-passworder
#21878
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 updated dependencies detected. Learn more about Socket for GitHub ↗︎
|
f17aac4
to
07faa5f
Compare
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
51a9958
to
8c166cf
Compare
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
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 applied fix has been ported upstream
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.
Looks good!
Uhm, looks like some of the tests intermittently fail, with a timeout error. Most of them seem to be unrelated (or not directly related at least) to a change in the encryption or the vault - This makes me think that the increased time needed by the key derivation might take up too much of the test case time, which ultimately leads to a timeout in some cases: this would explain a similar test flakiness |
After some local debugging, I think I have a clearer idea of why this happens. Some of our test cases open external pages in the browser to test dapp features, and these tests take action on these pages right after the login. Some of them explicitly wait some time (with
Not all tests are affected, as some of them don't use external pages, and some of them wait ~1 sec before taking actions on dapps, but this issue makes the tests completely flaky and dependent on the resources available on the system that runs them. |
The solution can be to use a shared helper login function to be used by all tests. This function would:
This will ensure that by the time the tests use dapps (or any other operation that needs the login), the wallet will be already unlocked. I will address this issue in a separate PR for ease of review. |
d5c97e4
to
583e6ea
Compare
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
aad500d
to
9a5edec
Compare
@metamaskbot update-policies |
Policy update failed. You can review the logs or retry the policy update here |
668957e
to
0780ec6
Compare
Builds ready [0780ec6]
Page Load Metrics (1397 ± 138 ms)
Bundle size diffs [🚀 Bundle size reduced!]
|
Builds ready [96a1a43]
Page Load Metrics (1335 ± 102 ms)
Bundle size diffs [🚀 Bundle size reduced!]
|
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.
Have not performed manual testing but changes LGTM
Builds ready [c33de4f]
Page Load Metrics (1386 ± 135 ms)
Bundle size diffs [🚀 Bundle size reduced!]
|
|
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.
Looks great!
@@ -315,6 +315,7 @@ const importSRPOnboardingFlow = async (driver, seedPhrase, password) => { | |||
await driver.fill('[data-testid="create-password-confirm"]', password); | |||
await driver.clickElement('[data-testid="create-password-terms"]'); | |||
await driver.clickElement('[data-testid="create-password-import"]'); | |||
await driver.waitForElementNotPresent('.loading-overlay'); |
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.
Perhaps we could extract this to a function whose name reflects this need in the future if we forget this, but this makes sense for now!
Catching up on and deduping dependencies starting to pay off ! |
Missing release label release-11.7.4 on PR. Adding release label release-11.7.4 on PR and removing other release labels(release-11.8.0), as PR was cherry-picked in branch 11.7.4. |
Description
This PR bumps these package versions:
@metamask/keyring-controller
to^9.0.0
@metamask/browser-passworder
to^4.3.0
@metamask/eth-keyring-controller
to^15.1.0
This set of updates brings a change in the way encryption keys are derived from the user password.
To allow encryption with different iteration numbers (e.g. for different use cases), and to easily change these iterations independently in the future, an encryptor factory has been added.
For performance reasons,
@metamask/eth-keyring-controller
has been fixed to prefer the cached encryption key over the password (it will not derive it again), when it is initialized withcacheEncryptionKey: true
and the encryptor supports it (which is the case with@metamask/browser-passworder
) - for this reason, this change only impacts the login UX, instead of every user interaction with the keychain.The encryptor for Snaps has been set lower for now.
Related issues
n/a
Manual testing steps
Note from DanM: probably a good idea to test this on a lower powered machine to see the performance impact. Test the before and after impact on performance of logging in, going from the unlock screen to the home screen.
These changes might have a UX impact on slower devices, for the following actions:
persistAllKeyrings
, which derives the encryption key again and re-encrypt the vault. e.g.:Add an accountRemove an accountConnecting a hardware wallet of any kindAdding a keyringRemoving a keyringImporting accountSnaps interactions: some of them callencrypt
/decrypt
, which also derive the key before/after all the interactionsScreenshots/Recordings
n/a
Before
n/a
After
n/a
Pre-merge author checklist
Pre-merge reviewer checklist