Menu
▾
▴
perl-ldap-dev
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(200) |
Jun
(129) |
Jul
(184) |
Aug
(204) |
Sep
(106) |
Oct
(79) |
Nov
(72) |
Dec
(54) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(83) |
Feb
(123) |
Mar
(84) |
Apr
(184) |
May
(106) |
Jun
(111) |
Jul
(104) |
Aug
(91) |
Sep
(59) |
Oct
(99) |
Nov
(100) |
Dec
(37) |
| 2002 |
Jan
(148) |
Feb
(88) |
Mar
(85) |
Apr
(151) |
May
(80) |
Jun
(110) |
Jul
(85) |
Aug
(43) |
Sep
(64) |
Oct
(89) |
Nov
(59) |
Dec
(42) |
| 2003 |
Jan
(129) |
Feb
(104) |
Mar
(162) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
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 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: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: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: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: 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: 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: 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: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: Chris R. <Chr...@me...> - 2000-05-10 11:26:52
|
On Wed, 10 May 2000 11:48:02 BST, Stuart Squibb wrote: > I realise that this is not strictly a perl-ldap issue, but given the breadth > of LDAP/X.500 knowledge available on the list I thought I'd ask here. > > One of the attributes we currently store in our Exchange server is an X.400 > address. Current we use textencodedoraddress. A 'standard' with our > organisation nationally is to use mhs-or-addresses. Can anyone enlighten me > as to what this should look like? I know it is defined in X.402, but is > there an 'easy' description I can use to implement this on an LDAP server? > > Thanks, > > Stuart. > > Stuart Squibb > IT Systems Manager > Isle of Wight Health Authority > 01983 535440 (Direct Line) > > The text encoding should look roughly the same as you use for the textEncodedORAddress attribute. The difference between mhsORAddresses and textEncodedblahblah is that the former is only defined to have an equality matching rule, whereas since the latter is a string, substring matches are permitted. And of course the directory should barf if you try to enter a bogus mhsORAddress... The text encoding is defined in RFC 1327. Section 4.2 looks like a good place to start. If your names have printable and teletex alternatives, then the encoding of these is ... bizarre ... I blame the author (my boss :-) Cheers, Chris |
|
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: Stuart S. <Stu...@iw...> - 2000-05-10 10:49:14
|
I realise that this is not strictly a perl-ldap issue, but given the breadth of LDAP/X.500 knowledge available on the list I thought I'd ask here. One of the attributes we currently store in our Exchange server is an X.400 address. Current we use textencodedoraddress. A 'standard' with our organisation nationally is to use mhs-or-addresses. Can anyone enlighten me as to what this should look like? I know it is defined in X.402, but is there an 'easy' description I can use to implement this on an LDAP server? Thanks, Stuart. Stuart Squibb IT Systems Manager Isle of Wight Health Authority 01983 535440 (Direct Line) |
|
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: Pythagoras W. <py...@ec...> - 2000-05-10 08:47:35
|
On Tue, May 09, 2000 at 05:10:16PM +0100, Graham Barr wrote: :CVS, see http://sourceforge.net/cvs/?group_id=5050 : :You will also need the latest Convert::ASN (also on sourceforge) :as this highlighted a problem. Looks good. My previously failing tests all pass now. -- 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: Charlie M. <cha...@mw...> - 2000-05-09 21:26:19
|
Corrie Sudol wrote: > > Hi! My name is Corrie from Aetea. Complaints about the SPAM from the aggressive recruiter should be directed to the folks below. ab...@uu..., re...@ae..., in...@ae..., in...@ae..., in...@ae..., cs...@ae..., hs...@ae..., fsh...@ae..., cb...@ae..., pos...@ae..., web...@ae..., ash...@ae... |
|
From: Eric S. J. <es...@ha...> - 2000-05-09 21:14:33
|
----- Original Message ----- From: "Mark Wilcox" <mew...@un...> To: "Corrie Sudol" <CS...@Ae...> Cc: <per...@ma...> Sent: Tuesday, May 09, 2000 4:53 PM Subject: Re: (no subject) > What's worse SPAM or SPAM from clueless recruiters who can't tell a > listserv from a real person? I think is merely confirms that technical recruiter is an oxymoron... |
|
From: Clif H. <cl...@di...> - 2000-05-09 21:09:33
|
It gave me a good laugh, so I guess it was good for something. If their recruiter is this clueless would you want to work for the company they represent. Clif > > What's worse SPAM or SPAM from clueless recruiters who can't tell a > listserv from a real person? > > Mark > > On Tue, 9 May 2000, Corrie Sudol wrote: > > > Hi! My name is Corrie from Aetea. I saw your name on the internet. We > > currently have an opportunity available at a Major Pharmaceutical > > Corporation in the Princeton New Jersey area for a Senior PERL Developer. > > This candidate will design a Universal ID Generation System that will serve > > as a component of the Enterprise Meta Directory. Using LDAP, candidates > > will create information in and pull information out of a directory, write > > applications, receive information and store information. > > If you are interested and would like to discuss this opportunity further, > > please attach a copy of your resume in word format and a number where you > > could be contacted at. > > Thank you. > > > > > > Corrie Sudol > > Technical Recruiter > > cs...@ae... > > AETEA Information Technology, Inc. > > 732-326-9000 ext. 249, fax 732-326-9022 > > > > Visit us on the Web at http://www.aetea.com > > > > > > > > > > > > > Regards, Clif Harden INTERNET: c-h...@ti... Texas Instruments |
|
From: Mark W. <mew...@un...> - 2000-05-09 20:55:35
|
What's worse SPAM or SPAM from clueless recruiters who can't tell a listserv from a real person? Mark On Tue, 9 May 2000, Corrie Sudol wrote: > Hi! My name is Corrie from Aetea. I saw your name on the internet. We > currently have an opportunity available at a Major Pharmaceutical > Corporation in the Princeton New Jersey area for a Senior PERL Developer. > This candidate will design a Universal ID Generation System that will serve > as a component of the Enterprise Meta Directory. Using LDAP, candidates > will create information in and pull information out of a directory, write > applications, receive information and store information. > If you are interested and would like to discuss this opportunity further, > please attach a copy of your resume in word format and a number where you > could be contacted at. > Thank you. > > > Corrie Sudol > Technical Recruiter > cs...@ae... > AETEA Information Technology, Inc. > 732-326-9000 ext. 249, fax 732-326-9022 > > Visit us on the Web at http://www.aetea.com > > > > > |
|
From: Corrie S. <CS...@Ae...> - 2000-05-09 20:50:37
|
Hi! My name is Corrie from Aetea. I saw your name on the internet. We currently have an opportunity available at a Major Pharmaceutical Corporation in the Princeton New Jersey area for a Senior PERL Developer. This candidate will design a Universal ID Generation System that will serve as a component of the Enterprise Meta Directory. Using LDAP, candidates will create information in and pull information out of a directory, write applications, receive information and store information. If you are interested and would like to discuss this opportunity further, please attach a copy of your resume in word format and a number where you could be contacted at. Thank you. Corrie Sudol Technical Recruiter cs...@ae... AETEA Information Technology, Inc. 732-326-9000 ext. 249, fax 732-326-9022 Visit us on the Web at http://www.aetea.com |
|
From: Graham B. <gb...@po...> - 2000-05-09 16:12:23
|
On Tue, May 09, 2000 at 09:10:55AM +0100, Chris Ridd wrote:
> On Tue, 09 May 2000 07:49:30 BST, Graham Barr wrote:
> > On Mon, May 08, 2000 at 10:40:44PM -0700, Pythagoras Watson wrote:
> > > I have attached a script that can be used to cause this problem.
> > > Basically, the script sits between your client and the LDAP server.
> > > Client requests are sent to the server. Server responses are sent to
> > > the client, but are split into small packets that arrive slowly. This
> > > causes asn_recv() to enter this "if" statement:
> > > 74 if ($len > length $buf) {
> > > 75 # Cannot get whole element
> > > 76 $_[1]='';
> > > 77 return $peer;
> > > 78 }
> >
> > While I would agree that this would cause the problem with asn_recv, it does
> > not explain why scripts hang when we use asn_read instead of asn_recv.
> >
> > If I could fix that I would just change back to using read instead
> > of recv which is what previous versions of Net::LDAP use.
>
> That would certainly make it easier to get LDAPS working again...
Hint, hint.
OK, I have changed it. The latest is available from the sourceforge
CVS, see http://sourceforge.net/cvs/?group_id=5050
You will also need the latest Convert::ASN (also on sourceforge) as this
highlighted a problem.
Graham.
|
|
From: Chris R. <Chr...@me...> - 2000-05-09 15:30:43
|
On Tue, 09 May 2000 15:57:42 BST, Reda Bouarich wrote: > > Hello all, > I would like to know if it is posssible (using LDIF for instance) to modify > an attribute "multivalued" value. > Example: > > the attribute X is multivalued > X = A > = B > = C > and i would like to modify that to > X = A > = B > = D > > > Thank you. > regards, > Reda Bouatrich > Compaq France > > LDAP permits you to remove individual values of an attribute (remove by value) as well as removing an entire attribute. So yes, you should be able to do this. Something like the following LDIF fragment should work. dn: cn=Ty Coon,o=Yoyodyne Corp,c=US changetype: modify add: X X: D - delete: X X: C Cheers, Chris |
|
From: Graham B. <gb...@po...> - 2000-05-09 15:22:41
|
On Tue, May 09, 2000 at 03:57:42PM +0100, Reda Bouarich wrote:
>
> Hello all,
> I would like to know if it is posssible (using LDIF for instance) to modify
> an attribute "multivalued" value.
> Example:
>
> the attribute X is multivalued
> X = A
> = B
> = C
> and i would like to modify that to
> X = A
> = B
> = D
Yes this is possible, but you have to know the value of C
In LDIF you can do
dn: your-dn-here
changetype: modify
delete: X
X: C
add: X
X: D
or directly in perl using Net::LDAP
$ldap->modify(
dn => $dn,
delete => [
X => $C
],
add => [
X => $D
]
);
Graham.
|
|
From: Reda B. <Red...@di...> - 2000-05-09 14:58:47
|
Hello all,
I would like to know if it is posssible (using LDIF for instance) to modify
an attribute "multivalued" value.
Example:
the attribute X is multivalued
X = A
= B
= C
and i would like to modify that to
X = A
= B
= D
Thank you.
regards,
Reda Bouatrich
Compaq France
|
|
From: Chris R. <Chr...@me...> - 2000-05-09 08:13:44
|
On Tue, 09 May 2000 07:49:30 BST, Graham Barr wrote:
> On Mon, May 08, 2000 at 10:40:44PM -0700, Pythagoras Watson wrote:
> > I have attached a script that can be used to cause this problem.
> > Basically, the script sits between your client and the LDAP server.
> > Client requests are sent to the server. Server responses are sent to
> > the client, but are split into small packets that arrive slowly. This
> > causes asn_recv() to enter this "if" statement:
> > 74 if ($len > length $buf) {
> > 75 # Cannot get whole element
> > 76 $_[1]='';
> > 77 return $peer;
> > 78 }
>
> While I would agree that this would cause the problem with asn_recv, it does
> not explain why scripts hang when we use asn_read instead of asn_recv.
>
> If I could fix that I would just change back to using read instead
> of recv which is what previous versions of Net::LDAP use.
That would certainly make it easier to get LDAPS working again...
Chris
|
|
From: Graham B. <gb...@po...> - 2000-05-09 08:00:11
|
On Mon, May 08, 2000 at 10:40:44PM -0700, Pythagoras Watson wrote:
> I have attached a script that can be used to cause this problem.
> Basically, the script sits between your client and the LDAP server.
> Client requests are sent to the server. Server responses are sent to
> the client, but are split into small packets that arrive slowly. This
> causes asn_recv() to enter this "if" statement:
> 74 if ($len > length $buf) {
> 75 # Cannot get whole element
> 76 $_[1]='';
> 77 return $peer;
> 78 }
While I would agree that this would cause the problem with asn_recv, it does
not explain why scripts hang when we use asn_read instead of asn_recv.
If I could fix that I would just change back to using read instead
of recv which is what previous versions of Net::LDAP use.
Graham.
PS: Thanks for the patch.
|
7902 messages has been excluded from this view by a project administrator.
