[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Classpath-inetlib] Possible bug in gnu.inet.util.BASE64

From: Jorge Barreiro
Subject: Re: [Classpath-inetlib] Possible bug in gnu.inet.util.BASE64
Date: Fri, 8 Jan 2010 19:13:28 +0100
User-agent: KMail/1.9.9

O Xoves, 26 de Novembro de 2009 ás 09:40:53 Chris Burdess escribiu:
> Jorge Barreiro wrote:
> > I've found what seems to be a bug in the gnu.inet.util.BASE64 class: The
> > encoding function never appends the '=' padding characters. I sent this
> > mail first because there's some code in the class dealing with this, but
> > it's commented, so I don't know if this is intentional. In addition, that
> > library wasn't updated in years. Is it deprecated? Is there any
> > alternative?
> >
> > This class is used in the gnu javax.mail implementation, and is
> > preventing me from authenticating with a server.
> >
> > If you confirm me that the padding characters should be there and this is
> > a bug, I can make and send you a patch.
> I'm pretty sure this was an old bug that was fixed a while ago. Check that
> you're using the most up-to-date release.
> If it's still not working, please feel free to send me a patch against CVS
> HEAD. --
> Chris Burdess

Hello again,

sorry for the delay. I've been busy, then the holidays...

I've checked the CVS head code and I've found the error: the length of the
target array was wrong. I've checked the history of this class too. It seems 
that this issue was already detected, but the fix was wrong and was reverted.

I attach my patch (base64len.patch), which corrects the length of the target 
array (so there's no need to truncate, I've removed that code), and 
uncommented the code to fill with padding simbols again.

The second patch (base64dec.patch) is for the decode function. That function 
works ok, but I detected something odd with the target array length. First, a 
buffer with an arbitrary length is created, then it's truncated to the 
correct size. But the length of the target array can be known beforehand, 
there's no need to truncate the array at the end.

With this patch, the method will throw an arrayoutofindex exception if the 
given array length is not divisible by 4, which I think is ok, since the 
result would be incorrect.

Please, let me know if you are going to apply the patch (specially the first 

Attachment: base64len.patch
Description: Text Data

Attachment: base64dec.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]