cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <cohei...@apache.org>
Subject Re: Releases on Friday/Monday?
Date Mon, 14 Jul 2014 10:46:47 GMT
Hi Alessio,

Some changes were made in XML Security 2.0.1 with regards to GCM support.
Namely, JDK 8 requires that javax.crypto.spec.GCMParameterSpec be used
instead of IVParameterSpec. However the former is only available as of JDK
7. So the solution was to try to load it reflectively, and to fall back on
IVParameterSpec if it is not available.

However, BouncyCastle does not add support for GCMParameterSpec until 1.50,
and there is a bug which means it won't work properly until 1.51 is
released. So the solution in WSS4J 2.0.1 is to set a system property in
Santuario to force it to use IVParametersSpec if BouncyCastle v.1.49 is in
use. In retrospect it was a mistake not to do this for BouncyCastle <=
1.49, but this was only intended to be a temporary workaround until
BouncyCastle 1.51 is released. This is why the CXF systests are working
correctly.

So in a nutshell, we require one of the following things for GCM to work
with the next set of CXF releases:

a) Upgrade to BouncyCastle 1.49 (or 1.51 when it gets released) OR
b) Set the system property
"org.apache.xml.security.cipher.gcm.useIvParameterSpec" to "true".

Colm.




On Fri, Jul 11, 2014 at 3:42 PM, Alessio Soldano <asoldano@redhat.com>
wrote:

> Hi Dan,
> I started testing the JBoss integration with current 3.0.1-SNAPSHOT and
> noticed some issues with the WS-Security endpoints using GCM algorithms.
> After updating both JDK and BouncyCastle I got past them, but I believe
> the release notes should properly clarify the actual new version
> requirements and backward compatibility limitations.
>
> The exception I had was:
>
> Caused by: java.security.InvalidAlgorithmParameterException: unknown
> parameter type.
>     at org.bouncycastle.jce.provider.JCEBlockCipher.engineInit(Unknown
> Source)
>     at javax.crypto.Cipher.implInit(Cipher.java:791) [jce.jar:1.7.0_10]
>     at javax.crypto.Cipher.chooseProvider(Cipher.java:849)
> [jce.jar:1.7.0_10]
>     at javax.crypto.Cipher.init(Cipher.java:1348) [jce.jar:1.7.0_10]
>     at javax.crypto.Cipher.init(Cipher.java:1282) [jce.jar:1.7.0_10]
>     at org.apache.xml.security.encryption.XMLCipher.
> encryptData(XMLCipher.java:1184)
>     at org.apache.xml.security.encryption.XMLCipher.
> encryptData(XMLCipher.java:1134)
>     at org.apache.xml.security.encryption.XMLCipher.encryptElementContent(
> XMLCipher.java:907)
>     at org.apache.xml.security.encryption.XMLCipher.doFinal(
> XMLCipher.java:1038)
>     at org.apache.wss4j.dom.message.WSSecEncrypt.encryptElement(WSSecEncrypt.java:602)
> [wss4j-ws-security-dom.jar:2.0.1]
>     ... 51 more
>
> Cheers
> Alessio
>
> On 09/07/14 15:00, Daniel Kulp wrote:
>
>> Now that we have the new WSS4J releases, is there anything left
>> outstanding that would prevent releases of 2.6.15/2.7.12/3.0.1 later this
>> week or on Monday?   If not, I’ll plan on doing the releases one of those
>> days.
>>
>> I’m really looking forward to the 2.6.x release so we can drop that
>> version and start the 3.1 updates for Java7.   :-)
>>
>>
>
> --
> Alessio Soldano
> Web Service Lead, JBoss
>
>


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message