[Bug]: lifecycle script triggering despite enableScripts=false

[legobeat]

Self-service

• I'd be willing to implement a fix

Describe the bug

It seems that for dependencies which themselves contain a yarn v1 lockfile, the enableScripts configuration value is ignored and lifecycle scripts are run regardless.

To reproduce

(Aside: The sherlock link in the GH template is 404ing)

• Set enableScripts: false in .yarnrc.yaml
• Add package with yarn v1 yarn.lock to dependencies
• Run yarn install

A reproduction PR on a minimal repo is available. As can be seen in the GitHub Actions workflow output from the yarn install step, the dependency preinstall and postinstall lifecycle scripts are triggered as part of the Resolution step.

Environment

System:
    OS: Linux 6.8 Debian GNU/Linux 12 (bookworm) 12 (bookworm)
    CPU: (10) x64 12th Gen Intel(R) Core(TM)
  Binaries:
    Node: 20.12.2 - /tmp/xfs-a3ccc8fc/node
    Yarn: 4.1.1 - /tmp/xfs-a3ccc8fc/yarn
    npm: 10.5.0 - /usr/local/bin/npm

Additional context

• Similar-looking but different: [Bug?]: disabled enableScripts setting still triggers postinstall script #4780
• Related: [Bug?]: Yarn 4 cannot install the packages from github #6240
• Addressing in fix: propagate --ignore-scripts to yarn v1 dependency bootstrap if enableScripts=false #6259

[legobeat]

@arcanis @merceyz PTAL

[legobeat]

Bump.

[legobeat]

@arcanis This is a security regression in 4.x vs 3.x.

On 3.8.3:

$ cat .yarnrc.yml
enableScripts: false

$ yarn --inline-builds --mode=skip-build
➤ YN0000: ┌ Resolution step
➤ YN0000: └ Completed
➤ YN0000: ┌ Fetch step
➤ YN0000: └ Completed
➤ YN0000: ┌ Link step
➤ YN0004: │ yuge-slow-npm-pkg@https://github.com/legobeat/yuge-slow-npm-pkg.git#commit=6940e29e44922456ab581090aab8015c23b55be0 lists build scripts, but all build scripts have been disabled.
➤ YN0000: └ Completed
➤ YN0000: Done with warnings in 0s 44ms

On 4.1.1:

$ cat .yarnrc.yml
enableScripts: false

$ yarn --inline-builds --mode=skip-build
➤ YN0000: · Yarn 4.1.1
➤ YN0000: ┌ Resolution step
➤ YN0000: └ Completed
➤ YN0000: ┌ Fetch step
➤ YN0000: │ /var/tmp/xfs-88ef6319 STDOUT Packing yuge-slow-npm-pkg@https://github.com/legobeat/yuge-slow-npm-pkg.git#commit=6940e29e44922456ab581090aab8015c23b55be0 from sources
➤ YN0000: │ /var/tmp/xfs-88ef6319 STDOUT Using Yarn Classic for bootstrap. Reason: "__metadata" key not found in yarn.lock, must be a Yarn classic lockfile
➤ YN0000: │ /var/tmp/xfs-88ef6319 STDOUT
➤ YN0000: │ /var/tmp/xfs-88ef6319 STDOUT ➤ YN0000: Downloading https://classic.yarnpkg.com/latest.js
➤ YN0000: │ /var/tmp/xfs-88ef6319 STDOUT ➤ YN0000: Saving the new release in .yarn/releases/yarn-classic.cjs
➤ YN0000: │ /var/tmp/xfs-88ef6319 STDOUT ➤ YN0000: Done in 2s 933ms
➤ YN0000: │ /var/tmp/xfs-88ef6319 STDOUT
➤ YN0000: │ /var/tmp/xfs-88ef6319 STDERR ! The local project doesn't define a 'packageManager' field. Corepack will now add one referencing yarn@4.3.1+sha512.af78262d7d125afbfeed740602ace8c5e4405cd7f4735c08feb327286b2fdb2390fbca01589bfd1f50b1240548b74806767f5a063c94b67e431aabd0d86f7774.
➤ YN0000: │ /var/tmp/xfs-88ef6319 STDERR ! For more details about this field, consult the documentation at https://nodejs.org/api/packages.html#packagemanager
➤ YN0000: │ /var/tmp/xfs-88ef6319 STDERR
➤ YN0000: │ /var/tmp/xfs-88ef6319 STDOUT yarn install v1.22.22
➤ YN0000: │ /var/tmp/xfs-88ef6319 STDOUT $ ./hooks.sh preinstall 30

(When package is present in lockfile/cache. When not, both v3 and v4 execute it)

Sidenote

The The local project doesn't define a 'packageManager' field. Corepack will now add one referencing yarn@4.3.1+sha512.af78262d7d125afbfeed740602ace8c5e4405cd7f4735c08feb327286b2fdb2390fbca01589bfd1f50b1240548b74806767f5a063c94b67e431aabd0d86f7774. line seems to be referencing the dependency, which is called here using Yarn Classic. So it also seems that the way this is being instrumented is confusing Corepack for dependencies which don't specify a packageManager field.

[ston1th]

Hi @arcanis

I'm not sure but I think this should get higher priority with the recent NPM package compromises like Shai-Hulud and Nx.
One of the main defenses was and is to disable all script execution. If this security feature does not work correctly anymore it should get fixed rather soon.

[RyanCavanaugh]

This also happens with git repo dependencies. Anyone who ran yarn install in grafana/grafana over the weekend got hit by the tanstack compromise due to a lack of lockfile in an git-dep'd repo.

A person reading .yarnrc.yml and seeing enableScripts=false should reasonably expect that running yarn install won't run scripts. approvedGitRepositories doesn't really help here either IMO; you should be able to configure yarn in a way that you can clone a git repo without running its scripts.

[arcanis]

Since I forgot to close this thread earlier: Yarn now respects enableScripts for exec dependencies. For git deps we have approvedGitRepos. If you still find ways to run code during install despite these settings (which both default to false nowadays) please open a new issue.

@RyanCavanaugh Problem is that without scripts installing git dependencies usually doesn't work since we need to run any prepack script (unless they check-in their build artifacts... but at that point they likely would use a registry). So it's a separate setting, which is also restrictive by default (no git repos allowed by default).