Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

deps: upgrade npm to 2.7.5 #1337

Closed
wants to merge 3 commits into from
Closed

deps: upgrade npm to 2.7.5 #1337

wants to merge 3 commits into from

Conversation

othiym23
Copy link
Contributor

@othiym23 othiym23 commented Apr 3, 2015

This release of npm is a little more important than most, because it contains two security fixes:

  • 300834e
    tar@2.0.0: Normalize symbolic links that point to targets outside the
    extraction root. This prevents packages containing symbolic links from
    overwriting targets outside the expected paths for a package. Thanks to Tim
    Cuthbertson
    and the team at Lift
    Security
    for working with the npm team to identify
    this issue. (@othiym23)
  • 0dc6875
    semver@4.3.2: Package versions can be no more than 256 characters long.
    This prevents a situation in which parsing the version number can use
    exponentially more time and memory to parse, leading to a potential denial of
    service. Thanks to Adam Baldwin at Lift Security for bringing this to our
    attention. (@isaacs)

The severity is medium and the impact is low, at least for now. We have no evidence that either of these vulnerabilities were being exploited in the wild. All the same, it would be good to get people upgrading.

This version also contains two important fixes to npm's git / GitHub support:

Unfortunately, npm@2.7.5 is missing the final piece of the git puzzle:

  • b747593
    #7630 Don't automatically log all
    git failures as errors. maybeGithub needs to be able to fail without
    logging to support its fallback logic.
    (@othiym23)

In most cases, npm@2.7.5 will work fine with private GitHub repositories, but it will log an ugly and misleading message about what it's doing. The above change (which is part of npm@2.7.6) takes care of that, but I still don't think it's a good idea to jump the gun with npm releases. I could maybe be persuaded otherwise.

I've applied the two roll-up patches for improved node-gyp support already. All I need are some reviewers!

R=@piscisaureus
R=@Fishrock123

@Fishrock123
Copy link
Member

Reviewing. Due to #1323 and the aforementioned fixes I'd like to get a release with this out within the next 48 hours or so. I'll also open a release proposal soon.

@mscdex mscdex added the npm Issues and PRs related to the npm client dependency or the npm registry. label Apr 3, 2015
@Fishrock123
Copy link
Member

// god, tar is so annoying

Hey, at least we aren't dealing with .psd files. :)

Looked over the code. In case anyone is wondering the diff is mostly:

  • new tar (tarball handling) dep
  • updated request

Getting some errors on test-npm though: https://gist.github.com/Fishrock123/06f00d64a30758a20f72

cjihrig and others added 2 commits April 3, 2015 10:03
Every npm version bump requires a few patches to be floated on
node-gyp for io.js compatibility. These patches are found in
03d1992,
5de334c, and
da730c7. This commit squashes
them into a single commit.

PR-URL: nodejs#990
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
On Windows, when node or io.js attempts to dynamically load a compiled
addon, the compiled addon tries to load node.exe or iojs.exe again -
depending on which import library the module used when it was linked.
This causes many compiled addons to break when node.exe or iojs.exe are
renamed, because when the binary has been renamed the addon DLL can't
find the (right) .exe file to load its imports from.

This patch gives compiled addon developers an option to overcome this
restriction by compiling a delay-load hook into their binary. The
delay-load hook ensures that whenever a module tries to load imports
from node.exe/iojs.exe, it'll just look at the process image, thereby
making the addon work regardless of what name the node/iojs binary has.

To enable this feature, the addon developer must set the
'win_delay_load_hook' option to 'true' in their binding.gyp file, like
this:

```
{
  'targets': [
    {
      'target_name': 'ernie',
      'win_delay_load_hook': 'true',
      ...
```

Bug: nodejs#751
Bug: nodejs#965
Upstream PR: nodejs/node-gyp#599

PR-URL: nodejs#1251
Reviewed-By: Rod Vagg <rod@vagg.org>

PR-URL: nodejs#1266
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
@othiym23
Copy link
Contributor Author

othiym23 commented Apr 3, 2015

@Fishrock123

Getting some errors on test-npm though: https://gist.github.com/Fishrock123/06f00d64a30758a20f72

That's due to HFS+ case folding and this line in io.js's .gitignore (TIL about git check-ignore --verbose!). To fix this, I ran

$  git config --unset-all core.ignorecase
$  git config --system core.ignorecase false

to make git stop following HFS+'s case-folding rules. Defaulting core.ignorecase to true on a per-platform basis is probably a bad idea, but I know from experience why git does it. Anyway, that's worked around the issue for me, and other OS X developers may want to do the same, and we might want to consider making that Debug/ rule less broad so that this is less likely to happen in the future.

@Fishrock123
Copy link
Member

and we might want to consider making that Debug/ rule less broad so that this is less likely to happen in the future.

Is there a good way to do this without having to externally set more stuff? I don't really understand the issue, but maybe our .gitignore can be fixed?

@othiym23
Copy link
Contributor Author

othiym23 commented Apr 3, 2015

It could probably just be added to the contributor's guide that core.ignorecase be set to false for io.js checkouts, much like we do with whitespace=fix now.

Anyway, can I get some LGTMs so I can get this merged in time for the next release window?

@Fishrock123
Copy link
Member

LGTM

othiym23 added a commit that referenced this pull request Apr 4, 2015
PR-URL: #1337
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
@othiym23
Copy link
Contributor Author

othiym23 commented Apr 4, 2015

Landed in 5eb983e, dac903f, and efadffe. Thanks for the review, @Fishrock123!

@othiym23 othiym23 closed this Apr 4, 2015
@othiym23 othiym23 deleted the npm-2.7.5 branch April 4, 2015 00:30
bmeck added a commit to bmeck/node that referenced this pull request Jul 14, 2020
This is a workaround for the REPL for a problem when multiple of the
entries have the same source text

Fixes: nodejs#1337
Refs: https://bugs.chromium.org/p/v8/issues/detail?id=10284
bmeck added a commit that referenced this pull request Aug 3, 2020
This is a workaround for the REPL for a problem when multiple of the
entries have the same source text

Fixes: #1337
Refs: https://bugs.chromium.org/p/v8/issues/detail?id=10284

PR-URL: #34372
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>
codebytere pushed a commit that referenced this pull request Aug 6, 2020
This is a workaround for the REPL for a problem when multiple of the
entries have the same source text

Fixes: #1337
Refs: https://bugs.chromium.org/p/v8/issues/detail?id=10284

PR-URL: #34372
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>
codebytere pushed a commit that referenced this pull request Aug 11, 2020
This is a workaround for the REPL for a problem when multiple of the
entries have the same source text

Fixes: #1337
Refs: https://bugs.chromium.org/p/v8/issues/detail?id=10284

PR-URL: #34372
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>
codebytere pushed a commit that referenced this pull request Nov 3, 2020
This is a workaround for the REPL for a problem when multiple of the
entries have the same source text

Fixes: #1337
Refs: https://bugs.chromium.org/p/v8/issues/detail?id=10284

PR-URL: #34372
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>
MylesBorins pushed a commit that referenced this pull request Nov 16, 2020
This is a workaround for the REPL for a problem when multiple of the
entries have the same source text

Fixes: #1337
Refs: https://bugs.chromium.org/p/v8/issues/detail?id=10284

PR-URL: #34372
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>
martenrichter added a commit to martenrichter/node that referenced this pull request Aug 5, 2023
Currently, node.js http/2 is limited in sending SETTINGs,
that are currently implemented by nghttp2.
However, nghttp2 has the ability to send arbitary SETTINGs,
that are not known beforehand.
This patch adds this feature including a fall back mechanism,
if a SETTING is implemented in a later nghttp2 or node version.

Fixes: nodejs#1337
martenrichter added a commit to martenrichter/node that referenced this pull request Aug 13, 2023
Currently, node.js http/2 is limited in sending SETTINGs,
that are currently implemented by nghttp2.
However, nghttp2 has the ability to send arbitary SETTINGs,
that are not known beforehand.
This patch adds this feature including a fall back mechanism,
if a SETTING is implemented in a later nghttp2 or node version.

Fixes: nodejs#1337
martenrichter added a commit to martenrichter/node that referenced this pull request Aug 13, 2023
Currently, node.js http/2 is limited in sending SETTINGs,
that are currently implemented by nghttp2.
However, nghttp2 has the ability to send arbitary SETTINGs,
that are not known beforehand.
This patch adds this feature including a fall back mechanism,
if a SETTING is implemented in a later nghttp2 or node version.

Fixes: nodejs#1337
martenrichter added a commit to martenrichter/node that referenced this pull request Aug 19, 2023
Currently, node.js http/2 is limited in sending SETTINGs,
that are currently implemented by nghttp2.
However, nghttp2 has the ability to send arbitary SETTINGs,
that are not known beforehand.
This patch adds this feature including a fall back mechanism,
if a SETTING is implemented in a later nghttp2 or node version.

Fixes: nodejs#1337
martenrichter added a commit to martenrichter/node that referenced this pull request Aug 21, 2023
Currently, node.js http/2 is limited in sending SETTINGs,
that are currently implemented by nghttp2.
However, nghttp2 has the ability to send arbitary SETTINGs,
that are not known beforehand.
This patch adds this feature including a fall back mechanism,
if a SETTING is implemented in a later nghttp2 or node version.

Fixes: nodejs#1337
martenrichter added a commit to martenrichter/node that referenced this pull request Sep 7, 2023
Currently, node.js http/2 is limited in sending SETTINGs,
that are currently implemented by nghttp2.
However, nghttp2 has the ability to send arbitary SETTINGs,
that are not known beforehand.
This patch adds this feature including a fall back mechanism,
if a SETTING is implemented in a later nghttp2 or node version.

Fixes: nodejs#1337
martenrichter added a commit to martenrichter/node that referenced this pull request Sep 9, 2023
Currently, node.js http/2 is limited in sending SETTINGs,
that are currently implemented by nghttp2.
However, nghttp2 has the ability to send arbitary SETTINGs,
that are not known beforehand.
This patch adds this feature including a fall back mechanism,
if a SETTING is implemented in a later nghttp2 or node version.

Fixes: nodejs#1337
martenrichter added a commit to martenrichter/node that referenced this pull request Sep 17, 2023
Currently, node.js http/2 is limited in sending SETTINGs,
that are currently implemented by nghttp2.
However, nghttp2 has the ability to send arbitary SETTINGs,
that are not known beforehand.
This patch adds this feature including a fall back mechanism,
if a SETTING is implemented in a later nghttp2 or node version.

Fixes: nodejs#1337
martenrichter added a commit to martenrichter/node that referenced this pull request Sep 17, 2023
Currently, node.js http/2 is limited in sending SETTINGs,
that are currently implemented by nghttp2.
However, nghttp2 has the ability to send arbitary SETTINGs,
that are not known beforehand.
This patch adds this feature including a fall back mechanism,
if a SETTING is implemented in a later nghttp2 or node version.

Fixes: nodejs#1337
martenrichter added a commit to martenrichter/node that referenced this pull request Oct 29, 2023
Currently, node.js http/2 is limited in sending SETTINGs,
that are currently implemented by nghttp2.
However, nghttp2 has the ability to send arbitary SETTINGs,
that are not known beforehand.
This patch adds this feature including a fall back mechanism,
if a SETTING is implemented in a later nghttp2 or node version.

Fixes: nodejs#1337
martenrichter added a commit to martenrichter/node that referenced this pull request Nov 26, 2023
Currently, node.js http/2 is limited in sending SETTINGs,
that are currently implemented by nghttp2.
However, nghttp2 has the ability to send arbitary SETTINGs,
that are not known beforehand.
This patch adds this feature including a fall back mechanism,
if a SETTING is implemented in a later nghttp2 or node version.

Fixes: nodejs#1337
martenrichter added a commit to martenrichter/node that referenced this pull request Nov 27, 2023
Currently, node.js http/2 is limited in sending SETTINGs,
that are currently implemented by nghttp2.
However, nghttp2 has the ability to send arbitary SETTINGs,
that are not known beforehand.
This patch adds this feature including a fall back mechanism,
if a SETTING is implemented in a later nghttp2 or node version.

Fixes: nodejs#1337
nodejs-github-bot pushed a commit that referenced this pull request Dec 18, 2023
Currently, node.js http/2 is limited in sending SETTINGs,
that are currently implemented by nghttp2.
However, nghttp2 has the ability to send arbitary SETTINGs,
that are not known beforehand.
This patch adds this feature including a fall back mechanism,
if a SETTING is implemented in a later nghttp2 or node version.

Fixes: #1337
PR-URL: #49025
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
RafaelGSS pushed a commit that referenced this pull request Jan 2, 2024
Currently, node.js http/2 is limited in sending SETTINGs,
that are currently implemented by nghttp2.
However, nghttp2 has the ability to send arbitary SETTINGs,
that are not known beforehand.
This patch adds this feature including a fall back mechanism,
if a SETTING is implemented in a later nghttp2 or node version.

Fixes: #1337
PR-URL: #49025
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
richardlau pushed a commit that referenced this pull request Mar 25, 2024
Currently, node.js http/2 is limited in sending SETTINGs,
that are currently implemented by nghttp2.
However, nghttp2 has the ability to send arbitary SETTINGs,
that are not known beforehand.
This patch adds this feature including a fall back mechanism,
if a SETTING is implemented in a later nghttp2 or node version.

Fixes: #1337
PR-URL: #49025
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
npm Issues and PRs related to the npm client dependency or the npm registry.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants