Repository navigation
fix(sdk-api): keep browser v1 decrypt to SJCL - #9684
Open
pranavjain97 wants to merge 1 commit into
Open
pranavjain97 wants to merge 1 commit into
pranavjain97 wants to merge 1 commit into
Conversation
Contributor
ralph-bitgo
Bot
force-pushed
the
pranavjain/wcn-2576-route-browser-v1-sjcl-decrypt-directly-to-legacy-decoder
branch
from
October 5, 2026 19:08
5f25978 to
8c12c59
Compare
In browser bundles webpack maps `crypto` to `crypto-browserify`, whose AES-CCM (browserify-aes) does not work. Every v1 decrypt therefore paid for a full PBKDF2 run that was guaranteed to fail, and then logged a fallback warning on every successful decrypt. Route browser and worker runtimes straight to the frozen SJCL decoder, gated by the same parseV1Envelope iter-cap check the native path uses so DoS protection is preserved. Node keeps native-first with the SJCL fallback. Also drop the adjacent dead test seams: the Node-injected decryptV1.browser.ts suite (it injected crypto-browserify but never exercised real browser dispatch), the decryptV1WithCrypto injection parameter that existed only for it, and the now-unused crypto-browserify devDependency. Real browser dispatch is now proven by a Cypress component spec on BitGoAPI.decrypt covering the absent-`v` legacy envelope and the iter-cap boundary. docs/sjcl-replacement.md states the engine boundary precisely. Why: customers decrypting legacy v1 key material in browser bundles pay a wasted PBKDF2 and see a misleading console warning per call, and the SJCL deprecation effort needs an exact, documented boundary between the native and frozen-SJCL code paths. Ticket: WCN-2576 Session-Id: b906da45-6cf8-444a-9623-1e04551347ae Task-Id: f81a1b1b-b7ee-46e9-a522-7708ed6ccc64 Requested-By: Pranav Jain
pranavjain97
force-pushed
the
pranavjain/wcn-2576-route-browser-v1-sjcl-decrypt-directly-to-legacy-decoder
branch
from
October 7, 2026 19:30
8c12c59 to
1ba0e92
Compare
Contributor
|
|
danielpeng1
approved these changes
Oct 9, 2026
Comment on lines
+80
to
+81
| expect(error, 'iter above the cap must be rejected').to.be.an('error'); | ||
| expect((error as Error).message).to.match(/iter/); |
Contributor
There was a problem hiding this comment.
Suggested change
| expect(error, 'iter above the cap must be rejected').to.be.an('error'); | |
| expect((error as Error).message).to.match(/iter/); | |
| if (!(error instanceof Error)) { | |
| throw new Error('Expected an Error rejection'); | |
| } | |
| expect(error.message).to.match(/iter/); |
This branch has not been deployed
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
3 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.
crypto-browserify's AES-CCM is reported broken in real browsers, so skip the native attempt there and go directly to sjcl.decrypt after the existing iteration-cap check. Also drops the unused, unreviewed WebCrypto CCM candidate (decryptV1WebCrypto.ts) that had no caller.
TICKET: WCN-2576