10.0 change to install scripts didn't go far enough? Can still run compromised scripts on package updates

[KieranP]

I've just started using PnPm and have seen the controversy around the change in 10.0 to prevent install scripts from running. I agree that it was a good step forward to stop them, but I think that the change didn't go far enough to prevent attacks. The change is good for first time package installs, but not for updates of existing packages.

Let's say that I have added a package, reviewed the install scripts, and added that dependency to the list of approved packages to run scripts. Later on, that package gets compromised and malicious updates are published. The moment I run pnpm update, the compromised package, which previously was fine and approved to run scripts, will now run the compromised install scripts.

The only way to ensure that updated packages have not had their install scripts tampered with is to store the hashes (sha512) along with the package name. e.g.

onlyBuiltDependencies:
  - name: package1
    integrity:
      install: sha512-a90e02e755a96c2ae7f870c544e7c0bdc0df6706691475fe0cd0d4025e2b8286
      preinstall: sha512-9fe92a1acec5e755f994eed95344dc91074eb021467db2093dcac3eae0056519
  - name: package2
    integrity:
      install: sha512-29a3c3a5974c8da4968fc9fc0d759908a36ad696f212b2df4ffc32be3041f34e
      postinstall: sha512-2dd8a500802d32520e1f876b0d3587e72f542225df65de4915eda1c47edc4673

When you approve a package, it adds the checksums. When you update in the future, if the checksums are the same, then it's all good to run them. But if they differ, then don't run them and get the user to recheck and reapprove. That would close the gap for package updates.

There would still be ways around it. e.g. if the package install script is just a small wrapped around a binary or other script, then altering the binary or other script would not be detected, the install scripts would be unchanged and run. Short of implemeting a parse to crawl all scripts used in the install scripts and generating hashes for those also, it's probably easier to leave to the package author to ensure their install scripts are self-contained and not calling into other code an attacker could alter.

The other approach (simpler to implement but more work for users) is to store the version that was approved. And any update to the package will require a reapproval of install scripts. Something like this:

onlyBuiltDependencies:
  - name: package1
    version: 1.12.3
  - name: package2
    version: 3.1.433

[Blinker73]

@KieranP

I just started using pnpm yesterday and am having the exact same concerns.

I think your recommendations are a good step forward even if they are not bulletproof.
for example, I am reviewing the @tailwindcss/oxide package which is part of the tailwindcss V4 package that comes when creating a new next.js project using
npx create-next-app@latest project --tailwind
it's install script downloads a binary executable so even with the same script and the same package version, the downloaded binary could be compromised.

That being said,
I would appreciate the option to specify a version so I am reminded to review the scripts when the package is updated and also run the binary trough an antivirus program.

I am sure some people would prefer to not include the version (or even disable de security feature altogether) but if the version adheres to the package.json version syntax, one could simply indicate all version with "*" or one of the alternative syntax using ^, ~, >=, etc... to target major, minor and release versions.

[Blinker73]

Another nice to have would be that pnpm reports the path to the scripts that were not executed when issuing the warning

[StefanWallin]

I've migrated to PNPM post Shai-Hulud as well. And I remember "fondly" the times I've upgraded packages with Debians apt-get and a package has a new config file, I get to review it in a git-like manner with edit/diff/accept/deny. This could be applied to whenever a post-install-script-approved package is updated, regardless of if the script itself was changed.

Screenshot of apt-get update review options for new openssh server config file:

Screenshot source: Reddit discussion