From dev-return-35588-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Fri Nov 12 09:52:42 2010 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 59463 invoked from network); 12 Nov 2010 09:52:41 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 12 Nov 2010 09:52:41 -0000 Received: (qmail 79875 invoked by uid 500); 12 Nov 2010 09:53:13 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 79680 invoked by uid 500); 12 Nov 2010 09:53:12 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 79673 invoked by uid 99); 12 Nov 2010 09:53:12 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Nov 2010 09:53:12 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of elecharny@gmail.com designates 74.125.82.178 as permitted sender) Received: from [74.125.82.178] (HELO mail-wy0-f178.google.com) (74.125.82.178) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Nov 2010 09:53:04 +0000 Received: by wyb33 with SMTP id 33so1578111wyb.37 for ; Fri, 12 Nov 2010 01:52:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=c2QaugYcKqOYtDOErvz3+dMePmjnK3fh+UpCP5Ig+Uw=; b=oBrLWKs/Eui1XVzkDHqABzVBeCa0NSnhlhrVCrm/SB8NgvJq2/b+SZUSDd9XAw64JA fPnIERX4cBxwDbSO4cadFwnut5n0LeMqQUj0g36IDU3CEDdBv1/hCyMexC1PFdA+LdJU BcNguY6YgX2jzOcCpPZk1ABZVLL5NLWUspGEw= 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 :content-type:content-transfer-encoding; b=Zk1s5/DSMEXrYQKamQqEDyZUQx2Sa0cGoZbhQTkalrfRwVdprG8RbOOBScNPuZeQ+6 mUUeNig8EjC3g81RWTynVqa9Z1FSe7rbEpuCHED4wM6KbeDfN8wFYkSsA7mICDQ+sK2h m27m/wK0fbiZMnT73zr44Xpf+ECBnObM8bl8o= Received: by 10.227.152.8 with SMTP id e8mr2104788wbw.175.1289555562645; Fri, 12 Nov 2010 01:52:42 -0800 (PST) Received: from emmanuel-lecharnys-MacBook-Pro.local (ran75-1-78-192-106-184.fbxo.proxad.net [78.192.106.184]) by mx.google.com with ESMTPS id b30sm2636023wbb.22.2010.11.12.01.52.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 12 Nov 2010 01:52:41 -0800 (PST) Message-ID: <4CDD0E68.9010804@gmail.com> Date: Fri, 12 Nov 2010 10:52:40 +0100 From: Emmanuel Lecharny 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 Subject: Trunk failures : status Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi guys, first, thanks Felix for having fixed the tests I broke with the change I did in the error message. This morning I checked the reason why we have some failures in protocol-kerberos. Stefan is right : some changes in the BitString class are the reason for those breakage. Can we revert ? No : the BitString class (and the Value.encode( BitString ) method ) are badly broken. The BitString BER encoding requires that the number of unused bits are present in the encoded value, something that is not correctly handled by the original class. Typically, the order on which the bits are stored is wrong in the previous BitString. BER encoding stipulate that the bits are stored from left to right, bit 0 being the left most (this is purely a convention). So the value 48 (decimal) will be stored as 0000 1100 with the last two 0s being insignificant in BER. One other thing is that the ending 0's can be omitted, as we can specify the number of unused bits (which can be 0 or bits that don't count). For instance, let's say we want to define 6 bits, and the value we have is 7 (0x07). This can be stored as : 0x03 0x02 0x02 0xE0 (0x03 = BitString tag, 0x02 = length, number of bytes to encode the value, 0x02 = number of unused bits, the last two, and 0xE0 = b'111000', which is 0x07 as the bits are ordered from left to right). or as : 0x03 0x03 0x05, 0xE0 (0x03 = BitString tag, 0x02 = length, number of bytes to encode the value, 0x05 = number of unused bits, the last five, as we have to insignificant bits, plus 3 bits set to 0, and 0xE = b'111', which is 0x07 as the bits are ordered from left to right) In DER (used for Kerberos), the encoding is strict : if a BitString has 0s on the right, then they are not encoded. So if we have a field of bits containing 32 bits, with only the bit 0 and 1 set, then the encoded BitString will be : 0x03 0x02 0x06 0xC0 0x05 -> BitString tag 0x02 -> Number of bytes needed to encode the value 0x06 : 6 bits are unused in the last encoded byte 0xC0 : b'11', the current BitString value. In BER, we could encode that in many ways : 0x03 0x02 0x06 0xC0 (as in DER) or 0x03 0x02 0x00 0xC0 (no unused bits) or 0x03 0x05 0x00 0xC0 0x00 0x00 0x00 (full 32 bits and no unused bits) That's a bit insane :/ -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com