react / react/react-native

okhttp/okio pinned at vulnerable versions (CVE-2023-3635) in gradle/libs.versions.toml, unchanged through current main

未关闭
#58,148 2 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

Needs: Attention Needs: Repro
主要语言
C++
星标
127k
派生
25.3k
平均合并
1 天 23 小时
30 天内合并 PR
4

描述

This is a dependency/security report, not a runtime crash — there's no code reproducer, since the issue is a static pinned version, not a behavior bug. Evidence is the dependency tree below instead.

Description

packages/react-native/gradle/libs.versions.toml pins:

okhttp = "4.9.2"
okio = "2.9.0"

okio 2.9.0 is affected by CVE-2023-3635 / GHSA-w33c-445m-f8w7 ("Okio Signed to Unsigned Conversion Error"), fixed in okio 3.4.0.

This isn't a transitive/incidental pull-in — it's explicitly pinned in RN's own version catalog, and it lands on the actual shipped release classpath of a consuming app (confirmed via ./gradlew :app:dependencies --configuration releaseRuntimeClasspath), not just test tooling:

com.squareup.okhttp3:okhttp:{strictly 4.9.2}
com.squareup.okio:okio:{strictly 2.9.0}

I checked whether a newer RN version already fixes this before filing — it doesn't. I compared the same file across:

  • v0.79.6 (a currently-supported release): okhttp = "4.9.2", okio = "2.9.0"
  • main (current unreleased development branch, 0.87.0-main): okhttp = "4.9.2", okio = "2.9.0" — identical, no bump even in active development

So there's no RN version, released or in development, that resolves this by upgrading.

I also tried working around it downstream, in case that's a viable interim path for consumers: resolutionStrategy.force 'com.squareup.okio:okio:3.4.0' in a consuming app's build.gradle. This fails resolution — okio 3.x split into a separate okio-jvm artifact, and something in RN's own OkHttp/Fresco dependency graph (which strictly pins okio) can't resolve against that new layout. So this isn't something a consuming app can safely patch around either; it needs to be addressed in RN's own version catalog (bumping okhttp to a release built against a patched okio, and updating the okio pin to reflect that).

Steps to reproduce

Not applicable in the usual crash-reproduction sense — this is a static dependency pin, reproducible by inspecting the file directly:

curl -s https://raw.githubusercontent.com/facebook/react-native/main/packages/react-native/gradle/libs.versions.toml | grep -E '^okhttp|^okio'

Or from any consuming app: ./gradlew :app:dependencies --configuration releaseRuntimeClasspath | grep -i okio

React Native Version

Confirmed present on 0.79.6 (currently-supported release) and on main (0.87.0-main, current development).

Affected Platforms

  • Runtime - Android
  • Build - MacOS

Output of npx @react-native-community/cli info

Not applicable — this is a static analysis of RN's own committed version catalog file, not an environment-specific issue.

贡献指南

打开贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

调研方向

从 packages/react-native/gradle/libs.versions.toml 开始,检查 okhttp 和 okio 的固定版本。在更改版本之前,运行 ./gradlew :app:dependencies --configuration releaseRuntimeClasspath,以验证已解析的 release 构件并检查依赖布局。完成标准是 catalog 使用兼容的已修补版本,并且 release classpath 不再包含存在漏洞的 okio 版本。

由索引模型根据 Issue 内容生成。

评估

技术栈
android
领域
build-system, mobile, security
Issue 类型
缺陷
难度
3/5
预计耗时
1-2 天
活跃度
活跃
描述清晰度
描述清楚
新手友好度
68/100

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。