Compose Multiplatform 项目中使用混淆时遇到的 Bouncy Castle 签名问题解析
项目地址: https://gitcode.com/GitHub_Trending/co/compose-multiplatform 问题背景
在 Compose Multiplatform 桌面应用开发中，当开发者启用代码混淆功能时，可能会遇到一个与 Bouncy Castle 加密库相关的安全异常。具体表现为应用运行时抛出 java.lang.SecurityException: SHA-256 digest error for org/bouncycastle/operator/OperatorCreationException.class 错误。
问题现象
开发者在使用 Compose Multiplatform 1.6.2 版本开发桌面应用时，当开启 ProGuard/R8 混淆后，调用 stringResource() 方法加载资源字符串时，应用会崩溃并抛出上述安全异常。关闭混淆后，应用又能正常运行。
根本原因分析
经过深入排查，发现问题的根源在于：
-
签名验证失败：Bouncy Castle 库的 JAR 文件包含了数字签名信息（META-INF 目录下的 .SF、.RSA、.DSA 等文件）。当这些签名文件被 ProGuard 处理后，JVM 在运行时验证签名时发现哈希值不匹配，导致安全异常。
-
混淆配置冲突：即使添加了
-keep class org.bouncycastle.** { *; }规则保留 Bouncy Castle 类，仍然会出现签名验证问题，因为签名文件本身在构建过程中被修改了。 -
加密算法依赖：当完全移除 Bouncy Castle 相关保留规则时，又会出现
no such algorithm: SHA256WITHRSA for provider BC错误，表明应用确实需要这些加密功能。
解决方案
方案一：排除并替换依赖
- 在 Gradle 配置中排除有签名问题的 Bouncy Castle 依赖：
dependencies {
implementation("some.dependency") {
exclude(group: "org.bouncycastle", module: "bcpkix-jdk18on")
}
}
- 手动添加已去除签名文件的 Bouncy Castle 库：
implementation(fileTree("dir" to "libs", "include" to listOf("*.jar")))
- 预处理 JAR 文件，移除签名信息：
zip -d file.jar 'META-INF/*.SF' 'META-INF/*.RSA' 'META-INF/*.DSA' 'META-INF/*.EC'
方案二：自定义构建任务
对于更复杂的项目，可以创建自定义 Gradle 任务来处理签名文件：
tasks.register<Zip>("repackageUberJar") {
val packageTask = tasks.getByName("packageReleaseUberJarForCurrentOS")
dependsOn(packageTask)
val originalJar = packageTask.outputs.files.first()
val outputJar = File(originalJar.parentFile, "${originalJar.nameWithoutExtension}-repacked.jar")
archiveFileName.set(outputJar.absolutePath)
destinationDirectory.set(originalJar.parentFile.absoluteFile)
// 排除所有签名文件
exclude("META-INF/*.SF")
exclude("META-INF/*.RSA")
exclude("META-INF/*.DSA")
from(project.zipTree(originalJar))
doLast {
delete(originalJar)
outputJar.renameTo(originalJar)
}
}
技术原理
-
JAR 签名机制：Java 的 JAR 签名机制会在 META-INF 目录下创建 .SF（签名文件）、.RSA/.DSA（数字签名）等文件，用于验证 JAR 内容的完整性。
-
ProGuard 处理：当 ProGuard 处理 JAR 文件时，即使保留了类文件，也可能修改了类的内容或重新打包了 JAR，导致签名验证失败。
-
安全验证：JVM 在加载类时会自动验证签名，如果发现签名无效或哈希不匹配，就会抛出 SecurityException。
最佳实践建议
-
评估依赖必要性：首先确认项目是否真的需要 Bouncy Castle 库，或许可以使用 Java 内置的加密功能。
-
版本选择：尝试使用不同版本的 Bouncy Castle 库，某些版本可能签名处理更友好。
-
构建流程优化：在混淆前预处理依赖库，确保签名文件被正确处理。
-
测试验证：在启用混淆后，务必进行全面测试，特别是涉及加密和安全相关的功能。
总结
在 Compose Multiplatform 项目中使用混淆时遇到 Bouncy Castle 签名问题，本质上是构建工具链与 Java 安全机制之间的冲突。通过排除问题依赖、手动处理签名文件或自定义构建任务，可以有效解决这一问题。开发者应当根据项目实际需求选择最适合的解决方案，并在混淆后进行全面测试，确保应用功能的完整性。
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
