Bump @testing-library/user-event from 13.5.0 to 14.4.3

[dependabot]

Bumps @testing-library/user-event from 13.5.0 to 14.4.3.

Release notes

Sourced from @​testing-library/user-event's releases.

v14.4.3

14.4.3 (2022-08-09)

Bug Fixes

• build: add types field in exports (#1029) (5bed8c6)
• remove circular dependencies (#1027) (1aa2027)

v14.4.2

14.4.2 (2022-08-04)

Bug Fixes

• build: add exports field (#1022) (7839e29)

v14.4.1

14.4.1 (2022-08-02)

Bug Fixes

• build: transpile to es2019 syntax (#1016) (4291cb8)

v14.4.0

14.4.0 (2022-08-02)

Features

• pointer: dispatch auxclick events (#1003) (2852509)

Bug Fixes

• event: be robust against incomplete event implementations (#1009) (289828b)
• upload: be robust against missing FileList implementation (#1007) (a46b4d7)
• keyboard: switch modifier state of lock keys on the correct event (#1003) (2852509)
• keyboard: remove platform-specific additional key events for Control on AltGraph (#1003) (2852509)
• pointer: dispatch contextmenu events with detail: 0 (#1003) (2852509)
• pointer: always set PointerEvent.isPrimary (#1003) (2852509)
• pointer: set button property on pointer events separately from legacy mouse events (#1003) (2852509)
• pointer: click closest common ancestor if mousedown and mouseup happen on different elements (#1003) (2852509)
• pointer: omit click event on release if another button is released first (#1003) (2852509)
• pointer: dispatch mouseover, mouseenter and mousemove on disabled elements (#1003) (2852509)
• pointer: prevent mouse* events per pointerdown event handler (#1003) (2852509)
• pointer: dispatch *out and *over events when moving into / out of nested elements (#1003) (2852509)
• pointer: dispatch *enter and *leave events on ancestors (#1003) (2852509)

v14.3.0

... (truncated)

Commits

• 1aa2027 fix: remove circular dependencies (#1027)
• 5bed8c6 fix(build): add types field in exports (#1029)
• b6bbbd6 chore: remove unnecessary CI steps (#1030)
• ab1a6c4 docs: add HillLiu as a contributor for bug (#1023)
• 7839e29 fix(build): add exports field (#1022)
• ff121ff docs: add kksy as a contributor for doc (#1020)
• ea50231 docs: add sesam as a contributor for bug (#1017)
• 4291cb8 fix(build): transpile to es2019 syntax (#1016)
• 47f2036 docs: add DGollings as a contributor for bug (#1013)
• 7b1aeea docs: add alkstal as a contributor for bug (#1012)
• Additional commits viewable 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 merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @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)

[mikermcneil]

@GuillaumeRoss I think we may already be on the same page here, but I noticed this when digging up another PR, so just checking:

Should we even bother upgrading development dependencies?

For example, Fleet ignores vulnerabilities in dev dependencies of the Fleet website.

Quick recap of reasons for posterity:

• The risk reduction of patching dev deps is low compared to the effort, noise, and distraction.
• The hypothetical attack surface is limited to the developer themselves or insiders with access to their laptop.
• The impact of exploiting such a vuln, even by accident, is pretty low.
• My understanding is that these dependencies' code paths only ever run locally (when running tests) and on build servers (github actions, CI/CD, with instrumentation written by Fleet team members).
• Testing libraries tend to be especially juicy, so in many cases, the vulnerable code path won't even be in use in the tests.
• New major versions of dependencies with breaking changes are frequently published, without older major versions being kept up to date with security patches as their dependencies inevitably accrue vulnerabilities from their dependencies.

In the past, the organizations I've worked with have taken the approach of setting up ignores for these kinds of dependencies. (That's also the best practice I've used and recommended to the Sails.js community for apps and miscellaneous packages since c. 2016, with no complaints so far (much more likely to hear about DMARC, but that's another conversation 🤪 ))

[mikermcneil]

see also dependabot/dependabot-core#4146

[mikermcneil]

If we’re not already doing this, we could peg dev deps onto specific versions, rather than using loose semantic version ranges. That’s what we’re doing in the Fleet website. It reduces (though, by itself does not entirely eliminate due to nested deps of deps) the slight (but non-zero) risk of leftpad-like surprise malicious releases of trusted open source packages.

14.4.3 instead of ^14.4.3. That eliminates the malicious package risk, at least in direct dependencies. And a lockfile will nab the rest, if we’ve got one.

[GuillaumeRoss]

@GuillaumeRoss I think we may already be on the same page here, but I noticed this when digging up another PR, so just checking:

Should we even bother upgrading development dependencies?

For example, Fleet ignores vulnerabilities in dev dependencies of the Fleet website.

Quick recap of reasons for posterity:

• The risk reduction of patching dev deps is low compared to the effort, noise, and distraction.
• The hypothetical attack surface is limited to the developer themselves or insiders with access to their laptop.
• The impact of exploiting such a vuln, even by accident, is pretty low.
• My understanding is that these dependencies' code paths only ever run locally (when running tests) and on build servers (github actions, CI/CD, with instrumentation written by Fleet team members).
• Testing libraries tend to be especially juicy, so in many cases, the vulnerable code path won't even be in use in the tests.
• New major versions of dependencies with breaking changes are frequently published, without older major versions being kept up to date with security patches as their dependencies inevitably accrue vulnerabilities from their dependencies.

In the past, the organizations I've worked with have taken the approach of setting up ignores for these kinds of dependencies. (That's also the best practice I've used and recommended to the Sails.js community for apps and miscellaneous packages since c. 2016, with no complaints so far (much more likely to hear about DMARC, but that's another conversation 🤪 ))

So there's a few things here:

1. Dependabot - if we use a config file with it (which we have to for reasons) - does not allow creating tickets ONLY when a security issue is fixed by an update. Sometimes, staying up to date has other advantages, often, it's an annoyance.
2. Dependabot has no context of HOW things are used either so even when a vulnerability is fixed by an update, it has no idea if it's a vulnerability that could've impacted us easily or at all.

The first thing we are doing (yesterday) is we have created a more granular config file https://github.com/fleetdm/fleet/blob/main/.github/dependabot.yml that will assign the right reviewers based on where the dependency is seen. I am not 100% sure yet it will work properly with sub-directories like "website" so we're leaving it running for a bit and we'll see.

As long as the right reviewer looks at the update, does the research to say "Yeah there is no way this can impact us, we don't use this functionality (or it's not exposed or whatever)", then, they're going to be the ones that can add a comment and merge or close the PR. I am pretty sure you are right and a pretty big amount of them will not be truly exploitable vulnerabilities.

We should use dependabot commands for this as much as possible.

As for 3) version pinning

100% agreed we need to do as much strict pinning as we can instead of version X "or newer".

Then, this quarter, @lucasmrod @lukeheath and I will look at establishing a recurring process to review the Dependabot created tickets so we can tune. Now that our config is more granular, we'll have the ability to fine-tune things a bit more.

[lukeheath]

FWIW dependabot says:

You can also ignore all major, minor, or patch releases for a dependency by adding an ignore condition with the desired update_types to your config file.

So if we get tired of getting pinged for dev or website dependencies we know we're not worried about, we can permanently ignore them. A downside I see is there could be a huge security issue with devDependencies like it connects to a remote server when run locally that we never see because dependabot is ignoring it.

[lukeheath]

Dev dependency.

@dependabot ignore this minor version

[dependabot]

OK, I won't notify you about version 14.4.x again, unless you re-open this PR or update to a 14.4.x release yourself.