OSSForks/node
1
0
Fork 0
mirror of https://github.com/zebrajr/node.git synced 2026-01-15 12:15:26 +00:00
Code Issues Actions 8 Packages Projects Releases Wiki Activity
40,263 Commits 30 Branches 683 Tags
041d435be97866f40b8b87a22a220f5e93f58fcc
Go to file
Clone
Open with VS Code Open with VSCodium Open with Intellij IDEA
Download ZIP Download TAR.GZ Download BUNDLE
Tobias Nießen 041d435be9 permission: do not create symlinks if target is relative 
The permission model's security guarantees fall apart in the presence of
relative symbolic links. When an application attempts to create a
relative symlink, the permission model currently resolves the relative
path into an absolute path based on the process's current working
directory, checks whether the process has the relevant permissions, and
then creates the symlink using the absolute target path. This behavior
is plainly incorrect for two reasons:

1. The target path should never be resolved relative to the current
   working directory. If anything, it should be resolved relative to the
   symlink's location. (Of course, there is one insane exception to this
   rule: on Windows, each process has a current working directory per
   drive, and symlinks can be created with a target path relative to the
   current working directory of a specific drive. In that case, the
   relative path will be resolved relative to the current working
   directory for the respective drive, and the symlink will be created
   on disk with the resulting absolute path. Other relative symlinks
   will be stored as-is.)
2. Silently creating an absolute symlink when the user requested a
   relative symlink is wrong. The user may (or may not) rely on the
   symlink being relative. For example, npm heavily relies on relative
   symbolic links such that node_modules directories can be moved around
   without breaking.

Because we don't know the user's intentions, we don't know if creating
an absolute symlink instead of a relative symlink is acceptable. This
patch prevents the faulty behavior by not (incorrectly) resolving
relative symlink targets when the permission model is enabled, and by
instead simply refusing the create any relative symlinks.

The fs APIs accept Uint8Array objects for paths to be able to handle
arbitrary file name charsets, however, checking whether such an object
represents a relative part in a reliable and portable manner is tricky.
Other parts of the permission model incorrectly convert such objects to
strings and then back to an Uint8Array (see 1f64147eb6),
however, for now, this bug fix will simply throw on non-string symlink
targets when the permission model is enabled. (The permission model
already breaks existing applications in various ways, so this shouldn't
be too dramatic.)

PR-URL: https://github.com/nodejs/node/pull/49156
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
2023-11-22 17:30:36 +00:00
.devcontainer
build: add devcontainer configuration
2023-04-22 09:02:28 -07:00
.github
deps: add simdjson
2023-11-17 00:16:38 +00:00
android-patches
build: rewritten the Android build system
2022-09-12 08:10:29 +00:00
benchmark
benchmark: increase the iteration number to an appropriate value
2023-11-19 06:33:59 +00:00
deps
build: add GN configurations for simdjson
2023-11-21 22:39:02 +00:00
doc
doc: create deprecation code for isWebAssemblyCompiledModule
2023-11-22 17:20:46 +00:00
lib
permission: do not create symlinks if target is relative
2023-11-22 17:30:36 +00:00
src
src: fix compatility with upcoming V8 12.1 APIs
2023-11-22 15:12:52 +00:00
test
permission: do not create symlinks if target is relative
2023-11-22 17:30:36 +00:00
tools
tools: use macOS keychain to notarize the releases
2023-11-22 10:33:12 -05:00
typings
src: move package resolver to c++
2023-11-17 00:16:38 +00:00
.clang-format
…
.cpplint
…
.editorconfig
…
.eslintignore
esm: use import attributes instead of import assertions
2023-10-14 03:52:38 +00:00
.eslintrc.js
esm: use import attributes instead of import assertions
2023-10-14 03:52:38 +00:00
.gitattributes
…
.gitignore
build: add devcontainer configuration
2023-04-22 09:02:28 -07:00
.gitpod.yml
doc,tools: switch to @node-core/utils
2023-09-25 11:48:03 +00:00
.mailmap
meta: add ethan.arrowood@vercel.com to mailmap
2023-10-31 19:49:14 +00:00
.nycrc
…
.yamllint.yaml
…
android_configure.py
zlib: fix discovery of cpu-features.h for android
2023-09-29 11:52:46 -04:00
android-configure
build: add python 3.11 support for android
2022-12-11 02:58:02 +00:00
BSDmakefile
…
BUILD.gn
build: add GN build files
2023-11-11 09:51:05 +00:00
BUILDING.md
doc: recommend supported Python versions
2023-11-01 13:41:03 +00:00
CHANGELOG.md
2023-11-22, Version 20.10.0 'Iron' (LTS)
2023-11-22 16:03:13 +01:00
CODE_OF_CONDUCT.md
…
codecov.yml
tools: disable Codecov commit statuses
2023-04-01 07:08:22 +00:00
common.gypi
deps: V8: cherry-pick 8f0b94671ddb
2023-11-12 14:22:15 +00:00
configure
build: support Python 3.12
2023-11-06 14:11:01 +00:00
configure.py
build: add configuration flag to enable Maglev
2023-11-20 04:10:40 +00:00
CONTRIBUTING.md
…
glossary.md
…
GOVERNANCE.md
meta: update link to collaborators discussion page
2023-03-25 11:56:49 +00:00
LICENSE
deps: add simdjson
2023-11-17 00:16:38 +00:00
Makefile
build: run embedtest using node executable
2023-09-18 00:06:20 +02:00
node.gni
build: add GN build files
2023-11-11 09:51:05 +00:00
node.gyp
src: move package resolver to c++
2023-11-17 00:16:38 +00:00
node.gypi
build,test: add proper support for IBM i
2023-02-22 04:18:56 +00:00
onboarding.md
doc,tools: switch to @node-core/utils
2023-09-25 11:48:03 +00:00
pyproject.toml
tools: skip ruff on tools/gyp
2023-10-31 12:44:37 +00:00
README.md
doc: add CanadaHonk to triagers
2023-11-22 20:10:06 +05:30
SECURITY.md
doc: include experimental features assessment
2023-07-21 13:51:55 +00:00
tsconfig.json
lib: fix internalBinding typings
2023-09-23 10:48:34 +00:00
unofficial.gni
build: add GN configurations for simdjson
2023-11-21 22:39:02 +00:00
vcbuild.bat
build: drop support for Visual Studio 2019
2023-10-09 16:25:32 +00:00

README.md

Node.js

Node.js is an open-source, cross-platform JavaScript runtime environment.

For information on using Node.js, see the Node.js website.

The Node.js project uses an open governance model. The OpenJS Foundation provides support for the project.

Contributors are expected to act in a collaborative manner to move the project forward. We encourage the constructive exchange of contrary opinions and compromise. The TSC reserves the right to limit or block contributors who repeatedly act in ways that discourage, exhaust, or otherwise negatively affect other participants.

This project has a Code of Conduct.

Table of contents

Support

Looking for help? Check out the instructions for getting support.

Release types

  • Current: Under active development. Code for the Current release is in the branch for its major version number (for example, v19.x). Node.js releases a new major version every 6 months, allowing for breaking changes. This happens in April and October every year. Releases appearing each October have a support life of 8 months. Releases appearing each April convert to LTS (see below) each October.
  • LTS: Releases that receive Long Term Support, with a focus on stability and security. Every even-numbered major version will become an LTS release. LTS releases receive 12 months of Active LTS support and a further 18 months of Maintenance. LTS release lines have alphabetically-ordered code names, beginning with v4 Argon. There are no breaking changes or feature additions, except in some special circumstances.
  • Nightly: Code from the Current branch built every 24-hours when there are changes. Use with caution.

Current and LTS releases follow semantic versioning. A member of the Release Team signs each Current and LTS release. For more information, see the Release README.

Download

Binaries, installers, and source tarballs are available at https://nodejs.org/en/download/.

Current and LTS releases

https://nodejs.org/download/release/

The latest directory is an alias for the latest Current release. The latest-codename directory is an alias for the latest release from an LTS line. For example, the latest-hydrogen directory contains the latest Hydrogen (Node.js 18) release.

Nightly releases

https://nodejs.org/download/nightly/

Each directory name and filename contains a date (in UTC) and the commit SHA at the HEAD of the release.

API documentation

Documentation for the latest Current release is at https://nodejs.org/api/. Version-specific documentation is available in each release directory in the docs subdirectory. Version-specific documentation is also at https://nodejs.org/download/docs/.

Verifying binaries

Download directories contain a SHASUMS256.txt file with SHA checksums for the files.

To download SHASUMS256.txt using curl:

curl -O https://nodejs.org/dist/vx.y.z/SHASUMS256.txt

To check that a downloaded file matches the checksum, run it through sha256sum with a command such as:

grep node-vx.y.z.tar.gz SHASUMS256.txt | sha256sum -c -

For Current and LTS, the GPG detached signature of SHASUMS256.txt is in SHASUMS256.txt.sig. You can use it with gpg to verify the integrity of SHASUMS256.txt. You will first need to import the GPG keys of individuals authorized to create releases. To import the keys:

gpg --keyserver hkps://keys.openpgp.org --recv-keys 4ED778F539E3634C779C87C6D7062848A1AB005C

See Release keys for a script to import active release keys.

Next, download the SHASUMS256.txt.sig for the release:

curl -O https://nodejs.org/dist/vx.y.z/SHASUMS256.txt.sig

Then use gpg --verify SHASUMS256.txt.sig SHASUMS256.txt to verify the file's signature.

Building Node.js

See BUILDING.md for instructions on how to build Node.js from source and a list of supported platforms.

Security

For information on reporting security vulnerabilities in Node.js, see SECURITY.md.

Contributing to Node.js

Current project team members

For information about the governance of the Node.js project, see GOVERNANCE.md.

TSC (Technical Steering Committee)

TSC voting members

TSC regular members

TSC emeriti members

TSC emeriti members

Collaborators

Emeriti

Collaborator emeriti

Collaborators follow the Collaborator Guide in maintaining the Node.js project.

Triagers

Triagers follow the Triage Guide when responding to new issues.

Release keys

Primary GPG keys for Node.js Releasers (some Releasers sign with subkeys):

To import the full set of trusted release keys (including subkeys possibly used to sign releases):

gpg --keyserver hkps://keys.openpgp.org --recv-keys 4ED778F539E3634C779C87C6D7062848A1AB005C
gpg --keyserver hkps://keys.openpgp.org --recv-keys 141F07595B7B3FFE74309A937405533BE57C7D57
gpg --keyserver hkps://keys.openpgp.org --recv-keys 74F12602B6F1C4E913FAA37AD3A89613643B6201
gpg --keyserver hkps://keys.openpgp.org --recv-keys DD792F5973C6DE52C432CBDAC77ABFA00DDBF2B7
gpg --keyserver hkps://keys.openpgp.org --recv-keys 8FCCA13FEF1D0C2E91008E09770F7A9A5AE15600
gpg --keyserver hkps://keys.openpgp.org --recv-keys C4F0DFFF4E8C1A8236409D08E73BC641CC11F4C8
gpg --keyserver hkps://keys.openpgp.org --recv-keys 890C08DB8579162FEE0DF9DB8BEAB4DFCF555EF4
gpg --keyserver hkps://keys.openpgp.org --recv-keys C82FA3AE1CBEDC6BE46B9360C43CEC45C17AB93C
gpg --keyserver hkps://keys.openpgp.org --recv-keys 108F52B48DB57BB0CC439B2997B01419BD92F80A
gpg --keyserver hkps://keys.openpgp.org --recv-keys A363A499291CBBC940DD62E41F10027AF002F8B0

See Verifying binaries for how to use these keys to verify a downloaded file.

Other keys used to sign some previous releases

Security release stewards

When possible, the commitment to take slots in the security release steward rotation is made by companies in order to ensure individuals who act as security stewards have the support and recognition from their employer to be able to prioritize security releases. Security release stewards manage security releases on a rotation basis as outlined in the security release process.

License

Node.js is available under the MIT license. Node.js also includes external libraries that are available under a variety of licenses. See LICENSE for the full license text.

Reference in New Issue View Git Blame Copy Permalink
Description
Node.js JavaScript runtime ✨🐢🚀✨ nodejs.org
Readme Multiple Licenses 1.4 GiB
Languages
JavaScript 62.4%
C++ 23.1%
Python 10.1%
C 2.7%
HTML 0.6%
Other 0.9%