build(deps): bump com.google.guava:guava from 30.1.1-jre to 32.0.0-jre in /java

[dependabot]

Bumps com.google.guava:guava from 30.1.1-jre to 32.0.0-jre.

Release notes

Sourced from com.google.guava:guava's releases.

32.0.0

Maven

<dependency>
  <groupId>com.google.guava</groupId>
  <artifactId>guava</artifactId>
  <version>32.0.0-jre</version>
  <!-- or, for Android: -->
  <version>32.0.0-android</version>
</dependency>

Jar files

• 32.0.0-jre.jar
• 32.0.0-android.jar

Guava requires one runtime dependency, which you can download here:

• failureaccess-1.0.1.jar

Javadoc

• 32.0.0-jre
• 32.0.0-android

JDiff

• 32.0.0-jre vs. 31.1-jre
• 32.0.0-android vs. 31.1-android
• 32.0.0-android vs. 32.0.0-jre

Changelog

Security fixes

• Reimplemented Files.createTempDir and FileBackedOutputStream to further address CVE-2020-8908 (#4011) and CVE-2023-2976 (#2575). (feb83a1c8f)

While CVE-2020-8908 was officially closed when we deprecated Files.createTempDir in Guava 30.0, we've heard from users that even recent versions of Guava have been listed as vulnerable in other databases of security vulnerabilities. In response, we've reimplemented the method (and the very rarely used FileBackedOutputStream class, which had a similar issue) to eliminate the insecure behavior entirely. This change could technically affect users in a number of different ways (discussed under "Incompatible changes" below), but in practice, the only problem users are likely to encounter is with Windows. If you are using those APIs under Windows, you should skip 32.0.0 and go straight to 32.0.1 which fixes the problem. (Unfortunately, we didn't think of the Windows problem until after the release. And while we warn that common.io in particular may not work under Windows, we didn't intend to regress support.) Sorry for the trouble.

Incompatible changes

Although this release bumps Guava's major version number, it makes no binary-incompatible changes to the guava artifact.

One change could cause issues for Widows users, and a few other changes could cause issues for users in more usual situations:

• The new implementations of Files.createTempDir and FileBackedOutputStream throw an exception under Windows. This is fixed in 32.0.1. Sorry for the trouble.
• guava-gwt now requires GWT 2.10.0.
• This release makes a binary-incompatible change to a @Beta API in the separate artifact guava-testlib. Specifically, we changed the return type of TestingExecutors.sameThreadScheduledExecutor to ListeningScheduledExecutorService. The old return type was a package-private class, which caused the Kotlin compiler to produce warnings. (dafaa3e435)

... (truncated)

Commits

• 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 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.

[vitess-bot]

Review Checklist

Hello reviewers! 👋 Please follow this checklist when reviewing this Pull Request.

General

• Ensure that the Pull Request has a descriptive title.
• Ensure there is a link to an issue (except for internal cleanup and flaky test fixes), new features should have an RFC that documents use cases and test cases.

Tests

• Bug fixes should have at least one unit or end-to-end test, enhancement and new features should have a sufficient number of tests.

Documentation

• Apply the release notes (needs details) label if users need to know about this change.
• New features should be documented.
• There should be some code comments as to why things are implemented the way they are.
• There should be a comment at the top of each new or modified test to explain what the test does.

New flags

• Is this flag really necessary?
• Flag names must be clear and intuitive, use dashes (-), and have a clear help text.

If a workflow is added or modified:

• Each item in Jobs should be named in order to mark it as required.
• If the workflow needs to be marked as required, the maintainer team must be notified.

Backward compatibility

• Protobuf changes should be wire-compatible.
• Changes to _vt tables and RPCs need to be backward compatible.
• RPC changes should be compatible with vitess-operator
• If a flag is removed, then it should also be removed from vitess-operator and arewefastyet, if used there.
• vtctl command output order should be stable and awk-able.