Warning: file_get_contents(/data/phpspider/zhask/data//catemap/5/ruby-on-rails-4/2.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
Java BouncyCastle版本冲突,供应商不合作_Java_Bouncycastle_Dependency Management - Fatal编程技术网

Java BouncyCastle版本冲突,供应商不合作

Java BouncyCastle版本冲突,供应商不合作,java,bouncycastle,dependency-management,Java,Bouncycastle,Dependency Management,由于与BouncyCastle的版本冲突,我目前一直在集成Java包 我们在内部开发了一个组件,用于处理发送到我们的地方税务局(不是“IRS”,而是另一个欧洲国家的等效税务机构)的数据文件,使用他们提供和维护的官方Java API。我们平台的另一个模块使用来自认证机构的组件来执行文件的认证时间戳。两者都必须集成到部署在客户站点的单个web应用程序中 您可能知道,两个包所依赖的BouncyCastle包都经历了几次公共API更改,因此后续版本不再与二进制兼容 收入服务提供了“cryptotools

由于与BouncyCastle的版本冲突,我目前一直在集成Java包

我们在内部开发了一个组件,用于处理发送到我们的地方税务局(不是“IRS”,而是另一个欧洲国家的等效税务机构)的数据文件,使用他们提供和维护的官方Java API。我们平台的另一个模块使用来自认证机构的组件来执行文件的认证时间戳。两者都必须集成到部署在客户站点的单个web应用程序中

您可能知道,两个包所依赖的BouncyCastle包都经历了几次公共API更改,因此后续版本不再与二进制兼容

收入服务提供了“cryptotools.jar”包,该包取决于以下内容:

<dependency org="org.bouncycastle" name="bcprov-jdk15on" rev="1.49"/>
<dependency org="org.bouncycastle" name="bcpkix-jdk15on" rev="1.49"/>

证书颁发机构提供的“jades内核”时间戳包取决于

<dependency org="org.bouncycastle" name="bcmail-jdk15"     rev="1.45"/>
<dependency org="org.bouncycastle" name="bcprov-jdk15"     rev="1.45"/>
<dependency org="org.bouncycastle" name="bcprov-ext-jdk15" rev="1.45"/>
<dependency org="org.bouncycastle" name="bctsp-jdk15"      rev="1.45"/>

将这两个包都放在类路径上会导致所有BouncyCastle包被转储到我的
WEB-INF/lib
文件夹中,这听起来正常

但是,如果我试图用所有这些包启动web应用程序,我会得到一个
错误
,表示类扩展了最终方法。我不会发布堆栈跟踪,这与我的问题无关

如果我删除BC的两个版本(1.45或1.49)中的任何一个,其中一个模块将无法编译。嗯,它们都已经编译好了,所以它们不会简单地链接到引用的类/方法

我已经使用较旧的BC版本(Black Duck发现该版本存在安全漏洞,因此我的客户让我感到痛苦)向CA报告了这种情况(我们与CA签订了Java API的维护合同)。CA还没有合作。他们需要发布一个新版本的加密API,该API与BouncyCastle的最新版本兼容

我和我的上司(C级上司)正在将问题升级到CA层级,根据我们当地的幽默,很快我们将升级到

提到幽默,请允许我以视觉方式分享我当前的感受

提问时间,现在回到严肃的讨论 假设我们的供应商不合作,或者至少不及时遵守我们的监管期限。收入服务显然不会将其JavaAPI降级为旧的BC版本

我们如何摆脱这种依赖地狱?例如,我知道log4j有一个“桥接”包,用于缓解那些尚未升级的包在1.x和2.x版本之间的API变化。当两个模块依赖于不同的BC版本时,我们如何使它们共存


我将发布一个可能的解决方案,但它不是我们首选的解决方案。

一个解决方案可能是将web应用程序拆分为多个应用程序,每个应用程序部署在不同的上下文中,并通过web服务进行通信。辅助应用程序将只是私有的

时间戳模块的类路径将使用较旧的BC版本,而税务服务模块将使用不同的类路径。“主”前端web应用程序根本不依赖于BC


这并不能解决Black Duck问题,因为客户将要求升级或需要大量的文书工作才能允许策略异常。

本质上,Java不是为此而构建的,Maven当然不是(因为有一个基本假设,即在解决此类冲突时,任何较新版本都是旧版本的完美替代品)

我的理解是,您有一个单片应用程序,因此您不能物理地分割类路径,因此可以逻辑地进行分割


处理这个问题的一种方法是在多个类加载器中运行应用程序,这样jar文件就不会“接触”前面的问题-这种方法与加载不在类路径上的jar相结合可能是可行的。

本质上我的应用程序是一个单一的web应用程序,对吗!web应用程序?然后您可以分为/a和/b,其中/b正在做需要旧jar的小部分,并与/a对话/b使用普通的web请求。这正是我在自己的回答中提出的解决方法(将修正措辞)。这并不美观,也不可能在短时间内完成。但至少可以让齿轮工作。更清楚地说:要求客户为我们分配不同的web应用程序上下文是两方面的文书工作,而且(如我所说)不会修复过时的依赖性的安全问题。但是这显然是不可能的范围,好像供应商不合作升级BC,除了支付从零开始重写供应商代码之外,我的公司就无能为力了。我需要考虑我的全部经验。你不能指望供应商更新。只是因为你遇到了一个不是他们的错的问题,所以我建议将你的麻烦模块(你有这个源代码)移植到你必须使用的BC版本。