Security: don't use an install script to download the binary

[mjroeleveld]

The usage of an install script is a vulnerability issue. It downloads an unsigned binary to the executing machine, which opens the way for potentially malicious code to be unintendedly downloaded. The NPM package should contain the binary such that it's there when installed and the install script can be omitted. This will make sure that an install of a locked version of the package will always result in the same artifact, which also helps with caching.

[kaiyoma]

We've also run into issues with the install script. The binary fails to download sometimes, which either causes our CI to fail during yarn install or causes our webpack build to fail with this:

ERROR in Sentry CLI Plugin: spawn .../node_modules/@sentry/cli/sentry-cli ENOENT

(It's a bit troubling how many npm packages connect to a non-npm URL directly and download mysterious things during package installation.)

[kaiyoma]

Another issue, if I'm reading scripts/install.js correctly, is that the download is not verified against a checksum. Why this is important: we're dealing with some network issues that are potentially causing corrupted/truncated downloads, but this sentry-cli install script isn't properly detecting those situations, leading to the error above (a missing file that should be there).

[sehcheese]

@kaiyoma We're having a similar issue with our CI where we get intermittent errors of

ERROR in Sentry CLI Plugin: spawn .../node_modules/@sentry/cli/sentry-cli ENOENT

It does seem that the ideal would be a prebuilt binary, both from a security and convenience standpoint. In the meantime, how have you worked around the CI error?

[kaiyoma]

@sehcheese We ended up creating a local binary/library cache on one of our internal file servers and populating it with the versions that we use. Sentry provides a mechanism to specify a custom URL to the sentry-cli binary:

https://docs.sentry.io/product/cli/installation/#downloading-from-a-custom-source

In our CI, our package installation looks like this now:

SENTRYCLI_CDNURL="http://cache/sentry-cli" yarn install --frozen-lockfile

(where cache is the network name of our file server)

[lobsterkatie]

I've been looking into this, and I believe the reason we've gone for the download-in-postinstall-script approach is in order to be able to match the installed binary to the architecture on which it's running.

It turns out esbuild had the exact same problem, which they ended up solving using optional dependencies. If you read that whole thread, you'll see that there are pros and cons to this approach. The biggest one of those cons (yarn and npm both downloading every binary, for every platform) has been fixed in the latest versions of both (see yarn's fix and npm's fix), and so I think it's a worthwhile strategy to for us to think about pursuing.

(That said, in the interests of full disclosure, with the holidays coming up it's unlikely this will come up for consideration before the new year.)

[github-actions]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

[mjroeleveld]

This issue should remain open.