镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

Node must de-duplicate environment variables before calling CreateProcess (and upon env.extend()) #35129

Description

@asklar
  • Version: 12.9.1
  • Platform: x64
  • Subsystem: Windows 10

What steps will reproduce the bug?

yarn sets up some environment variables (like npm_config_cache) and calls execSync. This calls the Win32 API CreateProcess and passes an environment block which is a merge of the existing environment block (i.e. from the calling process) with some additional stuff that includes npm_config_cache among others.

Environment variables in Windows are case-insensitive, but CreateProcess does not seem to sanitize the environment block. This is a problem because if the calling process had set up NPM_CONFIG_CACHE (all caps), then yarn will just set the lowercase variant of the variable, and node will call CreateProcess which will contain the variable twice). This breaks some tools that create dictionaries out of the environment block because they expect to run into each variable exactly once (regardless of casing).

In my case we have a nodejs script that we invoke via yarn, and the nodejs script calls a Windows build utility (msbuild) which crashes when trying to set up options for the compiler when it finds this option twice. We run into this when building in our CI in Azure DevOps pipeline, which sets up NPM_CONFIG_CACHE in the environment.

Related:

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

100%

What is the expected behavior?

node should de-duplicate variables before passing them to CreateProcess

What do you see instead?

CreateProcess gets an environment block with both variables:
image

Additional information

Activity

  1. bzoz commented on Sep 9, 2020

    @bzoz
    Contributor

    This is basically a duplicate of #34667

    When spawn gets the object with the env pairs there is no way for it to know which one is the "true one", there is no record of which was added later. This is a known, documented limitation and unfortunately, there is no way of fixing this in Node.

    In this case, yarn needs to be fixed to correctly handle environment variables on Windows.

  2. added
    duplicateIssues and PRs that are duplicates of other issues or PRs.
    processIssues and PRs related to the process subsystem.
    windowsIssues and PRs related to the Windows platform.
    on Sep 10, 2020
  3. bnoordhuis commented on Sep 10, 2020

    @bnoordhuis
    Member

    Closing as a duplicate.

  4. asklar commented on Sep 10, 2020

    @asklar
    Author

    @bnoordhuis @bzoz The documentation only mentions PATH as being the special case but in fact all environment variables are susceptible to this problem. Could you please update the documentation to reflect this?

    Moreover, the doc says it will sort the variables lexicographically and use the first occurrence of PATH. This is the same behavior that the OS GetEnvironmentVariable will do, so once you get into the duplicate variable case, it doesn't matter which one was added last - the only one that is reachable via GetEnvironmentVariable is going to be the first lexicographically, so spawn could sanitize the env block by doing exactly that, only keep the first instance of each variable

  5. bzoz commented on Sep 10, 2020

    @bzoz
    Contributor

    Those points make sense, both the doc update and the sanitization.

    I think keeping only one entry for each env variable would be a semver-major though.

  6. reopened this on Sep 10, 2020
  7. asklar commented on Sep 15, 2020

    @asklar
    Author

    @bzoz any clue when we might see this fixed?

  8. bzoz commented on Sep 15, 2020

    @bzoz
    Contributor

    I've opened a PR with a fix: #35210. I guess this is a semver-major though, so I would expect this to be shipped with the next major release of Node.

  9. asklar commented on Sep 15, 2020

    @asklar
    Author

    thanks a lot @bzoz. From the release doc it sounds like the next release is October so that would be ok assuming we can get this in soon 🤞

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    duplicateIssues and PRs that are duplicates of other issues or PRs.processIssues and PRs related to the process subsystem.windowsIssues and PRs related to the Windows platform.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions