openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

Re: (ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index
by h.b.furuseth＠usit.uio.no 04 Feb '19

04 Feb '19

The reason I like handling the problem in tpool is that tpools is fairly isolated, no worries about which bconfig parts are safe from each other. But by all means attack the problem in bconfig too:-) I've pushed a better version to <git://git.uio.no/u/hbf/openldap.git> branch "its8958-re24-task-speeds-v2". And I see how to port this to master after all, if anyone wants this included in OpenLDAP. RE24 tpool is simpler when discusissing the basics, though. -- Hallvard

1 0

RE: (ITS#8970) bind fails when length value is multi-byte
by lit＠CBORD.com 04 Feb '19

04 Feb '19

SSBqdXN0IG5vdGljZWQgdGhhdCBteSB0d28gdGVzdHMgZGlmZmVyIG9uIHRoZSBjYXNpbmVzcyBv ZiB0aGUgdXNlciBuYW1lLCBidXQgdGhhdCdzIG5vdCBzaWduaWZpY2FudC4gIEkgdGVzdGVkIGFn YWluIHRvIGJlIHN1cmUuIA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBI b3dhcmQgQ2h1IDxoeWNAc3ltYXMuY29tPiANClNlbnQ6IFN1bmRheSwgRmVicnVhcnkgMywgMjAx OSAxMDoyNSBQTQ0KVG86IExlbyBUb2hpbGwgPGxpdEBDQk9SRC5jb20+OyBvcGVubGRhcC1pdHNA T3BlbkxEQVAub3JnDQpTdWJqZWN0OiBSZTogKElUUyM4OTcwKSBiaW5kIGZhaWxzIHdoZW4gbGVu Z3RoIHZhbHVlIGlzIG11bHRpLWJ5dGUNCg0KbGl0QGNib3JkLmNvbSB3cm90ZToNCj4gRnVsbF9O YW1lOiBMZW8gVG9oaWxsDQo+IFZlcnNpb246IDIuNC4zMA0KPiBPUzogV2luZG93cyAxMA0KPiBV Ukw6IA0KPiBodHRwczovL2RvY3MuZ29vZ2xlLmNvbS9kb2N1bWVudC9kLzEwdUtnOU5oM0hMaXVP elRiTGZpNlo3YkNmVWI4eF9BaTZXDQo+IEs1THFOemJ3QS9lZGl0P3VzcD1zaGFyaW5nDQo+IFN1 Ym1pc3Npb24gZnJvbTogKE5VTEwpICg3NC43OS44LjQxKQ0KPiANCj4gDQo+IFN1bW1hcnk6IG9w ZW5sZGFwIDIuNC4zMCBkb2VzIG5vdCBhY2NvbW1vZGF0ZSBtdWx0aS1ieXRlIGxlbmd0aCB2YWx1 ZSANCj4gb24gYmluZCByZXF1ZXN0Lg0KPiANCj4gDQo+IEZpcnN0LCBJJ2xsIGFkbWl0IHRoYXQg SSdtIG91dCBvZiBteSBkZXB0aCBoZXJlLCBJJ20gcnVubmluZyBhIG9sZGVyIA0KPiB2ZXJzaW9u LCBJJ20gb24gV2luZG93cywgYW5kIG15IHBhY2thZ2Ugd2FzIGJ1aWx0IGJ5IEkgZG9uJ3Qga25v dy4gIA0KPiBCdXQgSSB3b3JrZWQgaGFyZCBlbm91Z2ggdG8gdHJhY2sgdGhpcyBkb3duIHRoYXQg SSB3YW50IHlvdSB0byBrbm93IA0KPiB3aGF0IEkgZm91bmQuICBJIG1pZ2h0IHVwZ3JhZGUsIGJ1 dCB0aGF0J3MgcHJvYmxlbWF0aWMuDQo+IA0KPiBBdCBzb21lIHBvaW50IG15IGJpbmRpbmdzIGZy b20gLm5ldCBiZWdhbiBmYWlsaW5nIHdpdGggInRoZSB1c2VybmFtZSANCj4gb3IgcGFzc3dvcmQg aXMgaW5jb3JyZWN0IiBCdXQgdGhleSB3ZXJlIGNvcnJlY3QuICBJIGNvdWxkIGNvbmZpcm0gd2l0 aCB2YXJpb3VzIG90aGVyIHRvb2xzLg0KPiBJIGNhcHR1cmVkIHRoZSB3aXJlIHRyYWZmaWMgdG8g aXNvbGF0ZSB0aGUgcHJvYmxlbS4gSXQgdHVybnMgb3V0IHRoYXQgDQo+IFdpbmRvd3MgZm9ybXMg dGhlIGJpbmRpbmcgcmVxdWVzdCB1c2luZyAgYSBtdWx0aS1ieXRlIGxlbmd0aCBpbmRpY2F0b3Ig aW4gdGhlIHJlcXVlc3QuDQo+IE9wZW5MZGFwIGFwcGFyZW50bHkgZG9lcyBub3QgYWNjb21tb2Rh dGUgdGhpcy4gIEkgY29tcGFyZWQgdG8gYSANCj4gcmVxdWVzdCBnZW5lcmF0ZWQgYnkgIGxkYXBz ZWFyY2guZXhlLiAgVGhhdCByZXF1ZXN0LCB3aGljaCBzdWNjZWVkcywgIA0KPiB2YXJpZXMgb25s eSBieSB1c2luZyBhIHNpbmdsZS1ieXRlIGxlbmd0aCBpbmRpY2F0b3IuDQo+IA0KPiBUaGUgbXVs dGktYnl0ZSBsZW5ndGggdmFsdWUgc2hvdWxkIGJlIGFsbG93ZWQsIHJpZ2h0PyAgSXNuJ3QgaXQg DQo+IHBvc3NpYmxlIHRvIGhhdmUgYSBiaW5kIHJlcXVlc3QgZGF0YSBwYWNrZXQgb2YgbGVuZ3Ro ID4gMTI3PyAgV2hpY2ggDQo+IHdvdWxkIHJlcXVpcmUgYSBtdWx0aS1ieXRlIGxlbmd0aCB2YWx1 ZS4gIFBlcmhhcHMgdGhpcyB3YXMgZml4ZWQgaW4gYSBsYXRlciB2ZXJzaW9uLg0KPiANCj4gU2Ny ZWVuc2hvdHMgb2YgdGhlIHdpcmUgY2FwdHVyZSBoZXJlOiANCj4gDQo+IGh0dHBzOi8vZG9jcy5n b29nbGUuY29tL2RvY3VtZW50L2QvMTB1S2c5TmgzSExpdU96VGJMZmk2WjdiQ2ZVYjh4X0FpNlcN Cj4gSzVMcU56YndBL2VkaXQ/dXNwPXNoYXJpbmcNCg0KVGhpcyBVUkwgaXMgaW5hY2Nlc3NpYmxl LCBwZXJtaXNzaW9uIGRlbmllZC4NCg0KSnVzdCBjb3B5IGhleCBkdW1wcyBvZiBib3RoIHJlcXVl c3RzIGhlcmUgaW4gdGV4dC4NCg0KLS0NCiAgLS0gSG93YXJkIENodQ0KICBDVE8sIFN5bWFzIENv cnAuICAgICAgICAgICBodHRwOi8vd3d3LnN5bWFzLmNvbQ0KICBEaXJlY3RvciwgSGlnaGxhbmQg U3VuICAgICBodHRwOi8vaGlnaGxhbmRzdW4uY29tL2h5Yy8NCiAgQ2hpZWYgQXJjaGl0ZWN0LCBP cGVuTERBUCAgaHR0cDovL3d3dy5vcGVubGRhcC5vcmcvcHJvamVjdC8NCg==

1 0

RE: (ITS#8970) bind fails when length value is multi-byte
by lit＠CBORD.com 03 Feb '19

03 Feb '19

ZnJhbWUgY2FwdHVyZXMgZm9sbG93LiAgTGRhcCBtZXNzYWdlIGJlZ2lucyBhdCBvZmZzZXQgMHgz NiAoYWZ0ZXIgZXRoZXJuZXQsIGlwLCB0Y3AgaGVhZGVycykNCnN1Y2Nlc3M6DQowMCBGRiAwNiAx NiBFNiBFMSAwMCBGRiAwNSAxNiBFNiBFMSAwOCAwMCA0NSAwMCAwMCA1MyA2QiBGRSA0MCAwMCA4 MCAwNiA0RiBGNCAwQSAwMSAyOCAyQSAwQSA3OCAwMiAxMCBENSAwOCAwMSA4NSAzMiBGQiAyQiBF NiA1MCAxNSA0NyBGMSA1MCAxOCAwMSAwMCA5MCA0OCAwMCAwMCAzMCAyOSAwMiAwMSAwMSA2MCAy NCAwMiAwMSAwMyAwNCAxOSA2MyA2RSAzRCA1NSA3MyA2NSA3MiAzMSAyQyA2NCA2MyAzRCA2RCA2 MSA3OCA2MyA3MiA2MyAyQyA2NCA2MyAzRCA2MyA2RiA2RCA4MCAwNCA2OSA2RSA2OSA3NCANCg0K ZmFpbHVyZToNCjAwIEZGIDA2IDE2IEU2IEUxIDAwIEZGIDA1IDE2IEU2IEUxIDA4IDAwIDQ1IDAw IDAwIDVCIDA1IDNBIDQwIDAwIDgwIDA2IEI3IEUyIDBBIDAxIDI4IDJBIDBBIDAxIDAxIDU1IEQ2 IDBBIDAxIDg1IDRGIDREIEYxIEYwIDU3IDJGIDUxIDNDIDUwIDE4IDAxIDAwIDE5IDA2IDAwIDAw IDMwIDg0IDAwIDAwIDAwIDJEIDAyIDAxIDAxIDYwIDg0IDAwIDAwIDAwIDI0IDAyIDAxIDAzIDA0 IDE5IDYzIDZFIDNEIDc1IDczIDY1IDcyIDMxIDJDIDY0IDYzIDNEIDZEIDYxIDc4IDYzIDcyIDYz IDJDIDY0IDYzIDNEIDYzIDZGIDZEIDgwIDA0IDY5IDZFIDY5IDc0IA0KDQpGb3IgeW91ciBjb252 ZW5pZW5jZSAobm90IG5lZWRlZD8pLCBoZXJlIGlzIHRoZSBuZXR3b3JrIG1vbml0b3IgVUkgbGFi ZWxpbmcgZm9yIGVhY2ggZnJhbWUgKHN0YXJ0aW5nIGF0IGxkYXAgbWVzc2FnZSkNCg0Kc3VjY2Vz czoNCiAgRnJhbWU6IE51bWJlciA9IDExOCwgQ2FwdHVyZWQgRnJhbWUgTGVuZ3RoID0gOTcsIE1l ZGlhVHlwZSA9IEVUSEVSTkVUDQorIEV0aGVybmV0OiBFdHlwZSA9IEludGVybmV0IElQIChJUHY0 KSxEZXN0aW5hdGlvbkFkZHJlc3M6WzAwLUZGLTA2LTE2LUU2LUUxXSxTb3VyY2VBZGRyZXNzOlsw MC1GRi0wNS0xNi1FNi1FMV0NCisgSXB2NDogU3JjID0gMTAuMS40MC40MiwgRGVzdCA9IDEwLjEy MC4yLjE2LCBOZXh0IFByb3RvY29sID0gVENQLCBQYWNrZXQgSUQgPSAyNzY0NiwgVG90YWwgSVAg TGVuZ3RoID0gODMNCisgVGNwOiBGbGFncz0uLi5BUC4uLiwgU3JjUG9ydD01NDUzNiwgRHN0UG9y dD1MREFQKDM4OSksIFBheWxvYWRMZW49NDMsIFNlcT04NTUzMjE1NzQgLSA4NTUzMjE2MTcsIEFj az0xMzQzNTcxOTUzLCBXaW49MjU2IChzY2FsZSBmYWN0b3IgMHg4KSA9IDY1NTM2DQogIExkYXA6 IEJpbmQgUmVxdWVzdCwgTWVzc2FnZUlEOiAxLCBWZXJzaW9uOiAzDQotIExEQVBNZXNzYWdlOiBC aW5kIFJlcXVlc3QsIE1lc3NhZ2VJRDogMQ0KICAtIFBhcnNlckhlYWRlcjogDQogICAtIEFzbklk OiBTZXF1ZW5jZSBhbmQgU2VxdWVuY2VPZiB0eXBlcyAoVW5pdmVyc2FsIDE2KQ0KICAgIC0gTG93 VGFnOiANCiAgICAgICBDbGFzczogICAgKDAwLi4uLi4uKSBVbml2ZXJzYWwgKDApDQogICAgICAg VHlwZTogICAgICguLjEuLi4uLikgQ29uc3RydWN0ZWQNCiAgICAgICBUYWdWYWx1ZTogKC4uLjEw MDAwKSAxNg0KICAgLSBBc25MZW46IExlbmd0aCA9IDQxLCBMZW5ndGhPZkxlbmd0aCA9IDANCiAg ICAgIExlbmd0aDogNDEgYnl0ZXMsIExlbmd0aE9mTGVuZ3RoID0gMA0KICAtIE1lc3NhZ2VJRDog MQ0KICAgLSBBc25JbnRlZ2VySGVhZGVyOiANCiAgICAtIEFzbklkOiBJbnRlZ2VyIHR5cGUgKFVu aXZlcnNhbCAyKQ0KICAgICAtIExvd1RhZzogDQogICAgICAgIENsYXNzOiAgICAoMDAuLi4uLi4p IFVuaXZlcnNhbCAoMCkNCiAgICAgICAgVHlwZTogICAgICguLjAuLi4uLikgUHJpbWl0aXZlDQog ICAgICAgIFRhZ1ZhbHVlOiAoLi4uMDAwMTApIDINCiAgICAtIEFzbkxlbjogTGVuZ3RoID0gMSwg TGVuZ3RoT2ZMZW5ndGggPSAwDQogICAgICAgTGVuZ3RoOiAxIGJ5dGVzLCBMZW5ndGhPZkxlbmd0 aCA9IDANCiAgICAgQXNuSW50OiAxICgweDEpDQogIC0gT3BlcmF0aW9uSGVhZGVyOiBCaW5kIFJl cXVlc3QsIDAoMCkNCiAgIC0gQXNuSWQ6IEFwcGxpY2F0aW9uIENvbnN0cnVjdGVkIFRhZyAoMCkN CiAgICAtIExvd1RhZzogDQogICAgICAgQ2xhc3M6ICAgICgwMS4uLi4uLikgQXBwbGljYXRpb24g KDEpDQogICAgICAgVHlwZTogICAgICguLjEuLi4uLikgQ29uc3RydWN0ZWQNCiAgICAgICBUYWdW YWx1ZTogKC4uLjAwMDAwKSAwDQogICAtIEFzbkxlbjogTGVuZ3RoID0gMzYsIExlbmd0aE9mTGVu Z3RoID0gMA0KICAgICAgTGVuZ3RoOiAzNiBieXRlcywgTGVuZ3RoT2ZMZW5ndGggPSAwDQogIC0g QmluZFJlcXVlc3Q6IFZlcnNpb246MywgTmFtZTpjbj1Vc2VyMSxkYz1tYXhjcmMsZGM9Y29tLCBV c2VyTmFtZTogaW5pdCwgQXV0aGVudGljYXRpb24gdHlwZSA9IHNpbXBsZQ0KICAgLSBWZXJzaW9u OiAzDQogICAgLSBBc25JbnRlZ2VySGVhZGVyOiANCiAgICAgLSBBc25JZDogSW50ZWdlciB0eXBl IChVbml2ZXJzYWwgMikNCiAgICAgIC0gTG93VGFnOiANCiAgICAgICAgIENsYXNzOiAgICAoMDAu Li4uLi4pIFVuaXZlcnNhbCAoMCkNCiAgICAgICAgIFR5cGU6ICAgICAoLi4wLi4uLi4pIFByaW1p dGl2ZQ0KICAgICAgICAgVGFnVmFsdWU6ICguLi4wMDAxMCkgMg0KICAgICAtIEFzbkxlbjogTGVu Z3RoID0gMSwgTGVuZ3RoT2ZMZW5ndGggPSAwDQogICAgICAgIExlbmd0aDogMSBieXRlcywgTGVu Z3RoT2ZMZW5ndGggPSAwDQogICAgICBBc25JbnQ6IDMgKDB4MykNCiAgIC0gTmFtZTogY249VXNl cjEsZGM9bWF4Y3JjLGRjPWNvbQ0KICAgIC0gQXNuT2N0ZXRTdHJpbmdIZWFkZXI6IA0KICAgICAt IEFzbklkOiBPY3RldFN0cmluZyB0eXBlIChVbml2ZXJzYWwgNCkNCiAgICAgIC0gTG93VGFnOiAN CiAgICAgICAgIENsYXNzOiAgICAoMDAuLi4uLi4pIFVuaXZlcnNhbCAoMCkNCiAgICAgICAgIFR5 cGU6ICAgICAoLi4wLi4uLi4pIFByaW1pdGl2ZQ0KICAgICAgICAgVGFnVmFsdWU6ICguLi4wMDEw MCkgNA0KICAgICAtIEFzbkxlbjogTGVuZ3RoID0gMjUsIExlbmd0aE9mTGVuZ3RoID0gMA0KICAg ICAgICBMZW5ndGg6IDI1IGJ5dGVzLCBMZW5ndGhPZkxlbmd0aCA9IDANCiAgICAgIE9jdGV0U3Ry ZWFtOiBjbj1Vc2VyMSxkYz1tYXhjcmMsZGM9Y29tDQogICAtIEF1dGhlbnRpY2F0aW9uOiBVc2Vy TmFtZTogaW5pdCwgQXV0aGVudGljYXRpb24gdHlwZSA9IHNpbXBsZQ0KICAgIC0gQXV0aGVudGlj YXRpb25UeXBlSGVhZGVyOiBBdXRoZW50aWNhdGlvbiB0eXBlID0gc2ltcGxlDQogICAgIC0gQXNu SWQ6IENvbnRleHQgU3BlY2lmaWMgUHJpbWl0aXZlIFRhZyAoMCkNCiAgICAgIC0gTG93VGFnOiAN CiAgICAgICAgIENsYXNzOiAgICAoMTAuLi4uLi4pIENvblRleHQgc3BlY2lmaWMgKDIpDQogICAg ICAgICBUeXBlOiAgICAgKC4uMC4uLi4uKSBQcmltaXRpdmUNCiAgICAgICAgIFRhZ1ZhbHVlOiAo Li4uMDAwMDApIDANCiAgICAgLSBBc25MZW46IExlbmd0aCA9IDQsIExlbmd0aE9mTGVuZ3RoID0g MA0KICAgICAgICBMZW5ndGg6IDQgYnl0ZXMsIExlbmd0aE9mTGVuZ3RoID0gMA0KICAgICAgU2lt cGxlQXV0aGVudGljYXRpb246IGluaXQNCg0KDQpmYWlsdXJlOg0KDQogIEZyYW1lOiBOdW1iZXIg PSAzMCwgQ2FwdHVyZWQgRnJhbWUgTGVuZ3RoID0gMTA1LCBNZWRpYVR5cGUgPSBFVEhFUk5FVA0K KyBFdGhlcm5ldDogRXR5cGUgPSBJbnRlcm5ldCBJUCAoSVB2NCksRGVzdGluYXRpb25BZGRyZXNz OlswMC1GRi0wNi0xNi1FNi1FMV0sU291cmNlQWRkcmVzczpbMDAtRkYtMDUtMTYtRTYtRTFdDQor IElwdjQ6IFNyYyA9IDEwLjEuNDAuNDIsIERlc3QgPSAxMC4xLjEuODUsIE5leHQgUHJvdG9jb2wg PSBUQ1AsIFBhY2tldCBJRCA9IDEzMzgsIFRvdGFsIElQIExlbmd0aCA9IDkxDQorIFRjcDogRmxh Z3M9Li4uQVAuLi4sIFNyY1BvcnQ9NTQ3OTQsIERzdFBvcnQ9TERBUCgzODkpLCBQYXlsb2FkTGVu PTUxLCBTZXE9MTMzMDUwODI3MiAtIDEzMzA1MDgzMjMsIEFjaz0xNDYyNzE4NzgwLCBXaW49MjU2 IChzY2FsZSBmYWN0b3IgMHg4KSA9IDY1NTM2DQogIExkYXA6IEJpbmQgUmVxdWVzdCwgTWVzc2Fn ZUlEOiAxLCBWZXJzaW9uOiAzDQotIExEQVBNZXNzYWdlOiBCaW5kIFJlcXVlc3QsIE1lc3NhZ2VJ RDogMQ0KICAtIFBhcnNlckhlYWRlcjogDQogICAtIEFzbklkOiBTZXF1ZW5jZSBhbmQgU2VxdWVu Y2VPZiB0eXBlcyAoVW5pdmVyc2FsIDE2KQ0KICAgIC0gTG93VGFnOiANCiAgICAgICBDbGFzczog ICAgKDAwLi4uLi4uKSBVbml2ZXJzYWwgKDApDQogICAgICAgVHlwZTogICAgICguLjEuLi4uLikg Q29uc3RydWN0ZWQNCiAgICAgICBUYWdWYWx1ZTogKC4uLjEwMDAwKSAxNg0KICAgLSBBc25MZW46 IExlbmd0aCA9IDQ1LCBMZW5ndGhPZkxlbmd0aCA9IDQNCiAgICAgIExlbmd0aFR5cGU6IExlbmd0 aE9mTGVuZ3RoID0gNA0KICAgICAgTGVuZ3RoOiA0NSBieXRlcw0KICAtIE1lc3NhZ2VJRDogMQ0K ICAgLSBBc25JbnRlZ2VySGVhZGVyOiANCiAgICAtIEFzbklkOiBJbnRlZ2VyIHR5cGUgKFVuaXZl cnNhbCAyKQ0KICAgICAtIExvd1RhZzogDQogICAgICAgIENsYXNzOiAgICAoMDAuLi4uLi4pIFVu aXZlcnNhbCAoMCkNCiAgICAgICAgVHlwZTogICAgICguLjAuLi4uLikgUHJpbWl0aXZlDQogICAg ICAgIFRhZ1ZhbHVlOiAoLi4uMDAwMTApIDINCiAgICAtIEFzbkxlbjogTGVuZ3RoID0gMSwgTGVu Z3RoT2ZMZW5ndGggPSAwDQogICAgICAgTGVuZ3RoOiAxIGJ5dGVzLCBMZW5ndGhPZkxlbmd0aCA9 IDANCiAgICAgQXNuSW50OiAxICgweDEpDQogIC0gT3BlcmF0aW9uSGVhZGVyOiBCaW5kIFJlcXVl c3QsIDAoMCkNCiAgIC0gQXNuSWQ6IEFwcGxpY2F0aW9uIENvbnN0cnVjdGVkIFRhZyAoMCkNCiAg ICAtIExvd1RhZzogDQogICAgICAgQ2xhc3M6ICAgICgwMS4uLi4uLikgQXBwbGljYXRpb24gKDEp DQogICAgICAgVHlwZTogICAgICguLjEuLi4uLikgQ29uc3RydWN0ZWQNCiAgICAgICBUYWdWYWx1 ZTogKC4uLjAwMDAwKSAwDQogICAtIEFzbkxlbjogTGVuZ3RoID0gMzYsIExlbmd0aE9mTGVuZ3Ro ID0gNA0KICAgICAgTGVuZ3RoVHlwZTogTGVuZ3RoT2ZMZW5ndGggPSA0DQogICAgICBMZW5ndGg6 IDM2IGJ5dGVzDQogIC0gQmluZFJlcXVlc3Q6IFZlcnNpb246MywgTmFtZTpjbj11c2VyMSxkYz1t YXhjcmMsZGM9Y29tLCBVc2VyTmFtZTogaW5pdCwgQXV0aGVudGljYXRpb24gdHlwZSA9IHNpbXBs ZQ0KICAgLSBWZXJzaW9uOiAzDQogICAgLSBBc25JbnRlZ2VySGVhZGVyOiANCiAgICAgLSBBc25J ZDogSW50ZWdlciB0eXBlIChVbml2ZXJzYWwgMikNCiAgICAgIC0gTG93VGFnOiANCiAgICAgICAg IENsYXNzOiAgICAoMDAuLi4uLi4pIFVuaXZlcnNhbCAoMCkNCiAgICAgICAgIFR5cGU6ICAgICAo Li4wLi4uLi4pIFByaW1pdGl2ZQ0KICAgICAgICAgVGFnVmFsdWU6ICguLi4wMDAxMCkgMg0KICAg ICAtIEFzbkxlbjogTGVuZ3RoID0gMSwgTGVuZ3RoT2ZMZW5ndGggPSAwDQogICAgICAgIExlbmd0 aDogMSBieXRlcywgTGVuZ3RoT2ZMZW5ndGggPSAwDQogICAgICBBc25JbnQ6IDMgKDB4MykNCiAg IC0gTmFtZTogY249dXNlcjEsZGM9bWF4Y3JjLGRjPWNvbQ0KICAgIC0gQXNuT2N0ZXRTdHJpbmdI ZWFkZXI6IA0KICAgICAtIEFzbklkOiBPY3RldFN0cmluZyB0eXBlIChVbml2ZXJzYWwgNCkNCiAg ICAgIC0gTG93VGFnOiANCiAgICAgICAgIENsYXNzOiAgICAoMDAuLi4uLi4pIFVuaXZlcnNhbCAo MCkNCiAgICAgICAgIFR5cGU6ICAgICAoLi4wLi4uLi4pIFByaW1pdGl2ZQ0KICAgICAgICAgVGFn VmFsdWU6ICguLi4wMDEwMCkgNA0KICAgICAtIEFzbkxlbjogTGVuZ3RoID0gMjUsIExlbmd0aE9m TGVuZ3RoID0gMA0KICAgICAgICBMZW5ndGg6IDI1IGJ5dGVzLCBMZW5ndGhPZkxlbmd0aCA9IDAN CiAgICAgIE9jdGV0U3RyZWFtOiBjbj11c2VyMSxkYz1tYXhjcmMsZGM9Y29tDQogICAtIEF1dGhl bnRpY2F0aW9uOiBVc2VyTmFtZTogaW5pdCwgQXV0aGVudGljYXRpb24gdHlwZSA9IHNpbXBsZQ0K ICAgIC0gQXV0aGVudGljYXRpb25UeXBlSGVhZGVyOiBBdXRoZW50aWNhdGlvbiB0eXBlID0gc2lt cGxlDQogICAgIC0gQXNuSWQ6IENvbnRleHQgU3BlY2lmaWMgUHJpbWl0aXZlIFRhZyAoMCkNCiAg ICAgIC0gTG93VGFnOiANCiAgICAgICAgIENsYXNzOiAgICAoMTAuLi4uLi4pIENvblRleHQgc3Bl Y2lmaWMgKDIpDQogICAgICAgICBUeXBlOiAgICAgKC4uMC4uLi4uKSBQcmltaXRpdmUNCiAgICAg ICAgIFRhZ1ZhbHVlOiAoLi4uMDAwMDApIDANCiAgICAgLSBBc25MZW46IExlbmd0aCA9IDQsIExl bmd0aE9mTGVuZ3RoID0gMA0KICAgICAgICBMZW5ndGg6IDQgYnl0ZXMsIExlbmd0aE9mTGVuZ3Ro ID0gMA0KICAgICAgU2ltcGxlQXV0aGVudGljYXRpb246IGluaXQNCiAgDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBIb3dhcmQgQ2h1IDxoeWNAc3ltYXMuY29tPiANClNlbnQ6 IFN1bmRheSwgRmVicnVhcnkgMywgMjAxOSAxMDoyNSBQTQ0KVG86IExlbyBUb2hpbGwgPGxpdEBD Qk9SRC5jb20+OyBvcGVubGRhcC1pdHNAT3BlbkxEQVAub3JnDQpTdWJqZWN0OiBSZTogKElUUyM4 OTcwKSBiaW5kIGZhaWxzIHdoZW4gbGVuZ3RoIHZhbHVlIGlzIG11bHRpLWJ5dGUNCg0KbGl0QGNi b3JkLmNvbSB3cm90ZToNCj4gRnVsbF9OYW1lOiBMZW8gVG9oaWxsDQo+IFZlcnNpb246IDIuNC4z MA0KPiBPUzogV2luZG93cyAxMA0KPiBVUkw6IA0KPiBodHRwczovL2RvY3MuZ29vZ2xlLmNvbS9k b2N1bWVudC9kLzEwdUtnOU5oM0hMaXVPelRiTGZpNlo3YkNmVWI4eF9BaTZXDQo+IEs1THFOemJ3 QS9lZGl0P3VzcD1zaGFyaW5nDQo+IFN1Ym1pc3Npb24gZnJvbTogKE5VTEwpICg3NC43OS44LjQx KQ0KPiANCj4gDQo+IFN1bW1hcnk6IG9wZW5sZGFwIDIuNC4zMCBkb2VzIG5vdCBhY2NvbW1vZGF0 ZSBtdWx0aS1ieXRlIGxlbmd0aCB2YWx1ZSANCj4gb24gYmluZCByZXF1ZXN0Lg0KPiANCj4gDQo+ IEZpcnN0LCBJJ2xsIGFkbWl0IHRoYXQgSSdtIG91dCBvZiBteSBkZXB0aCBoZXJlLCBJJ20gcnVu bmluZyBhIG9sZGVyIA0KPiB2ZXJzaW9uLCBJJ20gb24gV2luZG93cywgYW5kIG15IHBhY2thZ2Ug d2FzIGJ1aWx0IGJ5IEkgZG9uJ3Qga25vdy4gIA0KPiBCdXQgSSB3b3JrZWQgaGFyZCBlbm91Z2gg dG8gdHJhY2sgdGhpcyBkb3duIHRoYXQgSSB3YW50IHlvdSB0byBrbm93IA0KPiB3aGF0IEkgZm91 bmQuICBJIG1pZ2h0IHVwZ3JhZGUsIGJ1dCB0aGF0J3MgcHJvYmxlbWF0aWMuDQo+IA0KPiBBdCBz b21lIHBvaW50IG15IGJpbmRpbmdzIGZyb20gLm5ldCBiZWdhbiBmYWlsaW5nIHdpdGggInRoZSB1 c2VybmFtZSANCj4gb3IgcGFzc3dvcmQgaXMgaW5jb3JyZWN0IiBCdXQgdGhleSB3ZXJlIGNvcnJl Y3QuICBJIGNvdWxkIGNvbmZpcm0gd2l0aCB2YXJpb3VzIG90aGVyIHRvb2xzLg0KPiBJIGNhcHR1 cmVkIHRoZSB3aXJlIHRyYWZmaWMgdG8gaXNvbGF0ZSB0aGUgcHJvYmxlbS4gSXQgdHVybnMgb3V0 IHRoYXQgDQo+IFdpbmRvd3MgZm9ybXMgdGhlIGJpbmRpbmcgcmVxdWVzdCB1c2luZyAgYSBtdWx0 aS1ieXRlIGxlbmd0aCBpbmRpY2F0b3IgaW4gdGhlIHJlcXVlc3QuDQo+IE9wZW5MZGFwIGFwcGFy ZW50bHkgZG9lcyBub3QgYWNjb21tb2RhdGUgdGhpcy4gIEkgY29tcGFyZWQgdG8gYSANCj4gcmVx dWVzdCBnZW5lcmF0ZWQgYnkgIGxkYXBzZWFyY2guZXhlLiAgVGhhdCByZXF1ZXN0LCB3aGljaCBz dWNjZWVkcywgIA0KPiB2YXJpZXMgb25seSBieSB1c2luZyBhIHNpbmdsZS1ieXRlIGxlbmd0aCBp bmRpY2F0b3IuDQo+IA0KPiBUaGUgbXVsdGktYnl0ZSBsZW5ndGggdmFsdWUgc2hvdWxkIGJlIGFs bG93ZWQsIHJpZ2h0PyAgSXNuJ3QgaXQgDQo+IHBvc3NpYmxlIHRvIGhhdmUgYSBiaW5kIHJlcXVl c3QgZGF0YSBwYWNrZXQgb2YgbGVuZ3RoID4gMTI3PyAgV2hpY2ggDQo+IHdvdWxkIHJlcXVpcmUg YSBtdWx0aS1ieXRlIGxlbmd0aCB2YWx1ZS4gIFBlcmhhcHMgdGhpcyB3YXMgZml4ZWQgaW4gYSBs YXRlciB2ZXJzaW9uLg0KPiANCj4gU2NyZWVuc2hvdHMgb2YgdGhlIHdpcmUgY2FwdHVyZSBoZXJl OiANCj4gDQo+IGh0dHBzOi8vZG9jcy5nb29nbGUuY29tL2RvY3VtZW50L2QvMTB1S2c5TmgzSExp dU96VGJMZmk2WjdiQ2ZVYjh4X0FpNlcNCj4gSzVMcU56YndBL2VkaXQ/dXNwPXNoYXJpbmcNCg0K VGhpcyBVUkwgaXMgaW5hY2Nlc3NpYmxlLCBwZXJtaXNzaW9uIGRlbmllZC4NCg0KSnVzdCBjb3B5 IGhleCBkdW1wcyBvZiBib3RoIHJlcXVlc3RzIGhlcmUgaW4gdGV4dC4NCg0KLS0NCiAgLS0gSG93 YXJkIENodQ0KICBDVE8sIFN5bWFzIENvcnAuICAgICAgICAgICBodHRwOi8vd3d3LnN5bWFzLmNv bQ0KICBEaXJlY3RvciwgSGlnaGxhbmQgU3VuICAgICBodHRwOi8vaGlnaGxhbmRzdW4uY29tL2h5 Yy8NCiAgQ2hpZWYgQXJjaGl0ZWN0LCBPcGVuTERBUCAgaHR0cDovL3d3dy5vcGVubGRhcC5vcmcv cHJvamVjdC8NCg==

1 0

Re: (ITS#8970) bind fails when length value is multi-byte
by hyc＠symas.com 03 Feb '19

03 Feb '19

lit(a)cbord.com wrote: > Full_Name: Leo Tohill > Version: 2.4.30 > OS: Windows 10 > URL: https://docs.google.com/document/d/10uKg9Nh3HLiuOzTbLfi6Z7bCfUb8x_Ai6WK5LqN… > Submission from: (NULL) (74.79.8.41) > > > Summary: openldap 2.4.30 does not accommodate multi-byte length value on bind > request. > > > First, I'll admit that I'm out of my depth here, I'm running a older version, > I'm on Windows, and my package was built by I don't know. But I worked hard > enough to track this down that I want you to know what I found. I might > upgrade, but that's problematic. > > At some point my bindings from .net began failing with "the username or password > is incorrect" But they were correct. I could confirm with various other tools. > I captured the wire traffic to isolate the problem. It turns out that Windows > forms the binding request using a multi-byte length indicator in the request. > OpenLdap apparently does not accommodate this. I compared to a request > generated by ldapsearch.exe. That request, which succeeds, varies only by > using a single-byte length indicator. > > The multi-byte length value should be allowed, right? Isn't it possible to have > a bind request data packet of length > 127? Which would require a multi-byte > length value. Perhaps this was fixed in a later version. > > Screenshots of the wire capture here: > > https://docs.google.com/document/d/10uKg9Nh3HLiuOzTbLfi6Z7bCfUb8x_Ai6WK5LqN… This URL is inaccessible, permission denied. Just copy hex dumps of both requests here in text. -- -- 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#8971) slapo-accesslog hits assert
by hyc＠symas.com 02 Feb '19

02 Feb '19

michael(a)stroeder.com wrote: > Full_Name: > Version: RE24 branch > OS: openSUSE Linux > URL: > Submission from: (NULL) (212.68.198.84) > > > For the records an issue tested with Howard today: > > slapo-accesslog hits an assert checking for empty 'reqDN' after processing a > password modify extended operation. > > More information in the ITS upon request. > > Fixed in git master -- -- 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#8971) slapo-accesslog hits assert
by michael＠stroeder.com 02 Feb '19

02 Feb '19

Full_Name: Version: RE24 branch OS: openSUSE Linux URL: Submission from: (NULL) (212.68.198.84) For the records an issue tested with Howard today: slapo-accesslog hits an assert checking for empty 'reqDN' after processing a password modify extended operation. More information in the ITS upon request.

1 0

Re: (ITS#8963) Start TLS failed errors on back-ldap binds / short timeout, config option request
by janne.peltonen＠helsinki.fi 01 Feb '19

01 Feb '19

On Thu, Jan 31, 2019 at 11:41:07PM +0000, Howard Chu wrote: > Thanks for the report. Note that if you simply set a "timeout" with no specific > qualifiers, it would have worked for you as well. Oh dear. Of course. And it says so cleary on the man page, too. Thank you! > At this point, the "extended" timeout was meant for the other exops that back-ldap > supports, e.g. whoami and passwordModify. Since 2.4 is feature frozen we are not > going to implement the extended timeout feature here. > > Instead, I've changed the start_tls code to use the "bind" timeout, since it will > always be used as part of a bind operation anyway. OK, thanks a lot! --Janne / Helsinki Uni

1 0

(ITS#8970) bind fails when length value is multi-byte
by lit＠cbord.com 31 Jan '19

31 Jan '19

Full_Name: Leo Tohill Version: 2.4.30 OS: Windows 10 URL: https://docs.google.com/document/d/10uKg9Nh3HLiuOzTbLfi6Z7bCfUb8x_Ai6WK5LqN… Submission from: (NULL) (74.79.8.41) Summary: openldap 2.4.30 does not accommodate multi-byte length value on bind request. First, I'll admit that I'm out of my depth here, I'm running a older version, I'm on Windows, and my package was built by I don't know. But I worked hard enough to track this down that I want you to know what I found. I might upgrade, but that's problematic. At some point my bindings from .net began failing with "the username or password is incorrect" But they were correct. I could confirm with various other tools. I captured the wire traffic to isolate the problem. It turns out that Windows forms the binding request using a multi-byte length indicator in the request. OpenLdap apparently does not accommodate this. I compared to a request generated by ldapsearch.exe. That request, which succeeds, varies only by using a single-byte length indicator. The multi-byte length value should be allowed, right? Isn't it possible to have a bind request data packet of length > 127? Which would require a multi-byte length value. Perhaps this was fixed in a later version. Screenshots of the wire capture here: https://docs.google.com/document/d/10uKg9Nh3HLiuOzTbLfi6Z7bCfUb8x_Ai6WK5LqN… Thanks for any comments.

1 0

Re: (ITS#8963) Start TLS failed errors on back-ldap binds / short timeout, config option request
by hyc＠symas.com 31 Jan '19

31 Jan '19

janne.peltonen(a)helsinki.fi wrote: > Full_Name: Janne Peltonen > Version: 2.4.44 > OS: Red Hat Enterprise Linux 7 > URL: https://www.openldap.org/lists/openldap-technical/201901/msg00038.html > Submission from: (NULL) (2001:708:110:1820:3664:a9ff:fe04:7363) > > > Proxied BINDs on back-ldap sometimes create Start TLS failed errors on the > connection from proxy to backend, and the client of the proxy receives the error > 52. We had a look at the code, and it appears that in back-ldap/bind.c, the > timeout argument of the function ldap_back_start_tls always ends up as zero, so > the timeout tv.sec and tv.usec end up being set as 0 and 100000, respectively, > by the macro LDAP_BACK_TV_SET defined in back-ldap/back-ldap.h. This means that > the actual timeout waiting for starttls operation to complete will be 0.1 > seconds, which is sometimes too little if there are latencies. We did a > quick&dirty hack to just set tv.sec to 3 and tv.usec to 0, and were no longer > able to get any Start TLS failed errors on the proxy bind. > > We did find that the back-ldap has an "extended" timeout defined in > back-ldap/config.c - except that is commented out as "not implemented". Seems to > us that if that were implemented, you could set the timeout in your ldap > database section by something like "timeout extended=" and then you could have a > longer timeout. Thanks for the report. Note that if you simply set a "timeout" with no specific qualifiers, it would have worked for you as well. At this point, the "extended" timeout was meant for the other exops that back-ldap supports, e.g. whoami and passwordModify. Since 2.4 is feature frozen we are not going to implement the extended timeout feature here. Instead, I've changed the start_tls code to use the "bind" timeout, since it will always be used as part of a bind operation anyway. > > Steps to reproduce: > 1. Configure an openldap proxy-backend pair, the proxy using the "ldap" database > and using ldap urls to connect to the backend (using ldaps urls might actually > be a workaround). Configure the binds to be proxied to the backend, too. > 2. Create a script that creates multiple - say, 200 - simultaneous connections > to the proxy, using an ldaps url to connect to the proxy, and using the same DN > to bind as. (We haven't tried to connect to the frontend using ldap+starttls, > but I would suppose that would have a similar result, since the client > establishes TLS anyway before trying to bind to the proxy.) > 3. Observe some of the binds fail (we typically get 5-6 fails for 200 > simultaneous connection), with the client of the proxy getting a "Server is > unavailable: 52" type of error, and the proxy log containing lines such as > "conn=7716 op=0 RESULT tag=97 err=52 text=Start TLS failed" after the BIND from > the client. > > Possible workaround: Configure the proxy to use ldaps urls to the backend. > > Suggested fix: Implement the "extended" timeout type in back-ldap/config.c > timeout_table, so that people can set the StartTLS timeout to a larger value > than the default 0.1 seconds. > > References: discussion thread on the OpenLDAP-Technical mailing list. > > -- -- 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#8968) Async connect mode does not work on Solaris
by quanah＠symas.com 31 Jan '19

31 Jan '19

--On Wednesday, January 30, 2019 11:19 PM +0000 vsmith(a)interlinknetworks.com wrote: > Full_Name: Vernon Smith > Version: 2.4.47 > OS: Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2601:40d:4300:679a:c0c9:ced:d06f:39a4) > > > I have managed to upgrade to version 2.4.47 libldap libraries using the > Linux OS and async connect mode works fine. But when I tried to upgrade > to 2.4.47 using Solaris OS and use async connect mode, no connections > could be established to the ldap server. The libldap code did not even > send the ldap request to the ldap server. The ldap debug trace showed it > just freeing the request and returned an unable to connect. I traced the > issue to the routine ldap_int_flush_request which checks the sock_errno > return code for EAGAIN but Solaris 10 returns ENOTCONN. This error code > seems to mean the same thing as EAGAIN. I changed the code to test for > either return code and the async connect works for both Linux and Solaris > now. Here is may patch. Thanks for the report, this is now fixed in master (and will be a part of the next RE24 release). Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs