Command run failed with error : spawn EINVAL

Version

v18.20.2

Platform

Microsoft Windows NT 10.0.19045.0 x64

Subsystem

No response

What steps will reproduce the bug?

Download NodeJS Version v18.20.2, v20.12.2, v21.7.3
Download Visual Studio Code
Install Extension Pack SAP Fiori Extensions
Generate a sample Project
Use npm start

How often does it reproduce? Is there a required condition?

everytime using npm start

What is the expected behavior? Why is that the expected behavior?

It should open the web browser with the started App

What do you see instead?

[email protected] start
fiori run --open "test/flpSandbox.html?sap-ui-xx-viewCache=false#project1-display"

Command run failed with error : spawn EINVAL

Additional information

Happened first time after updating the node version.
Seems like a new problem after the security patch.
After downgrade it works fine.
See also: Link

Hi! This repo is mostly for issues regarding the NodeJS core, and we need further context/information to understand the problem.

If you have an issue with VSCode or Fiori, please report it to them.

Otherwise, please provide more context about the issue, such as stack traces and minimally reproducible examples.

Thank you!

This is a problem with spawn and spawnSync on Windows.

Platform: Windows 10.0.19045 N/A Build 19045

Using Node.js v20.12.1:

> node
Welcome to Node.js v20.12.1.
Type ".help" for more information.
> child_process.spawnSync('npm.cmd', ['-v'])
{
  status: 0,
  signal: null,
  output: [ null, <Buffer 31 30 2e 35 2e 31 0a>, <Buffer > ],
  pid: 23324,
  stdout: <Buffer 31 30 2e 35 2e 31 0a>,
  stderr: <Buffer >
}

Using Node.js 20.12.2:

> node
Welcome to Node.js v20.12.2.
Type ".help" for more information.
> child_process.spawnSync('npm.cmd', ['-v'])
{
  error: Error: spawnSync npm.cmd EINVAL
      at Object.spawnSync (node:internal/child_process:1124:20)
      at Object.spawnSync (node:child_process:876:24)
      at REPL1:1:15
      at ContextifyScript.runInThisContext (node:vm:136:12)
      at REPLServer.defaultEval (node:repl:598:22)
      at bound (node:domain:432:15)
      at REPLServer.runBound [as eval] (node:domain:443:12)
      at REPLServer.onLine (node:repl:927:10)
      at REPLServer.emit (node:events:530:35)
      at REPLServer.emit (node:domain:488:12) {
    errno: -4071,
    code: 'EINVAL',
    syscall: 'spawnSync npm.cmd',
    path: 'npm.cmd',
    spawnargs: [ '-v' ]
  },
  status: null,
  signal: null,
  output: null,
  pid: 0,
  stdout: null,
  stderr: null
}

https://nodejs.org/en/blog/vulnerability/april-2024-security-releases-2

@bnoordhuis

Caused by 69ffc6d.

@bnoordhuis @RafaelGSS Now that spawning .cmd files is blocked, what is the alternative? Leaving the .cmd extension off doesn't work.

> node
Welcome to Node.js v20.12.2.
Type ".help" for more information.
> child_process.spawnSync('npm', ['-v'])
{
  error: Error: spawnSync npm ENOENT
      at Object.spawnSync (node:internal/child_process:1124:20)
      at Object.spawnSync (node:child_process:876:24)
      at REPL1:1:15
      at ContextifyScript.runInThisContext (node:vm:136:12)
      at REPLServer.defaultEval (node:repl:598:22)
      at bound (node:domain:432:15)
      at REPLServer.runBound [as eval] (node:domain:443:12)
      at REPLServer.onLine (node:repl:927:10)
      at REPLServer.emit (node:events:530:35)
      at REPLServer.emit (node:domain:488:12) {
    errno: -4058,
    code: 'ENOENT',
    syscall: 'spawnSync npm',
    path: 'npm',
    spawnargs: [ '-v' ]
  },
  status: null,
  signal: null,
  output: null,
  pid: 0,
  stdout: null,
  stderr: null
}

@bnoordhuis

@bnoordhuis @RafaelGSS Now that spawning .cmd files is blocked, what is the alternative? Leaving the .cmd extension off doesn't work.

Use { shell: true } when spawning if the input is sanitized. @bnoordhuis is there any other suggested way?

@RafaelGSS

Awesome, that solves the problem for me. Thanks for the quick response @RafaelGSS ❤️

Thanks for the info! Sorry if I misunderstood the initial request!

This seems like a very significant breaking behavior change to make in a patch version? My team observed this same issue from a different tool which spawns npm.cmd to run scripts on Windows, and it seems like it would break any tool using this approach unless they already use { shell: true }.

@ecraig12345

@ecraig12345, while the change maybe is a bit more than a patch, it has been released, so there's really nothing we can do about that specifically, but maybe we can make a sort-of note that this change occurred, so that users will understand how to continue using their projects, WDYT @RafaelGSS?

I know we have the blog posts, but TBH not many end users will read all the way through the blogs to figure out this one issue, as not everyone reads the security updates

Maybe a notice in the documentation?

Fix JS build on Windows

fix: spawn issue on windows relative to nodejs/node#52554

I know we have the blog posts, but TBH not many end users will read all the way through the blogs to figure out this one issue, as not everyone reads the security updates

Maybe a notice in the documentation?

I think we can update the security release blog post to provide alternatives, then I can comment in the commit link to point to the blog post

Great!

This seems like a very significant breaking behavior change to make in a patch version? My team observed this same issue from a different tool which spawns npm.cmd to run scripts on Windows, and it seems like it would break any tool using this approach unless they already use { shell: true }.

According to our policy. We can only perform a breaking change in a semver-patch release if it's a security vulnerability is found. That was the case.

We also provide a mechanism to revert this behaviour such as --security-revert=CVE-2024-27980. Note, that this will disable the security patch, which is not recommended.

fix: spawn issue on windows relative to nodejs/node#52554

Fix broken spawn on windows

fix(node): support for Node 20.12.2 on Windows

This is quite an invasisve change and because of #52017 I cannot propagate the --security-revert to usages of spawn in libraries and/or subprocesses. Is there any approach to making this work?

This is quite an invasisve change and because of #52017 I cannot propagate the --security-revert to usages of spawn in libraries and/or subprocesses. Is there any approach to making this work?

If you don't have control of the process to pass the --security-revert (on its child processes too), then there's no official workaround for that. The #52365 should solve it, but it hasn't been released yet. You can try monkey-patching .spawnSync/spawn to bind { shell: true } by default, but monkey-patching is not really a recommended option, it might work until new PRs arrises.

Please note, that this was a coordinated security release with other teams (Rust, PHP, ...) and per policy, we must fix it -- even if it breaks people, security is a must. We always attempt to create revert options (such as --security-revert, but sometimes it might not apply to all environments).

Navigation Menu

Repository navigation

Command run failed with error : spawn EINVAL #52554

Version

Platform

Subsystem

What steps will reproduce the bug?

How often does it reproduce? Is there a required condition?

What is the expected behavior? Why is that the expected behavior?

What do you see instead?

Additional information

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Command run failed with error : spawn EINVAL #52554

Description

Version

Platform

Subsystem

What steps will reproduce the bug?

How often does it reproduce? Is there a required condition?

What is the expected behavior? Why is that the expected behavior?

What do you see instead?

Additional information

Activity

avivkeller commented on Apr 16, 2024

reduckted commented on Apr 16, 2024

cjihrig commented on Apr 16, 2024

reduckted commented on Apr 16, 2024

RafaelGSS commented on Apr 16, 2024

reduckted commented on Apr 16, 2024

avivkeller commented on Apr 16, 2024

ecraig12345 commented on Apr 16, 2024

avivkeller commented on Apr 16, 2024

RafaelGSS commented on Apr 17, 2024

avivkeller commented on Apr 17, 2024

RafaelGSS commented on Apr 17, 2024

JoostK commented on Apr 18, 2024

RafaelGSS commented on Apr 18, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions