Menu
▾
▴
perl-ldap-dev
|
From: Pythagoras W. <py...@ec...> - 2000-05-10 10:00:09
|
This appears to be a decoding error on Net::LDAP's part. When the operation number (5th byte of response) reaches 128 (0x80), the resulting message code changes to two. To wit: searching 126 ... 30 38 02 01 7F 64 33 04 2F 75 69 64 3D 70 79 2C 08...d3./uid=py, ... 0002 02 1: INTEGER = 127 ... searching 127 ... 30 38 02 01 80 64 33 04 2F 75 69 64 3D 70 79 2C 08...d3./uid=py, ... 0002 02 1: INTEGER = -128 search failed: 2 See the attached script and full output for more details. -- Py (Amateur Radio: KF6WFP) -- 3.141592653589793238462643383... Pythagoras Watson -- "Live long and may all your kernels pop." === py...@cs... ==== http://www.ecst.csuchico.edu/~py/ === |
|
From: Graham B. <gb...@po...> - 2000-05-10 10:57:09
|
On Wed, May 10, 2000 at 02:59:37AM -0700, Pythagoras Watson wrote: > This appears to be a decoding error on Net::LDAP's part. When the > operation number (5th byte of response) reaches 128 (0x80), the > resulting message code changes to two. Yes there was a bug in Convert::ASN1::IO.pm when $length & 0x80 was true. The CVS on sourceforge has a fix for this. It seems some people have verified this, so I will put together new releases of perl-ldap and Convert::ASN1 soon. Graham. |
|
From: Kurt D. Z. <Ku...@Op...> - 2000-05-10 12:30:54
|
At 02:59 AM 5/10/00 -0700, Pythagoras Watson wrote: >This appears to be a decoding error on Net::LDAP's part. When the >operation number (5th byte of response) reaches 128 (0x80), the >resulting message code changes to two. > >To wit: > searching 126 > ... > 30 38 02 01 7F 64 33 04 2F 75 69 64 3D 70 79 2C 08...d3./uid=py, > ... > 0002 02 1: INTEGER = 127 > ... > searching 127 > ... > 30 38 02 01 80 64 33 04 2F 75 69 64 3D 70 79 2C 08...d3./uid=py, > ... > 0002 02 1: INTEGER = -128 > search failed: 2 > 02 01 7F == 127 02 01 80 == -128 02 INTEGER 01 length of 1 xx 2-complement base-256 value From RSA's Layman's Guide: > Some example BER encodings (which also happen to be DER > encodings) are given in Table 3. > > Integer BER encoding > value > 0 02 01 00 > 127 02 01 7F > 128 02 02 00 80 > 256 02 02 01 00 > -128 02 01 80 > -129 02 02 FF 7F Appears to me that your server is broke. |
|
From: Graham B. <gb...@po...> - 2000-05-10 12:41:51
|
Good catch. I did not read the original message close enough Graham. On Wed, May 10, 2000 at 05:30:13AM -0700, Kurt D. Zeilenga wrote: > At 02:59 AM 5/10/00 -0700, Pythagoras Watson wrote: > >This appears to be a decoding error on Net::LDAP's part. When the > >operation number (5th byte of response) reaches 128 (0x80), the > >resulting message code changes to two. > > > >To wit: > > searching 126 > > ... > > 30 38 02 01 7F 64 33 04 2F 75 69 64 3D 70 79 2C 08...d3./uid=py, > > ... > > 0002 02 1: INTEGER = 127 > > ... > > searching 127 > > ... > > 30 38 02 01 80 64 33 04 2F 75 69 64 3D 70 79 2C 08...d3./uid=py, > > ... > > 0002 02 1: INTEGER = -128 > > search failed: 2 > > > > 02 01 7F == 127 > 02 01 80 == -128 > > 02 INTEGER > 01 length of 1 > xx 2-complement base-256 value > > >From RSA's Layman's Guide: > > Some example BER encodings (which also happen to be DER > > encodings) are given in Table 3. > > > > Integer BER encoding > > value > > 0 02 01 00 > > 127 02 01 7F > > 128 02 02 00 80 > > 256 02 02 01 00 > > -128 02 01 80 > > -129 02 02 FF 7F > > Appears to me that your server is broke. > |
|
From: Kurt D. Z. <Ku...@Op...> - 2000-05-10 12:47:49
|
At 01:39 PM 5/10/00 +0100, Graham Barr wrote:
>Good catch. I did not read the original message close enough
BTW, OpenLDAP liblber includes a couple of simple test
programs. You might want to mimic them for testing
purposes.
% echo "128" | ./etest i | ./dtest i
encode: start
encode: i
encode: end
ber_get_next
ber_get_next: tag 0x30 len 4 contents:
ber_dump: buf 0x8050030, ptr 0x8050030, end 0x8050034
02 02 00 80
decode: message tag 0x30 and length 4
decode: format i
ber_scanf fmt (i) ber:
ber_dump: buf 0x8050030, ptr 0x8050030, end 0x8050034
02 02 00 80
% echo "-128" | ./etest i | ./dtest i
encode: start
encode: i
encode: end
ber_get_next
ber_get_next: tag 0x30 len 3 contents:
ber_dump: buf 0x8050030, ptr 0x8050030, end 0x8050033
02 01 80
decode: message tag 0x30 and length 3
decode: format i
ber_scanf fmt (i) ber:
ber_dump: buf 0x8050030, ptr 0x8050030, end 0x8050033
02 01 80
|
|
From: Chris R. <Chr...@me...> - 2000-05-10 12:56:08
|
On Wed, 10 May 2000 05:30:13 PDT, "Kurt D. Zeilenga" wrote: > At 02:59 AM 5/10/00 -0700, Pythagoras Watson wrote: > >This appears to be a decoding error on Net::LDAP's part. When the > >operation number (5th byte of response) reaches 128 (0x80), the > >resulting message code changes to two. > > > >To wit: > > searching 126 > > ... > > 30 38 02 01 7F 64 33 04 2F 75 69 64 3D 70 79 2C 08...d3./uid=py, > > ... > > 0002 02 1: INTEGER = 127 > > ... > > searching 127 > > ... > > 30 38 02 01 80 64 33 04 2F 75 69 64 3D 70 79 2C 08...d3./uid=py, > > ... > > 0002 02 1: INTEGER = -128 > > search failed: 2 > > > > 02 01 7F == 127 > 02 01 80 == -128 > > 02 INTEGER > 01 length of 1 > xx 2-complement base-256 value > > From RSA's Layman's Guide: > > Some example BER encodings (which also happen to be DER > > encodings) are given in Table 3. > > > > Integer BER encoding > > value > > 0 02 01 00 > > 127 02 01 7F > > 128 02 02 00 80 > > 256 02 02 01 00 > > -128 02 01 80 > > -129 02 02 FF 7F > > Appears to me that your server is broke. > Kurt is quite right. X.208 (BER) says: ------------ 8 Encoding of an integer value 8.1 The encoding of an integer value shall be primitive. The contents octets shall consist of one or more octets. 8.2 If the contents octets of an integer value encoding consist of more than one octet, then the bits of the first octet and bit 8 of the second octet a) shall not all be ones; and b) shall not all be zero. Note - These rules ensure that an integer value is always encoded in the smallest possible number of octets. 8.3 The contents octets shall be a two's, complement binary number equal to the integer value, and consisting of bits 8 to 1 of the first octet, followed by bits 8 to 1 of the second octet, followed by bits 8 to 1 of each octet in turn up to and including the last octet of the contents octets. ------------ So 0x80 is -128. This is a common encoding error made by Microsoft software. (Read http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt and search for INTEGER.) Are you using an MS server, Pythagoras? Cheers, Chris |
|
From: Graham B. <gb...@po...> - 2000-05-10 13:07:38
|
On Wed, May 10, 2000 at 01:52:07PM +0100, Chris Ridd wrote: > So 0x80 is -128. > > This is a common encoding error made by Microsoft software. (Read > http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt and search for > INTEGER.) > > Are you using an MS server, Pythagoras? Given that the messageID is supposed to be non-negative. I wonder if it is worth adding a catch for negative ones and fix them. Graham. |
|
From: Kurt D. Z. <Ku...@Op...> - 2000-05-10 13:20:25
|
At 02:05 PM 5/10/00 +0100, Graham Barr wrote: >On Wed, May 10, 2000 at 01:52:07PM +0100, Chris Ridd wrote: >> So 0x80 is -128. >> >> This is a common encoding error made by Microsoft software. (Read >> http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt and search for >> INTEGER.) >> >> Are you using an MS server, Pythagoras? > >Given that the messageID is supposed to be non-negative. I wonder if it >is worth adding a catch for negative ones and fix them. You might consider putting something ABOVE the BER/DER level. However, I cringe. OpenLDAP and Mozilla SDKs do not do such munging of peer provided values. Kurt |
|
From: Graham B. <gb...@po...> - 2000-05-10 13:22:52
|
On Wed, May 10, 2000 at 06:19:29AM -0700, Kurt D. Zeilenga wrote: > At 02:05 PM 5/10/00 +0100, Graham Barr wrote: > >On Wed, May 10, 2000 at 01:52:07PM +0100, Chris Ridd wrote: > >> So 0x80 is -128. > >> > >> This is a common encoding error made by Microsoft software. (Read > >> http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt and search for > >> INTEGER.) > >> > >> Are you using an MS server, Pythagoras? > > > >Given that the messageID is supposed to be non-negative. I wonder if it > >is worth adding a catch for negative ones and fix them. > > You might consider putting something ABOVE the BER/DER level. > However, I cringe. OpenLDAP and Mozilla SDKs do not do such > munging of peer provided values. Ah, but it is a return of the value I send. So just avoid values where value & 0x80808080 is non-zero Graham. |
|
From: Kurt D. Z. <Ku...@Op...> - 2000-05-10 13:43:26
|
At 02:20 PM 5/10/00 +0100, Graham Barr wrote: >Ah, but it is a return of the value I send. So just avoid values where >value & 0x80808080 is non-zero You could do something like: msgid += msgid & 0x80808080; But I wouldn't as this won't fix all the other hosed encodings. I prefer to get Microsoft to properly fix their products. This can be done through interoperability/certification testing programs. I'll make a point of adding appropriate tests to the Basic Interoperability Test Suite (BLITS). http://www.opengroup.org/directory/mats/blits23/blits23.htm Also, note, that I know of no LDAP SDK which attempts to workaround such issues. Kurt |
|
From: Graham B. <gb...@po...> - 2000-05-10 13:50:36
|
On Wed, May 10, 2000 at 06:42:41AM -0700, Kurt D. Zeilenga wrote: > At 02:20 PM 5/10/00 +0100, Graham Barr wrote: > >Ah, but it is a return of the value I send. So just avoid values where > >value & 0x80808080 is non-zero > > You could do something like: > msgid += msgid & 0x80808080; no that would not work, consider if msgid contained 0x7f80 > But I wouldn't as this won't fix all the other hosed encodings. True. > I prefer to get Microsoft to properly fix their products. So would I, but how long do you think that would take. > This > can be done through interoperability/certification testing programs. > I'll make a point of adding appropriate tests to the Basic > Interoperability Test Suite (BLITS). > > http://www.opengroup.org/directory/mats/blits23/blits23.htm > > Also, note, that I know of no LDAP SDK which attempts to workaround > such issues. That does not mean that Net::LDAP should not. Whats the point of perl-ldap attempting to be as portable as possible if there are servers, albeit broken servers, that it cannot communicate with. Graham. |
|
From: Kurt D. Z. <Ku...@Op...> - 2000-05-10 14:16:55
|
At 02:48 PM 5/10/00 +0100, Graham Barr wrote: >That does not mean that Net::LDAP should not. Of course. >Whats the point of perl-ldap attempting to be as portable as >possible if there are servers, albeit broken servers, that it >cannot communicate with. The reality is that you will not be able to communicate with broken servers. Broken encoding will break all kinds of things. Yes, you can workaround this particular case, but this doesn't necessarily mean it's a good idea. You should consider the overall impact of such a change. Does the change effect client developers? Yes. If I have an array of outstanding requests which I grown by one for every new async message I send, my code will break when msgid generated jumps over 128. Does the change effect server admins? Yes. They will see msgid jump from 127 to 129 and will likely wonder what happen to 128. Now, one could argue that client developers and server admins shouldn't assume msgid increment by one for every new request. But the fact they general do is good for debugging as such oddities should be clues as to what's going wrong, not normal circumstance. |
|
From: Graham B. <gb...@po...> - 2000-05-10 14:47:48
|
On Wed, May 10, 2000 at 07:16:13AM -0700, Kurt D. Zeilenga wrote: > Now, one could argue that client developers and server > admins shouldn't assume msgid increment by one for every > new request. But the fact they general do is good for > debugging as such oddities should be clues as to what's > going wrong, not normal circumstance. Well you will already be surprised with Net::LDAP there is no gaurantee that msgid will increment for any connection. All the RFC states is that the number must be unique among all outstanding requests. Graham. |
|
From: Pythagoras W. <py...@ec...> - 2000-05-10 20:33:05
|
On Wed, May 10, 2000 at 05:30:13AM -0700, Kurt D. Zeilenga wrote: :At 02:59 AM 5/10/00 -0700, Pythagoras Watson wrote: :>This appears to be a decoding error on Net::LDAP's part. When the :>operation number (5th byte of response) reaches 128 (0x80), the :>resulting message code changes to two. :> :>To wit: :> searching 126 :> ... :> 30 38 02 01 7F 64 33 04 2F 75 69 64 3D 70 79 2C 08...d3./uid=py, :> ... :> 0002 02 1: INTEGER = 127 :> ... :> searching 127 :> ... :> 30 38 02 01 80 64 33 04 2F 75 69 64 3D 70 79 2C 08...d3./uid=py, :> ... :> 0002 02 1: INTEGER = -128 :> search failed: 2 :> : : 02 01 7F == 127 : 02 01 80 == -128 : :02 INTEGER :01 length of 1 :xx 2-complement base-256 value Interesting and good to know. :>From RSA's Layman's Guide: :> Some example BER encodings (which also happen to be DER :> encodings) are given in Table 3. :> :> Integer BER encoding :> value :> 0 02 01 00 :> 127 02 01 7F :> 128 02 02 00 80 :> 256 02 02 01 00 :> -128 02 01 80 :> -129 02 02 FF 7F : :Appears to me that your server is broke. Always a possibility, although I get the same results against both Netscape Directory Server 3.X and OpenLDAP 1.2.3. Perhaps the problem is still in Net::LDAP. Specifically I note that the SENDING debug info (which I did not generate before) has (for the 127th search): 30 52 02 01 80 63 4D 04 29 6F 3D 43 61 6C 69 66 0R...cM.)o=Calif which I assume is also incorrect and is causing the server to return the same bad info. I note that both sent and received packets are encoded correctly when using Convert::BER. -- Py (Amateur Radio: KF6WFP) -- 3.141592653589793238462643383... Pythagoras Watson -- "Live long and may all your kernels pop." === py...@cs... ==== http://www.ecst.csuchico.edu/~py/ === |
|
From: Graham B. <gb...@po...> - 2000-05-11 06:23:24
|
On Wed, May 10, 2000 at 01:32:31PM -0700, Pythagoras Watson wrote: > :Appears to me that your server is broke. > > Always a possibility, although I get the same results against both > Netscape Directory Server 3.X and OpenLDAP 1.2.3. Perhaps the problem > is still in Net::LDAP. Specifically I note that the SENDING debug info > (which I did not generate before) has (for the 127th search): > 30 52 02 01 80 63 4D 04 29 6F 3D 43 61 6C 69 66 0R...cM.)o=Calif > which I assume is also incorrect and is causing the server to return > the same bad info. I note that both sent and received packets are > encoded correctly when using Convert::BER. It would seem the bug is in Convert::ASN1, I will try to look into this today. What version of perl are you using ? Graham. |
|
From: David B. <D.B...@ma...> - 2000-05-11 06:36:29
|
Graham,
perl:
"This is perl 5.005_03 built for i586-linux."
Also:
i586 linux 2.2.13 (SuSe 6.3).
perl_ldap 0.16 (1 week old from website)
Convert::ASN1-0.04
Convert::BER-1.31
LDAP server: Netware 5.0 SP4 with LDAP NLM's 3.02
(I'm not sure if it was me you were asking or Pythagoras Watson, but you
know now anyway)
David.
>It would seem the bug is in Convert::ASN1, I will try to look into this
>today.
>
>What version of perl are you using ?
>
>Graham.
>
>
>
>
--------------------------------------------------------------------
David Bussenschutt Email: D.B...@ma...
Senior Computing Support Officer & Systems Administrator/Programmer
Location: Griffith University. Information Technology Services
Brisbane Qld. Aust. (TEN bldg. rm 1.33) Ph:(07)38757079
--------------------------------------------------------------------
|
|
From: Graham B. <gb...@po...> - 2000-05-11 08:24:28
Attachments:
patch
|
On Thu, May 11, 2000 at 07:11:22AM +0100, Graham Barr wrote: > It would seem the bug is in Convert::ASN1, I will try to look into this > today. And here is a patch, it will be on sourceforge shortly. If people can test this and if all is OK I will do a perl-ldap and Convert::ASN release to CPAN Graham. |
|
From: Pythagoras W. <py...@ec...> - 2000-05-11 22:27:02
|
On Thu, May 11, 2000 at 09:22:14AM +0100, Graham Barr wrote: :On Thu, May 11, 2000 at 07:11:22AM +0100, Graham Barr wrote: :> It would seem the bug is in Convert::ASN1, I will try to look into :> this today. : :And here is a patch, it will be on sourceforge shortly. If people can :test this and if all is OK I will do a perl-ldap and Convert::ASN :release to CPAN My test cases pass now. The output looks good to me. :- $len++ unless not($msb) == not($neg); :+ $len++ if $neg ? !$msb : $msb; It took running this through perl a few times for me to figure out what the difference was. Truly insidious. I almost never use the "named" versions of operators, so I had forgotten about their lower precedence. -- Py (Amateur Radio: KF6WFP) -- 3.141592653589793238462643383... Pythagoras Watson -- "Live long and may all your kernels pop." === py...@cs... ==== http://www.ecst.csuchico.edu/~py/ === |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X