Skip to content

Update SES lockdown#10663

Merged
kumavis merged 18 commits intodevelopfrom
ses-update
Mar 26, 2021
Merged

Update SES lockdown#10663
kumavis merged 18 commits intodevelopfrom
ses-update

Conversation

@EtDu
Copy link
Contributor

@EtDu EtDu commented Mar 17, 2021

Update to SES lockdown 0.12.4, which includes new option overrideTaming: 'severe'

@EtDu EtDu requested a review from a team as a code owner March 17, 2021 02:27
@EtDu EtDu requested a review from Gudahtt March 17, 2021 02:27
@github-actions
Copy link
Contributor

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.

@EtDu EtDu requested a review from kumavis as a code owner March 23, 2021 05:59
@MetaMask MetaMask deleted a comment from azmain84 Mar 23, 2021
@metamaskbot
Copy link
Collaborator

Builds ready [9202e49]
Page Load Metrics (604 ± 43 ms)
PlatformPageMetricMin (ms)Max (ms)Average (ms)StandardDeviation (ms)MarginOfError (ms)
ChromeHomefirstPaint438555115
domContentLoaded3588106029043
load3598116049043
domInteractive3578106029043

Copy link
Member

@kumavis kumavis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since we're bundling lockdown we can remove the ses dep

@kumavis
Copy link
Member

kumavis commented Mar 23, 2021

this will help keep develop close to where we are in the lavamoat-for-ui branches

kumavis
kumavis previously approved these changes Mar 23, 2021
@metamaskbot
Copy link
Collaborator

Builds ready [d62d37f]
Page Load Metrics (677 ± 27 ms)
PlatformPageMetricMin (ms)Max (ms)Average (ms)StandardDeviation (ms)MarginOfError (ms)
ChromeHomefirstPaint45755684
domContentLoaded5917966765728
load5967986775727
domInteractive5907966755728

Copy link
Member

@Gudahtt Gudahtt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why was the lockdown script vendored, rather than imported? Where specifically did this script come from, and which version is it?

@EtDu
Copy link
Contributor Author

EtDu commented Mar 24, 2021

Why was the lockdown script vendored, rather than imported? Where specifically did this script come from, and which version is it?

This script came from building lockdown from SES-Shim's master branch. V0.12.3+1-dev, which hasn't been published yet. We want this pre-release build because it applies a more broad override mistake workaround. (For at least all properties on Object.prototype, according to this doc) via overrideTaming: severe as a lockdown option.

@EtDu EtDu changed the title update ses Update SES lockdown Mar 24, 2021
@kumavis
Copy link
Member

kumavis commented Mar 24, 2021

@Gudahtt good question. asking agoric about next version release timeline
but im all for eager adoption and frequent updates since we're actively working on this stuff 👍

@kumavis
Copy link
Member

kumavis commented Mar 24, 2021

ses release "maybe tomorrow" 👍

@Gudahtt
Copy link
Member

Gudahtt commented Mar 24, 2021

Cool - makes sense 👍

Not against including vendored dependencies, but it would be nice if some context for what the file is was included in the codebase alongside it. A pattern I've seen used before is to create a directory under vendor (e.g. app/vendor/ses/) with a README.txt alongside it explaining what the file is, why it was vendored, and how to re-create it exactly (i.e. where to find it, or how to generate it if it was generated, and which modifications to apply if any). That helps ensure we can safely update it in the future without any surprises.

As an example of where this went wrong, I've briefly considered updating app/scripts/chromereload.js in the past, only to give up because I wasn't confident enough that I understood the specific version we used, so I couldn't find corresponding changelog entries for the update I wanted to make. We've periodically forgotten what that file was altogether, and had to rediscover it by googling portions of it, or by asking you.

It sounds like we'll be updating SES pretty soon so it's likely not to be an issue here, but you never know! We could get stuck on this version if the next update introduces problems. Better safe than sorry, and a couple of lines of text should be easy enough to add anyway.

@kumavis
Copy link
Member

kumavis commented Mar 25, 2021

hold

@metamaskbot
Copy link
Collaborator

Builds ready [c1f144a]
Page Load Metrics (599 ± 45 ms)
PlatformPageMetricMin (ms)Max (ms)Average (ms)StandardDeviation (ms)MarginOfError (ms)
ChromeHomefirstPaint45705673
domContentLoaded4038305989345
load4058365999445
domInteractive4038295989345

@kumavis
Copy link
Member

kumavis commented Mar 25, 2021

need to verify the ses-bug for errors in console is not affected in browser

@kumavis
Copy link
Member

kumavis commented Mar 26, 2021

heres the ses bug in question endojs/endo#636
validated that it does not affect the browser rendering of errors (only node, this ses version is only used in the browser)

var _proto = MiddlewareArray.prototype;

- _proto.concat = function concat() {
+ Object.defineProperty(_proto, 'concat', { value: function concat() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Huh. I don't quite follow what's going on here. Is this an array class that is extending Array and redefining concat?

Could we propose this upstream? They seem to be fairly responsive maintainers.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

your understanding is correct. its fine for them to do that (none of my business), but the override mistake doesnt allow them to do it via assignment. thus this.
yes, we usually PR these patches upstream. but we dont let that block us so we write patches as well.

Copy link
Member

@Gudahtt Gudahtt Mar 26, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it. Using a patch seems fine for now, but having that work started by creating a PR would be great. Then we could hopefully delete the patch on the next update, rather than re-write it each time. Especially for packages like this that are updated relatively frequently.

Copy link
Member

@Gudahtt Gudahtt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

I didn't test this yet, but it'll be a while before our next feature release so we'll have plenty of time to find any new SES-related breakages.

@kumavis kumavis merged commit 8fc2c32 into develop Mar 26, 2021
@kumavis kumavis deleted the ses-update branch March 26, 2021 04:27
@github-actions github-actions bot locked and limited conversation to collaborators Mar 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants