Update Renovatebot Gradle Updates (major) - #1194
Conversation
d16bdda to
c3b982f
Compare
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
c3b982f to
2e84225
Compare
2e84225 to
8f6fda0
Compare
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
There are 2 total unresolved issues (including 1 from previous review).
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 8f6fda0. Configure here.
| // Import log4j BOM first with higher priority | ||
| mavenBom "org.apache.logging.log4j:log4j-bom:2.25.4" | ||
| mavenBom 'org.junit:junit-bom:5.14.3' | ||
| mavenBom 'org.junit:junit-bom:6.1.0' |
There was a problem hiding this comment.
JUnit 6 Mockito mismatch
Medium Severity
Importing junit-bom 6.1.0 aligns all Jupiter and Platform artifacts to JUnit 6, but mockito-junit-jupiter stays at 5.23.0, which is built and released against JUnit 5. Core tests that use @ExtendWith(MockitoExtension.class) can fail at runtime because the Mockito extension and the JUnit 6 engine are not a supported combination.
Reviewed by Cursor Bugbot for commit 8f6fda0. Configure here.
8f6fda0 to
a7da13e
Compare
|
a7da13e to
2bb41c3
Compare
2bb41c3 to
11403f9
Compare
11403f9 to
630a03d
Compare
630a03d to
fbba3fc
Compare
fbba3fc to
38946c4
Compare
bb83a55 to
7558a2b
Compare
7558a2b to
876f4ea
Compare
876f4ea to
b62010e
Compare
b62010e to
dbff7fe
Compare
|
This PR contains the following updates:
9.48→10.9.14.12.0→5.5.04.12.0→5.5.04.12.0→5.5.017.9.0→18.4.011.20.3→13.3.011.20.3→13.3.05.0.2→6.0.05.0.2→6.0.05.0.2→6.0.05.5.7→6.0.15.15.0→7.6.04.5.26→5.1.64.5.26→5.1.64.5.26→5.1.64.5.26→5.1.64.5.26→5.1.64.5.26→5.1.64.5.26→5.1.64.4.0→5.1.012.2.1→13.0.05.14.3→6.1.3Release Notes
connect2id/nimbus-jose-jwt (com.nimbusds:nimbus-jose-jwt)
v10.9.1Compare Source
v10.9Compare Source
v10.8Compare Source
v10.7Compare Source
v10.6Compare Source
v10.5Compare Source
v10.4.2Compare Source
v10.4.1Compare Source
v10.4Compare Source
v10.3.1Compare Source
v10.3Compare Source
v10.2Compare Source
v10.1Compare Source
v10.0.2Compare Source
v10.0.1Compare Source
v10.0Compare Source
lysine-dev/okhttp (com.squareup.okhttp3:logging-interceptor)
v5.5.02026-08-16
This release introduces opt-in support for [Encrypted Client Hello (ECH)]. This new feature
improves user privacy by encrypting domain names in transit. With regular TLS, your coffee shop’s
Wi-Fi router can see that you’re visiting wikipedia.com, but it cannot see which page you’re
looking at. With ECH, the router observes only the IP address. This additional privacy is most
effective on sites hosted by big CDNs because the IP address doesn’t imply a particular website.
This requires ECH support in the platform’s TLS stack. Today this is only Android 17 (API 37,
released June 2026). When other TLS stacks add ECH support, we'll integrate them.
ECH took a lot of work to implement because the encryption keys are published over DNS in the
[HTTPS resource record], and we needed to write new code to fetch these records. This release
includes a major update to OkHttp’s DNS API: it now supports multiple resource record types (not
just IP addresses!), asynchronous streaming results, and in-memory caching.
To opt in, you can use
DnsOverHttps:You could also opt in with our new
AndroidDnsAPI. Unfortunately, the privacy benefits of ECH arethwarted because its DNS queries are not encrypted by default.
projects ([Retrofit], [Okio], and [SQLDelight]) recently joined [the Commonhaus Foundation].
@StartStopannotation now supports@NestedJUnit 5 tests.weren’t applied correctly.
the HTTP call to crash.
v5.4.02026-06-08
OkHttpClient.Builder, such as the cache, connection pool, socket factory, and DNS. We expectthis will allow most users to use interceptors everywhere, insted of mixing and matching
interceptors with custom
Call.Factorywrappers.okhttp-coroutinesartifact.v5.3.22025-11-18
Fix: Don't delay triggering timeouts. In Okio 3.16.0 we introduced a regression that caused
timeouts to fire later than they were supposed to.
Upgrade: [Okio 3.16.4][okio_3_16_4].
v5.3.12025-11-16
This release is the same as 5.3.0. Okio 3.16.3 didn't have a necessary fix!
v5.3.02025-10-30
New: Add tags to
Call, including computable tags. Use this to attach application-specificmetadata to a
Callin anEventListenerorInterceptor. The tag can be read in any otherEventListenerorInterceptor.New: Support request bodies on HTTP/1.1 connection upgrades.
New:
EventListener.plus()makes it easier to observe events in multiple listeners.Fix: Don't spam logs with ‘Method isLoggable in android.util.Log not mocked.’ when using
OkHttp in Robolectric and Paparazzi tests.
Upgrade: [Kotlin 2.2.21][kotlin_2_2_21].
Upgrade: [Okio 3.16.2][okio_3_16_2].
Upgrade: [ZSTD-KMP 0.4.0][zstd_kmp_0_4_0]. This update fixes a bug that caused APKs to fail
[16 KB ELF alignment checks][elf_alignment].
v5.2.32025-11-18
Fix: Don't delay triggering timeouts. In Okio 3.16.0 we introduced a regression that caused
timeouts to fire later than they were supposed to.
Upgrade: [Okio 3.16.4][okio_3_16_4].
v5.2.22025-11-16
This release is the same as 5.2.1. Okio 3.16.3 didn't have a necessary fix!
v5.2.12025-10-09
Fix: Don't crash when calling
Socket.shutdownOutput()orshutdownInput()on anSSLSocketon Android API 21 through 23. This method throws an
UnsupportedOperationException, so we nowcatch that and close the underlying stream instead.
Upgrade: [Okio 3.16.1][okio_3_16_1].
v5.2.02025-10-07
New: Support [HTTP 101] responses with
Response.socket. This mechanism is only supported onHTTP/1.1. We also reimplemented our websocket client to use this new mechanism.
New: The
okhttp-zstdmodule negotiates [Zstandard (zstd)][zstd] compression with servers thatsupport it. It integrates a new (unstable) [ZSTD-KMP] library, also from Square. Enable it like
this:
New: Support the
QUERYHTTP method. You will need to set theRequest.cacheUrlOverrideproperty to cache calls made with this method. The
RequestBody.sha256()may be helpful here;use it to compose a cache URL from the query body.
New: Publish events when calls must wait to execute.
EventListener.dispatcherQueueStart()is invoked when a call starts waiting, and
dispatcherQueueEnd()is invoked when it's done.New:
Request.toCurl()returns a copy-pasteable [curl] command consistent with Chrome’s andFirefox’s ‘copy as cURL’ features.
New: Support [JPMS]. We replaced our
Automatic-Module-Namemetadata with propermodule-info.javafiles.Fix: Recover gracefully when worker threads are interrupted. When we introduced fast fallback in
OkHttp 5.0, we started using background threads while connecting. Sadly that code didn't handle
interruptions well. This is now fixed.
Upgrade: [Kotlin 2.2.20][kotlin_2_2_20].
Upgrade: [Okio 3.16.0][okio_3_16_0].
v5.1.02025-07-07
New:
Response.peekTrailers(). When we changedResponse.trailers()to block instead ofthrowing in 5.0.0, we inadvertently removed the ability for callers to peek the trailers
(by catching the
IllegalStateExceptionif they weren't available). This new API restores thatcapability.
Fix: Don't crash on
trailers()if the response doesn't have a body. We broke [Retrofit] userswho read the trailers on the
raw()OkHttp response, after its body was decoded.v5.0.02025-07-02
This is our first stable release of OkHttp since 2023. Here's the highlights if you're upgrading
from OkHttp 4.x:
OkHttp is now packaged as separate JVM and Android artifacts. This allows us to offer
platform-specific features and optimizations. If your build system handles [Gradle module metadata],
this change should be automatic.
MockWebServer has a new coordinate and package name. We didn’t like that our old artifact
depends on JUnit 4 so the new one doesn’t. It also has a better API built on immutable values. (We
intend to continue publishing the old
okhttp3.mockwebserverartifact so there’s no urgency tomigrate.)
OkHttp now supports Happy Eyeballs ([RFC 8305]) for IPv4+IPv6 networks. It attempts both IPv6
and IPv4 connections concurrently, keeping whichever connects first.
We’ve improved our Kotlin APIs. You can skip the builder:
OkHttp now supports [GraalVM].
Here’s what has changed since 5.0.0-alpha.17:
NoSuchMethodErrorwhen using OkHttp with the Sentry SDK.okhttp3.mockwebserver.RecordedRequest.pathproperty. Weinadvertently changed this behavior when we introduced the
mockwebserver3API.zonkyio/embedded-postgres-binaries (io.zonky.test.postgres:embedded-postgres-binaries-bom)
v18.2.0Changes:
LFDT-web3j/web3j (org.web3j:crypto)
v6.0.0Bug Fixes
Features
eth_blobBaseFeeRPC (EIP-7918 / Fusaka-correct blob base fee) #2300BREAKING CHANGES
v5.0.3Bug Fixes
Features
BREAKING CHANGES
rest-assured/rest-assured (io.rest-assured:rest-assured)
v6.0.1v6.0.0mock-server/mockserver-monorepo (org.mock-server:mockserver-netty)
v7.6.0Changed
helm_sidecar_injection(admission-webhook sidecar injection),
helm_clustered_convergence, andhelm_jgroups_dns_ping(both the-clusteredInfinispan image) — now run blocking in CI instead of recording a skip. Previously the CI helm stepran with no JDK and never built those images, so all three recorded an honest but permanent SKIP — coverage that
looked green while proving nothing. A new
:maven: build container-test images (jars)step in themockserver-container-testspipeline builds themockserver-netty,mockserver-k8s-webhook, andmockserver-state-infinispanjars from the tree (once, via the Maven-in-Docker reactor) and hands them to thehelm step as Buildkite artifacts; the helm step downloads them and does cheap
docker builds (a COPY intodistroless) to produce the
-clusteredandmockserver-webhookimages, then runs the suite. The jars travel asartifacts (~200 MB total) rather than
docker saved images (~1.3 GB), mirroring the node-launcher / WAR hand-off. Bothlayers fail closed: the helm step exits non-zero if any jar artifact is absent, and the harness runs with
REQUIRE_CLUSTERED_IMAGE=true/REQUIRE_WEBHOOK_IMAGE=trueso an image that is expected-but-absent is recorded as aFAILURE, never a skip — a skip in CI is now impossible. Local
container_integration_tests/integration_tests.shis unchanged for a developer without the images: it still records a comprehensible SKIP (no fail-closed flag set),
and the harness now also builds the
mockserver-webhookimage locally (build_webhook_docker) so the sidecar caseruns blocking in local dev too — it was never built by the harness before, so that case had always skipped.
Added
check-false-green-guards.shCI gate. Rule 4 fails the build if a CI step runs thecontainer-integration harness with the helm/k3d cases active but does not export both
REQUIRE_CLUSTERED_IMAGE=trueandREQUIRE_WEBHOOK_IMAGE=true— the exact way the three image-dependent Kubernetes cases could silently revert to a greenSKIP. It is keyed on the step's behaviour (invokes
integration_tests.shwithoutSKIP_HELM_TESTS=true), not on afilename, so a rename or a second helm-running step is covered automatically. Rule 5 fails the build if a
mockserver-coretest that performs a JVM-global logging side effect (reachingLogManager.readConfiguration's handlerreset()via the staticConfigurationPropertieslogging setters or a forced fresh<clinit>) is not in thesequential-testsinclude list — the shape behind a release-blocking flake thatParallelStaticStateGuardTeststructurally cannot catch. Both rules fail closed on an empty corpus and carry a rotating allow-list. See
docs/operations/false-green-guards.md.
jarPathlauncher option and matchingMOCKSERVER_JAR_PATHenvironment variable formockserver-node, pointingstart_mockserverat a pre-provisionedmockserver-nettyjar-with-dependencies instead of downloading one fromMaven Central. When set, that exact jar is launched and no download is attempted; a configured-but-missing path is a
hard error (
... refusing to fall back to downloading a release) rather than a silent fall-back to a releasedjar, so a missing artifact fails loudly. Mirrors the existing
MOCKSERVER_BINARY_BASE_URLbring-your-own-artifactpath for the standalone binary, and serves air-gapped/corporate installs as well as testing a locally-built jar
(
jarPathtakes precedence overmockServerVersion/artifactory*; the option beats the env var). The Node launcherintegration tests now use it in CI: a new
:maven: build node launcher jarstep builds the jar from the tree andthe launcher-test step downloads it as an artifact and launches it via
MOCKSERVER_JAR_PATH— so the suite finallytests the repo's own code instead of the last release. Previously it ran a downloaded release chosen by
package.json's version, so amockserver-corefix could not green it and a regression could not red it; thatreleased jar also carried the shipped dynamic-CA generation race (fixed on master in
4cff56e61) and flaked ~8% ofruns. The launcher step fails closed if the tree-built jar is absent rather than reverting to a download, and
local
npm testoutside CI is unchanged (with neither the option nor the env var set it still downloads as before).LlmCodecStructuralContractTest), breaking theself-derivation weakness in the golden-file drift test.
LlmCodecGoldenFileTestregenerates its golden bodiesfrom the codec itself (
-Dmockserver.updateLlmGoldens=true), so a structural codec defect — a renamed field, awrong SSE event name, a dropped
finish_reason— bakes straight into its own golden and the byte-for-byte drifttest then passes forever, confirming only that the codec is consistent with itself (token counts were already
pinned separately by
shouldEncodeCanonicalTokenUsageCounts; the bodies were not). The new test asserts the livecodec output against hand-authored expectations taken from each provider's published API schema — required
fields, JSON types, the enum discriminators each provider uses (
object/type/finish_reason/stop_reason/finishReason/status/done), the tool-call envelope shape (arguments as a JSON string for OpenAI/Responsesvs a structured object for Anthropic/Gemini/Ollama), and the exact SSE event-name sequence for the event-typed
providers — across all seven chat/completion providers (Azure and Bedrock via their delegate codecs). Crucially it
never reads the golden files and is unaffected by
-Dmockserver.updateLlmGoldens=true, so regenerating goldenscannot silence it. Each named defect class was injected into a codec and confirmed to turn the test red without
regenerating goldens (OpenAI renamed
finish_reason; Anthropic SSEcontent_block_delta→content_delta; Geminidropped
finishReason; Responses renamedstatus; Ollama renamed terminaldone), then reverted. Residualstreaming-over-the-wire behaviour remains covered by
LlmAgentLoopE2eTest.HttpStateCassetteEndpointTest) and an authoritativeCassetteRegistryjavadoc note pinningthe settled decision that loading and recording register a cassette automatically. The
record_llm_fixturesand
load_expectations_from_fileMCP tools already auto-register the fixture in the process-wideCassetteRegistry(keyed by file path, origin
recorded/loaded, upserting on re-load/re-record) so it surfaces underGET /mockserver/cassettesand in the dashboard's Cassettes tab without a manualPUT /mockserver/cassettes— butnothing pinned that a so-registered cassette is actually retrievable through the GET endpoint, and the registration
policy lived only in the two MCP callers, inviting the question to be re-opened. The new test drives
GET /mockserver/cassettes(and the bare/cassettesalias) against a registry populated the way the load/recordhandlers populate it and asserts the documented body shape (path, derived filename, expectation count, origin,
lastUsed), that record-then-load on one path yields a single upserted entry, and that a server reset clears it. The
MCP tools and consumer docs (
ai_mcp_tools.html) already stated this behaviour; both are now clarified to say thefixture is registered automatically. This closes the "CassetteRegistry auto-population" product-decision item by
recording the decision in code, docs, and a test rather than leaving it to resurface.
(
.buildkite/scripts/steps/ui-client-codegen-compile.sh, wired intopipeline-ui.yml), closing the gap wherefive of the composer's seven languages had no compile check — only Java (
ui-java-codegen-compile.sh) and C#(
ComposerCodegenEquivalenceTests.cs) were gated, so an emitter bug or a client-API rename would ship brokengenerated code to users caught by nothing (the existing per-language tests only string/byte-compare the emitter
output, never feed it to a compiler). Each gate drives the shared representative composer matrix
(
extractParityCases.ts— the exactcombosthe byte-identity parity tests use) through that language's emitterand runs the lightest credible toolchain check:
python -m py_compileandruby -ccatch any emitter bug thatproduces malformed source (the strongest static check for a dynamically-typed client with no shipped type stubs),
while Go (
go build/go vet ./...) and Rust (cargo check) compile the generated code against the realin-repo
mockserver-client-go/mockserver-client-rust, so a renamed client method fails the build — the directanalog of the Java
javacgate. Node was already covered: thetsctype-proof innode.test.ts(
typecheck-node-codegen.mjs) runs undernpm test, so the orphaned-script concern was already resolved by thattest. All four new gates are proven to go red (emitter drift → non-zero exit) and green. Each phase runs in its
toolchain's Docker image via
run-in-docker.sh; setCODEGEN_COMPILE_USE_DOCKER=falsefor host validation.(
GcsBlobStoreRegistrarConfigWiringTest,AzureBlobStoreRegistrarConfigWiringTest), closing the gap whereonly S3 (
S3BlobStoreRegistrarConfigWiringTest) proved thatblobStoreTypeconfiguration is turned into aworking client. The GCS and Azure contract tests hand-build their clients (
new GcsBlobStore(storage, …),new AzureBlobStore(containerClient, …)), so the registrar that reads the bucket/container name, endpoint,credentials and project from configuration and constructs the client was never exercised — a wiring bug there
would ship silently because the contract tests bypass it. The new tests drive each registrar from configuration
only (as production does) against the same Docker emulator the contract tests use (fake-gcs-server for GCS,
Azurite
3.36.0 --skipApiVersionCheckfor Azure) and assert the wiring that can actually be got wrong:endpoint override, credentials, project id, and that a round-tripped object lands in the configured
bucket/container under the configured key prefix — verified through an independent admin client so a
mis-wired name cannot pass. Docker-gated via the canonical
DockerAvailability.isAvailable(...)probe.mockserver-testcontainers/node,mockserver-testcontainers/python)now start a real MockServer container in CI and assert against it, closing a false-green gap where both published
client libraries had jobs that passed having exercised nothing (
npm run test:unitandpytest -m "not docker"both skipped the container). Their CI steps now mount the Docker socket, run the existing integration tests that
start a
mockserver/mockservercontainer and drive it over HTTP, and — mirroring the Go/.NET/Rust steps — failclosed by grepping for an evidence marker the test prints only after a real container answered
PUT /mockserver/statuswith200. A skip (test filtered out, renamed, or Docker unusable) therefore fails theCI build loudly instead of reading as green, while the tests still degrade gracefully to a skip off-CI.
.github/workflows/dependency-submission.yml) now submits the resolved Maven dependencygraph so Dependabot vulnerability alerts stay accurate for the monorepo layout. GitHub's managed Maven
auto-submission only discovers a project at the repository root, so it silently stopped when the Java project moved
into
mockserver/— freezing the alerting graph at a pre-move snapshot that produced phantom Spring advisories andhid already-landed
log4j-api/jsoupfixes. The workflow resolves and submits themockserver/reactor (whichincludes
examples/java) and the separatemockserver-maven-pluginbuild under distinct correlators, path-gated tomockserver/**/pom.xml. Dependabot's security-update pull requests were unaffected — they read manifests directly;it was only the alerting graph that had gone stale.
.buildkite/scripts/steps/check-certificate-expiry.sh, wired into the Java pipeline) now sweeps everycommitted certificate PEM and fails the build when any certificate is already expired or expires within 30 days,
warning between 30 and 180 days. It checks every certificate in a chain file, allow-lists the one intentional
expired test fixture while asserting it stays expired, and enforces two structural invariants that previously had
no automation: every
leaf-cert.pemmust expire on or before its siblingca.pem, and the shipped default CAfiles must stay in lockstep (the PKCS#1 and PKCS#8 CA private keys are the same key, that key matches the CA
certificate, and the two committed copies of the CA certificate remain byte-identical). Certificate expiry had
previously only ever been discovered by the build going red.
check-false-green-guards.sh) that fails closed when a new "false-green" test shape isintroduced — a test or CI step that reports success while verifying nothing. The 2026-07-21 coverage audit named
these shapes but they lived only in plan documents, and the repository then produced ~a dozen fresh instances in a
single day. The guard enforces the three that can be pinned down precisely and each caused a real shipped false
green: (1) every JUnit suite gated by
Assume.assumeTrue(DockerAvailability.isAvailable(...))must be paired withassert-suite-ran.shover its reports, or a broken Docker socket skips it while the build stays green; (2) no CIstep may mount the Docker socket and then deselect the Docker-marked tests (e.g.
pytest -m "not docker"),starting no container yet passing; (3) no container-integration
logTestSkipmay park deferred work ("CI wiring isa follow-up") as a green skip. It runs always-on (a new false green can enter from any of several pipelines) and
carries a justified, self-verifying allow-list that fails if an entry no longer names what it claims. Wiring this
up also closed a live gap it found — the
Gcs/AzureRegistrarConfigWiringTestcloud suites ran under a Dockersocket in CI but were not fail-closed-asserted. See
docs/operations/false-green-guards.md.K3D_LOCAL_CA_BUNDLEhook incontainer_integration_tests/helm-deploy.shso the Helmintegration suite's k3d cluster can be stood up on a developer machine behind a corporate TLS-inspection proxy.
When set,
start-up-k8sovermounts the given combined CA bundle (system/public roots + corporate root) as thek3s node's containerd trust store at cluster-create time; when unset the
k3d cluster createcommand isbyte-identical to before, so CI (which never sets it) is unchanged. Warns rather than fails if the variable is set
but the file is missing, mirroring
LOCAL_DOCKER_CA_BUNDLEin.buildkite/scripts/run-in-docker.sh. This unblocksthe three Kubernetes test-coverage gaps that were previously (and incorrectly) deferred as impossible behind the
proxy: the host Docker daemon already trusts the corporate root so the node image pulls, but the in-node
containerd has its own public-roots-only trust store and otherwise cannot pull even the
rancher/mirrored-pausesandbox image (every pod fails sandbox creation with
x509: certificate signed by unknown authority). Seedocs/operations/build-system.md→ Local Development Behind a Corporate TLS-Inspection Proxy.previously shipped unproven.
helm_sidecar_injectiondeploys the chart withwebhook.enabled=true(self-signed TLSbootstrap Jobs + webhook handler Deployment +
MutatingWebhookConfiguration), drives a real labelled podCREATEthrough the admission path, and asserts the resulting pod spec carries the injected
mockserver-sidecarcontainer,mockserver-iptables-initinit container, andmockserver.org/injectedannotation — with a negative-control pod (noopt-in annotation) that must not be injected, so a webhook that injects unconditionally fails the test.
helm_jgroups_dns_pingdeploys two clustered replicas and asserts the headless Service is truly headless(
clusterIP: None), thatJGROUPS_DNS_QUERYis wired to its FQDN, that it resolves to ≥2 pod IPs (Endpoints plus anin-cluster
nslookup), that a ≥2-node JGroups/Infinispan view forms (the anti "two clusters of one" guard), and thatstate converges across the pods — exercising the Kubernetes DNS discovery path that
JGroupsKubernetesStackTest(XML-parse only) and
ClusteredTwoNodeTest(loopback MPING) never run. Both were proven red by degrading the exactbehaviour they name (deleting the
MutatingWebhookConfiguration; deleting the headless Service and rolling the pods).Both depend on Java-built images (the
-clusteredvariant and themockserver-webhookhandler); when those imagesare absent — e.g. the CI helm step runs with
SKIP_JAVA_BUILD=trueand no JDK — the cases record an honest SKIPrather than a misleading pass, and run blocking only where the images exist.
Changed
helm_clustered_convergenceis now a blocking container-integration test rather thannon_blocking || true. Theswallowed
k3d image import ... 2>/dev/null || trueis replaced by a deterministic import that verifies the image ispresent in the k3d node's containerd (via
crictl) before deploying, and a pre-deployensure_namespace_absentguardremoves the real back-to-back flake (
helm installinto a still-Terminatingnamespace left by a prior run/retry).When the
-clusteredimage is absent (CI helm step, no JDK) the case records an honest SKIP; when present it runsblocking so a genuine clustering regression reds the suite.
docker_compose_war_tomcatcontainer integration test (MockServer deployed as a WAR into Tomcat 10.1) nowactually runs in CI, closing a false-green gap where it silently skipped with "WAR artifact not present … CI wiring
is a follow-up" — a working behavioural test that never ran, in a demonstrated weak spot (the ROOT-context
percent-decode regression
66b5d51d2shipped and broke builds, and this is the suite that would have caught it).Buildkite steps share no filesystem, so the WAR (already built by the reactor in the
:maven: buildstep but neverpublished) is now uploaded via that step's
artifact_pathsand downloaded bycontainer-tests-run.shinto the paththe test globs. A missing WAR now fails the step closed (both an explicit presence check in
container-tests-run.shand, defensively,
prepare_warinintegration_test.shred the case) instead of skipping — a skip that reads as greenis the exact defect being closed. The case runs in the Java pipeline's master-only
:docker: container integration testsstep (triggered bymockserver/,mockserver-ui/,test-fixtures/changes); it was already declared requiredin
expected_tests.manifest, so no manifest change was needed.4.2.16.Finalto4.2.17.Finaland, in lockstep,netty-tcnative-boringssl-staticfrom2.0.78.Finalto2.0.81.Final(the tcnative version the Netty 4.2.17 BOM aligns to). The two must move together:the Netty BOM pins the transitively-resolved native-classifier tcnative jars to
2.0.81.Final, so a mismatchedmain-artifact pin fails the enforcer
DependencyConvergencerule inmockserver-core. TheNETTY_TCNATIVEbuildargs in every
docker/*/Dockerfilewere updated to match. This unblocks Dependabot PRs #2523 and #2532.netty-tcnativeversion-synchronisation step that made every Netty upgrade a convergence trap.netty-tcnative-boringssl-staticno longer has its own version property ordependencyManagementoverride — theimported
netty-bomnow governs the base artifact and every OS/arch native classifier together, so the two can nolonger diverge and break the enforcer
DependencyConvergencerule. The server jars (which ship tcnative classesbut, per #1778, no natives) are stamped at build time with their resolved tcnative version at
META-INF/mockserver-tcnative.version, and everydocker/*/Dockerfilenow derives the native.sodownload fromthat stamp instead of a hardcoded
NETTY_TCNATIVE=build arg (SHA256 verification of the download is unchanged).Both jars a Dockerfile can consume carry the stamp: the shaded
mockserver-netty-no-dependenciesjar used by thesource=copypath (release/snapshot/CI) and themockserver-nettyassembly-jar-with-dependencies.jarused bythe default
source=downloadpath (the public reference build), stamped via the same script so they cannot drift. ANetty bump therefore needs no tcnative pin update and no Docker edit, and the native
.socan never be a differentversion than the tcnative classes it pairs with.
TLSv1.2,TLSv1.3(previouslyTLSv1,TLSv1.1,TLSv1.2), andtlsAllowInsecureProtocolsnow defaults tofalse(previouslytrue).TLSv1 and TLSv1.1 are deprecated by RFC 8996 and vulnerable to BEAST/POODLE, and TLSv1.3 was previously never
negotiated unless explicitly configured. This is a breaking change for a client that can only speak TLSv1 or
TLSv1.1: its handshake to MockServer will now fail. To
restore the legacy protocols set
mockserver.tlsProtocols=TLSv1,TLSv1.1,TLSv1.2ANDmockserver.tlsAllowInsecureProtocols=true(both are required — the insecure-protocol filter strips TLSv1/TLSv1.1unless it is explicitly allowed). The inbound server always applies the strong
Http2SecurityUtilcipher suites, sono weak-cipher combination becomes reachable as a result of this change.
expiry) and the three Netty TLS integration CAs were re-issued with a 10-year validity, and every leaf they sign
was re-issued with a shorter 5-year validity so that a leaf can no longer outlive its issuing CA. The existing CA
and leaf private keys were preserved (so key encodings, Subject/Authority Key Identifiers and existing signatures
are unchanged); only the certificates were re-minted.
Security
org.apache.logging.log4j:log4j-apito2.25.5to resolve GHSA-qv9r-c865-cp47. It is pulled in transitivelyat compile scope (via
spring-boot-starter-logging->log4j-to-slf4j) and lands in a shaded artifact, so it isshipped; the pin manages
log4j-apionly (log4j-coreis not on the dependency tree).org.jsoup:jsoupto1.23.1to resolve GHSA-pmhh-3w7g-xqp8. jsoup is used only at test scope (never shipped);the pin guards against a future transitive downgrade below the fixed version.
com.azure:azure-storage-blobfrom12.29.1to12.35.0in the optionalmockserver-blob-azuremodule toresolve the
io.projectreactor.netty:reactor-netty-httpchained-redirect credential-leak advisory (fixed inreactor-netty
1.2.8). The old stack pulledazure-core-http-netty:1.15.10, which pins the vulnerablereactor-netty
1.0.48pair transitively;12.35.0pullsazure-core-http-netty:1.16.5, which advances bothreactor-netty-httpandreactor-netty-coreto1.2.18as a matched pair. This exposure surfaced only whenGitHub's Maven dependency-graph submission was restored (submission had silently frozen at a pre-move snapshot, so
the alert had been invisible to Dependabot). The whole Azure stack (azure-core
1.58.1, reactor-netty1.2.18,reactor-core
3.7.19) remains Java-8 bytecode, so the Java 17 floor is preserved. A module-scopeddependencyManagementpin ofio.projectreactor:reactor-coreto3.7.19reconciles the one internal off-by-one inthe 12.35.0 stack (azure-core declares
3.7.18, reactor-netty declares3.7.19) so the enforcerDependencyConvergencerule stays satisfied. The Docker-gated Azurite contract test moves to Azurite3.36.0with--skipApiVersionCheck, since the newer SDK negotiates a Storage REST API version that runs ahead of every releasedAzurite build.
dependency-graph submission was restored (submission had silently frozen at a pre-move snapshot on 5 May, so these
real exposures had been invisible to Dependabot). None required moving the direct dependency that introduces them:
tools.jackson.core:jackson-databind,:jackson-core,tools.jackson.dataformat:jackson-dataformat-yaml)pinned to
3.1.5to resolve GHSA-5gvw-p9qm-jgwh (vulnerable>=3.0.0, <=3.1.4). It arrives at compile scope viacom.networknt:json-schema-validator:3.0.6and is shade-relocated intoshaded_package.tools.jackson, so itships in every distributed jar — the one broad, shipped, runtime exposure of the three. All three artifacts
resolve in lockstep and are pinned together so the enforcer
DependencyConvergencerule stays satisfied. The pinis inherited by the separate
mockserver-maven-pluginbuild (same parent pom), closing its alert too.at.yawk.lz4:lz4-javapinned to1.11.1to resolve GHSA-6qcp-4vqm-vf35 (native XXHash JVM crash; vulnerable<=1.11.0). Arrives viaorg.apache.kafka:kafka-clients:3.9.2— optional inmockserver-netty, runtime inmockserver-async. Note this is theat.yawk.lz4fork coordinate, notorg.lz4.org.apache.commons:commons-compresspinned to1.27.1to resolve the>=1.21, <1.26.0advisories. Arrives attest scope via
org.testcontainers:testcontainers:1.21.4, which reConfiguration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.
This PR has been generated by Mend Renovate.
Note
High Risk
Vert.x 5 and Flyway 13 affect the HTTP runtime and DB migrations; JUnit 6, web3j 6, and Nimbus JWT 10 are broad major upgrades across tests and JWT-related transitive use—breakage may only show up in CI.
Overview
Renovate-driven major version bumps in
build.gradleandgradle/versions.gradleonly—no application source changes.Build tooling: OWASP Dependency-Check
12.2.1→13.0.0, Error Prone Gradle plugin4.4.0→5.1.0.Managed dependencies: JUnit BOM
5.14.3→6.1.3; Vert.x stack4.5.26→5.1.6; web3j (besu,core,crypto)5.0.2→6.0.0; OkHttp4.12.0→5.5.0; Flyway11.20.3→13.3.0; REST Assured5.5.7→6.0.1; MockServer Netty5.15.0→7.6.0; embedded Postgres binaries BOM17.9.0→18.4.0; Nimbus JOSE JWT9.48→10.9.1.Expect compile/test and integration behavior to shift with these majors; full
./gradlew build(and slashing-protection Flyway paths) is the main validation gate.Reviewed by Cursor Bugbot for commit dbff7fe. Bugbot is set up for automated code reviews on this repo. Configure here.