Merge a99b8b0ca3 into 1aab8b2d5a

Let's say we have nvm installed in a separate mount, /.socket. NVM_DIR is $HOME/.nvm in /etc/profile.d/nvm.sh. With this setup, users can install Node versions to their home directories without each installing nvm.

nvm install --lts

This works fine as does nvm use --lts. When nvm exec is used though, it fails because it looks for nvm-exec in $NVM_DIR. First fix is to look for nvm-exec in $NVM_DIR. If NVM_DIR does not contain nvm-exec, check $BASH_SOURCE[0]. The second fix is to follow nvm-exec if a symbolic link to determine the proper location of nvm's home. Alternatively we could use a second environment variable, NVM_HOME in exec instead of relying on the directory name of nvm-exec.

.github/INCIDENT_RESPONSE_PLAN.md

@@ -0,0 +1,117 @@
+# Incident Response Process for **nvm**
+
+## Reporting a Vulnerability
+
+We take the security of **nvm** very seriously. If you believe you’ve found a security vulnerability, please inform us responsibly through coordinated disclosure.
+
+### How to Report
+
+> **Do not** report security vulnerabilities through public GitHub issues, discussions, or social media.
+
+Instead, please use one of these secure channels:
+
+1. **GitHub Security Advisories**
+    Use the **Report a vulnerability** button in the Security tab of the [nvm-sh/nvm repository](https://github.com/nvm-sh/nvm).
+
+2. **Email**
+    Follow the posted [Security Policy](https://github.com/nvm-sh/nvm/security/policy).
+
+### What to Include
+
+**Required Information:**
+- Brief description of the vulnerability type
+- Affected version(s) and components
+- Steps to reproduce the issue
+- Impact assessment (what an attacker could achieve)
+
+**Helpful Additional Details:**
+- Full paths of affected scripts or files
+- Specific commit or branch where the issue exists
+- Required configuration to reproduce
+- Proof-of-concept code (if available)
+- Suggested mitigation or fix
+
+## Our Response Process
+
+**Timeline Commitments:**
+- **Initial acknowledgment**: Within 24 hours
+- **Detailed response**: Within 3 business days
+- **Status updates**: Every 7 days until resolved
+- **Resolution target**: 90 days for most issues
+
+**What We’ll Do:**
+1. Acknowledge your report and assign a tracking ID
+2. Assess the vulnerability and determine severity
+3. Develop and test a fix
+4. Coordinate disclosure timeline with you
+5. Release a security update and publish an advisory and CVE
+6. Credit you in our security advisory (if desired)
+
+## Disclosure Policy
+
+- **Coordinated disclosure**: We’ll work with you on timing
+- **Typical timeline**: 90 days from report to public disclosure
+- **Early disclosure**: If actively exploited
+- **Delayed disclosure**: For complex issues
+
+## Scope
+
+**In Scope:**
+- **nvm** project (all supported versions)
+- Installation and update scripts (`install.sh`, `nvm.sh`)
+- Official documentation and CI/CD integrations
+- Dependencies with direct security implications
+
+**Out of Scope:**
+- Third-party forks or mirrors
+- Platform-specific installs outside core scripts
+- Social engineering or physical attacks
+- Theoretical vulnerabilities without practical exploitation
+
+## Security Measures
+
+**Our Commitments:**
+- Regular vulnerability scanning via GitHub Actions
+- Automated security checks in CI/CD pipelines
+- Secure scripting practices and mandatory code review
+- Prompt patch releases for critical issues
+
+**User Responsibilities:**
+- Keep **nvm** updated
+- Verify script downloads via PGP signatures
+- Follow secure configuration guidelines for shell environments
+
+## Legal Safe Harbor
+
+**We will NOT:**
+- Initiate legal action
+- Contact law enforcement
+- Suspend or terminate your access
+
+**You must:**
+- Only test against your own installations
+- Not access, modify, or delete user data
+- Not degrade service availability
+- Not publicly disclose before coordinated disclosure
+- Act in good faith
+
+## Recognition
+
+- **Advisory Credits**: Credit in GitHub Security Advisories (unless anonymous)
+
+## Security Updates
+
+**Stay Informed:**
+- Subscribe to GitHub releases for **nvm**
+- Enable GitHub Security Advisory notifications
+
+**Update Process:**
+- Patch releases (e.g., v0.40.3 → v0.40.4)
+- Out-of-band releases for critical issues
+- Advisories via GitHub Security Advisories
+
+## Contact Information
+
+- **Security reports**: Security tab of [nvm-sh/nvm](https://github.com/nvm-sh/nvm/security)
+- **General inquiries**: GitHub Discussions or Issues
+

.github/SECURITY.md

@@ -1,6 +1,6 @@
 # Security
 
-Please email [@ljharb](https://github.com/ljharb) or see https://tidelift.com/security if you have a potential security vulnerability to report.
+Please file a private vulnerability report via GitHub, email [@ljharb](https://github.com/ljharb), or see https://tidelift.com/security if you have a potential security vulnerability to report.
 
 ## OpenSSF CII Best Practices
 
@@ -12,16 +12,17 @@ There are three “tiers”: passing, silver, and gold.
 We meet 100% of the “passing” criteria.
 
 ### Silver
-We meet 95% of the “silver” criteria. The gaps are as follows:
+We meet 100% of the “silver” criteria.
-  - we do not have a DCO or a CLA process for contributions.
-  - because we only have one maintainer, the project has no way to continue if that maintainer stops being active.
-  - we do not currently document “what the user can and cannot expect in terms of security” for our project. This is planned to be completed in 2023.
 
 ### Gold
-We meet 65% of the “gold” criteria. The gaps are as follows:
+We meet 78% of the “gold” criteria. The gaps are as follows:
-  - we do not yet have the “silver” badge; see all the gaps above.
+  - because we only have one maintainer, the project has no way to continue if that maintainer stops being active.
   - We do not include a copyright or license statement in each source file. Efforts are underway to change this archaic practice into a suggestion instead of a hard requirement.
 
 ## Threat Model
 
-See [THREAT_MODEL.md](./THREAT_MODEL.md).
+See [THREAT_MODEL.md](.github/THREAT_MODEL.md).
+
+## Incident Response Plan
+
+Please see our [Incident Response Plan](.github/INCIDENT_RESPONSE_PLAN.md).

nvm-exec

@@ -1,6 +1,6 @@
 #!/usr/bin/env bash
 
-DIR="$(command cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
+DIR="$(dirname "$(realpath "${BASH_SOURCE[0]}")")"
 
 unset NVM_CD_FLAGS
 

nvm.sh

@@ -4080,8 +4080,14 @@ nvm() {
           nvm_echo "Running node ${VERSION}$(nvm use --silent "${VERSION}" && nvm_print_npm_version)"
         fi
       fi
-      NODE_VERSION="${VERSION}" "${NVM_DIR}/nvm-exec" "$@"
+
+      NVM_EXEC="${NVM_DIR}/nvm-exec"
+      if [ ! -f "${NVM_EXEC}" ]; then
+        NVM_EXEC="$(dirname "${BASH_SOURCE[0]-}")/nvm-exec"
+      fi
+      NODE_VERSION="${VERSION}" "${NVM_EXEC}" "$@"
     ;;
+
     "ls" | "list")
       local PATTERN
       local NVM_NO_COLORS

test/slow/nvm exec/Running 'nvm exec --lts' when NVM_DIR differs from nvm

@@ -0,0 +1,18 @@
+#!/bin/sh
+
+set -ex
+
+die () { echo "$@" ; exit 1; }
+
+INSTPATH="$(mktemp -p "$(pwd)" -d)"
+trap 'test ! -z "${INSTPATH-}" && test -d "$INSTPATH" && rm -rf "$INSTPATH"' EXIT
+declare -x NVM_DIR=$INSTPATH
+\. ../../../nvm.sh
+
+nvm install --lts || die 'nvm install --lts failed'
+nvm exec --lts npm --version || die "`nvm exec` failed to run"
+declare -x NODE_VERSION="$(nvm exec --lts --silent node --version)"
+
+ln -s ../../../../nvm-exec "$INSTPATH/nvm-exec" || die "failed to create a symlink to $INSTPATH/"
+"$INSTPATH/nvm-exec" npm ls > /dev/null || die "`nvm exec` failed to run using nvm-exec helper"
+