Downgrade Kotlin/Ktor for Kotlin 2.1-compatible metadata - #112
Conversation
The 3.4.0 bump (#93) fixed CVE-2025-29904 but pulled in Kotlin 2.3.0 class metadata, which can break consumers on older Kotlin compilers. 3.2.4 keeps the CVE fix (resolved in 3.1.1) while shipping Kotlin 2.1.0 metadata instead. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
🦋 Changeset detectedLatest commit: cffa149 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Warning Review the following alerts detected in dependencies. According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.
|
Ktor 3.2.4 already ships Kotlin 2.1.0 metadata, but the project's own Kotlin Gradle plugin was still 2.2.21, so evervault-core's own classes carried mv=[2,2,0]. Dropping the plugin to 2.1.20 (and the pinned kotlin-stdlib-common versions to match) brings all shipped modules down to mv=[2,1,0], with lockfiles regenerated accordingly. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…pinned kotlin-stdlib to 2.3.0 The previous lockfile regeneration didn't touch the lint model's androidTest compile classpath for this module, leaving a stale kotlin-stdlib:2.3.0 lock entry that conflicted with the rest of the graph and broke generateDebugAndroidTestLintModel (and thus `./gradlew build`) in CI. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Summary
In order to be compatible with React Native, we need to make this library compatible with Kotlin 2.1. This required downgrading the ktor dependency to 3.2.4 (which supports 2.1) and switching our build to output 2.1 metadata
This has been tested with React Native 0.79 & Expo 53 and works as expected
What Changed
evervault-coreshippedkotlin.Metadatawithmv=[2,3,0]because the Ktor bump in Fix: Update Vulnerabilities #93 (to fix CVE-2025-29904) went all the way to3.4.0, which is built with Kotlin 2.3.0.ktor-client-core/ktor-client-okhttpto3.2.4, which is built with Kotlin 2.1.0 metadata, while staying well past3.1.1(the version that fixed CVE-2025-29904).2.2.21, soevervault-core's own classes carriedmv=[2,2,0]regardless of the Ktor pin. Downgraded the Kotlin plugin (org.jetbrains.kotlin.android,plugin.serialization,plugin.compose) to2.1.20and matched the pinnedkotlin-stdlib-commonversions, so every shipped module (evervault-core,evervault-cages,evervault-enclaves,evervault-inputs) now carriesmv=[2,1,0].gradle.lockfiles to match.Test plan
testDebugUnitTest/testReleaseUnitTest— 75/75 pass for every module, against the live Evervault APIassembleDebug/assembleReleaseacross all modulesmv=[2,1,0]metadata (down from[2,3,0])mavenLocalunder2.4.0-localfor cross-repo consumer testingktorVersionvar inexamples/sharedis unused)🤖 Generated with Claude Code