[CVE] Bump follow-redirects to 1.15.2 to fix CVE-2022-0155 and CVE-20…

[ZilongX]

Signed-off-by: Zilong Xia [email protected]

Description

• Resolves CVE-2022-0155 and CVE-2022-0536 by bumping follow-redirects up to 1.15.2
• There are no breaking changes introduced in by checking detailed change history of follow-redirects
• This PR is to backport similar updates in 2.0.0 (Removes deprecated request and @percy/agent #1113) to 1.x

Issues Resolved

Resolves #1133
Resolves #1238

Check List

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

[zhongnansu]

LGTM, left one comment about change log

[zhongnansu]

combining change log into one? Since we always have 1 PR mapping to 1 change log. according to @ananzh 's comment here, and even tho it's different cve number, but the the change of dependency is the same.

[seraphjiang]

combining change log into one? Since we always have 1 PR mapping to 1 change log. according to @ananzh 's comment here, and even tho it's different cve number, but the the change of dependency is the same.

As long as it is not PR log or commit log, keep separate entry make sense to me.

Btw, I'm not fan of changelog file 😎

[ZilongX]

Well actually I'm not quite sold on this one (#2640 (comment)) aka one changelog item per one PR, my $0.02 are :

• changelogs are for humans not machines, and for humans we read focus on the first key word of a sentence and for CVE changes the keywords are always the CVE numbers
• as a developer and a customer (as targeted audiences of the changelog), I care more about which changes have been done rather than how many changes have been done in one single PR, single fix could span across multiple PRs and single PR could achieve multiple changes, it would be good as long as the changed items are listed clearly in the changelog,

The one shared is actually a bad example, comparing

• [CVE-2022-3517] Bumps minimatch from 3.0.4 to 3.0.5 and [IBM X-Force ID: 220063] unset-value from 1.0.1 to 2.0.1
  vs
• [CVE-2022-3517] Bumps minimatch from 3.0.4 to 3.0.5
• [IBM X-Force ID: 220063] unset-value from 1.0.1 to 2.0.1

The latter one actually seems more concise and clear to me.

[zhongnansu]

change log is something that doesn't have a standard, it relies more on community discussion and consensus. @ZilongX 's point is valid, cve number is critical info and it should be treated as 2 items in change log. I'll approve to unblock this PR.

single fix could span across multiple PRs and single PR could achieve multiple changes,

But I can't fully agree with this. I think the best practice for PR is still single responsibility rule. I PR aims to solve 1 issue. Even for #2640, I think the best practice is to divide into 2 PRs, that fixes 2 cves, and create 2 change log items.

[joshuarrrr]

Agree with @ZilongX that we should use a standard format for CVEs, because quickly searching/scanning for those is likely a common use for this changelog. And also 💯 to @zhongnansu's point about smaller, single responsibility PRs/commits.

[ZilongX]

@zhongnansu @joshuarrrr , I actually searched a bunch of other repos' CHANGELOG trying to find a unified style yet no luck, so yes we got to work together with the community and the format may just keep pivoting.

And yes agreed on :)

• Single responsibility PR per issue (per CVE or per Package) makes good sense to me, it makes each change more clear especially for CVE fixings
• CVE change items in CHANGELOG needs to follow a standard for quick searching/scanning purposes at least, and for now we are following format as
  [CVE Number] - Fix Message - PR Link
  (with one example [CVE-2022-0536] Bump follow-redirects to 1.15.2 #2653))