openldap-bugs January 2007

openldap-bugs@openldap.org

29 participants
118 discussions

(ITS#4800) ldapmodify.c:parse_ldif_control() broken
by h.b.furuseth＠usit.uio.no 10 Jan '07

10 Jan '07

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard tools/ldapmodify.c:parse_ldif_control() uses variable s uninitialized - the variable which supposedly contains the control. Buggy since ver 1.189 Fri Nov 24 16:05:45 2006 UTC, by hyc: "Parser rewrite: use liblutil's ldif_read_record instead of read_one_record track line numbers across entire LDIF instead of just for a single entry, to allow easier locating of errors. (we can also add the -j jump option later.) split Add/Modify parse paths, precompute size of pmods instead of continuously using realloc. Entry processing is now linear time instead of n^2 with entry size." Looks like a test case which uses controls is also needed.

1 0

Re: (ITS#4494) connections are not asynchrounous
by ando＠sys-net.it 10 Jan '07

10 Jan '07

lrm(a)interlinknetworks.com wrote: > I have patched the 2.3.20 code to make all connections non-blocking. I > did not address referrals, and I'm sure there are other features I > overlooked as well. > > Would it be helpful to see what I have done to get around the problem? > I would be happy to send you a patch. Sure. If you want it to be considered for inclusion in OpenLDAP, please use the ITS (continuing this ITS may be an option). Usually, we request that patches are applied to HEAD code; 2.3.20 might be recent enough wrt/ libldap. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4648) ldap_pvt_put_filter() succeeds on certain incorrect ldap filters
by hyc＠symas.com 10 Jan '07

10 Jan '07

john.bowers(a)quest.com wrote: > Full_Name: John Bowers > Version: 2.3.27 > OS: Suse Linux 9.1 > URL: ftp://ftp.openldap.org/incoming/john-bowers-06-08-23.patch > Submission from: (NULL) (192.41.88.6) > > > The ldap_search code uses ldap_pvt_put_filter() to add the search filter to the > search request. Certain (if I am not enirely mistaken) invalid search filters > are successfully added by the ldap_pvt_put_filter() code. An example of this > type of search filter follows: > > "(objectclass=group)(cn=test)" I've committed a simpler fix to CVS HEAD. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4494) connections are not asynchrounous
by lrm＠interlinknetworks.com 09 Jan '07

09 Jan '07

I have patched the 2.3.20 code to make all connections non-blocking. I did not address referrals, and I'm sure there are other features I overlooked as well. Would it be helpful to see what I have done to get around the problem? I would be happy to send you a patch. That's all for now, --Larry Morris Interlink Networsk, LLC. lrm(a)interlinknetworks.com On Tue, 2007-01-09 at 19:23, Pierangelo Masarati wrote: > Larry Morris wrote: > > Your efforts are appreciated. > > > > Please see my additional responses inline below. > > > > My single-threaded application requires that multiple connection > > attempts may be in-progress simultaneously, in conjunction with other > > activities that need timely attention. In other words, I need to have > > multiple connections in non-blocking SSL_connect() at the same time, > > with the application doing select() on all the LDAP connection sockets > > as needed. The fix you have provided will allow this? > > > No, at a first glance it's not going to have any impact on that portion > of code. I'll try to sort out if and how anything similar can be done > in that area. > > What is the time-frame for this to be available in a "stable" version? > > > There's no definite timeframe. It's not going to appear in OpenLDAP > 2.3, since it's feature frozen and this does not represent a significant > bug fix, but rather a new, marginal feature. 2.4 is on its way, and > this code will surely be in the next 2.4 release. Whether this will be > still alpha or release, I have no idea right now. > > p. > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.n.c. > Via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > ------------------------------------------ > Office: +39.02.23998309 > Mobile: +39.333.4963172 > Email: pierangelo.masarati(a)sys-net.it > ------------------------------------------ >

1 0

Re: (ITS#4799) kbind removal
by Kurt＠OpenLDAP.org 09 Jan '07

09 Jan '07

At 04:48 PM 1/9/2007, Kurt(a)OpenLDAP.org wrote: >At 02:23 PM 1/9/2007, quanah(a)OpenLDAP.org wrote: >>Full_Name: Quanah Gibson-Mount >>Version: HEAD/2.4 >>OS: NA >>URL: ftp://ftp.openldap.org/incoming/ >>Submission from: (NULL) (171.66.155.86) >> >> >>kbind was slated for removal in 2.2, but was missed. Before 2.4 goes out, kbind >>should be finally removed from HEAD & 2.4. > >There is no KBIND support in current HEAD. s/no/no longer/ Ando had me thinking I had already axed it. But it's now axed. Kurt

1 0

Re: (ITS#4799) kbind removal
by Kurt＠OpenLDAP.org 09 Jan '07

09 Jan '07

At 02:23 PM 1/9/2007, quanah(a)OpenLDAP.org wrote: >Full_Name: Quanah Gibson-Mount >Version: HEAD/2.4 >OS: NA >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (171.66.155.86) > > >kbind was slated for removal in 2.2, but was missed. Before 2.4 goes out, kbind >should be finally removed from HEAD & 2.4. There is no KBIND support in current HEAD. Kurt

1 0

Re: (ITS#4494) connections are not asynchrounous
by ando＠sys-net.it 09 Jan '07

09 Jan '07

Larry Morris wrote: > Your efforts are appreciated. > > Please see my additional responses inline below. > > My single-threaded application requires that multiple connection > attempts may be in-progress simultaneously, in conjunction with other > activities that need timely attention. In other words, I need to have > multiple connections in non-blocking SSL_connect() at the same time, > with the application doing select() on all the LDAP connection sockets > as needed. The fix you have provided will allow this? > No, at a first glance it's not going to have any impact on that portion of code. I'll try to sort out if and how anything similar can be done in that area. > What is the time-frame for this to be available in a "stable" version? > There's no definite timeframe. It's not going to appear in OpenLDAP 2.3, since it's feature frozen and this does not represent a significant bug fix, but rather a new, marginal feature. 2.4 is on its way, and this code will surely be in the next 2.4 release. Whether this will be still alpha or release, I have no idea right now. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

(ITS#4799) kbind removal
by quanah＠OpenLDAP.org 09 Jan '07

09 Jan '07

Full_Name: Quanah Gibson-Mount Version: HEAD/2.4 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.66.155.86) kbind was slated for removal in 2.2, but was missed. Before 2.4 goes out, kbind should be finally removed from HEAD & 2.4.

1 0

Re: (ITS#4494) connections are not asynchrounous
by lrm＠interlinknetworks.com 09 Jan '07

09 Jan '07

Your efforts are appreciated. Please see my additional responses inline below. My single-threaded application requires that multiple connection attempts may be in-progress simultaneously, in conjunction with other activities that need timely attention. In other words, I need to have multiple connections in non-blocking SSL_connect() at the same time, with the application doing select() on all the LDAP connection sockets as needed. The fix you have provided will allow this? What is the time-frame for this to be available in a "stable" version? That's all for now, --Larry Morris Interlink Networks, LLC. lrm(a)interlinknetworks.com On Mon, 2007-01-08 at 08:39, Pierangelo Masarati wrote: > Is it an option for you to use Start TLS instead of ldaps? In this I could try using ldap_start_tls() as a quick-and-dirty test to verify that you have fixed the connection issues, but it is not acceptable for our production use. We must support LDAPv2, which does not allow the use of start TLS. Are you planning to support this for ldaps: URLs in the future? Do you need/want me to verify that using start TLS with your patches fixes the connection issues? I would prefer to hold off until the ldaps: support is in place. > case, code in right HEAD should fix all non-blocking issues, as soon as > you specify a network timeout and LDAP_OPT_CONNECT_ASYNC (undocumented > yet, it's been committed just hours ago). What is the "right HEAD" CVS branch? Do I have access to that branch via anonymous CVS? I am not very familiar with CVS, a sample command line to retrieve the correct sources would be quite helpful. > > The usage I suggest is to set LDAP_OPT_NETWORK_TIMEOUT to a positive > value; then set LDAP_OPT_CONNECT_ASYNC to TRUE before performing the > first operation, and reset it to FALSE after the first operation > succeeds. In your case, the first operation would be ldap_start_tls[_s](3). Can I leave LDAP_OPT_CONNECT_ASYNC set to TRUE always? I would like referrals, if used, to be non-blocking as well. Could you make this automatic in ldap_int_tls_start()?

1 0

Re: (ITS#4796) Contribution: JLDAP support for simple paging of results (RFC 2696)
by Kurt＠OpenLDAP.org 08 Jan '07

08 Jan '07

At 03:28 PM 1/6/2007, radovan(a)skolnik.info wrote: >Full_Name: Radovan Skolnik >Version: JLDAP CVS version >OS: Windows/Java >URL: http://www.skolnik.info/LDAPPagedResults.zip >Submission from: (NULL) (82.119.120.128) > > >Hello, > >I hope this is the right place to make this submission ;-) Recently I found that >JLDAP does not support simple paging mechanism via control as stated in RFC2696 >(control OID 1.2.840.113556.1.4.319). So I made an attempt to implement it and >it seems to me it works as it's supposed to. I would like to contribute it to >the project for the benefit of others. The files can be found at >http://www.skolnik.info/LDAPPagedResults.zip If there is something more needed >from me please let me know. Your submission lacks both a notice of origin and a rights statement, as required of contributions. See <http://www.openldap.org/devel/contributing.html#notice>. Though submissions such as this should be in the form of patch file (with notices placed above the patch in the file), a zip file is acceptable. In this case, just place the required notice and statement in a file called NOTICE. Please revise. -- Kurt

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2007