Reducing opportunities for supply-chain attacks with ses distribution tighter to source code

[DavidBruant]

Hi :-)

I love ses <3
Thank you for the work on this project

This issue certainly edges on nit-picking,
but i'd rather share it and be useless rather than taking the risk to eventually be right in my assessment and having said nothing

Currently, the recommanded path to install ses is

npm install ses

and i feel it leaves holes in the distribution

My understanding of the ses distribution is that:

1. some improved ses source code is pushed to github
2. an ses dev, from their machine, publish a new version of the package from the source code (hopefully unchanged in the meantime) which sends it to the npm registry
3. Then unauditable npm machinery happens
4. Then, when someone tries npm install ses, (and they may or may not receive what the ses dev sent)

Given how critical to security ses may be, it'd be nice to remove any doubt in the distribution process of ses and to have a more direct and transparent path from source to installed npm tarball
Currently, I see threats in steps 2 and 3. I feel they're very low, but also unnecessary

I feel like building what is distributed should probably be built in a more controlled environment like a github action (which build process can be partially audited afterward via the action's log)

If the npm registry is kept as the preferred distribution channel, it could be nice to add package provenance at least to improve the auditability of the publication process

Alternatively, npm and yarn allow to install from urls to .gzip files, so it's possible to distribute ses as a .gzip file generated automatically via a github action creating a package distributed on the endo github repo
This would allow to distribute ses without having to trust npm internals (which may be amazing today and also may change later by mistake or malice)

Alternatively, npm and yarn accept to install from git urls (in which a commit hash, a tag or a branch can be specified), so the github action could also bundle the ses package and distribute it in a dedicated branch on the endo repo. This solution has the nice property that the package-lock.json of a ses dependent store the exact commit hash, so it's nice to increase at least the replicabilty of the install

I haven't looked into it enough, but i wonder why a build process (current npm run build) is necessary for ses. Would it make sense to install ses directly from source? Does pre-bundling add security properties?

[turadg]

Example of Ava adding provenance: avajs/ava#3385

[naugtur]

On the topic of publishing to npm registry:
Local publishing from a dev machine remains the only way one can publish to npm with a second factor required for every publish. All other options expose a publishing token that can be stolen. Once it's stolen, the only mechanism that protects it is the TTL, but while the token is alive, it can be used to publish any number of things it's scoped for. (it's true for OIDC too. AFAIK the trust in trusted publishing ends up being used to invoke an API that returns a not-single-use npm token that's used for publishing)
That's why I remain skeptical about automated publishing. That being said, provenance would be nice.

Fully automated publishing without 2fa would be a great option if we had staged publishing (github suggested they will build that for npm in one of the announcements)

As for the integrity of the SES package itself - that's a fairly easy problem to solve. SES is distributed as a bundled file and the bundler is intended to be deterministic, so anyone should be able to:

• download the npm tarball
• look up the matching commit in git ( https://registry.npmjs.org/ses/latest gitHead field)
• run SES build
• compare dist files with the ones in the published tarball
• make noise if not identical

It'd be much harder for the packages that we publish unbundled, but for SES itself, that'd be the way to go.