Bump svgo from 3.3.3 to 3.3.4 in /htdocs

[dependabot]

Bumps svgo from 3.3.3 to 3.3.4.

Release notes

Sourced from svgo's releases.

v3.3.4

What's Changed

Security

• removeScriptElement, remove JavaScript URIs case-insensitively and make <script> handling namespace aware. By @​SethFalco

Support

SVGO v3 is not officially supported, please consider upgrading to SVGO v4 instead. We've backported this fix as there are security implications, but there is no commitment to do this for more complex changes in future.

Consider reading our Migration Guide from v3 to v4 which should ease the process.

Commits

• 72a2388 Merge commit from fork
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  You can disable automated security fix PRs for this repo from the Security Alerts page.

[drgrice1]

Should we bother with this with the release only a few weeks away? These security vulnerabilities are minor and do not affect webwork and pg in production usage.

[somiaj]

Since we don't really have a workflow to support security fixes for older releases once a new release is made, we could just close these since they will all be fixed next week with the release of 2.21.

Would it be worth setting up a branch/tag for 2.20 and provide some limited support for it for a while vs just drop all support for 2.20 next week?

[drgrice1]

A WeBWorK-2.20+ tag will be created next week pointing to the last commit before the 2.21 release as usual. The only way to support further changes would be to create an actual branch, and doing that would involve extra effort to maintain back ported security vulnerabilities. Note that these npm security vulnerabilities are not production server vulnerabilities. They are only vulnerabilities for the build system (the generate-assets.js script). I suspect that even when running the script with the vulnerabilities there is really any actual danger.

[somiaj]

I was more commenting in general, not these particular fixes, and thinking about the list of vulns you just submitted a PR to fix on the other side. Though this is a change in standard workflow, we have never supported an older release with hotfixes/security fixes of any kind that I can recall in recent history.