fix(core): remove vendored lockdown.umd.js

[boneskull]

This removes the vendored lib/lockdown.umd.js.

ses does not actually export its dist/lockdown.umd.js. It does export dist/ses.cjs as lockdown. dist/ses.cjs is identical to dist/lockdown.umd.js (as well as lockdown.mjs, lockdown.cjs, ses.mjs, and ses.umd.js).

What are the implications of doing this?

[boneskull]

OK, this is not so straightforward, because we're using the resolve package in lavamoat-browserify. resolve doesn't understand subpath exports--so the only way to be able to resolve ses/lockdown from lavamoat-browserify via aa would be to provide a different resolver--e.g., Node.js' builtin resolver.

I'm not sure it's worth doing this or not.

[legobeat]

The alternative I had in mind would be to keep in the resulting dist/ but remove it from source-control, instead in the file from the devDependency on bundling.

[naugtur]

Aditionally, when we resolve SES instead of reading it from a file, we open up more ways to hack the build in a way that dismantles the bundle runtime security.

[boneskull]

@legobeat

The alternative I had in mind would be to keep in the resulting dist/ but remove it from source-control, instead in the file from the devDependency on bundling.

I don't follow

@naugtur

Aditionally, when we resolve SES instead of reading it from a file, we open up more ways to hack the build in a way that dismantles the bundle runtime security.

Yes. This is a tradeoff in that it it opens this hole, but closes another hole: currently, a consumer cannot easily override or otherwise provide a custom resolution for the version of ses consumed by lavamoat-core in order to mitigate a vulnerability in our bundled version of ses. The status quo requires action on our part; the alternative (as presented here) is to hand that responsibility to the consumer.

Of course, either way, a consumer can patch-package their way out of the problem, if needed.

I don't really understand which issue is more severe, or more likely. Hopefully someone else has better insight. 😄

[weizman]

I gave

Aditionally, when we resolve SES instead of reading it from a file, we open up more ways to hack the build in a way that dismantles the bundle runtime security.

some thought, because it's a great argument, but I think that eventually this statement is true to many other dependencies we rely on. Some set of deps (ideally as small as possible) is going to be a set we vet on, and I think SES needs to be one of them, given it's a project we contribute to and trust is secure.

Thus, maybe resolving it locally isn't the worst idea and it would be far better than having a checked in version of the entire file in terms of convenience.

We can also consider building a mechanizm that verifies the content of the SES we're about to use matches the public published version, but not as a blocker to this PR IMO.