Purge SJCL #73
Purge SJCL #73
Conversation
|
Interesting... so we'll still need to figure out a solution in react-native. Do you know if file:// is considered a secure context? I wonder how much this will decrease our bundle size! I'm fine with removing it assuming code build passes. |
|
Contexts starting with We will need to figure something out for idempotency tokens in react native, but that is true with or without this PR. |
|
At least right now it's just idempotency tokens we have to worry about. At least customers can manually provide those to get around it. |
* Remove SJCL from browser random source * Use crypto feature detection rather than generic runtime detection * Remove packages vendoring portions of the SJCL * Fix flaky signature tests
|
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs and link to relevant comments in this thread. |
The SJCL, even just the parts we're vendoring, is a large, sophisticated crypto dependency that we're not actually using. It would be a lot of noise for any automated or manual security review of the SDK.
The SJCL was still being used in the random source packages, but the only runtimes we're targeting that don't support IE 11 Crypto or WebCrypto (to wit, React Native and potentially NativeScript) also wouldn't be able to use the SJCL's fortuna implementation, as it relies on attaching event listeners to
windowanddocument.I've saved a reversion of the last commit on my fork if we do end up needing these packages.