Resolves async to v3.2.3

[tmarkley]

Description

• Resolves older versions of async: v0.9.2, v1.5.2, v2.6.3
  • There are known breaking changes, so this manual resolution carries some risk. The mitigation is testing.
  • CHANGELOG
• Addresses CVE-2021-43138.
• This requires a manual resolution because @elastic/makelogs@6.1.0, grunt-contrib-clean@2.0.0, ejs@3.1.6, and webpack-dev-server@4.8.1 have downstream dependencies on older versions of async and none of them have newer versions to fix this. I've documented this in Remove unnecessary resolutions from package.json #1298.
• Bumps getos from v3.1.0 to v3.2.1.
• Bumps @elastic/makelogs from v6.0.0 to v6.1.0.
• Bumps archiver from v3.1.1 to v5.3.0 and @types/archiver from v3.1.0 to v5.3.1.
  • Used in the build script, which runs successfully.
  • Breaking changes include removing support for older versions of Node.js as well as no longer supporting absolute path glob patterns, which are not used in our repository.
  • CHANGELOG
• Bumps webpack-dev-server from v4.7.4 to v4.8.1.
• Removes grunt-contrib-watch dependency since it is unused.
• Removes unnecessary @types/react resolution.

Issues Resolved

Resolves #1440

Testing

Ran the build script with no flags as well as with the --release flag and both built successfully.

Check List

• New functionality includes testing.
  • All tests pass
    • yarn test:jest
    • yarn test:jest_integration
    • yarn test:ftr
• New functionality has been documented.
• Commits are signed per the DCO using --signoff

[kavilla]

Since code freeze for rc1 is a few days away did want to hold of on this mitigation until post rc1? Or look into the impact to plugins and if it's going to cause a breakage for them?

[tmarkley]

Since code freeze for rc1 is a few days away did want to hold of on this mitigation until post rc1? Or look into the impact to plugins and if it's going to cause a breakage for them?

@kavilla good question, I think we should try to get it in to give us more time to address any problems that may come up. If it ends up being a blocker for RC1 we can revert it, but we need to address the CVE either way.

[kavilla]

@kavilla good question, I think we should try to get it in to give us more time to address any problems that may come up. If it ends up being a blocker for RC1 we can revert it, but we need to address the CVE either way.

I think the CVE was open 4 days ago? I'd rather be more defensive than reactive here unless we know we won't break plugins since the current turn around time from us checking something and plugins reacting is about a week.

[tmarkley]

I think the CVE was open 4 days ago? I'd rather be more defensive than reactive here unless we know we won't break plugins since the current turn around time from us checking something and plugins reacting is about a week.

That should give us another reason to push us to resolve these CVEs sooner rather than later, right? We're less than a month away from 2.0, and our goal should be to resolve any CVEs that are found until ~2 weeks before the release date. We can't be walking on eggshells because plugins have a delayed reaction to every change; security should be our top priority.

[kavilla]

That should give us another reason to push us to resolve these CVEs sooner rather than later, right? We're less than a month away from 2.0, and our goal should be to resolve any CVEs that are found until ~2 weeks before the release date. We can't be walking on eggshells because plugins have a delayed reaction to every change; security should be our top priority.

I don't think it's walking on eggshells as much as I'd rather we know that this PR won't break plugins days before they should be code frozen for 2.0-rc1. And if we do know it's going to break plugins and needs to go into 2.0-rc1 then we should be raising the red flag that 4/18 will be unlikely.

[tmarkley]

I don't think it's walking on eggshells as much as I'd rather we know that this PR won't break plugins days before they should be code frozen for 2.0-rc1. And if we do know it's going to break plugins and needs to go into 2.0-rc1 then we should be raising the red flag that 4/18 will be unlikely.

I think this is a good call-out. I see that some plugin changes are going to occur after RC1 anyways, so plugins should be able to stay on top of anything that needs to be addressed because of this PR.

[kavilla]

Blocking but if we ensure this doesn't break plugins for rc-1 then I'm okay to merge this in.

We need to merge these CVE PRs in for RC1 to address any breaking changes.

[ananzh]

LGTM