You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Daniel Kulp <dk...@apache.org> on 2014/07/09 15:00:13 UTC

Releases on Friday/Monday?

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.   :-)

-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com


Re: Releases on Friday/Monday?

Posted by Daniel Kulp <dk...@apache.org>.
I didn’t get to the releases today due to tracking down some other issues, test failures on the branches, etc….

Hopefully tomorrow….
Dan


On Jul 9, 2014, at 9:00 AM, Daniel Kulp <dk...@apache.org> 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.   :-)
> 
> -- 
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
> 

-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com


Re: Releases on Friday/Monday?

Posted by Alessio Soldano <as...@redhat.com>.
OK, thanks for the explanation Colm! Let's add this to the release notes.

I agree in retrospective it would have been better to apply changes for 
versions previous to 1.49 ;-)

Cheers
Alessio

On 14/07/14 12:46, Colm O hEigeartaigh wrote:
> 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 <as...@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
>>
>>
>


-- 
Alessio Soldano
Web Service Lead, JBoss


Re: Releases on Friday/Monday?

Posted by Colm O hEigeartaigh <co...@apache.org>.
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 <as...@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

Re: Releases on Friday/Monday?

Posted by Alessio Soldano <as...@redhat.com>.
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


Re: Releases on Friday/Monday?

Posted by Christian Schneider <ch...@die-schneider.net>.
 From my side the major concern is with the 
"org.apache.cxf.jaxrs.impl.tl.ThreadLocalProxy is not visible from class 
loader" issue.
I reproduced it with a simple jaxrs example.

So I think we should fix it before the 3.0.1 release. Is there already a 
jira issue for this?

Christian

Am 09.07.2014 15:00, schrieb Daniel Kulp:
> 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.   :-)
>


-- 
  
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com