Skip to content

DebugAdapterExecutable does not support passing shell: true so .bat-based debug adapters are broken in current Insiders #224184

Closed

Description

@DanTup

In current Insiders (and presumably the upcoming release), spawning a .bat file on Windows without shell: true fails due to a breaking change in NodeJS:

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

It is important to note that there has been a breaking change for Windows users who utilize child_process.spawn and child_process.spawnSync. Node.js will now error with EINVAL if a .bat or .cmd file is passed to child_process.spawn and child_process.spawnSync without the shell option set.

It appears that there's no way to signal this to DebugAdapterExecutable and therefore any .bat-based debug adapters launched this way fail in current Insiders (and will presumably fail in stable soon).

Could shell: bool? be added to DebugAdapterExecutableOptions? I don't know enough to contribute this, but this seems quite important.

Activity

  1. DanTup commented on Jul 29, 2024

    @DanTup
    Author
  2. DanTup commented on Jul 29, 2024

    @DanTup
    Author
  3. DanTup commented on Jul 29, 2024

    @DanTup
    ContributorAuthor

    I have a fix in a PR at #224204

    Although because I sneakily have a space in the path to my DA, I also noticed that enabling shell: true also changes behaviour, and the path to the executable will need quoting/escaping. I've called this out on the doc for shell because it's something extension authors will need to consider when switching to use this.

    Screenshot 2024-07-29 165337

    Screenshot 2024-07-29 165356

  4. added
    bugIssue identified by VS Code Team member as probable bug
    on Jul 29, 2024
  5. added this to the August 2024 milestone on Jul 29, 2024
  6. DanTup commented on Jul 29, 2024

    @DanTup
    ContributorAuthor

    roblourens I noticed you assigned this to the August milestone - does this mean that the next stable will ship without a fix for this? It breaks debug adapters that use .bat like Flutter, which will affect a considerable number of users.

  7. roblourens commented on Jul 29, 2024

    @roblourens
    Member

    Well, I can't take the PR for the next Stable because it adds extension API and we can't add that two days before we release. I'll take a look at this.

    Maybe you could wrap your .bat in a node script where you can call spawn yourself, and vscode can run the node script? You just have to connect the stdin and stdout pipes.

  8. connor4312 commented on Jul 30, 2024

    @connor4312
    Member

    Please see gitkraken/vscode-gitlens#3387 for guidance -- that was the issue template we automated posting on on extensions that contained bat files. I don't think there's any 'fix' for this we can apply on the VS Code side without reverting the CVE patch.

    This is not really related to DAP. DAP does not know anything about the runtime that debug adapters are executed in.

  9. DanTup commented on Jul 30, 2024

    @DanTup
    ContributorAuthor

    roblourens

    Well, I can't take the PR for the next Stable because it adds extension API and we can't add that two days before we release. I'll take a look at this.

    The Flutter extension has almost 9m installs and this issue breaks starting debug sessions for all of them on Windows. Surely if a critical issue like this is discovered right before a release, some solution should be looked at? The change could be made without an API change by having VS Code just check for .bat on the end of the DA executable, but I'm not sure if that's a better fix.

    Maybe you could wrap your .bat in a node script where you can call spawn yourself, and vscode can run the node script? You just have to connect the stdin and stdout pipes.

    This might work, but I suspect there are edge cases (like handling termination of additional processes) that IMO make this a riskier fix to ship the day before a release than adding shell: true.

    Connor Peet (@connor4312)

    Please see gitkraken/vscode-gitlens#3387 for guidance

    Dart-Code never got this template (it doesn't contain bat files, the Flutter debug adapter lives in the Flutter SDK). If I did, I could've sent the PR weeks ago :-(

    This is not really related to DAP. DAP does not know anything about the runtime that debug adapters are executed in.

    I think you have misunderstood the issue. I am familiar with the breaking change - this is a process being spawned by VS Code, not the extension:

    this.serverProcess = cp.spawn(command, args, spawnOptions);

    All my extension code has always used shell: true where necessary, but this is code where we provide the executable and args to VS Code and it spawns the process - it does not use (and gives us no ability to pass) shell: true. Please see my linked PR which fixes the issue.

  10. 1 remaining item

  11. roblourens commented on Jul 30, 2024

    @roblourens
    Member

    I just discussed this with Connor, and we agree that this is different than the other issues. We can likely check for a DebugAdapterExecutable command that ends in .bat and set the shell flag ourselves (and escape spaces). We can do that on vscode's end without new API. And maybe can get that in before the next stable release. I will try that out today.

  12. DanTup commented on Jul 30, 2024

    @DanTup
    ContributorAuthor

    And maybe can get that in before the next stable release.

    Thank you! I was preparing a workaround to ship in Dart-Code, however it's far from ideal (it hard-codes assumptions about what the shell script does that may not hold across all Flutter SDK versions) and it would only work for users that update to the latest extension (whereas a fix in VS Code as you describe would prevent anyone from breaking).

    I may still ship the workaround in a pre-release today to get some additional testing so if you cannot fix this I at least have a fallback, but I'd appreciate if you could keep me posted with your testing and when it might hit insiders, because I need to decide whether to include the workaround in the stable extension release (which is likely to be tomorrow or Thursday).

    Tnx! :)

  13. added
    candidateIssue identified as probable candidate for fixing in the next release
    and removed on Jul 30, 2024
  14. roblourens commented on Jul 30, 2024

    @roblourens
    Member

    /closedBy 3bb1578

  15. locked and limited conversation to collaborators on Sep 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugIssue identified by VS Code Team member as probable bugcandidateIssue identified as probable candidate for fixing in the next releasedebugDebug viewlet, configurations, breakpoints, adapter issuesverifiedVerification succeeded

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions