gulpjs / glob-parent Goto Github PK

I was investigating https://github.com/gulpjs/glob-parent/blob/main/index.js#L26-L29 in relation to the test suite and I think the pattern is completely wrong.

For example: 'path/\\[bar]' is matched by that pattern, but the "enclosure" ([bar]) doesn't contain any path separator.

My gut feeling is that the [\/]* pattern is supposed to be [\/]+ so that it matches only if there's one or more / inside the enclosure, instead of 0 or more. But I have no idea... maybe @paulmillr or @es128 have an idea 🤞

Given the string 'foo/bar/baz/file.txt':

• glob2base returns 'foo/bar/baz'
• glob-parent returns 'foo/bar/baz/file.txt'

For complete parity you might want to fix. I want to use glob-parent; not having to add conditionals based on glob.hasMagic and extension !== '' would make it a more pleasant experience.

This seems to be due to a bug in micromatch/is-glob#21

I've noticed this issue being marked as spam, apologies if I'm missing where this issue is still open. I'm a contract developer using Nuxt.js and had the Snyk scan request made by the client's IT after development was underway. This library is a dependency for several libraries used by Nuxt, and this issue is now preventing the framework from being used for enterprise applications. Is there a fix that can be applied, or do you have a cost for implementing a fix that you can share so that the issue can addressed?

Don't spam our repo.

Originally posted by @phated in #37 (comment)

One test is failing though, see micromatch/glob-base#5 for a discussion

 1) glob-parent should strip glob magic to return parent path:

      AssertionError: qmarks must be escaped
      + expected - actual

      -path/?
      +path
      
      at Context.<anonymous> (/home/pravi/forge/debian/git/pkg-javascript/node-glob-parent/test.js:48:12)
      at callFn (/usr/lib/nodejs/mocha/lib/runnable.js:223:21)
      at Test.Runnable.run (/usr/lib/nodejs/mocha/lib/runnable.js:216:7)
      at Runner.runTest (/usr/lib/nodejs/mocha/lib/runner.js:373:10)
      at /usr/lib/nodejs/mocha/lib/runner.js:451:12
      at next (/usr/lib/nodejs/mocha/lib/runner.js:298:14)
      at /usr/lib/nodejs/mocha/lib/runner.js:308:7
      at next (/usr/lib/nodejs/mocha/lib/runner.js:246:23)
      at Immediate.<anonymous> (/usr/lib/nodejs/mocha/lib/runner.js:275:5)
      at runCallback (timers.js:672:20)
      at tryOnImmediate (timers.js:645:5)
      at processImmediate [as _immediateCallback] (timers.js:617:5)
  

glob-parent was flagged as of this morning with high severity security risk. The recommendation is to downgrade to 3.0.0, 2.0.0, or 1.0.0.

I apologize if you are already informed, thank you for your attention regarding this manner.

@paulmillr I'm about to head out for the night after I publish glob-parent 4.0.0 but I'll get path-dirname removed tomorrow and bump the major.

URL: https://app.snyk.io/test/npm/glob-parent

I have one pattern that uses escaping for parenthesis:

file-\\(suffix\\).md

As a result of the work I get:

globParent('file-\\(suffix\\).md')
// file-

// expected result: .

Obviously, this is an incorrect parent directory. Yeap, I understand that this is described in the documentation, but I find it difficult to get all users to use the new format. Also I see no reason to change user input inside my package, because it can lead to problems.

Maybe we can add an option to control automatic replacement?

Found this issue in mrmlnc/fast-glob#223. The fast-glob package only accepts patterns with forward slashes.

This module was adopted in glob-stream as a drop-in replacement to glob2base; however, we've needed to add a bunch of workarounds into the glob-stream codebase to make this work.

Do you think it makes sense to always return a path ending in a separator due to path.dirname being called on each segment (thus the parent should always be a directory)?

I'd like to write:

var basePath = toAbsoluteGlob(globParent(myGlob), opts);

but currently have to use:

var basePath = toAbsoluteGlob(globParent(myGlob) + '/', opts);

to get my test suite to pass correctly.

@jonschlinkert @es128 thoughts?

What were you expecting to happen?

The string base/folder?/file1.txt should return base as the non-magic parent path

What actually happened?

globParent('base/folder?/file1.txt') returns base/folder?

Please provide the following information:

• OS & version: Windows 10 20H2, also Ubuntu 16.04
• node version (run node -v): 15.10
• yarn version: 1.22.5

Additional information

I've been trying to track down the source of my issue where the del library wasn't deleting expected folders based on a pattern like the one mentioned above (after del switched to using fast-glob). This led me to follow the dependency tree from del to fast-glob to glob-parent.

Unless I'm completely mistaken about how this library works I would expect a question mark to be treated like other special characters. For example, globParent('base/folder*/file1.txt') returns base.

Our enclosure logic doesn't account for escaped brackets. See PR thread for more information.

Originally posted by @phated in #49 (comment)

Hello,

On June 11, I sent a report of a security vulnerability I found to [email protected] in accordance with the security policy of this project. On their Security process page, Tidelift says that "the Tidelift security team will reply to the reporter within two business days to acknowledge receipt". Tidelift has yet to respond back to me.

For this reason, I now opened this issue. Who can I contact to report the security vulnerability I found?

Originally from gulpjs/path-dirname#1

> gp('/foo/{,/,bar/baz,qux}/')
'/foo/{,/,bar'
> gp('/foo[a\\\/]/')
'/foo[a\\'

is-glob used to return true for the presence of { or [, but it no longer does without the accompanying closing character.

Seems we need to do an extra truncation step over here for any unescaped sets of enclosure characters that might have a path separator inside. Is that only square and curly brackets, or are parentheses an issue as well?

If you are here because npm audit or another tool told you there's a vulnerability, please carefully review this template.

We also see vulnerability issues and regularly review them. If we identify a risk to our projects, we will fix them immediately. When we decide they are not a risk to our projects, there is nothing else we should do.

Upgrading (when there's not a risk to our projects) is a breaking change to our compatibility matrix and we don't currently take these requests.

It's uncommon for the npm ecosystem to backport security fixes to older versions that we rely on for our compatibility matrix. It would be a great help to the community if you could contribute a backport on the older release stream of the vulnerable package.

If you open an issue like this, it will be closed and locked with no further reason. Continued offenses might result in a temporary ban to keep the noise down in our inbox.

spam

┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate │ Regular expression denial of service │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package │ glob-parent │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in │ >=5.1.2 │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ gulp-htmlhint [dev] │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path │ gulp-htmlhint > htmlhint > parse-glob > glob-base > │
│ │ glob-parent │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info │ https://npmjs.com/advisories/1751 │

Before you open this issue, please complete the following tasks:

• use the search bar at the top of the page to search this repository for similar issues or discussions that have already been opened.
• if you are looking for help from the gulp team or community, open a discussion.
• if you think there is a problem with the plugin you're using, open a discussion.
• if you think there is a bug in our code, open this issue.

What were you expecting to happen?

glob-parent latest version doesn't contain known vulnerabilities.

What actually happened?

Snyk.io has reported a ReDoS vulnarability with POC that affects all glob-parent versions: https://app.snyk.io/vuln/SNYK-JS-GLOBPARENT-1016905
As glob-parent package is a dependency in multiple packages, this vulnerability leaks in via many dependency paths to applications, e.g latest eslint: https://github.com/eslint/eslint/blob/v7.18.0/package.json

Please give us a sample of your gulpfile

N/A

Terminal output / screenshots

N/A

Please provide the following information:

N/A

Additional information

Seems there's some problems on Windows.

We were notified of this Snyk finding and CVE:

https://snyk.io/vuln/SNYK-JS-GLOBPARENT-1016905

I didn't see an open issue on this yet, any thoughts on a potential fix?

lets merge these two http://github.com/wearefractal/glob2base

do you see any features glob2base doesnt support?

I've migrated most of the repo to the gulp patterns but I still need to rebase the commit history to reword for our conventional changelog setup.

Certain security scanners are marking this library as vulnerable.

Please see(sample code is included):
https://snyk.io/vuln/SNYK-JS-GLOBPARENT-1016905

There is also a CVE here:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-28469

What were you expecting to happen?

expect(gp('C:/', { flipBackslashes: false })).toEqual('C:/');
expect(gp('C:/.', { flipBackslashes: false })).toEqual('C:/');
expect(gp('C:/*', { flipBackslashes: false })).toEqual('C:/');
expect(gp('C:/./*', { flipBackslashes: false })).toEqual('C:/.');
expect(gp('C://', { flipBackslashes: false })).toEqual('C:/');
expect(gp('C://*', { flipBackslashes: false })).toEqual('C:/');

What actually happened?

expect(gp('C:/', { flipBackslashes: false })).toEqual('C:'); // 🔴 C: instead of C:/
expect(gp('C:/.', { flipBackslashes: false })).toEqual('C:'); // 🔴 C: instead of C:/
expect(gp('C:/*', { flipBackslashes: false })).toEqual('C:'); // 🔴 C: instead of C:/
expect(gp('C:/./*', { flipBackslashes: false })).toEqual('C:/.'); // 🟢 
expect(gp('C://', { flipBackslashes: false })).toEqual('C:/'); // 🟢 
expect(gp('C://*', { flipBackslashes: false })).toEqual('C:/'); // 🟢 

Please give us a sample of your gulpfile

The examples above are tests for this repository.

Please provide the following information:

• OS & version [e.g. MacOS Catalina 10.15.4]: Windows 11 PRO 22H2
• node version (run node -v): v20.0.0
• npm version (run npm -v): 9.6.4
• gulp version (run gulp -v): nope

Additional information

The current result is not correct because its use leads to incorrect results in standard Node methods.like path.* or fs.*:

CWD: D:\\OpenSource\\glob-parent

const path = require('path');

path.win32.resolve('D:'); // CWD
path.win32.resolve('D:/'); // D:\\

const fs = require('fs');

fs.readdirSync('D:'); // list CWD
fs.readdirSync('D:/'); // list D:\\

With this change, at least locally for me:

• All tests continue to pass.
• The following proof-of-concept runs quickly (on the order of milliseconds) whereas with the current regular
  expression, it freezes up for a long time. (I hit control C after maybe five or ten seconds. Not sure how long it
  would run to finish. Don't care, honestly.)

  var globParent = require('./index.js');
  
  globParent('{' + '/'.repeat(5000));

Originally posted by @Trott in #34 (comment)

I think this is the right library and right repo, I seen this while getting reports and wanted to point it out just in case it was not brought up before. If I am wrong then please close this.

my code

var globParent = require('glob-parent');
var _glob = 'C:\\Users\\ys\\mf\\src\\html\\*.html';
var _base = globParent(_glob); // return '.'

I read the source,in win32,it must use pathDirname.win32 ,why it can not auto match the windows?

Basically v6 drops support for nodejs v8. That's fine by me, i'd drop v10 also.

But there are tons of chokidar users that keep using nodejs v8. Can we get 5.2.0 out with fix for re ddos?

Got this message: glob-parent before 6.0.1 is vulnerable to Regular Expression Denial of Service (ReDoS).

Please help to fix it. Thanks