Bump github.com/elastic/mito from 1.1.0 to 1.2.0

[dependabot]

Bumps github.com/elastic/mito from 1.1.0 to 1.2.0.

Commits

• 6c756d4 lib: add support for md5 hashing
• 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 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)

[elasticmachine]

Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane)

[mergify]

This pull request does not have a backport label.
If this is a bug or security fix, could you label this PR @dependabot[bot]? 🙏.
For such, you'll need to label your PR with:

• The upcoming major version of the Elastic Stack
• The upcoming minor version of the Elastic Stack (if you're not pushing a breaking change)

To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-v8./d.0 is the label to automatically backport to the 8./d branch. /d is the digit

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2023-05-25T11:05:57.592+0000

• Duration: 108 min 11 sec

Test stats 🧪

Test	Results
Failed	0
Passed	26419
Skipped	1975
Total	28394

💚 Flaky test report

Tests succeeded.

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

• /package : Generate the packages and run the E2E tests.

• /beats-tester : Run the installation tests with beats-tester.

• run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

[efd6]

I was concerned this would happen with making auto-upgrade a thing. There are docs that needed to be updated.

[cmacknz]

I was concerned this would happen with making auto-upgrade a thing. There are docs that needed to be updated.

Any suggestions on how to avoid this? In general I like that we automated this, but there isn't a great way to know if other changes are necessary when one of these PRs is created.

Ideally we'd have codeowners for each dependency but I don't think the codeowners syntax supports that.

[efd6]

I have what is likely an unpopular opinion, so I don't propose it as a solution (I don't see a good solution); I don't think robots should be making these calls since event with patch-level updates there is potential for breaking client code when a dep is upgraded either because of a failure of the dep's author to properly mark changes according to semver or because of Hyrum's Law. IMO versions should be bumped when they are needed to be bumped, this should really always be the decision of an informed human and at most should be triggered by the raising of an issue rather than the posting of a pull request.

[cmacknz]

That's a reasonable opinion, but despite the problems you described I still think the automation is valuable as we have shipped bugs that were fixed in https://github.com/elastic/elastic-agent-libs but the fix was propagated to every affected repository. Automating this is much better than relying on every team to monitor new releases.

There is also a use case in picking up security fixes in transient dependencies in some of these packages, where upgrading stops us from getting requests to explain whether we are vulnerable to certain CVEs.

The dependabot configuration is fairly flexible, so we can could set it to ignore certain dependencies that we know require more careful attention for upgrades. I wouldn't be opposed to setting mito as an ignored dependency to ensure you and the SEI team own the updates instead of an automated PR. https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#ignore