Closed LamGC closed 3 years ago
@LamGC 这个加密套件的兼容性可不可以通过判断系统环境来自适应呢?
然后目前所有的加密操作都是存在于CertUtil
中,没错的。
@LamGC 这个加密套件的兼容性可不可以通过判断系统环境来自适应呢? 然后目前所有的加密操作都是存在于
CertUtil
中,没错的。
@monkeyWie 唔,我的想法是,如果不区分分支的话,将 CertUtil
转化为中间层(类似于 Slf4j 的 LoggerFactory
),区分具体实现,然后根据需要引入(或者直接整合,按环境区分,不过这个我得确定一下)。
这个感觉可以,或者其实提供一个自定义注册加密套件的入口就行了,把这段逻辑做成可定制的:
@monkeyWie 也行,或者简单一点,为 CertUtil 提供设置提供者名称,让开发者自由选择,没设置就默认BC,或者Null选JVM默认。(这个有兼容性问题)
单纯自定义注册加密套件可能不是一个很好的方法,注册了不一定会成为首选,所以可能还是要整一套接口和实现(晚点我试试看)。
@LamGC 嗯嗯,等看看你的实现思路
这边等待 Pull Request #108 的确认了,我疏忽大意忘记了分支跟 PR 的关联性,所以需要等待 PR #108 处理完成后才能 Push 并发起 PR。
补充个细节,这次更改使得 Proxyee 即使不自行实现一个 CertGenerator
,也可以运用到新版 Android 了,核心问题在于 provider 不能为 BC
,而不是 BouncyCastle 被禁用了,因此实际上只要不指定 Provider 就可以了。 😆
补充个细节,这次更改使得 Proxyee 即使不自行实现一个
CertGenerator
,也可以运用到新版 Android 了,核心问题在于 provider 不能为BC
,而不是 BouncyCastle 被禁用了,因此实际上只要不指定 Provider 就可以了。 😆
是新版安卓sdk内置了BC
吗
补充个细节,这次更改使得 Proxyee 即使不自行实现一个
CertGenerator
,也可以运用到新版 Android 了,核心问题在于 provider 不能为BC
,而不是 BouncyCastle 被禁用了,因此实际上只要不指定 Provider 就可以了。 😆是新版安卓sdk内置了
BC
吗
安卓实际上早就内置 BC 了,不过后来又加了几种加密套件,到 API 24 (7.0) 开始移除 BC 套件以减轻维护负担,所以就不能使用了。(具体可以看这个 issue 附上的链接)
我比较好奇的是移除了BC,那由什么补上,谷歌自己开发了一套加密套件吗
差不多,我忘记是啥了,文章有写(现在科学不了打不开)
@LamGC 了解
这个应该算是兼容性问题,Android P 开始将会移除 BC 加密套件(因为已经提供了 Android 上的其他加密套件),这将会导致 Proxyee 在 API 24 及以上无法使用。
要解决这个方法,需要移除对加密套件的指定,以允许 Android 为其自动提供可用的加密套件,但这个操作在 Desktop 环境显然不是很现实(除非 Java 自带的加密套件可以运用在 Proxyee),因此我想对 Proxyee 原版做一个小调整,独立出一个除 加密套件 不同外其他都与原版一样的新分支(暂定为
master-android
)。然后是提出这个 Issue 的原因:Proxyee 对于加密的所有操作都存在于
CertUtil
吗? 希望作者能回答我,感谢!Google 对于加密套件变更的官方文章:Cryptography changes in Android P