Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (athena.apache.org: domain of elecharny@gmail.com
 designates 74.125.82.44 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:reply-to:user-agent:mime-version:to:subject
         :references:in-reply-to:content-type:content-transfer-encoding;
        b=ohvNz+PYifSvdXILjCVeGUUFt36jGMcvzp5R5FqpcBvR8NY/MF6nIOzku2yQr1GFHM
         BmD9wzX9cRYKbEBfMHsEtq6DagtPsrzVpslxdkLy3aIBIl1vu3rIlesK+/UMowjyhoMz
         j8YmUnnC6I37T/vyfB2qsfL1i7BqFZ6eYpxFU=
Message-ID: <4CE7F2E1.1030802@gmail.com>
Date: Sat, 20 Nov 2010 17:10:09 +0100
From: Emmanuel Lecharny <elecharny@gmail.com>
Reply-To: elecharny@apache.org
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: Disable Kerberos modules and tests (was: Build failed in Hudson:
 dir-studio-jdk15-ubuntu-deploy #97)
References: <AANLkTinROy9NeNbhEdxokh2ionf7H07L-BjEjRTA+buZ@mail.gmail.com>
 <4CE79623.3020505@gmail.com> <4CE79CDD.40109@apache.org>
 <4CE7A36A.8000808@gmail.com> <4CE7A884.2070803@apache.org>
 <4CE7C912.7000702@gmail.com> <4CE7E943.8030309@apache.org>
In-Reply-To: <4CE7E943.8030309@apache.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 11/20/10 4:29 PM, Felix Knecht wrote:
> On 11/20/2010 02:11 PM, Emmanuel Lecharny wrote:
>> On 11/20/10 11:52 AM, Felix Knecht wrote:
>>>> It's most certainly an issue with the way we deal with BitString. 
>>>> Th pb
>>>> is that the new codec uses the modified version, so if I revert, it 
>>>> will
>>>> break the new codec.
>>>>
>>>> I'll try to understand why the old code is not happy with the perfect
>>>> code I injected in the kerberos part ;)
>>>
>>>
>>> My guess is that the getBytes(int xxx) has something to do with it. In
>>> comparison to the code before it adds some additional information in
>>> the [0] index (A first byte containing the number of unused bits is
>>> added) whereas in the old code it just started without additional
>>> information.
>> Which is wrong. I'm looking at some PDU Stefan captured for me, and the
>> KdcOptions are really encoded in 5 bytes, which means the byte
>> containing the unused bytes is present :
>> 0xA0 0x07
>> 0x03 0x05 0x00 0x00 0x00 0x00 0x00
>> ^^^^
>> the unused bits.
>
> AbstractKerberosFlags isn't aware at every place, that there have 5 
> bytes to be in the array, but extends and used methods of BitString:
>
> /**
>  * Modify a byte array to an integer value
>  * @param bytes The 4 bytes byte array to transform.
>  */
> public void setFlags( byte[] bytes )
> {
>     if ( (bytes== null ) || ( bytes.length != 4 ) )
>     {
>         value = -1;
>     }
>     value = ( ( bytes[0] & 0x00F ) << 24 ) | ( ( bytes[1] & 0x00FF ) 
> << 16 ) | ( ( bytes[2] & 0x00FF ) << 8 ) | ( 0x00FF & bytes[3] );
>         setData( bytes );
>     }
>
> This will include the first byte ([0]) for value calculation but 
> BitString will use the same value afterwards to set the unused bits 
> value. -> An array of length 5 instead of length 4 should be used.
>
>
>
> public static byte[] getBytes( int flags )
> {
>     return new byte[]{
>         (byte)( flags >>> 24),
>         (byte)( ( flags >> 16 ) & 0x00ff ),
>         (byte)( ( flags >> 8 ) & 0x00ff ),
>         (byte)( flags & 0x00ff ) };
> }
>
> This method doesn't returns as well a byte array not containing the 
> byte[0] representing the unused bits whereas the method
>
> public byte[] getBytes()
> {
>     return getData();
> }
>
> delivers the byte array comming inherited from BitString containing 
> the 'unused bits' byte.
>
> Is it correct, that ALL classes extended BitString must use a byte 
> array of length 5?
If there are 32 bits, yes. But it depends on the encoding. In pure DER, 
we don't necessarily uses all the bytes, we use just enough bytes to 
store the bits up to the last 1. So it can be from 2 to 5 bytes. 
Complicated ...

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com