`install.js` should check the integrity of the file as part of `downloadDirectlyFromNPM`

[earthlingdavey]

Considering the install script is downloading a binary file from npm.

The file checksum should be validated, otherwise a corrupted or tampered binary could be downloaded and subsequently executed.

[evanw]

I'm not inclined to do this because I'm not sure what this would accomplish. If the concern is that content coming from npm could be malicious, then the malicious content on npm could also include an altered install script that changes or disables the checksum validation. So adding such a check wouldn't actually address your concern.

[earthlingdavey]

Hi @evanw thanks for getting back to me and explaining your current position on this.

While I understand what you're saying, I respectfully disagree.

One of the reasons for package-lock.json (or it's equivalents like yarn.lock etc.) is to verify package integrity. This means that:

1. Once a package has been installed, all future installs of the package will be the exact same.
2. There is an auditable trail. If, for whatever reason, a tampered package is installed, and the package-lock.json is pushed to version control - then the tampering could be identified at that point, during a routine scan, or a security incident post-mortem.

With this in mind, I can download a popular open source JS repository, that has a package-lock.json, run npm ci --ignore-scripts, and be 100% certain that the downloaded packages will be the exactly same as everyone else who runs that command - including the package maintainers and other developers.

With the above command, if a tampered package is served, then the package will fail it's integrity checks, and ultimately the command will fail.

---

On the other hand, an install script that downloads a binary from npm, without checksum validation doesn't offer the same security guarantees.

For example:

• NPM could serve an infected binary only when the IP address matches the offices of yarn or pnpm offices
• NPM could serve an infected binary only when the IP address matches CI runner in specific countries. Since CI runners are ephemeral, this would be near impossible to discover.
• In countries where the powers that be have root SSL certs installed on the population's machines, they could send a tampered binary, infect the machine, then cleanup with the legit binary.
• The download is otherwize incomplete or corrupt due to other external factors.

---

In summary, there is a subtle, but important difference between trusting npm to install packages, and trusting npm to serve binaries.

Considering the integrity of the esbuild package is checked during install, why not push for complete integrity by also checking the integrity of the binary?

If you reconsider your position, I would be happy to work on this in my spare time over the course of a few weekends.

---

All the best.
Sincerely Davey

[evanw]

Marking as a breaking change since a bug with this could break esbuild installation. It should be done in a breaking change release just in case.

[earthlingdavey]

@evanw thanks for categorizing. Would you be ok with an AI assisted PR, if so, is this along the right direction?

https://github.com/earthlingdavey/esbuild/pull/1/changes