- openldap-bugs - openldap.org

Re: (ITS#8618) ldapsearch - unexpected behavior with
by arekkusu＠r42.ch 03 Mar '18

03 Mar '18

I was referring to best practice/RFC regarding what is a valid hostname. My example was intentionally provocative. I think rejecting hostname containing the '://' construct is actually a good idea. Those would be problematic for parsing and such broken hostname are unlikely to ever be use. Been reading a bit more (1) and I think internationalized domain are also not an issue as they have a ASCII representation. So the only real concern I can think of at this point is underscore. But I could be missing something... I am still not convinced about having addition verification beside: - What the DNS standard says (RFC2181) - Prohibiting hostname that would cause cause an issue with parsing ('://') Why do the 'host' and 'dig' command does not seem to place any restriction when querying for A records ? (would be interested to see how other software handle this) Andew: Did you manage to find out why the behavior with '-h' option and both ' --h' and '-p' option was different ? Best, Alex (1) https://stackoverflow.com/questions/2180465/can-domain-name-subdomains-have- an-underscore-in-it PS: Andrew: In my client (evolution) your previous plain text email did show up as base64 encoded. (had to use 'base64 -d' to read them). I did not remember outlook making it so hard to send plain text email (!) On Sat, 2018-03-03 at 10:29 +0000, michael(a)stroeder.com wrote: > Alexandre Rosenberg wrote: > > Micheal, you are *right* about the man page saying _hostname_. Indeed > > OpenLDAP > > only accepting hostname as per best practice/RFC might be the most correct > > behavior. > > There is no relevant RFC or best practice, only the man-page. And the -h > and -p arguments come from the old UMich LDAP times. > > > However we can not change this behavior without breakable. consider: > > AFAICS backward compability has only be provided to those ancient Umich > or Netscape Directory tools. So IMO LDAP URI does not have to be accepted. > > > - Underscore are not that uncommon with Active Directory > > - What about > > - ... (probably more) > > If you want to fix something for 2.4.x to match what the man-page says > you could effectively reject LDAP URI by simply rejecting colons and > slashes. Those chars are never in even seriously broken hostnames. If > they were they would cause more interop issues anyway. > > > Therefore I believe such change could only be done in a major release. And > > at > > that point we might just remove the depreciated '-h' option altogether. > > Agreed. 2.5 release chould IMO simply remove options -h and -p. > > Ciao, Michael. > > >

1 0

RE: (ITS#8618) ldapsearch - unexpected behavior with
by andrew.lawrence＠siemens.com 03 Mar '18

03 Mar '18

I am using Outlook and in addition to sending messages with HTML by default= it also uses some kind of encoding if you select plain text. I have spent = most of the afternoon trying to turn this off and hopefully I have now been= successful. I followed the instructions to upload the patch (andrew-lawrence-180303.pa= tch) to ftp://openldap.org/incoming/. I am not sure if it was successful a= s I cannot see the contents of the folder. The attached file is derived from OpenLDAP Software. All of the modificatio= ns to OpenLDAP Software represented in the following patch(es) were develop= ed by Siemens Rail Automation Holdings Limited. Siemens Rail Automation Hol= dings Limited has not assigned rights and/or interest in this work to any p= arty. I, Andrew Lawrence am authorized by Siemens Rail Automation Holdings = Limited, my employer, to release this work under the following terms. Siemens Rail Automation Holdings Limited hereby place the following modific= ations to OpenLDAP Software (and only these modifications) into the public = domain. Hence, these modifications may be freely used and/or redistributed = for any purpose with or without attribution and/or other notice. Cheers, Andy -----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: 02 March 2018 22:53 To: Lawrence, Andy (MO MM R&D UK IXL); openldap-its(a)OpenLDAP.org Subject: Re: (ITS#8618) ldapsearch - unexpected behavior with andrew.lawrence(a)siemens.com wrote: > --_004_4CF710229787A0419BF92C9304DC6446E7927ADEFTHW99EI5MSXww9_ > Content-Type: multipart/alternative; > boundary=3D"_000_4CF710229787A0419BF92C9304DC6446E7927ADEFTHW99EI5M= SXww9_" > > --_000_4CF710229787A0419BF92C9304DC6446E7927ADEFTHW99EI5MSXww9_ > Content-Type: text/plain; charset=3D"iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > I believe the following patch addresses this problem. I am still a bit > conf=3D used about what constitutes a DNS name. Alex has suggested they > should cont=3D ain an underscore. My colleague who reviewed the code had > a different opini=3D on. > > > > I am also not sure what to do about copyright headers and whether it > is acc=3D eptable or not for me to add them into the files. Please read the Contributing guidelines. Please do not use HTML email. Please demonstrate a basic ability to read and follow directions, otherwise= your patch will be discarded. It's not like the information is hard to fin= d, everything is linked from the front page of the web site. http://www.openldap.org/devel/contributing.html -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8618) ldapsearch - unexpected behavior with
by michael＠stroeder.com 03 Mar '18

03 Mar '18

Alexandre Rosenberg wrote: > Micheal, you are *right* about the man page saying _hostname_. Indeed OpenLDAP > only accepting hostname as per best practice/RFC might be the most correct > behavior. There is no relevant RFC or best practice, only the man-page. And the -h and -p arguments come from the old UMich LDAP times. > However we can not change this behavior without breakable. consider: AFAICS backward compability has only be provided to those ancient Umich or Netscape Directory tools. So IMO LDAP URI does not have to be accepted. > - Underscore are not that uncommon with Active Directory > - What about internationalized DNS name > - ... (probably more) If you want to fix something for 2.4.x to match what the man-page says you could effectively reject LDAP URI by simply rejecting colons and slashes. Those chars are never in even seriously broken hostnames. If they were they would cause more interop issues anyway. > Therefore I believe such change could only be done in a major release. And at > that point we might just remove the depreciated '-h' option altogether. Agreed. 2.5 release chould IMO simply remove options -h and -p. Ciao, Michael.

1 0

RE: (ITS#8618) ldapsearch - unexpected behavior with
by andrew.lawrence＠siemens.com 03 Mar '18

03 Mar '18

SSBmb2xsb3dlZCB0aGUgaW5zdHJ1Y3Rpb25zIHRvIHVwbG9hZCB0aGUgcGF0Y2ggIChhbmRyZXct bGF3cmVuY2UtMTgwMzAzLnBhdGNoKSAgdG8gZnRwOi8vb3BlbmxkYXAub3JnL2luY29taW5nLy4g SSBhbSBub3Qgc3VyZSBpZiBpdCB3YXMgc3VjY2Vzc2Z1bCBhcyBJIGNhbm5vdCBzZWUgdGhlIGNv bnRlbnRzIG9mIHRoZSBmb2xkZXIuDQoNClRoZSBhdHRhY2hlZCBmaWxlIGlzIGRlcml2ZWQgZnJv bSBPcGVuTERBUCBTb2Z0d2FyZS4gQWxsIG9mIHRoZSBtb2RpZmljYXRpb25zIHRvIE9wZW5MREFQ IFNvZnR3YXJlIHJlcHJlc2VudGVkIGluIHRoZSBmb2xsb3dpbmcgcGF0Y2goZXMpIHdlcmUgZGV2 ZWxvcGVkIGJ5IFNpZW1lbnMgUmFpbCBBdXRvbWF0aW9uIEhvbGRpbmdzIExpbWl0ZWQuIFNpZW1l bnMgUmFpbCBBdXRvbWF0aW9uIEhvbGRpbmdzIExpbWl0ZWQgaGFzIG5vdCBhc3NpZ25lZCByaWdo dHMgYW5kL29yIGludGVyZXN0IGluIHRoaXMgd29yayB0byBhbnkgcGFydHkuIEksIEFuZHJldyBM YXdyZW5jZSBhbSBhdXRob3JpemVkIGJ5IFNpZW1lbnMgUmFpbCBBdXRvbWF0aW9uIEhvbGRpbmdz IExpbWl0ZWQsIG15IGVtcGxveWVyLCB0byByZWxlYXNlIHRoaXMgd29yayB1bmRlciB0aGUgZm9s bG93aW5nIHRlcm1zLg0KDQpTaWVtZW5zIFJhaWwgQXV0b21hdGlvbiBIb2xkaW5ncyBMaW1pdGVk IGhlcmVieSBwbGFjZSB0aGUgZm9sbG93aW5nIG1vZGlmaWNhdGlvbnMgdG8gT3BlbkxEQVAgU29m dHdhcmUgKGFuZCBvbmx5IHRoZXNlIG1vZGlmaWNhdGlvbnMpIGludG8gdGhlIHB1YmxpYyBkb21h aW4uIEhlbmNlLCB0aGVzZSBtb2RpZmljYXRpb25zIG1heSBiZSBmcmVlbHkgdXNlZCBhbmQvb3Ig cmVkaXN0cmlidXRlZCBmb3IgYW55IHB1cnBvc2Ugd2l0aCBvciB3aXRob3V0IGF0dHJpYnV0aW9u IGFuZC9vciBvdGhlciBub3RpY2UuDQoNCkNoZWVycywNCkFuZHkNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IEhvd2FyZCBDaHUgW21haWx0bzpoeWNAc3ltYXMuY29tXSANClNl bnQ6IDAyIE1hcmNoIDIwMTggMjI6NTMNClRvOiBMYXdyZW5jZSwgQW5keSAoTU8gTU0gUiZEIFVL IElYTCk7IG9wZW5sZGFwLWl0c0BPcGVuTERBUC5vcmcNClN1YmplY3Q6IFJlOiAoSVRTIzg2MTgp IGxkYXBzZWFyY2ggLSB1bmV4cGVjdGVkIGJlaGF2aW9yIHdpdGgNCg0KYW5kcmV3Lmxhd3JlbmNl QHNpZW1lbnMuY29tIHdyb3RlOg0KPiAtLV8wMDRfNENGNzEwMjI5Nzg3QTA0MTlCRjkyQzkzMDRE QzY0NDZFNzkyN0FERUZUSFc5OUVJNU1TWHd3OV8NCj4gQ29udGVudC1UeXBlOiBtdWx0aXBhcnQv YWx0ZXJuYXRpdmU7DQo+IAlib3VuZGFyeT0iXzAwMF80Q0Y3MTAyMjk3ODdBMDQxOUJGOTJDOTMw NERDNjQ0NkU3OTI3QURFRlRIVzk5RUk1TVNYd3c5XyINCj4gDQo+IC0tXzAwMF80Q0Y3MTAyMjk3 ODdBMDQxOUJGOTJDOTMwNERDNjQ0NkU3OTI3QURFRlRIVzk5RUk1TVNYd3c5Xw0KPiBDb250ZW50 LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9Imlzby04ODU5LTEiDQo+IENvbnRlbnQtVHJhbnNm ZXItRW5jb2Rpbmc6IHF1b3RlZC1wcmludGFibGUNCj4gDQo+IEkgYmVsaWV2ZSB0aGUgZm9sbG93 aW5nIHBhdGNoIGFkZHJlc3NlcyB0aGlzIHByb2JsZW0uIEkgYW0gc3RpbGwgYSBiaXQgDQo+IGNv bmY9IHVzZWQgYWJvdXQgd2hhdCBjb25zdGl0dXRlcyBhIEROUyBuYW1lLiBBbGV4IGhhcyBzdWdn ZXN0ZWQgdGhleSANCj4gc2hvdWxkIGNvbnQ9IGFpbiBhbiB1bmRlcnNjb3JlLiBNeSBjb2xsZWFn dWUgd2hvIHJldmlld2VkIHRoZSBjb2RlIGhhZCANCj4gYSBkaWZmZXJlbnQgb3Bpbmk9IG9uLg0K PiANCj4gDQo+IA0KPiBJIGFtIGFsc28gbm90IHN1cmUgd2hhdCB0byBkbyBhYm91dCBjb3B5cmln aHQgaGVhZGVycyBhbmQgd2hldGhlciBpdCANCj4gaXMgYWNjPSBlcHRhYmxlIG9yIG5vdCBmb3Ig bWUgdG8gYWRkIHRoZW0gaW50byB0aGUgZmlsZXMuDQoNClBsZWFzZSByZWFkIHRoZSBDb250cmli dXRpbmcgZ3VpZGVsaW5lcy4NClBsZWFzZSBkbyBub3QgdXNlIEhUTUwgZW1haWwuDQoNClBsZWFz ZSBkZW1vbnN0cmF0ZSBhIGJhc2ljIGFiaWxpdHkgdG8gcmVhZCBhbmQgZm9sbG93IGRpcmVjdGlv bnMsIG90aGVyd2lzZSB5b3VyIHBhdGNoIHdpbGwgYmUgZGlzY2FyZGVkLiBJdCdzIG5vdCBsaWtl IHRoZSBpbmZvcm1hdGlvbiBpcyBoYXJkIHRvIGZpbmQsIGV2ZXJ5dGhpbmcgaXMgbGlua2VkIGZy b20gdGhlIGZyb250IHBhZ2Ugb2YgdGhlIHdlYiBzaXRlLg0KDQpodHRwOi8vd3d3Lm9wZW5sZGFw Lm9yZy9kZXZlbC9jb250cmlidXRpbmcuaHRtbA0KDQotLSANCiAgIC0tIEhvd2FyZCBDaHUNCiAg IENUTywgU3ltYXMgQ29ycC4gICAgICAgICAgIGh0dHA6Ly93d3cuc3ltYXMuY29tDQogICBEaXJl Y3RvciwgSGlnaGxhbmQgU3VuICAgICBodHRwOi8vaGlnaGxhbmRzdW4uY29tL2h5Yy8NCiAgIENo aWVmIEFyY2hpdGVjdCwgT3BlbkxEQVAgIGh0dHA6Ly93d3cub3BlbmxkYXAub3JnL3Byb2plY3Qv DQo=

1 0

Re: (ITS#8618) ldapsearch - unexpected behavior with
by arekkusu＠r42.ch 03 Mar '18

03 Mar '18

I am also not a C programmer. I've not even looked at patch at this point. I agree best practice says hostname are limited to specific ASCII characters. And underscore are indeed not included. However DNS name in general only have very few restriction (RFC2181) (2). I did some tests using the 'host' and 'dig' command and they do not perform additional validation. For example (2): $ host 'ldap://.test.com' ldap://.test.com has address 69.172.200.109 I would expect C library for resolving DNS names to already enforce those basic constrain. I believe we should be careful about performing additional validation/restriction. Micheal, you are *right* about the man page saying _hostname_. Indeed OpenLDAP only accepting hostname as per best practice/RFC might be the most correct behavior. However we can not change this behavior without breakable. consider: - Underscore are not that uncommon with Active Directory - What about internationalized DNS name - ... (probably more) Therefore I believe such change could only be done in a major release. And at that point we might just remove the depreciated '-h' option altogether. I don't know how OpenLDAP code work. I have a suspicion it might transform hostname + port into a URI. The ITC shows that (for some cases) hostname are handled differently when: 1. Using only '-h' without '-p' 2. Using both '-h' and '-p' And this is clearly not a correct behavior. Best, Alex (1) See RFC for reference but essentially: - A full domain name is limited to 255 octets (including the separators) - Each part of the domain (label) can be between 1 and 63 octets (2) test.com DNS seems to simply return the same A record for any subdomain (wildcard). It highlights that wierd name like works at the DNS level. PS: I exchanged a few email regarding DNS/hostname with Lawrence off the list. I believe this email summarizes the main points from my perspective. On Fri, 2018-03-02 at 18:48 +0000, michael(a)stroeder.com wrote: > andrew.lawrence(a)siemens.com wrote: > > I believe the following patch addresses this problem. I am still a > > bit conf used about what constitutes a DNS name. Alex has suggested > > they should contain an underscore. My colleague who reviewed the code > > had a different opinion. > > Disclaimer: Since I'm not a C programmer I did not really review your > patch in detail but just want to add some general notes. > > 1. Reviewing this ticket my is that the only problem is that > -h also accepts a LDAP URI because -H should be used instead. > IIRC -h was only meant to take an IP address or hostname. > Therefore I'd strongly recommend to simply reject an LDAP URI for -h. > Is that your goal? > > 2. The term "DNS name" is a bit too blurry. In case of option -h it > should be an IP address or . And according to best practices > hostnames SHOULD NOT contain underscores. > Whether you _allow_ underscores to accommodate some strange setups is > your decision. > > Ciao, . > > >

1 0

Re: (ITS#8618) ldapsearch - unexpected behavior with
by hyc＠symas.com 02 Mar '18

02 Mar '18

andrew.lawrence(a)siemens.com wrote: > --_004_4CF710229787A0419BF92C9304DC6446E7927ADEFTHW99EI5MSXww9_ > Content-Type: multipart/alternative; > boundary="_000_4CF710229787A0419BF92C9304DC6446E7927ADEFTHW99EI5MSXww9_" > > --_000_4CF710229787A0419BF92C9304DC6446E7927ADEFTHW99EI5MSXww9_ > Content-Type: text/plain; charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > I believe the following patch addresses this problem. I am still a bit conf= > used about what constitutes a DNS name. Alex has suggested they should cont= > ain an underscore. My colleague who reviewed the code had a different opini= > on. > > > > I am also not sure what to do about copyright headers and whether it is acc= > eptable or not for me to add them into the files. Please read the Contributing guidelines. Please do not use HTML email. Please demonstrate a basic ability to read and follow directions, otherwise your patch will be discarded. It's not like the information is hard to find, everything is linked from the front page of the web site. http://www.openldap.org/devel/contributing.html -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

RE: (ITS#8618) ldapsearch - unexpected behavior with
by andrew.lawrence＠siemens.com 02 Mar '18

02 Mar '18

SGkgTWljaGFlbCwNCg0KTXkgZ29hbCB3YXMgdG8gb25seSBhbGxvdyB2YWxpZCBob3N0bmFtZXMg d2hlbiB1c2luZyB0aGUgLWggb3B0aW9uLiBBICBiaXByb2R1Y3Qgb2YgdGhpcyBpcyB0aGF0IGxk YXAgdXJpcyBhcmUgYWxzbyByZWplY3RlZC4NCg0KVGhlIHBhdGNoIHJlamVjdHMgaG9zdG5hbWVz IHdpdGggdW5kZXJzY29yZXMgYXMgYmVpbmcgaW52YWxpZC4gSSBoYWQgaGVhcmQgc2V2ZXJhbCBv cGluaW9ucyB3aGVuIHdyaXRpbmcgdGhlIHBhdGNoIGFuZCBvbmUgb2YgdGhlbSB3YXMgdGhhdCBB Y3RpdmUgRGlyZWN0b3J5IGFsbG93cyB1bmRlcnNjb3JlcyBpbiBob3N0bmFtZXMuDQoNCkFuZHkN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1pY2hhZWwgU3Ryw7ZkZXIgW21h aWx0bzptaWNoYWVsQHN0cm9lZGVyLmNvbV0NClNlbnQ6IDAyIE1hcmNoIDIwMTggMTg6NDgNClRv OiBMYXdyZW5jZSwgQW5keSAoTU8gTU0gUiZEIFVLIElYTCk7IG9wZW5sZGFwLWl0c0BPcGVuTERB UC5vcmcNClN1YmplY3Q6IFJlOiAoSVRTIzg2MTgpIGxkYXBzZWFyY2ggLSB1bmV4cGVjdGVkIGJl aGF2aW9yIHdpdGgNCg0KYW5kcmV3Lmxhd3JlbmNlQHNpZW1lbnMuY29tIHdyb3RlOg0KPiBJIGJl bGlldmUgdGhlIGZvbGxvd2luZyBwYXRjaCBhZGRyZXNzZXMgdGhpcyBwcm9ibGVtLiBJIGFtIHN0 aWxsIGEgYml0DQo+IGNvbmYgdXNlZCBhYm91dCB3aGF0IGNvbnN0aXR1dGVzIGEgRE5TIG5hbWUu IEFsZXggaGFzIHN1Z2dlc3RlZCB0aGV5DQo+IHNob3VsZCBjb250YWluIGFuIHVuZGVyc2NvcmUu IE15IGNvbGxlYWd1ZSB3aG8gcmV2aWV3ZWQgdGhlIGNvZGUgaGFkIGENCj4gZGlmZmVyZW50IG9w aW5pb24uDQpEaXNjbGFpbWVyOiBTaW5jZSBJJ20gbm90IGEgQyBwcm9ncmFtbWVyIEkgZGlkIG5v dCByZWFsbHkgcmV2aWV3IHlvdXIgcGF0Y2ggaW4gZGV0YWlsIGJ1dCBqdXN0IHdhbnQgdG8gYWRk IHNvbWUgZ2VuZXJhbCBub3Rlcy4NCg0KMS4gUmV2aWV3aW5nIHRoaXMgdGlja2V0IG15IGltcHJl c3Npb24gaXMgdGhhdCB0aGUgb25seSBwcm9ibGVtIGlzIHRoYXQgLWggYWxzbyBhY2NlcHRzIGEg TERBUCBVUkkgYmVjYXVzZSAtSCBzaG91bGQgYmUgdXNlZCBpbnN0ZWFkLg0KSUlSQyAtaCB3YXMg b25seSBtZWFudCB0byB0YWtlIGFuIElQIGFkZHJlc3Mgb3IgaG9zdG5hbWUuDQpUaGVyZWZvcmUg SSdkIHN0cm9uZ2x5IHJlY29tbWVuZCB0byBzaW1wbHkgcmVqZWN0IGFuIExEQVAgVVJJIGZvciAt aC4NCklzIHRoYXQgeW91ciBnb2FsPw0KDQoyLiBUaGUgdGVybSAiRE5TIG5hbWUiIGlzIGEgYml0 IHRvbyBibHVycnkuIEluIGNhc2Ugb2Ygb3B0aW9uIC1oIGl0IHNob3VsZCBiZSBhbiBJUCBhZGRy ZXNzIG9yIF9ob3N0bmFtZV8uIEFuZCBhY2NvcmRpbmcgdG8gYmVzdCBwcmFjdGljZXMgaG9zdG5h bWVzIFNIT1VMRCBOT1QgY29udGFpbiB1bmRlcnNjb3Jlcy4NCldoZXRoZXIgeW91IF9hbGxvd18g dW5kZXJzY29yZXMgdG8gYWNjb21tb2RhdGUgc29tZSBzdHJhbmdlIHNldHVwcyBpcyB5b3VyIGRl Y2lzaW9uLg0KDQpDaWFvLCBNaWNoYWVsLg0K

1 0

Re: (ITS#8618) ldapsearch - unexpected behavior with
by michael＠stroeder.com 02 Mar '18

02 Mar '18

andrew.lawrence(a)siemens.com wrote: > I believe the following patch addresses this problem. I am still a > bit conf used about what constitutes a DNS name. Alex has suggested > they should contain an underscore. My colleague who reviewed the code > had a different opinion. Disclaimer: Since I'm not a C programmer I did not really review your patch in detail but just want to add some general notes. 1. Reviewing this ticket my impression is that the only problem is that -h also accepts a LDAP URI because -H should be used instead. IIRC -h was only meant to take an IP address or hostname. Therefore I'd strongly recommend to simply reject an LDAP URI for -h. Is that your goal? 2. The term "DNS name" is a bit too blurry. In case of option -h it should be an IP address or _hostname_. And according to best practices hostnames SHOULD NOT contain underscores. Whether you _allow_ underscores to accommodate some strange setups is your decision. Ciao, Michael.

1 0

Re: (ITS#8618) ldapsearch - unexpected behavior with
by andrew.lawrence＠siemens.com 02 Mar '18

02 Mar '18

--_004_4CF710229787A0419BF92C9304DC6446E7927ADEFTHW99EI5MSXww9_ Content-Type: multipart/alternative; boundary="_000_4CF710229787A0419BF92C9304DC6446E7927ADEFTHW99EI5MSXww9_" --_000_4CF710229787A0419BF92C9304DC6446E7927ADEFTHW99EI5MSXww9_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I believe the following patch addresses this problem. I am still a bit conf= used about what constitutes a DNS name. Alex has suggested they should cont= ain an underscore. My colleague who reviewed the code had a different opini= on. I am also not sure what to do about copyright headers and whether it is acc= eptable or not for me to add them into the files. >From b3d02c8478edaa877b39f3d8824b54dc7b70146d Mon Sep 17 00:00:00 2001 From: Andrew Lawrence <andrew.lawrence(a)siemens.com> Date: Thu, 25 Jan 2018 22:15:14 +0000 Subject: [PATCH] Added host name validation Removed spurious include Fixed review comments Fixed additional review comments regarding errorcode and underscore --- clients/tools/common.c | 14 ++++++++++++-- include/ldap_pvt.h | 4 ++++ libraries/libldap/url.c | 32 ++++++++++++++++++++++++++++++++ 3 files changed, 48 insertions(+), 2 deletions(-) diff --git a/clients/tools/common.c b/clients/tools/common.c index 5eb41aa..821b006 100644 --- a/clients/tools/common.c +++ b/clients/tools/common.c @@ -5,6 +5,7 @@ * Copyright 1998-2017 The OpenLDAP Foundation. * Portions Copyright 2003 Kurt D. Zeilenga. * Portions Copyright 2003 IBM Corporation. + * Portions Copyright 2018 Siemens Rail Automation Holdings Limited. * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -1242,7 +1243,16 @@ tool_conn_setup( int dont, void (*private_setup)( LD= AP * ) ) int rc; if( ( ldaphost !=3D NULL || ldapport ) && ( ldapuri =3D=3D N= ULL ) ) { - /* construct URL */ + + rc =3D ldap_validate_hostname(ldaphost); + if (rc !=3D LDAP_URL_SUCCESS) { + fprintf( stderr, + "Invalid host name %s\n", + ldaphost); + exit( EXIT_FAILURE ); + } + + /* construct URL */ LDAPURLDesc url; memset( &url, 0, sizeof(url)); @@ -1394,7 +1404,7 @@ dnssrv_free:; fprintf( stderr, "Could not create LDAP session handle for URI= =3D%s (%d): %s\n", ldapuri, rc, ldap_err2string(rc) ); - exit( EXIT_FAILURE ); + exit( EXIT_FAILURE ); } if( private_setup ) private_setup( ld ); diff --git a/include/ldap_pvt.h b/include/ldap_pvt.h index f1d93ac..6d1a6cb 100644 --- a/include/ldap_pvt.h +++ b/include/ldap_pvt.h @@ -2,6 +2,7 @@ /* This work is part of OpenLDAP Software <http://www.openldap.org/>. * * Copyright 1998-2017 The OpenLDAP Foundation. + * Portions Copyright 2018 Siemens Rail Automation Holdings Limited. * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -68,6 +69,9 @@ LDAP_F (int) ldap_url_parselist_ext LDAP_P(( const char *sep, unsigned flags )); +LDAP_F (int) ldap_validate_hostname LDAP_P(( + const char *hostname )); + LDAP_F (char *) ldap_url_list2urls LDAP_P(( struct ldap_url_desc *ludlist )); diff --git a/libraries/libldap/url.c b/libraries/libldap/url.c index b65e2b9..2702fec 100644 --- a/libraries/libldap/url.c +++ b/libraries/libldap/url.c @@ -3,6 +3,7 @@ /* This work is part of OpenLDAP Software <http://www.openldap.org/>. * * Copyright 1998-2017 The OpenLDAP Foundation. + * Portions Copyright 2018 Siemens Rail Automation Holdings Limited. * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -36,6 +37,7 @@ #include <stdio.h> + #include <ac/stdlib.h> #include <ac/ctype.h> @@ -1325,6 +1327,36 @@ ldap_url_parselist_ext (LDAPURLDesc **ludlist, const= char *url, const char *sep, } int +ldap_validate_hostname (const char *url) +{ + assert( url !=3D NULL ); + + // Empty host names are invalid + if (strlen(url) =3D=3D 0) { + return LDAP_URL_ERR_BADHOST; + } + + int prevalnum =3D 0; + int labelcount =3D 0; + int i; + + for (i=3D0; url[i] !=3D '\0'; i++) { + if (!(isalnum(url[i]) || url[i] =3D=3D '.' || url[i] =3D=3D= '-') || + (labelcount =3D=3D 0 && url[i] =3D=3D '.'&& !(i =3D=3D 0= && url[i+1] =3D=3D '\0')) || + i =3D=3D 255 || labelcount =3D=3D 63) { + // We have an invalid hostname. Fail. + return LDAP_URL_ERR_BADHOST; + } else if (url[i] =3D=3D '.') { + labelcount =3D 0; + } else { + labelcount++; + } + } + + return LDAP_URL_SUCCESS; +} + +int ldap_url_parsehosts( LDAPURLDesc **ludlist, const char *hosts, -- libgit2 0.26.0 With best regards, Dr Andrew Lawrence Siemens Rail Automation Holdings Limited MO MM R&D UK IXL 17 Langley Park Way Chippenham SN15 1GG, Gro=DFbritannien und Nordirland mailto:andrew.lawrence@siemens.com www.siemens.com/rail-automation<http://www.siemens.com/rail-automation> www.siemens.com/ingenuityforlife<https://siemens.com/ingenuityforlife> www.siemens.com/ingenuityforlife Siemens Rail Automation Holdings Limited - registered office: Faraday House= , Sir William Siemens Square, Frimley Camberley GU16 8QD. Registered No. 00= 016033 --_000_4CF710229787A0419BF92C9304DC6446E7927ADEFTHW99EI5MSXww9_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"EN-GB" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> I believe the follo= wing patch addresses this problem. I am still a bit confused about what con= stitutes a DNS name. Alex has suggested they should contain an underscore. My colleague who reviewed the code had a different = opinion.<o:p></o:p> <o:p> </o:p></= span> I am also not sure = what to do about copyright headers and whether it is acceptable or not for = me to add them into the files.<o:p></o:p> <o:p> </o:p></= span> From b3d02c8478edaa= 877b39f3d8824b54dc7b70146d Mon Sep 17 00:00:00 2001<o:p></o:p> From: Andrew Lawren= ce <andrew.lawrence(a)siemens.com><o:p></o:p> Date: Thu, 25 Jan 2= 018 22:15:14 +0000<o:p></o:p> Subject: [PATCH] Ad= ded host name validation<o:p></o:p> <o:p> </o:p></= span> Removed spurious in= clude<o:p></o:p> <o:p> </o:p></= span> Fixed review commen= ts<o:p></o:p> <o:p> </o:p></= span> Fixed additional re= view comments regarding errorcode and underscore<o:p></o:p> ---<o:p></o:p></spa= n> clients/tools/commo= n.c  | 14 ++++++++++++= --<o:p></o:p> include/ldap_pvt.h&= nbsp;     |  4 ++++<o:p></o:p></sp= an> libraries/libldap/u= rl.c | 32 +++++++++++++= +++++++++++++++= ++++<o:p></o:p> 3 files changed, 48= insertions(+), 2 deletions(-)<o:p></o:p> <o:p> </o:p></= span> diff --git a/client= s/tools/common.c b/clients/tools/common.c<o:p></o:p> index 5eb41aa..821b= 006 100644<o:p></o:p> --- a/clients/tools= /common.c<o:p></o:p> +++ b/c= lients/tools/common.c<o:p></o:p> @@ -5,6 +5,7 @@= <o:p></o:p>   * Copyright = 1998-2017 The OpenLDAP Foundation.<o:p></o:p>   * Portions C= opyright 2003 Kurt D. Zeilenga.<o:p></o:p>   * Portions C= opyright 2003 IBM Corporation.<o:p></o:p> + * Portions Co= pyright 2018 Siemens Rail Automation Holdings Limited.<o:p></o:p></p= >   * All rights= reserved.<o:p></o:p>   *<o:p></o:p>=   * Redistribu= tion and use in source and binary forms, with or without<o:p></o:p><= /p> @@ -1242,7 +124= 3,16 @@ tool_conn_setup( int dont, void (*private_setup)( LDAP * ) )<o:p></= o:p>    &= nbsp;          int rc;<o:p></o= :p> <o:p></o:p><= /p>    &= nbsp;           if( ( lda= phost !=3D NULL || ldapport ) && ( ldapuri =3D=3D NULL ) ) {<o:p></= o:p> -   =             &nb= sp;      /* construct URL */<o:p></o:p> +<o:p></o:p></s= pan> +  &n= bsp;           &nbsp= ;       rc =3D ldap_validate_hostname(ldaphos= t);<o:p></o:p> +  &n= bsp;           &nbsp= ;       if (rc !=3D LDAP_URL_SUCCESS) {<o:p><= /o:p> +  &n= bsp;           &nbsp= ;            &n= bsp;  fprintf( stderr,<o:p></o:p> +  &n= bsp;           &nbsp= ;            &n= bsp;     "Invalid host name %s\n",<o:p></o:p></spa= n> +  &n= bsp;           &nbsp= ;            &n= bsp;         ldaphost);<o:p></o:p><= /span> +  &n= bsp;           &nbsp= ;            &n= bsp;  exit( EXIT_FAILURE );<o:p></o:p> +  &n= bsp;            &nbs= p;      }<o:p></o:p> +<o:p></o:p></s= pan> +  &n= bsp;            &nbs= p;      /* construct URL */<o:p></o:p>    &= nbsp;           &nbs= p;      LDAPURLDesc url;<o:p></o:p>    &= nbsp;           &nbs= p;      memset( &url, 0, sizeof(url));<o:p></o= :p> <o:p></o:p><= /p> @@ -1394,7 +140= 4,7 @@ dnssrv_free:;<o:p></o:p>    &= nbsp;           &nbs= p;      fprintf( stderr,<o:p></o:p>    &= nbsp;           &nbs= p;            &= nbsp; "Could not create LDAP session handle for URI=3D%s (%d): %s\n&qu= ot;,<o:p></o:p>    &= nbsp;           &nbs= p;            &= nbsp; ldapuri, rc, ldap_err2string(rc) );<o:p></o:p> -   =             &nb= sp;      exit( EXIT_FAILURE );<o:p></o:p></= p> +  &n= bsp;            &nbs= p;     exit( EXIT_FAILURE );<o:p></o:p>    &= nbsp;          }<o:p></o:p></s= pan> <o:p></o:p><= /p>    &= nbsp;           if( priva= te_setup ) private_setup( ld );<o:p></o:p> diff --git a/includ= e/ldap_pvt.h b/include/ldap_pvt.h<o:p></o:p> index f1d93ac..6d1a= 6cb 100644<o:p></o:p> --- a/include/ldap_= pvt.h<o:p></o:p> +++ b/i= nclude/ldap_pvt.h<o:p></o:p> @@ -2,6 +2,7 @@= <o:p></o:p> /* This work is par= t of OpenLDAP Software <http://www.openldap.org/>.<o:p></o:p><= /p>   * <o:p></o:p>   * Copyr= ight 1998-2017 The OpenLDAP Foundation.<o:p></o:p> + * Portions Co= pyright 2018 Siemens Rail Automation Holdings Limited.<o:p></o:p></p= >   * All rights= reserved.<o:p></o:p>   *<o:p></o:p>=   * Redistribu= tion and use in source and binary forms, with or without<o:p></o:p><= /p> @@ -68,6 +69,9 = @@ LDAP_F (int) ldap_url_parselist_ext LDAP_P((<o:p></o:p>    &= nbsp;   const char *sep,<o:p></o:p>    &= nbsp;   unsigned flags ));<o:p></o:p> <o:p></o:p><= /p> +LDAP_F (int) l= dap_validate_hostname LDAP_P((<o:p></o:p> +  &n= bsp;    const char *hostname ));<o:p></o:p> +<o:p></o:p></s= pan> LDAP_F (char *) lda= p_url_list2urls LDAP_P((<o:p></o:p>    &= nbsp;   struct ldap_url_desc *ludlist ));<o:p></o:p> <o:p></o:p><= /p> diff --git a/librar= ies/libldap/url.c b/libraries/libldap/url.c<o:p></o:p> index b65e2b9..2702= fec 100644<o:p></o:p> --- a/libraries/lib= ldap/url.c<o:p></o:p> +++ b/l= ibraries/libldap/url.c<o:p></o:p> @@ -3,6 +3,7 @@= <o:p></o:p> /* This work is par= t of OpenLDAP Software <http://www.openldap.org/>.<o:p></o:p><= /p>   *<o:p></o:p>=   * Copyright = 1998-2017 The OpenLDAP Foundation.<o:p></o:p> + * Portions Co= pyright 2018 Siemens Rail Automation Holdings Limited.<o:p></o:p></p= >   * All rights= reserved.<o:p></o:p>   *<o:p></o:p>=   * Redistribu= tion and use in source and binary forms, with or without<o:p></o:p><= /p> @@ -36,6 +37,7 = @@<o:p></o:p> <o:p></o:p><= /p>  #include <= stdio.h><o:p></o:p> <o:p></o:p><= /p> +<o:p></o:p></s= pan> #include <ac/std= lib.h><o:p></o:p> #include <ac/cty= pe.h><o:p></o:p> <o:p></o:p><= /p> @@ -1325,6 +132= 7,36 @@ ldap_url_parselist_ext (LDAPURLDesc **ludlist, const char *url, con= st char *sep,<o:p></o:p> }<o:p></o:p>= <o:p></o:p><= /p>  int<o:p></o:p= > +ldap_validate_= hostname (const char *url)<o:p></o:p> +{<o:p></o:p></= span> +  &n= bsp;    assert( url !=3D NULL );<o:p></o:p> +<o:p></o:p></s= pan> +  &n= bsp;    // Empty host names are invalid<o:p></o:p></p= > +  &n= bsp;    if (strlen(url) =3D=3D 0) {<o:p></o:p> +  &n= bsp;           return LDA= P_URL_ERR_BADHOST;<o:p></o:p> +  &n= bsp;    }<o:p></o:p> +  &n= bsp;    <o:p></o:p> +  &n= bsp;     int prevalnum =3D 0;<o:p></o:p> +  &n= bsp;    int labelcount =3D 0;<o:p></o:p> +  &n= bsp;    int i;<o:p></o:p> +  &n= bsp;    <o:p></o:p> +  &n= bsp;    for (i=3D0; url[i] !=3D '\0'; i++) {<o:p></o= :p> +  &n= bsp;            if (!(isa= lnum(url[i]) || url[i] =3D=3D '.' || url[i] =3D=3D '-') ||<o:p></o:p></span= > +  &n= bsp;            &nbs= p;  (labelcount =3D=3D 0 && url[i] =3D=3D '.'&& !(i = =3D=3D 0 && url[i+1] =3D=3D '\0')) ||<o:p></o:p> +  &n= bsp;            &nbs= p;  i =3D=3D 255 || labelcount =3D=3D 63) { <o:p></o:p> +  &n= bsp;           &nbsp= ;       // We have an invalid hostname. Fail.= <o:p></o:p> +  &n= bsp;            &nbs= p;      return LDAP_URL_ERR_BADHOST;<o:p></o:p></s= pan> +  &n= bsp;           } else if = (url[i] =3D=3D '.') {<o:p></o:p> +  &n= bsp;           &nbsp= ;       labelcount =3D 0;<o:p></o:p></= p> +  &n= bsp;           } else {<o= :p></o:p> +  &n= bsp;           &nbsp= ;       labelcount++;<o:p></o:p></spa= n> +  &n= bsp;           } &nb= sp; <o:p></o:p> +  &n= bsp;    }<o:p></o:p> +<o:p></o:p></s= pan> +  &n= bsp;    return LDAP_URL_SUCCESS;<o:p></o:p> +}<o:p></o:p></= span> +<o:p></o:p></s= pan> +int<o:p></o:p>= ldap_url_parsehosts= (<o:p></o:p>    &= nbsp;   LDAPURLDesc **ludlist,<o:p></o:p>    &= nbsp;   const char *hosts,<o:p></o:p> --<o:p></o:p></span= > libgit2 0.26.0<o:p>= </o:p> <o:p> </o:p> <o:p> </o:p> With best rega= rds, Dr Andrew Lawrence Siemens Rail Automation Holdings Limited MO MM R&D UK IXL 17 Langley Park Way Chippenham SN15 1GG, Gro=DFbritannien und Nordirland <a href=3D"mailto:andrew.lawrence@siemens.com">m= ailto:andrew.lawrence@siemens.com</a> <a href=3D"http://www.siemens.com/rail-automation">www.siemens.com/rail-automation</a> <a href=3D"https://siemens.com/ingenuityforlife">www.siemens.com/ingenuityforlife</a> <img border=3D"0" width=3D"300= " height=3D"109" id=3D"_x0000_i1025" src=3D"cid:image003.png@01D3B24C.628B2= 0A0" alt=3D"www.siemens.com/ingenuityforlife"> Siemens Rail Automation Holding= s Limited - registered office: Faraday House, Sir William Siemens Square, F= rimley Camberley GU16 8QD. Registered No. 00016033<o:p></o:p> <o:p> </o:p> </div> </body> </html> --_000_4CF710229787A0419BF92C9304DC6446E7927ADEFTHW99EI5MSXww9_-- --_004_4CF710229787A0419BF92C9304DC6446E7927ADEFTHW99EI5MSXww9_ Content-Type: image/png; name="image003.png" Content-Description: image003.png Content-Disposition: inline; filename="image003.png"; size=9561; creation-date="Fri, 02 Mar 2018 17:32:42 GMT"; modification-date="Fri, 02 Mar 2018 17:32:42 GMT" Content-ID: <image003.png(a)01D3B24C.628B20A0> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAASwAAABtCAYAAAAbDlwIAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAS dAAAEnQB3mYfeAAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAACTZSURBVHja 7Z0HfFVV8sdDEwEV7AURsQOWdYtrR1HsiAX76q5rL+ti278FlCotQAgdpPcWeu8ltEDoEDpKgNB7 lTD/+Z73brh5vEBCQPLi/Pjczwv33XvOmXPu/O7MnDnnRYnBYDBECKKsCwwGQ6TACMtgMEQMjLAM BkPEwAjLYDBEDIywDAZDxMAIy2AwRAyMsAwGQ8TACMtgMEQMjLAMBkPEwAjLYDBEDIywDAZDxMAI y2AwRAyMsAwGQ8TACMtgMEQMjLAMBkPEwAjLYDBEDIywDAZDxMAIy2AwRAyMsAwGQ8TACMtgMEQM jLAMBkPEwAjLYDBEDIywDAZDxMAIy2AwRAyMsAwGQ8TACMtgMEQMjLAMBkPEwAjLYDBEDIywDAZD xMAIy2AwRAzOGmH9dvSobNi3T5bt3CmLtm+Xpfr5y969suPQoZPee1SPI3o//1LdcWKkBo+jmfzn rnflZ66s1KOpp9wP3Juu3qB8GcqdJVlEUuVohuWFypKaenI5jh4NtPNIWtlHMyXnoSNHZL2Orxvv HVkbb4PhrBAWJLNg2zbptWKFVJsxQz4cM1b+MXy4vDJsmLwxYoS8O3asVJk8RWrNni2dly2T2Zs3 yyGfEvEX5FY/MVG+nzZdqul1VafPkB+nTZMey5fLpv3709V3UO/tu2qVu6bqjJnu+nTHnPBH1Zkz 9Z7pMvrXX2Xvb7+5sg5rWTM2bZJo6oyPP3a9+/80qT5rlozZsCFT/bD54EHprn3wg7abetLVq+eG rVkjOw8fTnfPVr2nl8r4vdZddVZCJmSZo+cTVG7tn4QEiU9JSVfedJWl4ew5UnVqvLvO1a/X/qDt 6b96tSPs48ZPj6QdO6T5vHny/ZQp2vZpEr1gvqzdsyesnAe1jLlbt0rnpKXyrcr1wZgxOt4j5BUd 89d1vN8JjndN7bvOy5bLEi3bYMgRhLVZ36S9lYTeGDxYrv25vUTFNJWoeg0kqlZtiapRU6Jq1pKo Oj9JVH09V7++XNSihbw/ebJsUUX1cFgVoKcqetFWrfXe+hLVrLle21CifvpJHhk0SOYqGfqB0lcc OTJQZsNGges5YptJVFOO2PBHA8qsK1UmTpQNQRLco8TVcP48ubSZ3le7jkQ1bxE4KC+6saujsirh Dl97M8L4Devl2q5dVYZ6EtWo8bGy+FvrfV+JfHUICSSpRVJp0OBA3fTdyWThfJMYiaqr/dSkidSc OzetLKiorpLOhdRJ/3Mtf1Ouln9Xt24yY3OKe8H4cUj/P0DJ7MZ2P0tU9Rpadj25pEMnGb9+/XEy phw8IJ2XLJFXBg6UK9q2DbSFMaP9jLV/vPX8pa3byI9KoEfFYDjLhIV10mTBArmhTVvJx4MKIaBU jQKKzoOfdvD/aj+4485+/WStug1+wsLKuLhFS6fYroygEjwycIAkhiGsp0aMDFzj1ekUWRWzYXTg XLiDNv7wo3yqxLHOR1gNVMmvpAy+j/WThP5do5aUVsWMW73KtTMj4Aq30HKiohsF6oIkvHbRJpXl w9FjjiMsXKjnVfkdwTRucnJZOAdZ/VDDfX6nVpifsOpoGy6CfHlZ0AbK4qhVRwo3bKgvi0nOqgsl rDi1/m5p2871D2NwRfsOMiGEsHDz6iTOkVItW0o+yqcttBOZ/ePNuHBQ1o/V5emRo44jSYPhdyUs lHdMcrLc07FjQDl40/I2V4Ur1KaN3NKjp5RXRawweJDcowR1fbfuUhAi0zd42T59ZNXu3emUve+K lfrGbhd4+Fu2UtJrIgUaNJCnhw6Reeou+rFLCauyKr8jRurFMvMOSM+zbEIPrlel/0otvA0HDriy cA1jlHRLtgxad5RB/XwqEaOIhRs3lvemTJatJ4jLJKqL9NKQIQGFhSDUskgrR4kjj9b76fjxssZH 1GDZrl3y8tChAYXHsuJ67s1IFs5RPuQVGys/KUH5CStaZSnepnWgHVzrlcU9WsdNXbupO7fluLEc vHat3N6pU8BSUiIqoZbiJJ8rzDVDlNRuwqryW4MxsXKu9lPpnj3VGtbxVov4Lh3vEp07S95GjdxL 4HF1FQ+nporBcNYIC5fu7QkTpGCDgOmPcubXN/ud+uBGz58vo/XtPH3LZpm5ZYtMSUmREUpubRct kq8nTpKac+bIxn370hPWylVyBS4lBISSNYmVAo2i5dlhQ2V+GMJ6Ra0kdy2KiGKqAt3cvYd8Mm2a xC5aLI0XLpRGC9If0eo+NUpMlKmqiPuDMSwsrKZ6bUnqVAvEkRR/88nhXMNGUlYJOHHLlgz7o1VS klzM9R7hQr5eOdrGPEqW/9H+WhtCWMshrGHDAgSEHJCLkn5pleUzlaWRtq2JXxb39wInR+MF82W2 r00QFtdeDalQHmXRDtrAp7bhXH0RfDNzuqwPEnYaGUFYSjKO6PS6Euo++glr+e5d8sboUQF3Lyhj fiXQu/r2lZaLF7vxnqFtYbwn6XgP/fVXablwgXyh7ndT/Txw5IhppeHsERaxl9K9ewfcAt78Sh6F oqPlo4kTZG9qxg8ngelfVWkPBAnjOMLCLXKE1VQKaHkVMyCsl/2ExaGK9oxadJBkVpCOsBpEB5Qb 4oB0OBe0+oopiUC4e8Mo3h5tz6eqmI4kIDiPePyEpWVkirCoVy2hSirLvG1bsyQLhNXYIywsNs/q pEyPfPV8SbWkRiihhCUsXPIwhDVuw3q5pkuXQDsZb5XnvKZN5XMl1RMh5cB+Wb9vr1lYhrNLWPO2 bZOS6uY5N8tZOOoaKIFUUvdmdPI62Xk489Pa2SIsL0CthPX84MEyJyTelSXCqt9Q8qpi5/e7cxCW 1lNQFfVFtTCWKsGEYowq8/1qWTpl177Io/fl13LyelZaVglLLdaXVJakXTuzT1jOhWx+TBZcOf0O t3jToUAs60gmCGu4ElzR9h0C40OZ2ifnqUv68sgRMmNTihsTgyHHEtbiHTvkpp69AhYWpKGKmUcf 5HP0eKBPX4mZmygLlTz2KSGcLNx6WghLlfzZQYOUsLJmlaQjLFXWIqrU1yn5lOjeXc6FPFBODlXi yzt2lKG//JJOHuyGL2fOkkJYHdqG/HrtNXpvcVX4ghBEMH6UVcKqrLIQkD9lwlIChziLKMmcQzs8 K4s69LubOnWWPmvWpMlwMsIaoy7flVhY0cFZWS0zj34WUbkrxPWX5uqeLtNnYp/PcjYYcgxhJe/b J88MHy55iWHxEDMljmLoQ5xPSexKffve36eP1FFlTti0yZHSGSEsyCro6lSIi5MJGze6a8jzIm4S ehxJTU1HOGmE1aaNmxG8WJX9ubFj5MMpU+Q62oMFiVzqEkI6NadPl22HDvr6Ya9UGDgokIYREyOX q7tF2sa96tLl9dyxU3AJn+4fJ9NTUlzfcHjt3x/8JGEzNKcqjbDatXPB7sLaL48OGSqPDR8hVzI+ Xt9qe/LqGFXRdro+0fsIut/WKWPCmqtj8NigwZKP7+l3rC1nPTaX/CrblUpcj/TvL/Vnz5b5mzeL wZCjCOugPug9V66QEq1aBaavIQ2UgoeYqfnglPxVqhwP9+4j38VPkykbN4TNXs8WYVFXcOaseOcu 8syo0fJRfLy8q4Tzjiokx7/1eH3sWPlMP1HCg754SjoLq0ZNOV/l+ffkSTJq3Tp5ZMCAgBxe/EeV 9TE9Fx+Mk6Hs7ZOSpBTfV68hBZs3c/lho5KTpZKSuXO/skpYkJzWdbXK8qzK8v7UqfKeJ4t+vj1x oryphFpl2jTnlocnrJ9dOsH52j+fTJosfZWMKpM6Adl4bmqdn+R2tZiGaFtx5oar5Xgbs4QZEBZ9 /vPixVKkadNA+gf9wXhRVsyxFIwSzZrJ42ph105IkGn6orLIlSFHEBbYffiQy6AuTt5PnTrBqfZm AYuEhzlo+eDinKtE9ESvnhIzb64sD8lFyjZhcT1K2rxlME+pbjAfKHjwd9Vqkl+VtOGcObLdF29J R1i1akleleXF0aNdlvf/zZolRZANhYRMlHQuVkus1dKl7l7SHCqNHiMFabOWX0q/67J8uctXqjw0 SEJZJSxPlhaeLPWOyVK/fiBfS+tC9t4rV2ZMWBCo1vlPJWrqbJyYKPmwFpGFOrTN+bX8jydNcvfO 27pF7uraLTALGIawQMr+/fKZkublseSs1T6WtEt9HEHXnKOYEttTSlytFy2Udfv3mUYazj5hgWR9 iOslzpE/6du6GK4hSoYC8/B60/tYDZxXl6uYPuz/VSVZu3t32ts324TFWz6o5Hm0nrxqJeQhhuMd KJEq+UW160gjdVm2ZUhYqoQxTeThIUNknbq8E9W9/AtxG6wOvodEtKyv1GoBvyipkX7gZFOyK9er l1tHifVZkex1L/B9yoTVMNj+oBxKWHloY7VqUlBl73ciwlJrkb6oQPB+506JVzftrl69A7IQb2Nc 6tSVcj16OHJep+16VC1hl2OVAWEB5KuhRH6buoTnM6vqkkeDrrkX2A+6tVhixVu2lJozpssWXxqF wXDWCAvgYrGGDZfrDlWAC/QBzgtJeDNKrYNuCIqib/BLVCFqz5gpm4IPcbZjWCiKln1Jx45y94A4 eVoJ4Aklnce9Y+hQKde/v0vsZD3ffl9qwnGE1aSJ3D9okIvREQf794gRASX30hy0/S/GDZBEbdPg 1aulODKpkudp3FheGzfOlUmO2UP94wLKfCqEpZ+Xduwk96j7+aTK/8TQY3I8pq5d+X79pPKoUW4N 5AkJS8ssN2CgzN26zc0ERifMlry8VLCyIBZtX3Gtq6aSOORUoV//gIV0AsJy4639N2ldsnyg1tut Sujn6ZilG28vlw3rS9tRSq3U6Hnz1SK3mURDDiAsD6zPS9Q3eeOEBKdUFzRvHlAAT0G8xFBV8Bu6 dpeJGzZmn7C8tXeqnOXj4qTv2jWyQq23FUoEy71j9y5nZazSz13qrh31BauPJ6wYR1jrg4mtPyXO lTzNmh3LqNfP6zt1lsqqrBWURAoFl/SUUPmaLF7s7lmybZvcq+6Qm4w4lVlCJZLHVJah69YFZNl9 TA4+2RlhtZ4PnZELS1hKcLO3BmZOIaDSPXoEEmSdBdxa8ukY3dCjp3w8darcQZtjAkttSnTNmLC8 upJVloSUFKk9c6aU6907EN/CsqJsz00MrqO8Q627+Vu3isGQYwjLw04lBXYRaLNggVSM6x+IA7nU h6C7EMzd6pS0zF2PvdNvVfbTGlhEvCDk2pMhQ8IKEsuI9evlbyTIQrxBVyq/klBBlaOAl/ag7toL g4bIymCOFqR9d58+p05YWteLKsty3/KlzCAcYT0EYQWz4Ynd/aTu+3lqDabN7AZnMi/v0lUuVCLO G0zhOBlh+bFZLeUpem3s3ER5ROXO1zS46NpLnFUCLqr/767jvd8y3g05jbD8mLxxg7w6cqQUhVQa x6RNq6OczZXQQOppIizysGadYPlMVghrXZBYcFu/nTIlveUQDKS7+JlaJHljY6WGbxHyHCWse7JJ WC9oGxZlcVuWkxEWWLxtq9xOwq+3dhFCoc4gweQNvlCyQlj++kevT5aX1I0ujKXGEUynuEj/jk5M lO22T5bhbBAWbhWxjIOZWHLRfNEiucYFrBsEyCg469Z2yZLTR1hq5VQaPFhmbc1G4qiPsH7xEQv7 fBWBeNJicm2OxeRIwuzaVfr98svpIywts7LKsuRUE0dPQFj0HTs8FPN2xPDWPHopFRlYWMTA9mdi vGlDmyWL5BIv1SG4hrGYjlMbfQ72WGKp4WwQFg/vZH2g+6syE8dgMTTKwAO5N3gQZF26c4e8PW6c nA+xoCQoub7dL2zfXoYElfxIdoPuwbVtd/fpK22SktzOCTM3bZIZ2q5jxyaZvnGjxK/f4DKyvQ38 9maCsNiP61E9lw+rxIvHBZfcIEsoEWWbsFTB71NZOixf7uSYdZwsKS6pNH7DRlmupHbQ52adjLAA Y1KO9tWtf8x1847grhahhLVNLaNxycluvHF5t2Uw3nO0798YMyYQ2/MWpjdoINd07CTjk9fbvliG s0NY5CB9OW2alNaHvGz7DvLkiJHypipklenT5JtZs+T/Zs6Uf0+aLA8OGuh2MWDZjjczVaBOHXUb hqdZENlOawjGYYro/dequ3Nrr95ud4Uy/qNnLynTpauU1rZ8PnGS1h2IN+1TZT8ZYe1SZWwyb54U i4kJxN+8tANtayG9r8/Klen2e8oWYQW3gzlPZSmlspTVdh8nC0e3blJa+/MrUkT27skSYZHrjwt7 WfNgnpyXTHoCwlq5Z49LR7lFXzy3duokz4wapeM7ST4PjvfXOt5v6//v7R8nRVu1OjbeasUVql9f Xh87TpL37TfNNJwdwiLQ+tb48YGsZxIZlTjyqWJeoA/8xS1bykWsK3T7Jfk2siMBUq//c5cuMm7d urQALCv5++ibO/1+WI0lv76ZmdYPtx/WC/79sLyUA9+eV2E3viO59bvv5Yl+cTJzS8B1ZPcFNiG8 hjLY10vvv3vAgOO2B56nSn9r9+7H2qdyFWBmUl23BSGxpgSC7uQ8QQbBrW8gj0/GjZc1YXYcdfto eTuthsqS0YaE9OX3VeWZ/v3TrTmMVsK6irWEP1Z3ZT4QFxc2rkebn9R707LWfcuIqJNM+4k+wlq2 e7e8zi6vWmdU9eruOsa3aHC8L1Q5C3hJtjGxgYN0kJo1nTU34yTLswxGWGcUuASfxcdLfhRNScBl SKPwLNMJ7izqttvlPErH4mG1UJ7u2096rFol/rkiCKvb0qVSiIedMiAFrB1Vunvj+klCSFyKHUfL k0lOtrW3P1Ojxsd2+8yIsGoHCatv/zTC2nPkN6mdOEcu4P6v/+cU+MZevdJtMAgIFr+lFhLJlp5s 5yghxarltSMkv4glKWVZl0dfUC+Kq7L8S63QlSHlElh/sl+/QJn1G2ROFo+wVJaKSjpJvh0kasxN VHdM+/HLr1yZZXv2lPjNm8KOYcPERCmMRUufUzf1Mp4q2/lqcY1VF9ADGw9+OH5CgOBoa0bjjawN AwmlV+nLhN1UB/q2sjEYzgphEbPgByUq9Okrt7RuLdepdXS1vqFZBHu5vnk5rmrRQkrqm/tmdRmf 0Ae3ekKCiy+FgjfvyLVr5UElitLqCpXp3kPK6D23aZnvjh93XPCZuMnHU+PdNWU6dgpcf7IDN0qt hjJt2sgXEyamuYRYeR2SkqR8D70mtrkr88UxY1ziqB8HlFR7rVwh5Tp0lJL16kkpJdcHyS0KY72w S8Vr6ubhspVRt66MklfZdu2k1vTpLoPeD/KpqqilSrvKdO2aOVk41GUro6Ty1cSJ6dzMn5cluX4s oxYOZb46ZrS61OG33Jmt7XxPZS2j40cbXR+p9VtaXcryAwa6Rese2Fa53aLFcp/WfYtacKX0YLyv 0PG+jPHWTzfeeq5Mx45SUd3q2uoqrsjixIHBCOuMAOOeXTuX79whE5PXSb8VK6WtPtAxanHU0zc3 v4DTbP586bJkiYzVNyx5TRntOklZW9XFnK0KQj7PtI0pEs+OpXosDbNlCfGipB07Zep6vTZ4fdqR kvERz7VqNazwlcmOB7Rttn4/Vd1UriGX61CYtrJGcOyaNdJZXcieahGO0/aFyyvaqxbXQiXmKfr9 NAL9GwLtXK2W0MGQ6+lDJgGm6rXxem2mZdFruYd7/f3K0hkny6/rnKyLlJT2ZJBhjuwbVfbpyevd LqyubP2k3fyykX+PK2aF6TN+AWe8jid78LdetEga63jXZbznzpVYHe+u2i+TtN4t+/fbLqOGnENY oYRz8EiqKsZvTqm3BQ9cNx7y1Fw0N3Q4qLgQ1R81JoPUkBGzgseN9xFLWzBkHfbLzwaDIWJghGUw GCIGRlgGgyFiYIRlMBgiBkZYBoMhYmCEZTAYIgZGWAaDIWKQqwmLJMZ169bJ8uXLZecfLJMa2ffv 3y979+6V307zVi0HDhyQ7du3n/ZyDYaTIVcTFiT1+eefy6OPPio9evRIt+VxbsERfi8wTKb4xo0b ncwdO3aUX3x7cGUXhw8floEDB0q9evVk1KhRcvDgwTPSr6mpqY4QU0P21eL/4eSlDbt375a1a9c6 Mk21n7zPlcjVhDV37lz5+9//LlFRUfLf//43Vz7EK1askDFjxkhSUlI6RR4yZIhcd911csMNN8iE CRNOS11YVv369ZP77rtPLrnkErn33nulZ8+esm/f6f15Ll40tH/48OGyNWRN6XqWMU2bJosXL043 nitXrpSPP/5Y/va3v0mVKlVkSXDTR0PuQq4lLCyBAQMGOIW96KKLpGHDhrnSwoqPj5dXX31Vnn76 aUdcyJicnCzvvPOOI2q+W7Vq1WmpC0utQoUKcsEFF8iDDz4oL730ktSoUUO2bdt22uTZs2eP/Pjj j3LnnXc66ziUsJDlm2++ce34+eefnTUF2rdvL0WLFpWCBQtK2bJl3f8P26/v5DrkWsLCPahbt64U K1ZMHnjgAZkxY0aulHP16tVSrVo1eeyxx6Rr166OsOLi4qR48eJy+eWXy8yZM09LPcTCcC8hq2ee eUamTp0qiYmJznrbE7J3V3awcOFCufbaayVv3rxSs2ZNORSyt/uOHTukefPmctddd8l//vMf2cAi 9AULpFy5cnLeeec5smvUqJGzzojhGXIXci1hpaSkSKVKlZyV8a9//Us2b978u9SL2/R7v9mpE0Vn cgEQX0JurJQNWfyBiBMRSfny5eWcc86Rtm3bnjE5KBuLGAsKlz4cIK2JEyfKyJEjHVk2aNDAyfvn P//ZWZcA99gsrNyHXEtYxHZKlSrlHuTatWs7y8P9IMbBg+4hP5TFX2XhvhMpAGUTR+ndu7eMHj3a EaQ/xkJ9KOSRTG6lciruK2VT51dffeXkfu+992RLFn8dKCMMGjRIChUqJFdddZUjizMB4lJPPfWU nHvuuRIdHX3CvkJO+pSxfPvttx2Rfv3116fV2jMYYf1umDJlilxxxRXOJezSpYs7RzCXmMvjjz8u nTt3znRZixYtcm9x7sHSQClClYn40Ysvvih/+tOfXFAaK2fNmjVp9aKAX375pYs5nQwQH9fh7vmJ C8Lzuzko7bJly9ICzAS/IZNHHnnEKT1xLMiT8jIiaO4h9QNCzgh8h3t9/vnnu7jSpk2bsj0+tJ1y /aQ+bNgwKVKkiKsHly4zYDxwB6+//noXqPePi9/yPGwpGEZYORUoZ7du3VwMBzdh/Pjx7jwEcvPN N6fNGnrKSHC+T58+TnH9YFqdWTDckzJlyjiXCDfz+++/l1mzZqVdxzQ/JMX3BIQJ/uKOTZo0yX0/ f/58ufXWWyVfvnyOyDwQe4EMUSwPEFT16tXloYcekm+//VaO+BS6e/fubiZs3Lhxrt3MmGFV/POf /5SEhAQXFH/33XddnAmL47bbbnMkyvefffaZ9OrVK51rPG/ePEdq//jHPxzBZ2TRcA9l0J8tWrRw 1it9hWuGC0bMjDhabGysI0cP9PfkyZPl1+DWx5Br69atXf/x4qA9/oB9mzZt3Njcfffdrm2hgJiJ m+32bR9NXO3SSy91lpmfdKdPn+7qefbZZ11IoGOHDmntMBhh5SgwcwQxEAthJgsFg3yGDh3qpuOZ RULpUbiqVavKTTfd5AipXbt26R568pgIAF922WWOPJ5//nmnUBAB9wMUjhk6zr/88svStGlTp3Af ffRRWr2tWrVyAWHqHTFihLPQqIvg9SuvvOLa5ZEV9/zlL39x5eHqeMDi+utf/+rO4/IhI4QIAaOw kBlxuw8//NCRVYkSJdz0PkTCpAP3Pffcc2kW2tKlS+WNN95w57mWeJBHWPQBhITS9+/f3xEohMsM HNYMBPDJJ5/Id9995wgU6+biiy+WkiVLuv9j0SA3biSzlFxLH0Ce9DPt4TpeKh5hYenRVsj2008/ PY5cINS33nrLWXgQPWMH2VMmMlAmVhkueZMmTVzfknZBf/DyuK5UKUeIBiOsHAfe+lhQWDq4YRAE 0+P/+9//5EJ1EWvVquWUmwcbBcFyyJ8/v3v4UVSUDTK4/fbb3WwbDzplonhch1XCrBmWEd+hqNTF TN2bb77pZqk8S4bZNFw04j9Mw3Mf90CC1MtsGC4qeVQASw8CgYhwkSAxCACiQDEvvPBC+eGHHxxh MSvoETDtpd2QLGVTp0e+XIdrjOJiAWH5oMiURxsgd3+sCzKDFMlhQ37cNNoJ6UJcWH+epcp5SAgL DkLEDf/iiy9ceVietI3rOK6++moXVxs8eLDrT/rPc3khKKxD5MF99q9MgJi8lwIWLtbXnDlzHIEx fp4c9D/EhTvsET6zw1hftB231mCEleOA64FlhaLhpgACuk888YQUVuLgTY71ceONNzpLiLc/ikXO FrEossS5n4ee71Gmli1bOuXFrYuJiXEWwdixY930ukckkCPKDinhljLLhRJi8WCdQCaQFfWigLhX 3E+ZtIkycU+x6rCmyCSHiCACys+TJ49TetoLCeNeQYT33HNPWjY7bhbKS3a/ZzFBUMjD+ddff10q V67srDLKox9CA9XIhRUJCVM27UVGXF5cPGYeIX3OQTBYP7SdGFLp0qXdAclC1p5VSH0QJ0QbbvIC d++FF15wbaSf/Offf//9NBLCBaZvSdegjRAmMS9IFDeTlAcIlGshbQgSEuMFxtgYjLByHIhzEFOC KHARAIrmWQXXXHONXHnllU55saiIiXjuEdYTb3CPsMgWhzBQQqwrrB9IDHfotddec9YRiu2RG2SH YqA8vPHvv/9+F4iHsFAkFPLhhx92iki9KBiu6y233OIC5FgeWA4oIQqJRQP5oOxYb7QB5cOVwi2F ZCFbYmpYKygy9UEUXjwJ4kImZkupG5KjvcR3vFQIP7AOifvRHkj3gw8+cPXiqnnxNqwkZMGimj17 tjuHZVm4cGFnyZHg2aFDB2fZ0d9YTXtDfhzWD9qK+0h5uJKAupGZscLlpM0QO8ACYxIE+ZG3b9++ jkghROKIvKxoH5YkpH86JgoMRlhnBASg77jjDveA42IBSMQjIQ5iR8RCPGAl8D1LO7CmiCvh2mBh QGIoO2kSKCBEgrtBNjWJk82aNXPWBy4kVkLFihVdOdyHImE18T2kBcF5wXhA4JyysWJwXWgT7g7k h/WFEnszZrhYEBiu63pVzh1B5cSSINaE5QEJQmjcC6n4ZwdR8k6dOjmCRaEzG9MhQRPXq379+mnL cLA6ISEmNch6h/xJeYCUkRmrDReavsa1PBlhcD0WJy8E+ohYFWTPi6JOnTquDQUKFHCfHiBpyBo3 ERffA2MNuWKVQmbICQHT78TqcLUhWUuBMMLKEcAFwj1DkXBvAJYBf+NeEPANl5SI20hcC4UjHoSS EQPh7c9sIZYCiotyhuYioRDUCcFgkWBt+JfEQICkRoSrl3gPyop7hhsFUEDq8Aef+Rt3Cctie/BX pLHUsCIhOc/Vos2Ux5o7P2FBNpAsioySZ2a9HRYjBImVw73+tApv8gCCwarCzfW7cySBUo9/ZvRE YOEykyBYwlidvAAYD4DVjMWKZYvFiFxYcLSLSYDQ9Yz0PbOEWNoE33mJMDYcjD9jvD3kl8INRlhn BSguDyxvVBTODxQuK4ugcY8IljMT5mVTM9OXEY5k4zf2cOl27dqVqQztzCSWhl7DTCMzolh6zNBl BvQjRIRrjKUYrm24YricfisH8JJgsiMrW/tAPLwcsDo98gZMIGAZEdfzEkZZH4q1iDUVDlwHaWMZ cg1WK5MJxADJz7JMeCOsHAWIKTsLnlE03EJv1o7AL2/rM5XpnRUyOpW+IEhPXI8Zx3B5TuHABAaW DURHTOv32PECoiHeFdoPEAzfcZ6xIZ5FPI4xOlFfQm7E/CBPrCr+b3t5RSZsx9ETgLcxKQLEhHAh sDIIgBMjizTgUpEAi6vFFjGZXRiM1cSkA6SdkYV1NkAeFu4h1iIzh4Y/BoywwgBXBuVkpo44GEpL MJzAOLNWkZgxjRvETB9T/KGu24kAQRFXIpkVNzKn7ICABUacEKuXmUDDHwNGWGFATIacLWbSmFXD rSD4S84RW55E2rYlECxBZ5InveTVrIAgPgF0LMusLho/U8ClIz7FODFT6l/eZMi9MMIKAeSEguIC oQxeZjizXbgfrF2LNJB+wOwmaRu5SbGx/gjCk+zrX19oyL0wwgqBtycTmdmkIQBmq8gwJx0gs7sI 5BQQbCYHDHfWS8jMTcDSwuqzPdz/GDDCCgEzSEyD4/55WfIkYGKhsGOBt2VMJICZNG9NJesos+oK Ggw5DUZYIeBtTZ4VGdRkauNOPfnkky6J0VtgHAlg+p5lP6Qx4AqSnmAwRDqMsMKAKXO2iSFQTcIo 6/LIYYqk+A9rBEmWJPZGSoPBkBtghJUBiImwBIblMriEkQZmBrEUQzclNBgiGUZYJwDLRAhaR+IS DlzXE217bDBEIoywDAZDxMAIy2AwRAyMsAwGQ8TACMtgMEQMjLAMBkPEwAjLYDBEDIywDAZDxMAI y2AwRAyMsAwGQ8TACMtgMEQMjLAMBkPEwAjLYDBEDIywDAZDxMAIy2AwRAyMsAwGQ8TACMtgMEQM jLAMBkPEwAjLYDBEDIywDAZDxOD/AfJ2nuAo4uJvAAAAAElFTkSuQmCC --_004_4CF710229787A0419BF92C9304DC6446E7927ADEFTHW99EI5MSXww9_--

1 0

(ITS#8812) OpenLDAP 2.4 Standalone or embedded
by muthamma.appaiah＠wellsfargo.com 02 Mar '18

02 Mar '18

Full_Name: Muthamma Version: 2.4 and 2.3 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2620:160:e708:6::a) Hi team, Could you confirm if the product OpenLDAP is a stand-alone product or embedded?

1 0

Re: (ITS#8810) speeling-error
by quanah＠symas.com 24 Feb '18

24 Feb '18

--On Saturday, February 24, 2018 11:54 AM +0000 sca+openldap(a)andreasschulze.de wrote: > Full_Name: Andreas Schulze > Version: 2.4.45 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/andreas-schulze-180224.patch > Submission from: (NULL) (2001:470:77b3:50::65) > > > Debian Lintian found a typo in libraries/libldap/os-local.c: "errror" > should be "error" > Patch attached Hi Andreas, Please always check OpenLDAP head before filing a report. :) commit c1512eea5818c81ff19d81d8aeae1967bab7e64f Author: Quanah Gibson-Mount <quanah(a)openldap.org> Date: Fri Sep 8 12:03:02 2017 -0700 Fix typo "errror" -> "error" --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8810) speeling-error
by sca+openldap＠andreasschulze.de 24 Feb '18

24 Feb '18

Full_Name: Andreas Schulze Version: 2.4.45 OS: Linux URL: ftp://ftp.openldap.org/incoming/andreas-schulze-180224.patch Submission from: (NULL) (2001:470:77b3:50::65) Debian Lintian found a typo in libraries/libldap/os-local.c: "errror" should be "error" Patch attached Andreas

1 0

Re: (ITS#8809) tls_o failure when linking to OpenSSL 1.0.2 with "no-deprecated" compile flag
by quanah＠symas.com 23 Feb '18

23 Feb '18

--On Friday, February 23, 2018 5:07 PM +0000 Howard Chu <hyc(a)symas.com> wrote: > quanah(a)openldap.org wrote: >> Full_Name: Quanah Gibson-Mount >> Version: HEAD >> OS: N/A >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (47.208.148.239) >> >> >> When attempting to link OpenLDAP to OpenSSL 1.0.2 series, where OpenSSL >> has been built with deprecated API's disabled, the build will fail. >> This is because RSA_F4 is deprecated in 1.0.2. In master, this is >> around line 1367: >> >> # if OPENSSL_VERSION_NUMBER < 0x10100000 >> static RSA * >> tlso_tmp_rsa_cb( SSL *ssl, int is_export, int key_length ) > >> This function needs to check < 1.0.2 rather than < 1.1 > > That would only be true if the RSA callback is not needed at all in > 1.0.2. Is that true? Not sure. Exact error is in RE24 is: tls_o.c:1184:25: error: 'RSA_F4' undeclared (first use in this function) if ( BN_set_word( bn, RSA_F4 )) { so it dies before we get to the RSA_generate_key_ex function itself. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8809) tls_o failure when linking to OpenSSL 1.0.2 with "no-deprecated" compile flag
by hyc＠symas.com 23 Feb '18

23 Feb '18

quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: HEAD > OS: N/A > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.148.239) > > > When attempting to link OpenLDAP to OpenSSL 1.0.2 series, where OpenSSL has been > built with deprecated API's disabled, the build will fail. This is because > RSA_F4 is deprecated in 1.0.2. In master, this is around line 1367: > > #if OPENSSL_VERSION_NUMBER < 0x10100000 > static RSA * > tlso_tmp_rsa_cb( SSL *ssl, int is_export, int key_length ) > This function needs to check < 1.0.2 rather than < 1.1 That would only be true if the RSA callback is not needed at all in 1.0.2. Is that true? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8809) tls_o failure when linking to OpenSSL 1.0.2 with "no-deprecated" compile flag
by quanah＠openldap.org 23 Feb '18

23 Feb '18

Full_Name: Quanah Gibson-Mount Version: HEAD OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) When attempting to link OpenLDAP to OpenSSL 1.0.2 series, where OpenSSL has been built with deprecated API's disabled, the build will fail. This is because RSA_F4 is deprecated in 1.0.2. In master, this is around line 1367: #if OPENSSL_VERSION_NUMBER < 0x10100000 static RSA * tlso_tmp_rsa_cb( SSL *ssl, int is_export, int key_length ) { RSA *tmp_rsa; /* FIXME: Pregenerate the key on startup */ /* FIXME: Who frees the key? */ #if OPENSSL_VERSION_NUMBER >= 0x00908000 BIGNUM *bn = BN_new(); tmp_rsa = NULL; if ( bn ) { if ( BN_set_word( bn, RSA_F4 )) { tmp_rsa = RSA_new(); if ( tmp_rsa && !RSA_generate_key_ex( tmp_rsa, key_length, bn, NULL )) { RSA_free( tmp_rsa ); tmp_rsa = NULL; } } BN_free( bn ); } #else tmp_rsa = RSA_generate_key( key_length, RSA_F4, NULL, NULL ); #endif if ( !tmp_rsa ) { Debug( LDAP_DEBUG_ANY, "TLS: Failed to generate temporary %d-bit %s RSA key\n", key_length, is_export ? "export" : "domestic", 0 ); } return tmp_rsa; } #endif /* OPENSSL_VERSION_NUMBER < 1.1 */ This function needs to check < 1.0.2 rather than < 1.1

1 0

Re: (ITS#8805) Documentation for LDAP_OPT_X_TLS_NEWCTX is wrong
by hyc＠symas.com 15 Feb '18

15 Feb '18

cheimes(a)redhat.com wrote: > This is an OpenPGP/MIME signed message (RFC 4880 and 3156) > --xtLU7S4g0jUK8GMHh0QtLLEN50A6OirhP > Content-Type: multipart/mixed; boundary="ImAEehvUF6AyAI2LgcI3vl7LvbpVlLmbd"; > protected-headers="v1" > From: Christian Heimes <cheimes(a)redhat.com> > To: Howard Chu <hyc(a)symas.com>, openldap-its(a)OpenLDAP.org > Message-ID: <1ad5d71c-c2c2-701e-1550-5296c850a51e(a)redhat.com> > Subject: Re: (ITS#8805) Documentation for LDAP_OPT_X_TLS_NEWCTX is wrong > References: <E1emLjU-0005uv-8G(a)gauss.openldap.net> > <9e35c40f-d567-5dec-dd5d-085dcd356483(a)symas.com> > In-Reply-To: <9e35c40f-d567-5dec-dd5d-085dcd356483(a)symas.com> > > --ImAEehvUF6AyAI2LgcI3vl7LvbpVlLmbd > Content-Type: text/plain; charset=utf-8 > Content-Language: en-US > Content-Transfer-Encoding: quoted-printable > > On 2018-02-15 17:04, Howard Chu wrote: >> I see no disagreement between the code and the documentation. Please >> elaborate, otherwise this ITS will be closed. > > For a non-native speaker, the documentation sounds a bit like > ldap_set_option(l, LDAP_OPT_X_TLS_NEWCTX, 0) does not create a new > context at all because the input value is zero. Could you please mention > that a zero value creates a client context? "This option creates a context. If you specify a 1, it will create a context for a server." Nothing in these statements implies that it will *not* create a context. Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8805) Documentation for LDAP_OPT_X_TLS_NEWCTX is wrong
by cheimes＠redhat.com 15 Feb '18

15 Feb '18

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xtLU7S4g0jUK8GMHh0QtLLEN50A6OirhP Content-Type: multipart/mixed; boundary="ImAEehvUF6AyAI2LgcI3vl7LvbpVlLmbd"; protected-headers="v1" From: Christian Heimes <cheimes(a)redhat.com> To: Howard Chu <hyc(a)symas.com>, openldap-its(a)OpenLDAP.org Message-ID: <1ad5d71c-c2c2-701e-1550-5296c850a51e(a)redhat.com> Subject: Re: (ITS#8805) Documentation for LDAP_OPT_X_TLS_NEWCTX is wrong References: <E1emLjU-0005uv-8G(a)gauss.openldap.net> <9e35c40f-d567-5dec-dd5d-085dcd356483(a)symas.com> In-Reply-To: <9e35c40f-d567-5dec-dd5d-085dcd356483(a)symas.com> --ImAEehvUF6AyAI2LgcI3vl7LvbpVlLmbd Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2018-02-15 17:04, Howard Chu wrote: > I see no disagreement between the code and the documentation. Please > elaborate, otherwise this ITS will be closed. For a non-native speaker, the documentation sounds a bit like ldap_set_option(l, LDAP_OPT_X_TLS_NEWCTX, 0) does not create a new context at all because the input value is zero. Could you please mention that a zero value creates a client context? --=20 Christian Heimes Senior Software Engineer, Identity Management and Platform Security Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander --ImAEehvUF6AyAI2LgcI3vl7LvbpVlLmbd-- --xtLU7S4g0jUK8GMHh0QtLLEN50A6OirhP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEL7+ElqIWjf0BBClLhmhSSSEttokFAlqFtLAACgkQhmhSSSEt ton6FggAqOSMIaWDSrVLYVQPxhqAQh+HDbinIaxgLPZarYxr0ijth8wPbpdt0f1s Bgq21a71Qkrrr9joDhb6T3I7ZOs85wsq8mFlHAqciVV2qJGCOFDYd7SOveAyyY6/ PgETKxQ9/S/ei+8NKiRhc0UP2wAvUF8pus7TyJDMao8/EumButO8R8MJWydBOdkh /5kUuROlo1B9owujmNY9V7tIKUU5to6zj1r05gJXrznP+ex+ZkoJz6Us+PedueRe uF5/jAibFnLIpk0WRN+DdTl1PqZnXVGHfBaHsVbpH5Wff+yzxgUNwo4zmQB6sCuA w+82yYr0Lbh243efKYPC+ivRjfs4kg== =A94C -----END PGP SIGNATURE----- --xtLU7S4g0jUK8GMHh0QtLLEN50A6OirhP--

1 0

Re: (ITS#8805) Documentation for LDAP_OPT_X_TLS_NEWCTX is wrong
by hyc＠symas.com 15 Feb '18

15 Feb '18

cheimes(a)redhat.com wrote: > Full_Name: Christian Heimes > Version: 2.4.45 > OS: Fedora > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:16b8:607e:f300:6312:6da:8e63:dfa2) > > > The documentation for ldap_set_option LDAP_OPT_X_TLS_NEWCTX is wrong or at least > misleading. The man page https://linux.die.net/man/3/ldap_set_option describes > the option as: > >> Instructs the library to create a new TLS library context. invalue must be > const int *. A non-zero value pointed to by invalue tells the library to create > a context for a server. > > However tls2 creates a new context for any non-NULL argument, even for > ldap_set_option(l, LDAP_OPT_X_TLS_NEWCTX, 0). See > https://github.com/openldap/openldap/blob/OPENLDAP_REL_ENG_2_4_45/libraries… I see no disagreement between the code and the documentation. Please elaborate, otherwise this ITS will be closed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8805) Documentation for LDAP_OPT_X_TLS_NEWCTX is wrong
by cheimes＠redhat.com 15 Feb '18

15 Feb '18

Full_Name: Christian Heimes Version: 2.4.45 OS: Fedora URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:16b8:607e:f300:6312:6da:8e63:dfa2) The documentation for ldap_set_option LDAP_OPT_X_TLS_NEWCTX is wrong or at least misleading. The man page https://linux.die.net/man/3/ldap_set_option describes the option as: > Instructs the library to create a new TLS library context. invalue must be const int *. A non-zero value pointed to by invalue tells the library to create a context for a server. However tls2 creates a new context for any non-NULL argument, even for ldap_set_option(l, LDAP_OPT_X_TLS_NEWCTX, 0). See https://github.com/openldap/openldap/blob/OPENLDAP_REL_ENG_2_4_45/libraries…

1 0

Re: (ITS#7625) ppolicy doesn't support changing olcPasswordHash without restart
by ghenadii.batalski＠gmail.com 15 Feb '18

15 Feb '18

--94eb2c07ce7efcc3bb056541f87a Content-Type: text/plain; charset="UTF-8" Hello, today i faced the same problem but because of multiple *olcPasswordHash *entries. This caused the *userPassword *attribute was created multiple times for a single password change request: once for each hash algorithm declared in *olcPasswordHash* By the way, restarts didn't help. Regards, Gena --94eb2c07ce7efcc3bb056541f87a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Hello,<div> </div><div>today i faced the same problem b= ut because of multiple=C2=A0olcPasswordHash entries. This caused the= =C2=A0userPassword=C2=A0attribute was created multiple times for a s= ingle password change request: once for each hash algorithm declared in=C2= =A0 <b style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:smal= l;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;= letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;= white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-= decoration-style:initial;text-decoration-color:initial">olcPasswordHash= </div><div> </div><div>By the way, restarts didn't help.</div><div><= br></div><div>Regards,</div><div> </div><div>Gena</div><div> </div><d= iv> </div></div> --94eb2c07ce7efcc3bb056541f87a--

1 0

(ITS#8804) repeated crashes using chaning
by klaus.jungbauer＠is4it.de 13 Feb '18

13 Feb '18

Full_Name: Klaus Jungbauer Version: 2.4.45 OS: RHEL 7.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.135.30.210) I tried to use slapd within a productive environment where the slapd uses its mdb to resolve technical accounts and netgroups while real user accounts have to be resolved at AD. To do this a proxy was configured with chaining to resolve referrals. This configuration leads to very often crashes within an interval from 3 to 60 seconds (!): slapd: chain.c:226: ldap_chain_uri_cmp: Assertion `!((&li2->li_bvuri[ 0 ])->bv_val == ((void *)0))' failed. Using gdb i can see the crashes were caused by chain.c:226 or 227 coming from chain.c:831. Going deeper i saw that the assert checking li_bvuri uses a pointer at li_bvuri.bv_val which was an allocated mem at insertion time of node to tree which gets freed at chain:893. This points to a strange memory (mis)management. As a quick and dirty hack i changed chain:893 and chain.c:620 from 'ldap_memfree( li.li_uri );' to 'if ( temporary ) ldap_memfree( li.li_uri );' and inserted 'if (li2->li_bvuri[0].bv_len == 0 || li2->li_bvuri[0].bv_val == NULL) return -1;' below chain.c:225. With this changes slapd runs about half a day. Adding a Debug statement like 'Debug( 256, "#### uri_cmp: li2->li_bvuri[0].{bv_len=%d, bv_val='%s'}\n", li2->li_bvuri[0].bv_len, li2->li_bvuri[0].bv_val, 0 );' at end of chain.c:225 shows strange outputs like: 5a82a1de #### uri_cmp: li2->li_bvuri[0].{bv_len=-967084369, bv_val='(null)'} I expect another place in code adds nodes to tree too - with unresolved pointers. cn=config was created by slaptest from slapd.conf. I uploaded slapd.conf as slapd.conf_chain_provider__klaus.jungbauer(a)is4it.de to your ftp server. See RedHat Ticket #02027931 too. What do you need on additional files like config, logs, ...? Kind regards Klaus Jungbauer

1 0

Re: (ITS#8486) Syncprov sessionlog is inefficient, kills perf
by quanah＠symas.com 11 Feb '18

11 Feb '18

Using the patch in the openldap-scratch repository, this is no longer a problem. Test case: 2 masters with identical DBs Approximately 4 million user DB Modify every user on master 1 (replicated to master 2) Stop master 2, reload it with the original DB Let time pass so the accesslog DB empties out a record of all changes Start master 2 master 2 will then start querying the sesison log to find any deleted entries while this is ongoing, perform 4 concurrent queries against master 1 (in this case, a search against the entire DB with filter "(uid=*)" requesting 1.1 All four searches execute w/o issue once this patch is in place. Master 2 logs: Feb 10 19:09:54 anvil2 systemd[1]: Started LSB: Symas OpenLDAP. Feb 10 19:09:54 anvil2 slapd[5580]: do_syncrep2: rid=100 LDAP_RES_SEARCH_RESULT Feb 10 19:09:54 anvil2 slapd[5580]: do_syncrep2: rid=100 delta-sync lost sync, switching to REFRESH Feb 10 19:09:54 anvil2 slapd[5580]: do_syncrep2: rid=100 (4096) Content Sync Refresh Required --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8803) [PATCH] Add -L option for using external locking
by nirsof＠gmail.com 10 Feb '18

10 Feb '18

Full_Name: Nir Soffer Version: master OS: Fedora 27 URL: https://github.com/nirs/lmdb/commit/e9ffc44797f9884590c480d0f160d8f745ee8ff9 Submission from: (NULL) (217.132.180.29) A user may prefer to provide external locking using the MDB_NOLOCK when using the lmdb library. To use the mdb_dump, mdb_load, and mdb_stat with the same locking, we need an option to disable the library internal locking when running these tools. The attached patch file is derived from lmdb Software. All of the modifications to lmdb represented in the following patch(es) were developed by Nir Soffer nirsof(a)gmail.com. I have not assigned rights and/or interest in this work to any party. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2018 Nir Soffer Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

Re: (ITS#6268) multi-master sync replication ldap_add error code 68 bug
by quanah＠symas.com 10 Feb '18

10 Feb '18

Hi Barry, I had a few questions to ask in relation to this ITS: a) Can you reproduce this problem with current RE24? and b) Could you provide copies of your shell scripts so I can create a generalized regression test case for this? (And, if this issue is not resolved as of yet, it will help with getting it fixed). Thanks! Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

AW: (ITS#8777) [LMDB] Closing read cursor uses already freed transaction (MDB_VL32)
by markus＠greenrobot.de 09 Feb '18

09 Feb '18

It's not that trivial. We recycle cursors because they *might* be reused later. At the point when the txn is done it is unknown whether the cursor will be used in the future.

1 0

Re: (ITS#8777) [LMDB] Closing read cursor uses already freed transaction (MDB_VL32)
by hyc＠symas.com 09 Feb '18

09 Feb '18

Howard Chu wrote: > Markus Junginger wrote: >>> There was never a bug here. The doc is quite explicit >>> http://www.lmdb.tech/doc/group__mdb.html#ga73a5938ae4c3239ee11efa07eb22b882 >>> >>> After txn_abort the only valid call on a still-open cursor is >>> cursor_renew, not cursor_close. >> >> However you want to call it, are you open to improve this workflow? >> >> API-wise, it would be so much simpler just to free a cursor after it became >> obsolete. It's counter-intuitive to open a new txn, renew the cursor, close >> the cursor, and abort the txn - just to close a cursor. > > API-wise, it is much simpler to just close the cursor before closing its > transaction, if you have no need to reuse the cursor. To be explicit - a typical workflow, as outlined in the Getting Started guide: Open an env Open a txn inside the env Open a cursor inside the txn When finished: Close cursor inside txn Close txn inside env Close env The only reason the API allows a read cursor to exist outside of its creating read txn is to allow it to be reused in a later read txn. If you're not reusing it then you should just close it in the proper order. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8777) [LMDB] Closing read cursor uses already freed transaction (MDB_VL32)
by hyc＠symas.com 09 Feb '18

09 Feb '18

Markus Junginger wrote: >> There was never a bug here. The doc is quite explicit >> http://www.lmdb.tech/doc/group__mdb.html#ga73a5938ae4c3239ee11efa07eb22b882 >> >> After txn_abort the only valid call on a still-open cursor is >> cursor_renew, not cursor_close. > > However you want to call it, are you open to improve this workflow? > > API-wise, it would be so much simpler just to free a cursor after it became > obsolete. It's counter-intuitive to open a new txn, renew the cursor, close > the cursor, and abort the txn - just to close a cursor. API-wise, it is much simpler to just close the cursor before closing its transaction, if you have no need to reuse the cursor. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8777) [LMDB] Closing read cursor uses already freed transaction (MDB_VL32)
by markus＠greenrobot.de 09 Feb '18

09 Feb '18

> There was never a bug here. The doc is quite explicit > http://www.lmdb.tech/doc/group__mdb.html#ga73a5938ae4c3239ee11efa07eb22b882 > > After txn_abort the only valid call on a still-open cursor is > cursor_renew, not cursor_close. However you want to call it, are you open to improve this workflow? API-wise, it would be so much simpler just to free a cursor after it became obsolete. It's counter-intuitive to open a new txn, renew the cursor, close the cursor, and abort the txn - just to close a cursor. And without MDB_VL32, plain cursor closing after txn abort seems to work just fine (I did not consider "closing" as "using" when I read the docs). One could say that the inconsistent behavior is a result of the complexity MDB_VL32 introduces. If you don't want to change the current behavior, it would still be nice for future developers to null the obsolete txn ptr in the cursor on txn abort to make the unwanted close call crash always, not just occasionally.

1 0

Re: AW: AW: (ITS#8777) [LMDB] Closing read cursor uses already freed transaction (MDB_VL32)
by hyc＠symas.com 09 Feb '18

09 Feb '18

Markus Junginger wrote: > I perfectly see that MDB_VL32 is the superior as a feature. On the other > hand I'm a bit worried that it may hold up LMDB development for use cases > you refer to as obsolete yourself. > > While there are workarounds for this particular bug (which we applied), There was never a bug here. The doc is quite explicit http://www.lmdb.tech/doc/group__mdb.html#ga73a5938ae4c3239ee11efa07eb22b882 After txn_abort the only valid call on a still-open cursor is cursor_renew, not cursor_close. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

AW: AW: (ITS#8777) [LMDB] Closing read cursor uses already freed transaction (MDB_VL32)
by markus＠greenrobot.de 09 Feb '18

09 Feb '18

I perfectly see that MDB_VL32 is the superior as a feature. On the other hand I'm a bit worried that it may hold up LMDB development for use cases you refer to as obsolete yourself. While there are workarounds for this particular bug (which we applied), I wouldn't be surprised if MDB_VL32 still needs some stabilization after it will be officially released to get real exposure in the real world. Also, for future changes, the MDB_VL32 "fork" will have to be adjusted as well.

1 0

Re: AW: (ITS#8777) [LMDB] Closing read cursor uses already freed transaction (MDB_VL32)
by hyc＠symas.com 09 Feb '18

09 Feb '18

markus(a)greenrobot.de wrote: >> When using MDB_VL32 to access a 64bit DB on a 32bit CPU, the DB cannot fit >> into a single mmap. >> [...] > > Long story short: I did not understand MDB_VL32 in the first place. I > thought it would just enable 64 bit sizes. Pointless, if you're still limited to 2GB. It would only eat up 4 extra bytes overhead in every internal integer. >> Ideally, you should quit using obsolete 32bit CPUs. > > Of course. Think about mobile and IoT however: Here, there are still 32 bit > CPUs and it's not uncommon to even make 64 bit ARM CPUs operate in 32 bit > mode to reduce binary size etc. > > I'd like to propose a different approach to 64 bits on 32 bit CPUs; > something like this: > #ifdef MDB_SIZE64 > typedef uint64_t mdb_size_t; > ... > > Why? MDB_VL32 adds complexity and it would take additional coding and > testing efforts to get it production ready. If you had used the API as intended, with txn_reset/renew as I originally suggested, there would be no problem. > > I think MDB_SIZE64 might be a better trade-off. Of course this would only > work with smaller DBs files (< 2GB/4GB). But I don't see a huge scenario for > 32 bit CPUs being able to work with huge files anyway. The reason MDB_VL32 exists at all is because of exactly this - people wanted to use 32 bit CPUs with 64 bit databases. > The main reason I see > to use 64 bits consistently across CPU architecture is binary compatibility. > This is a big thing for Android (shipping apps with prefilled DBs). Also it > enables getting DB files from 32 bit devices and open those on the desktop, > etc. > > What do you think? Bad idea. MDB_VL32 provides *full* compatibility between 32bit and 64bit CPUs *regardless of filesize*. Your suggestion will only cause confusion, as people wonder why their DB dies after reaching 2GB in size. It offers none of the benefits of 64bit capability, while still paying all of the cost in terms of storage overhead. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

AW: (ITS#8777) [LMDB] Closing read cursor uses already freed transaction (MDB_VL32)
by markus＠greenrobot.de 09 Feb '18

09 Feb '18

> When using MDB_VL32 to access a 64bit DB on a 32bit CPU, the DB cannot fit > into a single mmap. > [...] Long story short: I did not understand MDB_VL32 in the first place. I thought it would just enable 64 bit sizes. > Ideally, you should quit using obsolete 32bit CPUs. Of course. Think about mobile and IoT however: Here, there are still 32 bit CPUs and it's not uncommon to even make 64 bit ARM CPUs operate in 32 bit mode to reduce binary size etc. I'd like to propose a different approach to 64 bits on 32 bit CPUs; something like this: #ifdef MDB_SIZE64 typedef uint64_t mdb_size_t; ... Why? MDB_VL32 adds complexity and it would take additional coding and testing efforts to get it production ready. I think MDB_SIZE64 might be a better trade-off. Of course this would only work with smaller DBs files (< 2GB/4GB). But I don't see a huge scenario for 32 bit CPUs being able to work with huge files anyway. The main reason I see to use 64 bits consistently across CPU architecture is binary compatibility. This is a big thing for Android (shipping apps with prefilled DBs). Also it enables getting DB files from 32 bit devices and open those on the desktop, etc. What do you think? Thanks, Markus PS.: Here's the full patch (adding MDB_SIZE64), which runs fine at least with our test suite: lmdb.h @@ -187,7 +187,15 @@ # define MDB_FMT_Z "z" /**< printf/scanf format modifier for size_t */ #endif -#ifndef MDB_VL32 +#if defined(MDB_VL32) && defined(MDB_SIZE64) +#error either define MDB_VL32 OR MDB_SIZE64 +#endif +#ifdef MDB_SIZE64 +typedef uint64_t mdb_size_t; +# define MDB_SIZE_MAX SIZE_MAX /**< max #mdb_size_t */ +# define MDB_PRIy(t) PRI##t##64 +# define MDB_SCNy(t) SCN##t##64 +#elif !defined(MDB_VL32)) /** Unsigned type used for mapsize, entry counts and page/transaction IDs. * * It is normally size_t, hence the name. Defining MDB_VL32 makes it

1 0

(ITS#8802) ldappasswd ppolicy
by matsl＠irf.se 08 Feb '18

08 Feb '18

Full_Name: Mats Luspa Version: openldap-2.4.40+dfsg OS: 3.16.0-4-686-pae #1 SMP Debian 3.16.43-2+deb8u5 (2017-09-19) i686 GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:6b0:27:cc:2740:e692:a5b1:4b0f) Hello! When you are using ppolicy password changed are recorded in pwdHistory attribute. ldappasswd can't be used due to that. It checks of some reason that pwdHistory not exists before it changes that password. If pwdHistory exists then the ldappaswd can't change the password. Here's the log file: 2018-02-08T09:42:45+01:00 mailserver slapd[725]: bdb_modify_internal: replace userPassword 2018-02-08T09:42:45+01:00 mailserver slapd[725]: bdb_modify_internal: replace pwdChangedTime 2018-02-08T09:42:45+01:00 mailserver slapd[725]: bdb_modify_internal: add pwdHistory 2018-02-08T09:42:45+01:00 mailserver slapd[725]: bdb_modify_internal: replace pwdChangedTime 2018-02-08T09:42:45+01:00 mailserver slapd[725]: bdb_modify_internal: add pwdHistory 2018-02-08T09:42:45+01:00 mailserver slapd[725]: bdb_modify_internal: 20 modify/add: pwdHistory: value #0 already exists 2018-02-08T09:42:45+01:00 mailserver slapd[725]: send_ldap_result: err=20 matched="" text="modify/add: pwdHistory: value #0 already exists" /Regards Mats

1 0

Re: (ITS#8801) Fix pending CSN queue
by Howard Chu 06 Feb '18

06 Feb '18

The problem was noticed because the accesslog overlay was invoking a spurious slap_graduate_commit_csn() on a CSN that had already been graduated by the underlying backend.

1 0

(ITS#8801) Fix pending CSN queue
by hyc＠openldap.org 06 Feb '18

06 Feb '18

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.136.45.75) Submitted by: hyc The CSN queue tracks in-progress write operations. It uses connID and opID to identify a CSN queue entry that corresponds to a given operation. This is error-prone in the case of syncrepl, which always uses the same connID and opID for all of its internal operations. Should just use the Operation pointer, which is always unique and unambiguous.

1 0

Re: (ITS#8800) MMR: out of date master will ignore history of its own changes
by quanah＠symas.com 31 Jan '18

31 Jan '18

--On Tuesday, January 30, 2018 9:04 PM +0000 quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.45 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.148.239) > > > Did the following test: > > 4-way MMR setup, database populated from an initial DB that has history > to it Per Howard's suggestion, I commented out lines 2390-2396 in syncprov.c, which allows the master to get fed back its own operations on startup. On the plus side, the database indeed get all the operations sent back. There were 1187 entries in the accesslog DBs of all 4 nodes. On the minus side, while server IDs 2,3, and 4 all agreed on the final resulting contextCSN, serverID 1 did not. Which then broke the ability for the nodes to communicate with each other (err=53) Last entry on serverIDs 1/2/3/4: dn: reqStart=20180130233019.000017Z,cn=accesslog objectClass: auditModify reqStart: 20180130233019.000017Z reqEnd: 20180130233019.000018Z reqType: modify reqSession: 1 reqAuthzID: cn=ldaproot,dc=xxx,dc=yyy reqDN: dc=xxx,dc=yyy reqResult: 0 reqMod: contextCSN:= 20180130233019.035885Z#000000#001#000000 reqMod: contextCSN:= 20171130222521.056018Z#000000#002#000000 reqMod: contextCSN:= 20171130222318.939265Z#000000#003#000000 reqMod: contextCSN:= 20171203041258.811473Z#000000#004#000000 reqEntryUUID: 156eb8cc-18e9-1027-80e5-d3f2010890dc contextCSNs on 2/3/4: base contextCSN: 20180130233019.035885Z#000000#001#000000 contextCSN: 20171130222521.056018Z#000000#002#000000 contextCSN: 20171130222318.939265Z#000000#003#000000 contextCSN: 20171203041258.811473Z#000000#004#000000 accesslog contextCSN: 20180130233019.035885Z#000000#001#000000 contextCSN: 20171130222521.056018Z#000000#002#000000 contextCSN: 20171130222318.939265Z#000000#003#000000 contextCSN: 20171203041258.811473Z#000000#004#000000 contextCSNs on 1: base contextCSN: 20180130233019.035885Z#000000#001#000000 contextCSN: 20171130222521.056018Z#000000#002#000000 contextCSN: 20171130222318.939265Z#000000#003#000000 contextCSN: 20171203041258.811473Z#000000#004#000000 accesslog contextCSN: 20180130233016.137867Z#000000#001#000000 contextCSN: 20171130222521.056018Z#000000#002#000000 contextCSN: 20171130222318.939265Z#000000#003#000000 contextCSN: 20171203041258.811473Z#000000#004#000000 Note that the contextCSN is correct on the database root, but incorrect in the accesslog entry. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8800) MMR: out of date master will ignore history of its own changes
by quanah＠openldap.org 30 Jan '18

30 Jan '18

Full_Name: Quanah Gibson-Mount Version: 2.4.45 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) Did the following test: 4-way MMR setup, database populated from an initial DB that has history to it Make several thousand MODs to serverID 1 only Stop serverID 1 wipe its database reload serverID 1 from the initial DB Expected result: serverID 1 REFRESHes from the other servers to sync up its database Actual result: serverID 1 updates its contextCSN to the last change op, but does not sync any actual changes back, leaving it out of sync with the rest of the cluster.

1 0

Re: (ITS#8100) Empty accesslog causes issues with delta-syncrepl MMR configurations
by quanah＠symas.com 29 Jan '18

29 Jan '18

--On Monday, January 29, 2018 10:23 AM -0800 Quanah Gibson-Mount <quanah(a)symas.com> wrote: > I'll continue testing for the other half of the fix (Deleting all but the > most recent entry from the accesslog during purge) This part appears to work as desired. I set the purge interval to 10 minutes, checking every 5 minutes. Made changes. All entries but the most recent one were removed after 15 minutes went by. Made more changes, did the same wait period, and again, all entries but the most recent were removed during the next cleanup interval. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8100) Empty accesslog causes issues with delta-syncrepl MMR configurations
by quanah＠symas.com 29 Jan '18

29 Jan '18

--On Friday, January 26, 2018 8:23 PM +0000 hyc(a)symas.com wrote: > A patch which skips deleting the final entry, and creates an initial > dummy log entry if needed, is available in > https://github.com/quanah/openldap-scratch/tree/its8100 for testing. Hi Howard, When reinstalling a 4-way MMR system from scratch, we still end up in REFRESH mode. In the database I'm loading, there are 4 contextCSN values, one per active master: contextCSN: 20171203010043.825769Z#000000#001#000000 contextCSN: 20171130222521.056018Z#000000#002#000000 contextCSN: 20171130222318.939265Z#000000#003#000000 contextCSN: 20171203041258.811473Z#000000#004#000000 When I start up the first master (serverID 4 in this case), a contextCSN value is properly written for it to the underlying db: Jan 29 10:06:06 anvil4 slapd[1949]: slapd starting Jan 29 10:06:06 anvil4 slapd[1949]: slap_queue_csn: queueing 0x7f54d4104220 20171203041258.811473Z#000000#004#000000 Jan 29 10:06:06 anvil4 slapd[1949]: slap_queue_csn: queueing 0x7f54d4104cc0 20171203041258.811473Z#000000#004#000000 Jan 29 10:06:06 anvil4 slapd[1949]: slap_graduate_commit_csn: removing 0x7f54d4104cc0 20171203041258.811473Z#000000#004#000000 Jan 29 10:06:06 anvil4 slapd[1949]: slap_graduate_commit_csn: removing 0x7f54d4104220 20171203041258.811473Z#000000#004#000000 But when I start the other 3 masters, they do not write an entry for their CSN, and since there's no CSN value for them on the other masters either, they all fall back to REFRESH_DELETE: Jan 29 10:06:26 anvil4 slapd[1949]: do_syncrep2: rid=003 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Even worse, they do this for every master that comes online. I think the code needs to add an entry to the accesslog for every contextCSN value, not just the final contextCSN? I'll continue testing for the other half of the fix (Deleting all but the most recent entry from the accesslog during purge) Thanks! --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8553) LMDB Windows UWP Patch
by hyc＠symas.com 29 Jan '18

29 Jan '18

temp(a)zeropass-app.io wrote: > Hi, why is this not merged yet? Any particular reason? Lack of support. AFAICS the only reason UWP exists is to support Windows 10 Mobile, which Microsoft has discontinued. The LMDB source is C code. Compiling under a C++ compiler is a non-goal and we will not support C++ syntax compatibility going forward. Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8553) LMDB Windows UWP Patch
by temp＠zeropass-app.io 29 Jan '18

29 Jan '18

Hi, why is this not merged yet? Any particular reason?

1 0

Re: (ITS#8486) Syncprov sessionlog is inefficient, kills perf
by hyc＠symas.com 26 Jan '18

26 Jan '18

quanah(a)zimbra.com wrote: > --On Monday, August 29, 2016 9:16 PM +0000 quanah(a)openldap.org wrote: > >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.44 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.52.177) > > In doing testing for ITS#8491, I encountered this problem in my lab. Any > time a single replica is parsing the session log, all other operations on > the server come to a complete halt. I.e., slapd does *nothing* other than > handle the sessionlog query. This seems like a fatal problem. A patch for this is available for testing in https://github.com/quanah/openldap-scratch/tree/its8486. It no longer keeps the sessionlog mutex locked for the entire time that it's playing the log. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8100) Empty accesslog causes issues with delta-syncrepl MMR configurations
by hyc＠symas.com 26 Jan '18

26 Jan '18

quanah(a)symas.com wrote: > --On Thursday, April 09, 2015 5:42 AM +0000 quanah(a)openldap.org wrote: > >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.39 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (50.25.188.166) >> >> >> When one has an MMR setup using delta-syncrepl, and the masters get into a >> situation where one is out of sync, or adding a new MMR node to an >> existing cluster, things will be broken until the new/reloaded node has a >> write op that goes to the accesslog DB. In an existing cluster, where a >> node is being reloaded, it causes all nodes to go into an endless looping >> fallback sync until that write occurs. > > One possible fix for this, would be to refuse to delete the final entry in > the accesslog during the purge phase. That way, the accesslog would never > be empty. I'm not sure how difficult this would be to implement, code wise. A patch which skips deleting the final entry, and creates an initial dummy log entry if needed, is available in https://github.com/quanah/openldap-scratch/tree/its8100 for testing. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8791) OpenSSL 1.1.1 compat issue
by quanah＠symas.com 25 Jan '18

25 Jan '18

Hi Bradley, I believe it's waiting on a review from Howard. I also plan on throwing it into my scratch repo and testing when I get the time, but my primary focus at the moment is migrating the OpenLDAP project to new infrastructure and a new bug tracking system. ;) --Quanah --On Wednesday, January 24, 2018 10:23 PM +0000 bbaetz(a)google.com wrote: > --089e082f9ab494ea2405638d1cae > Content-Type: text/plain; charset="UTF-8" > > Is there anything else I need to do in order to get this committed? > > Bradley > > On Fri, 15 Dec 2017 at 12:08 Bradley Baetz <bbaetz(a)google.com> wrote: > >> Done in ftp://ftp.openldap.org/incoming/bradley-baetz-20171215.patch >> >> >> On Fri, 15 Dec 2017 at 04:36 Howard Chu <hyc(a)symas.com> wrote: >> >>> bbaetz(a)google.com wrote: >>> > Full_Name: Bradley Baetz >>> > Version: 2.4.45 >>> > OS: linux >>> > URL: ftp://ftp.openldap.org/incoming/bradley-baetz-20171214.patch >>> > Submission from: (NULL) (2401:fa00:9:11:7ac0:58b5:299c:bebb) >>> >>> Thanks for the patch. The initialization of the static tlso_bio_method >>> is racy. One-time initializations should be done in tlso_init, and the >>> allocated >>> memory should be freed in tlso_destroy. >>> >>> > >>> > ITS#8533 added support for the OpenSSL's hiding of the bio_method_st >>> struct. >>> > >>> > However, it did this by re-defining the now-private structure, using >>> the OpenSSL >>> > 1.0 version. That will fail when OpenSSL changes their structure, >>> > which >>> they >>> > have already done for v1.1.1 - see >>> > >>> https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=include/internal >>> /bio.h;hb=e1dd8fa00a1e06d27c8b024dac7657a8d8a9b451#l16 >>> > >>> > It also fails with BoringSSL, which has v1.0's OPENSSL_VERSION_NUMBER >>> define, >>> > but has not yet hidden the struct definition. >>> > >>> > The attached file is derived from OpenLDAP Software. All of the >>> modifications to >>> > OpenLDAP Software represented in the following patch(es) were >>> > developed >>> by >>> > Google, LLC. Google, LLC has not assigned rights and/or interest in >>> this work to >>> > any party. I, Bradley Baetz am authorized by Google, LLC, my employer, >>> to >>> > release this work under the following terms. >>> > >>> > The attached modifications to OpenLDAP Software are subject to the >>> following >>> > notice: >>> > Copyright 2017 Google, LLC. >>> > Redistribution and use in source and binary forms, with or without >>> modification, >>> > are permitted only as authorized by the OpenLDAP Public License. >>> > >>> > >>> >>> >>> -- >>> -- Howard Chu >>> CTO, Symas Corp. http://www.symas.com >>> Director, Highland Sun http://highlandsun.com/hyc/ >>> Chief Architect, OpenLDAP http://www.openldap.org/project/ >>> >> > > --089e082f9ab494ea2405638d1cae > Content-Type: text/html; charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > > <div dir=3D"ltr">Is there anything else I need to do in order to get this > c= ommitted?<div> </div><div>Bradley</div></div> <div > class=3D"gmail_quo= te"><div dir=3D"ltr">On Fri, 15 Dec 2017 at 12:08 > Bradley Baetz <<a href= > =3D"mailto:bbaetz@google.com">bbaetz(a)google.com</a>> > wrote: </div><bl= ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 > .8ex;border-left:1px #= ccc solid;padding-left:1ex"><div > dir=3D"ltr">Done in=C2=A0<a > href=3D"ftp://ftp.openldap.org/incoming/bradley-ba= etz-20171215.patch" > style=3D"font-size:small" target=3D"_blank">ftp://ftp.o= > penldap.org/incoming/bradley-baetz-20171215.patch</a> class=3D"m_906= > 2438285945864329inbox-inbox-Apple-interchange-newline"></div> <div > class= =3D"gmail_quote"><div dir=3D"ltr">On Fri, 15 Dec 2017 at 04:36 > Howard Chu &= lt;<a href=3D"mailto:hyc@symas.com" > target=3D"_blank">hyc(a)symas.com</a>>= wrote: </div><blockquote > class=3D"gmail_quote" style=3D"margin:0 0 0 .8= ex;border-left:1px #ccc > solid;padding-left:1ex"><a href=3D"mailto:bbaetz@go= ogle.com" > target=3D"_blank">bbaetz(a)google.com</a> wrote: > > Full_Name: Bradley Baetz > > Version: 2.4.45 > > OS: linux > > URL: <a > href=3D"ftp://ftp.openldap.org/incoming/bradley-baetz-20171214= .patch" > rel=3D"noreferrer" target=3D"_blank">ftp://ftp.openldap.org/incomin= > g/bradley-baetz-20171214.patch</a> > > Submission from: (NULL) (2401:fa00:9:11:7ac0:58b5:299c:bebb) > > Thanks for the patch. The initialization of the static tlso_bio_method > is<b= r> > racy. One-time initializations should be done in tlso_init, and the > allocat= ed > memory should be freed in tlso_destroy. > > > > > ITS#8533 added support for the OpenSSL's hiding of the > bio_method_= st struct. > > > > However, it did this by re-defining the now-private structure, using > t= he OpenSSL > > 1.0 version. That will fail when OpenSSL changes their structure, > whic= h they > > have already done for v1.1.1 - see > > <a > href=3D"https://git.openssl.org/gitweb/?p=3Dopenssl.git;a=3Dblob;f= > =3Dinclude/internal/bio.h;hb=3De1dd8fa00a1e06d27c8b024dac7657a8d8a9b451#l > 16= " rel=3D"noreferrer" > target=3D"_blank">https://git.openssl.org/gitweb/?p=3D= > openssl.git;a=3Dblob;f=3Dinclude/internal/bio.h;hb=3De1dd8fa00a1e06d27c8b > 02= 4dac7657a8d8a9b451#l16</a> > > > > It also fails with BoringSSL, which has v1.0's > OPENSSL_VERSION_NUM= BER define, > > but has not yet hidden the struct definition. > > > > The attached file is derived from OpenLDAP Software. All of the > modifi= cations to > > OpenLDAP Software represented in the following patch(es) were > develope= d by > > Google, LLC. Google, LLC has not assigned rights and/or interest in > th= is work to > > any party. I, Bradley Baetz am authorized by Google, LLC, my > employer,= to > > release this work under the following terms. > > > > The attached modifications to OpenLDAP Software are subject to the > fol= lowing > > notice: > > Copyright 2017 Google, LLC. > > Redistribution and use in source and binary forms, with or without > mod= ification, > > are permitted only as authorized by the OpenLDAP Public License. > > > > > > > -- > =C2=A0 =C2=A0-- Howard Chu > =C2=A0 =C2=A0CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a > hr= ef=3D"http://www.symas.com" rel=3D"noreferrer" > target=3D"_blank">http://www= .symas.com</a> > =C2=A0 =C2=A0Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a > href=3D"http://hi= ghlandsun.com/hyc/" rel=3D"noreferrer" > target=3D"_blank">http://highlandsun= .com/hyc/</a> > =C2=A0 =C2=A0Chief Architect, OpenLDAP=C2=A0 <a > href=3D"http://www.openldap= .org/project/" rel=3D"noreferrer" > target=3D"_blank">http://www.openldap.org= /project/</a> > </blockquote></div></blockquote></div> > > --089e082f9ab494ea2405638d1cae-- > > > -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8791) OpenSSL 1.1.1 compat issue
by bbaetz＠google.com 24 Jan '18

24 Jan '18

--089e082f9ab494ea2405638d1cae Content-Type: text/plain; charset="UTF-8" Is there anything else I need to do in order to get this committed? Bradley On Fri, 15 Dec 2017 at 12:08 Bradley Baetz <bbaetz(a)google.com> wrote: > Done in ftp://ftp.openldap.org/incoming/bradley-baetz-20171215.patch > > > On Fri, 15 Dec 2017 at 04:36 Howard Chu <hyc(a)symas.com> wrote: > >> bbaetz(a)google.com wrote: >> > Full_Name: Bradley Baetz >> > Version: 2.4.45 >> > OS: linux >> > URL: ftp://ftp.openldap.org/incoming/bradley-baetz-20171214.patch >> > Submission from: (NULL) (2401:fa00:9:11:7ac0:58b5:299c:bebb) >> >> Thanks for the patch. The initialization of the static tlso_bio_method is >> racy. One-time initializations should be done in tlso_init, and the >> allocated >> memory should be freed in tlso_destroy. >> >> > >> > ITS#8533 added support for the OpenSSL's hiding of the bio_method_st >> struct. >> > >> > However, it did this by re-defining the now-private structure, using >> the OpenSSL >> > 1.0 version. That will fail when OpenSSL changes their structure, which >> they >> > have already done for v1.1.1 - see >> > >> https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=include/internal/bio… >> > >> > It also fails with BoringSSL, which has v1.0's OPENSSL_VERSION_NUMBER >> define, >> > but has not yet hidden the struct definition. >> > >> > The attached file is derived from OpenLDAP Software. All of the >> modifications to >> > OpenLDAP Software represented in the following patch(es) were developed >> by >> > Google, LLC. Google, LLC has not assigned rights and/or interest in >> this work to >> > any party. I, Bradley Baetz am authorized by Google, LLC, my employer, >> to >> > release this work under the following terms. >> > >> > The attached modifications to OpenLDAP Software are subject to the >> following >> > notice: >> > Copyright 2017 Google, LLC. >> > Redistribution and use in source and binary forms, with or without >> modification, >> > are permitted only as authorized by the OpenLDAP Public License. >> > >> > >> >> >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/project/ >> > --089e082f9ab494ea2405638d1cae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Is there anything else I need to do in order to get this c= ommitted?<div> </div><div>Bradley</div></div> <div class=3D"gmail_quo= te"><div dir=3D"ltr">On Fri, 15 Dec 2017 at 12:08 Bradley Baetz <<a href= =3D"mailto:bbaetz@google.com">bbaetz(a)google.com</a>> wrote: </div><bl= ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #= ccc solid;padding-left:1ex"><div dir=3D"ltr">Done in=C2=A0<a href=3D"ftp://ftp.openldap.org/incoming/bradley-ba= etz-20171215.patch" style=3D"font-size:small" target=3D"_blank">ftp://ftp.o= penldap.org/incoming/bradley-baetz-20171215.patch</a> </div> <div class= =3D"gmail_quote"><div dir=3D"ltr">On Fri, 15 Dec 2017 at 04:36 Howard Chu &= lt;<a href=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com</a>>= wrote: </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8= ex;border-left:1px #ccc solid;padding-left:1ex"><a href=3D"mailto:bbaetz@go= ogle.com" target=3D"_blank">bbaetz(a)google.com</a> wrote: > Full_Name: Bradley Baetz > Version: 2.4.45 > OS: linux > URL: <a href=3D"ftp://ftp.openldap.org/incoming/bradley-baetz-20171214= .patch" rel=3D"noreferrer" target=3D"_blank">ftp://ftp.openldap.org/incomin= g/bradley-baetz-20171214.patch</a> > Submission from: (NULL) (2401:fa00:9:11:7ac0:58b5:299c:bebb) Thanks for the patch. The initialization of the static tlso_bio_method is<b= r> racy. One-time initializations should be done in tlso_init, and the allocat= ed memory should be freed in tlso_destroy. > > ITS#8533 added support for the OpenSSL's hiding of the bio_method_= st struct. > > However, it did this by re-defining the now-private structure, using t= he OpenSSL > 1.0 version. That will fail when OpenSSL changes their structure, whic= h they > have already done for v1.1.1 - see > <a href=3D"https://git.openssl.org/gitweb/?p=3Dopenssl.git;a=3Dblob;f= =3Dinclude/internal/bio.h;hb=3De1dd8fa00a1e06d27c8b024dac7657a8d8a9b451#l16= " rel=3D"noreferrer" target=3D"_blank">https://git.openssl.org/gitweb/?p=3D= openssl.git;a=3Dblob;f=3Dinclude/internal/bio.h;hb=3De1dd8fa00a1e06d27c8b02= 4dac7657a8d8a9b451#l16</a> > > It also fails with BoringSSL, which has v1.0's OPENSSL_VERSION_NUM= BER define, > but has not yet hidden the struct definition. > > The attached file is derived from OpenLDAP Software. All of the modifi= cations to > OpenLDAP Software represented in the following patch(es) were develope= d by > Google, LLC. Google, LLC has not assigned rights and/or interest in th= is work to > any party. I, Bradley Baetz am authorized by Google, LLC, my employer,= to > release this work under the following terms. > > The attached modifications to OpenLDAP Software are subject to the fol= lowing > notice: > Copyright 2017 Google, LLC. > Redistribution and use in source and binary forms, with or without mod= ification, > are permitted only as authorized by the OpenLDAP Public License. > > -- =C2=A0 =C2=A0-- Howard Chu =C2=A0 =C2=A0CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a hr= ef=3D"http://www.symas.com" rel=3D"noreferrer" target=3D"_blank">http://www= .symas.com</a> =C2=A0 =C2=A0Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://hi= ghlandsun.com/hyc/" rel=3D"noreferrer" target=3D"_blank">http://highlandsun= .com/hyc/</a> =C2=A0 =C2=A0Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap= .org/project/" rel=3D"noreferrer" target=3D"_blank">http://www.openldap.org= /project/</a> </blockquote></div></blockquote></div> --089e082f9ab494ea2405638d1cae--

1 0

Re: (ITS#8799) slaptest fails to properly convert chain configuration
by ondra＠mistotebe.net 23 Jan '18

23 Jan '18

On Mon, Jan 22, 2018 at 09:59:21PM +0000, quanah(a)openldap.org wrote: > The process for converting a slapd configuration to cn=config making use of > slapo-chain at a global level is seriously broken. It's not as bad, just a little bit broken: > This can be trivially illustrated by using the slapd.conf generated by test032. > > After doing conversion, the resulting cn=config database has *two* ldap backends > defined: > > dn: olcDatabase={-1}frontend,cn=config > dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config > dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=conf This is the catchall database used to handle referrals that are not handled by any other database you configure by hand. It collects all the chain-* settings that appear before the first chain-uri. > dn: olcDatabase={1}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=conf > > The first instance ({0}ldap,...) isn't even valid. If you remove the entire > chain configuration from this database, and then attempt to import it, you get > the following: Yeah that is a problem. > ldap_add: Object class violation (65) > > This is because the first instance ({0}) is *missing* the required olcDbURI > attribute. In addition, it generates completely bogus attribute values (See > ITS#8693) Maybe we just need to inherit objectclass: olcLdapDatabase somehow in olcChainOverlay and keep these settings in the overlay entry, or specify a bogus URI to be configured there. Whatever is most useable and still allows for seamless expansion. > The *second* generated LDAP backend database is what is correct. > > Here's the LDIF for the incorrect database: > > [...] > > Here's the LDIF for the *correct* database: > > [...] -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

(ITS#8799) slaptest fails to properly convert chain configuration
by quanah＠openldap.org 22 Jan '18

22 Jan '18

Full_Name: Quanah Gibson-Mount Version: 2.4.45 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) The process for converting a slapd configuration to cn=config making use of slapo-chain at a global level is seriously broken. This can be trivially illustrated by using the slapd.conf generated by test032. After doing conversion, the resulting cn=config database has *two* ldap backends defined: dn: olcDatabase={-1}frontend,cn=config dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=conf dn: olcDatabase={1}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=conf The first instance ({0}ldap,...) isn't even valid. If you remove the entire chain configuration from this database, and then attempt to import it, you get the following: ldapadd -H ldap:/// -D cn=config -w secret -f ./olcOverlay\=\{0\}chain.ldif adding new entry "olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config" ldapadd -H ldap:/// -D cn=config -w secret -f ./olcDatabase\=\{0\}ldap.ldif adding new entry "olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config" ldap_add: Object class violation (65) This is because the first instance ({0}) is *missing* the required olcDbURI attribute. In addition, it generates completely bogus attribute values (See ITS#8693) The *second* generated LDAP backend database is what is correct. Here's the LDIF for the incorrect database: dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbStartTLS: none starttls=no olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: FALSE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0 Here's the LDIF for the *correct* database: dn: olcDatabase={1}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {1}ldap olcDbURI: "ldap://localhost:9012" olcDbStartTLS: none starttls=no olcDbIDAssertBind: mode=self flags=non-prescriptive,proxy-authz-non-critical bindmethod=simple timeout=0 network-timeout=0 binddn="cn=manager,dc=exampl e,dc=com" credentials="secret" keepalive=0:0:0 olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: FALSE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0 However, even in the case of the *correct* LDIF, the bogus olcDbStartTLS attribute is defined (Again, ITS#8693) This is the slapd.conf used to convert: include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/openldap.schema include /usr/local/etc/openldap/schema/nis.schema pidfile /tmp/slapd.1.pid argsfile /tmp/slapd.1.args modulepath /usr/local/libexec/openldap moduleload back_mdb.la moduleload back_ldap.la moduleload back_monitor.la overlay chain chain-uri ldap://localhost:9012/ chain-idassert-bind bindmethod=simple binddn="cn=Manager,dc=example,dc=com" credentials=secret mode=self flags=non-prescriptive database mdb suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" rootpw secret directory /tmp/db.1.a index objectClass eq index cn,sn,uid pres,eq,sub database monitor

1 0

Re: (ITS#8798) slapd-tester tools improvements
by hyc＠symas.com 16 Jan '18

16 Jan '18

ondra(a)openldap.org wrote: > Full_Name: Ondrej Kuznik > Version: master > OS: > URL: https://github.com/mistotebe/openldap/tree/ITS8798 > Submission from: (NULL) (82.10.24.68) > > > The above branch unifies most of the configuration/set-up between the tester > programs and adds support for the following: > - retry support for binds > - debug level (-d option) > - SASL bind support > > slapd-tester and slapd-auth (a slamd helper) are left intact. > > Looks great. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8798) slapd-tester tools improvements
by ondra＠openldap.org 16 Jan '18

16 Jan '18

Full_Name: Ondrej Kuznik Version: master OS: URL: https://github.com/mistotebe/openldap/tree/ITS8798 Submission from: (NULL) (82.10.24.68) The above branch unifies most of the configuration/set-up between the tester programs and adds support for the following: - retry support for binds - debug level (-d option) - SASL bind support slapd-tester and slapd-auth (a slamd helper) are left intact.

1 0

Re: (ITS#8797) improper use of gnutls causes segfault
by hyc＠symas.com 16 Jan '18

16 Jan '18

lukas(a)selfnet.de wrote: >> PAM should be using nss-pam-ldapd, not calling libldap directly. This >> is an architectural flaw in both GnuTLS and PAM, not an OpenLDAP bug. >> This ITS is invalid. > > It's called _lib_ldap after all, so are other projects linking against / > dlopen()ing libldap doing the wrong thing? PAM should not be polluting the application namespace with libraries that the application may itself be using. The same type of problems arise if e.g. the application uses Kerberos and PAM also uses Kerberos, and the application and PAM want to use different configurations. The only correct way for a PAM module to work is to never expose its underlying libraries to the calling application. This is not an OpenLDAP issue. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs