Fix: Backport removal of mkdirp to 6.x (fixes #13050)

[evanplaice]

• the CVE is caused by the mkdirp dependency
• mkdirp is no longer supported
• mkdirp has been removed as of 7.0.0-alpha0
• this back-ports the change to v6.x

Prerequisites checklist

• I have read the contributing guidelines.
• The team has reached consensus on the changes proposed in this pull request. If not, I understand that the evaluation process will begin with this pull request and won't be merged until the team has reached consensus.

What is the purpose of this pull request? (put an "X" next to an item)

[ ] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofixing to a rule
[ ] Add a CLI option
[ ] Add something to the core
[x] Other, please explain:

Other:
This PR removes the mkdirp dependency reflecting a change made in #12753 and included in the 7.0.0-alpha0 tag. This change fixes the security vulnerability CVE-2020-7598. Specifics are outlined in issue #13050.

Patching this into the v6.x line will ensure that users who still depend on v6.x can reliably update ESLint, thereby removing the security vulnerability and related security audit notices.

What changes did you make? (Give an overview)

• remove the mkdirp dependency from package.json
• remove the require("mkdirp") statement in /lib/cli.js
• replace the call to mkdirp.sync with a call to the node built-in fs.mkdirSync() in /lib/cli.js

These changes were extracted from the #12753 diff

Is there anything you'd like reviewers to focus on?

Guess I should start with the obvious question. Does ESLint support back-porting security fixes to previous versions? If so, is this the right way to handle it?

This change has been tested with the pkg.engines specified in the v6.8.0 tag (ie "^8.10.0 || ^10.13.0 || >=11.10.1"). Double-check to make sure this change doesn't break anything.

From what I could gather from the git history, it looks like all changes after v6.8.0 apply to the new 7.x series. I wasn't sure if I should build off a specific commit following v6.8.0 so I branched directly off the tag. If the change needs to be rebased on top of a later commit, let me know.

[kaicataldo]

We don’t have a policy of backporting commits to old versions of ESLint. This situation is one of the downsides of our current major release process, since it takes a while. I think it would be worth evaluating our process for the next major release.

[mattpass]

We don’t have a policy of backporting commits to old versions of ESLint. This situation is one of the downsides of our current major release process, since it takes a while. I think it would be worth evaluating our process for the next major release.

Hope this PR can be accepted into 6.8.x, the version of mkdirp being used is almost 6 years old. Keeping dependencies up to date is crucial (I love Dependabot for this), but if it's hardly being used (as PR shows), it can be hopefully dropped as a dependency - it's flagging security warnings.

Thanks and keep up the good work on ESLint. 👍

[nzakas]

Because we're in the middle of a major release, I'd prefer to wait until after v7.0.0 before evaluating if a backport is necessary. As @kaicataldo mentioned, we don't actually have a process for backporting changes to previously released versions, and I'd prefer not to derail v7.0.0 development to try to figure out how to do so.

We can certainly make this change for v7.0.0 and then see if anything further is necessary afterwards.

[mattpass]

@nzakas bah, that's a pity. We use eslint but it's flagging security warnings for now and as 7 is only an alpha, we're can't to upgrade to it, so a bit stuck for now. OK, I'll inform our team tomorrow and we'll evaluate what to do next if this PR isn't going to be merged soon.

[kaicataldo]

Please note that mkdirp@0.5.3 has now been released (see here). Since ESLint's package.json has the range ^0.5.1, folks just need to update their lockfiles.

[mattpass]

Please note that mkdirp@0.5.3 has now been released (see here). Since ESLint's package.json has the range ^0.5.1, folks just need to update their lockfiles.

@kaicataldo Ah I wasn't aware of that and wasn't there when I looked earlier today. Great tip and that'll likely solve things for us folks on 6.x branch, many thanks 👍

[evanplaice]

@kaicataldo Thanks for the update.

I'm good with closing this PR now that there's another possible upgrade path.

[kaicataldo]

@evanplaice We appreciate you being willing to contribute.