-
Notifications
You must be signed in to change notification settings - Fork 94
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
refactor: remove crypto-js which is now deprecated #5866
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #5866 +/- ##
========================================
Coverage 87.60% 87.60%
========================================
Files 735 736 +1
Lines 31590 31616 +26
Branches 5675 5675
========================================
+ Hits 27673 27696 +23
+ Misses 3873 3697 -176
- Partials 44 223 +179
... and 75 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
// This file was copied from https://github.com/RaisinTen/aes-crypto-js/blob/2978af8e004d47539d767e751def003fe134b6e2/index.js | ||
// and modified slightly for TS compatibility. |
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 found this while looking for a recommended migration path in brix/crypto-js#468
I chose to copy the implementation instead of importing it from NPM as it's critical to the correct behavior of Valora.
And wanted to avoid yet another unmaintained package in the future 😄
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'm sure this is all probably totally fine, but something about checking in code that operates at this low-level of abstraction makes me nervous 😅 This is all totally backwards compatible with data that's already been stored and encrypted by our previous library, right? That is, you can encrypt data the old way, decrypt it the new way, and it will decrypt as we'd expect?
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.
Yes, I carefully added tests for backward compatibility and ensured everything was fine by manually testing too.
Well of course there's always room for subtle bugs, but these should be minimized now.
// Use real encryption | ||
jest.unmock('crypto-js') |
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.
Real encryption is now the default, since __mocks__/crypto-js.ts
was removed, which was mocking encryption and decryption.
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 fantastic! Glad it was an easy migration, and happy to get rid of this :)
@@ -124,7 +124,6 @@ | |||
"bignumber.js": "^9.1.2", | |||
"clevertap-react-native": "^2.2.1", | |||
"country-data": "^0.0.31", | |||
"crypto-js": "^4.2.0", |
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.
🎉
// This file was copied from https://github.com/RaisinTen/aes-crypto-js/blob/2978af8e004d47539d767e751def003fe134b6e2/index.js | ||
// and modified slightly for TS compatibility. |
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'm sure this is all probably totally fine, but something about checking in code that operates at this low-level of abstraction makes me nervous 😅 This is all totally backwards compatible with data that's already been stored and encrypted by our previous library, right? That is, you can encrypt data the old way, decrypt it the new way, and it will decrypt as we'd expect?
const originalAes = jest.requireActual('src/utils/aes') | ||
|
||
return { | ||
...originalAes, |
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.
Why do we need to return the original import here? It seems like the only two functions in that file are aesEncrypt
and aesDecrypt
, which we're mocking anyways.
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.
This is in case it changes in the future and more things are exported.
Less likely that we'd need to touch the mock.
3ffb507
to
4290d87
Compare
aead8c2
to
de8507c
Compare
de8507c
to
aa68a40
Compare
### Description Cloud Account Backup broke in #5866. That PR changed `global.crypto` to be polyfilled by `react-native-quick-crypto` and the version of `@toruslabs/eccrypto` pulled by our Cloud Account Backup, wasn't working out-of-the box with it. However it got fixed in torusresearch/eccrypto#40 and landed in `@toruslabs/eccrypto >= 5.0.2`. So this PR upgrades the `@toruslabs` libs so it pulls the latest version of `@toruslabs/[email protected]` which works with `react-native-quick-crypto`. It's using new major versions. Scanning through the [release notes](https://github.com/torusresearch/torus.js/releases), the main impact for us was the way to import the module. But let me know if there's an important detail I've missed. Additionally, I found there was a bug in `react-native-quick-crypto`, `getAuthTag` was returning an `ArrayBuffer` instead of a `Buffer` leading to an incorrect encoding in the final encrypted string. I contributed a fix upstream (margelo/react-native-quick-crypto#443) and created a patch to use until it's merged. And made a slight change to the wallet code so we can decrypt data if the `authTag` was serialized as an `ArrayBuffer` (e.g. `"1,2,3,4,..."`) instead of the expected base64. This replaces #5934 ### Test plan - Tests pass - Manually tested: - Restore from Cloud Account Backup works - Setup Cloud Account Backup works - Delete Cloud Account Backup works ### Related issues See Slack: [thread 1](https://valora-app.slack.com/archives/C04B61SJ6DS/p1725642273567639), [thread 2](https://valora-app.slack.com/archives/C025X4WJT09/p1725666426992419). ### Backwards compatibility Yes ### Network scalability If a new NetworkId and/or Network are added in the future, the changes in this PR will: - [x] Continue to work without code changes, OR trigger a compilation error (guaranteeing we find it when a new network is added)
Description
This removes crypto-js which is now discontinued:
Bonus, because it now uses the native crypto module (via react-native-quick-crypto) AES encryption/decryption should be faster. Though the gains are probably not noticeable given the small use we have.
Note: there's an important change for tests too, they now all use real encryption.
Test plan
Related issues
Backwards compatibility
Yes
Network scalability
If a new NetworkId and/or Network are added in the future, the changes in this PR will: