You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@santuario.apache.org by Chris Harris <ch...@thunderhead.com> on 2007/01/24 13:46:23 UTC

BufferOverflowException when encrypting large documents

Hi all,

 

We have a requirement to encrypt large xml documents and our
experiencing the following error:

 

Caused by: java.nio.BufferOverflowException

            at
java.nio.charset.CoderResult.throwException(CoderResult.java:259)

            at
java.lang.StringCoding$CharsetSE.encode(StringCoding.java:340)

            at java.lang.StringCoding.encode(StringCoding.java:374)

            at java.lang.StringCoding.encode(StringCoding.java:380)

            at java.lang.String.getBytes(String.java:590)

            at
org.apache.xml.security.encryption.XMLCipher.encryptData(Unknown Source)

            at
org.apache.xml.security.encryption.XMLCipher.encryptElementContent(Unkno
wn Source)

            at
org.apache.xml.security.encryption.XMLCipher.doFinal(Unknown Source)

            at
org.apache.ws.security.message.WSSecEncrypt.doEncryption(WSSecEncrypt.ja
va:455)

 

 

After doing some research, I discovered that this is actually being
caused by a bug in the JVM:

 

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4949631

 

The sun bug log contains a number of workarounds however to get around
this issue the XMLCipher class would need to change the String before it
calls getBytes. I have attached a patch version of XMLCipher along with
a String utility class.

 

Is there any chance of getting this into the next release of the
security library?

 

Regards,

 

Chris.

Re: BufferOverflowException when encrypting large documents

Posted by Sean Mullan <Se...@Sun.COM>.
Chris Harris wrote:
> Hi all,
> 
>  
> 
> We have a requirement to encrypt large xml documents and our 
> experiencing the following error:
> 
>  
> 
> Caused by: java.nio.BufferOverflowException
> 
>             at 
> java.nio.charset.CoderResult.throwException(CoderResult.java:259)
> 
>             at 
> java.lang.StringCoding$CharsetSE.encode(StringCoding.java:340)
> 
>             at java.lang.StringCoding.encode(StringCoding.java:374)
> 
>             at java.lang.StringCoding.encode(StringCoding.java:380)
> 
>             at java.lang.String.getBytes(String.java:590)
> 
>             at 
> org.apache.xml.security.encryption.XMLCipher.encryptData(Unknown Source)
> 
>             at 
> org.apache.xml.security.encryption.XMLCipher.encryptElementContent(Unknown 
> Source)
> 
>             at 
> org.apache.xml.security.encryption.XMLCipher.doFinal(Unknown Source)
> 
>             at 
> org.apache.ws.security.message.WSSecEncrypt.doEncryption(WSSecEncrypt.java:455)
> 
>  
> 
>  
> 
> After doing some research, I discovered that this is actually being 
> caused by a bug in the JVM:
> 
>  
> 
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4949631
> 
>  
> 
> The sun bug log contains a number of workarounds however to get around 
> this issue the XMLCipher class would need to change the String before it 
> calls getBytes. I have attached a patch version of XMLCipher along with 
> a String utility class.
> 
>  
> 
> Is there any chance of getting this into the next release of the 
> security library?

Yes, I don't think it should be a problem. Do you mind opening a bug 
(and attach your patch) so we can track this at: 
http://issues.apache.org/bugzilla/

And thanks for the patch!

--Sean