[Bug]: lifecycle script triggering despite enableScripts=false

legobeat commented 5 months ago

Self-service

[X] 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: #4780
Related: #6240
Addressing in #6259

legobeat commented 5 months ago

@arcanis @merceyz PTAL

legobeat commented 2 months ago

Bump.

legobeat commented 2 months ago

@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.

yarnpkg / berry