Repository navigation
fix: drop okhttp internal hostname verifier import, pin hostname verification, harden insurance test - #6928
Merged
AndyScherzinger merged 3 commits intoOct 18, 2026
Conversation
RestModule wrapped okhttp3.internal.tls.OkHostnameVerifier, an internal class without compatibility guarantees that a later okhttp release may move or remove. Read the same default verifier through the public OkHttpClient.hostnameVerifier() instead; in okhttp 5 it is OkHostnameVerifier, so hostname verification is unchanged. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: Andy Scherzinger <info@andy-scherzinger.de>
The insurance request reaches the network mock from the pull flow on Dispatchers.IO, which runCurrent() does not wait for. A never() check right after runCurrent() therefore passed even when a request had been started too early, as long as the IO thread had not reached the mock yet. Verify with after(), so the check watches for a while before concluding that nothing was sent. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: Andy Scherzinger <info@andy-scherzinger.de>
TrustManagerTest covers our verifier wrapper with a mocked default verifier only. Build the client through RestModule.provideHttpClient and run real certificates through its hostname verifier: a certificate for another host, a subdomain or with the host only as common name is rejected, and a mismatching one is only accepted once the user trusted it. This fails if hostname verification is ever weakened, whether by an okhttp default or by the client setup. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: Andy Scherzinger <info@andy-scherzinger.de>
Contributor
📱 QA build
The QA build installs alongside a released Nextcloud app, so you can keep Downloading the file requires a GitHub account, so open this link on the |
Contributor
AndyScherzinger
deleted the
fix/noid/okhttp-internal-and-insurance-test-race
branch
October 18, 2026 08:14
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two follow-ups from the okhttp 5 update (#6500) and the flaky test fix (#6927), plus a test pinning hostname verification.
1. Stop importing okhttp's internal
OkHostnameVerifierRestModulewrappedokhttp3.internal.tls.OkHostnameVerifier, an internal okhttp class without compatibility guarantees that a later release may move or remove. The same default verifier is now read through the publicOkHttpClient.hostnameVerifier(). In okhttp 5.5.0OkHostnameVerifieris a Kotlinobjectand the client's default (OkHttpClient.Builder.hostnameVerifier), so the very same instance is wrapped as before and hostname verification is unchanged, including the wrapping by ourTrustManagerfor user-accepted certificates.The new
RestModuleHostnameVerificationTestbuilds the client throughRestModule.provideHttpClientand runs real certificates (okhttp-tlsHeldCertificate) through its hostname verifier:TrustManagerfallback)Unlike
TrustManagerTest, which mocks the default verifier, this fails if hostname verification is ever weakened, whether by an okhttp default or by the client setup. Checked by temporarily installing an accept-all verifier inRestModule: all four rejection tests fail.2. Make the insurance request
never()checks observe the IO threadIn
OfflineFirstChatRepositoryTest, the insurance request reaches the network mock fromChatMessageSyncer's pull flow onDispatchers.IO, whichrunCurrent()does not wait for. Anever()check right afterrunCurrent()therefore passed even when a request had been started too early, as long as the IO thread had not reached the mock yet: the mirror image of the race fixed in #6927. The three checks now useafter(LONG_POLLING_OBSERVATION_MILLIS).never(), so they watch for 200 ms before concluding that nothing was sent.Verified by injecting a bug (insurance requests no longer skipped while paused, plus a 100 ms delay on the IO thread): the old test still passed, the new one fails as it should. Without the injected bug, the class passes repeatedly (about 0.6 s slower in total); ktlint and detekt are clean; gplay and generic compile.
🖼️ Screenshots
🚧 TODO
🏁 Checklist
/backport to stable-xx.x🤖 AI (if applicable)