Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: lifecycle script triggering despite enableScripts=false #6258

Open
1 task done
legobeat opened this issue Apr 30, 2024 · 3 comments · May be fixed by #6280
Open
1 task done

[Bug]: lifecycle script triggering despite enableScripts=false #6258

legobeat opened this issue Apr 30, 2024 · 3 comments · May be fixed by #6280
Labels
bug Something isn't working

Comments

@legobeat
Copy link

legobeat commented Apr 30, 2024

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

@legobeat legobeat added the bug Something isn't working label Apr 30, 2024
@legobeat legobeat changed the title [Bug?]: lifecycle script triggering despite enableScripts=false [Bug]: lifecycle script triggering despite enableScripts=false Apr 30, 2024
@legobeat
Copy link
Author

legobeat commented May 2, 2024

@arcanis @merceyz PTAL

@legobeat
Copy link
Author

legobeat commented Jul 6, 2024

Bump.

@legobeat
Copy link
Author

legobeat commented Jul 7, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant