Add SES lockdown to extension webapp#9729
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. |
b36718f to
6cc4424
Compare
c8cc1c0 to
340d54c
Compare
7f6a7b7 to
791917b
Compare
kumavis
left a comment
There was a problem hiding this comment.
I think this will work for our purposes but is not valid esm (running code between import statements). To make it work we should run the lockdown as part of the module initialization. If we don't have a great way to add the context (ui, etc) to the lockdown we can create lockdowns for each context that hard code it 😐
1023085 to
5f7d446
Compare
Builds ready [b91bb87]
Page Load Metrics (452 ± 40 ms)
|
b91bb87 to
2919fce
Compare
Builds ready [2919fce]
Page Load Metrics (485 ± 67 ms)
|
Builds ready [220e180]
Page Load Metrics (407 ± 54 ms)
|
Builds ready [2c0627d]
Page Load Metrics (575 ± 99 ms)
|
2c0627d to
3557632
Compare
Builds ready [2cf0a84]
Page Load Metrics (495 ± 70 ms)
|
2cf0a84 to
9a577d1
Compare
Builds ready [9a577d1]
Page Load Metrics (432 ± 46 ms)
|
Gudahtt
left a comment
There was a problem hiding this comment.
That seems like a clever way to keep Sentry working! Though I'm surprised this worked - I would have expected the lockdown to "undo" global mutations as well as preventing new ones. Though I don't know - maybe it doesn't work like that. We can test this either way with real Sentry events, targeting our test Sentry project.
I wonder if there is some way to operate Sentry in a reduced capacity as well, such that global mutations are not necessary 🤔
Builds ready [2328351]
Page Load Metrics (466 ± 55 ms)
|
|
CI is listing a pending check (test-deps) but it in fact passed |
|
Since there is a working upstream version of e.g. in the We still need Edit: I've opened a PR against this branch with this change - let me know what you think, and/or feel free to merge! |
|
I have tested this locally, and have confirmed that Sentry still works correctly! The error was rate-limited so I didn't see it in the dashboard, but the network request looked correct to me. |
Instead of patching `symbol-observable`, this ensures that all versions of `symbol-observable` are resolved to the given range, even if it contradicts the requested range.
Builds ready [87c1c7a]
Page Load Metrics (481 ± 67 ms)
|
Adds
lockdown()to background, UI, contentscript & phishing-detect (all contexts except in-page)SES + Sentry integration
Sentry integrates itself by overriding some intrinsics like
Function.prototype.toStringand platform apis likeconsole. We carefully install only Sentry before performing the lockdown. Then start the app normally.SES compat via
patch-packagesymbol-observablemodifiesSymbolintrinsic (pattern used by multiple packages, in our case Redux). Once we get these upstream changes merged, we can remove the patchredux(merged, awaiting publish)redux-devtools-instrument(merged, updated inremote-redux-devtools)reactiveX(not yet merged)Summary of Changes:
patch-packagefor workaround withsymbol-observable@1envifywithloose-envifyfor parsing error workaroundprocess.envto child processeslavamoat-core, useses