openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#5581) slapd: search.c:970: oc_filter: Assertion `f != ((void *)0)' failed.
by ando＠sys-net.it 06 Aug '08

06 Aug '08

----- stef(a)memberwebs.com wrote: > I get this problem with 2.4.11 (but not with 2.4.10). My slapo-unique > configuration is as follows: > > unique_uri ldap:///?cn?sub > unique_uri ldap:///?uid,login?sub?(!(disabled=TRUE)) > > The filter seems valid to me, but please correct me if I'm wrong. Does "disabled" exist? I mean: is it defined __before__ this line in your slapd.conf? Does TRUE comply with its syntax? I've checked the fix to this bug, and it seems to mischeck the validity of the filter, so if what you specify in the "filter" field of the URI is not a valid filter, the string "(?=error)" shows up instead of the normalization of your filter, causing subsequent harm to filter evaluation. This does not occur if the filter is valid, so there must be also an error on your side (I'm fixing the test, in the meanwhile, so that the error is notified while parsing the configuration). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5586) SLAPD crashing with SIGABRT in connection.c on Solaris - reference through nil pointer
by dbb＠st-andrews.ac.uk 06 Aug '08

06 Aug '08

Thanks. Howard Chu wrote: > dbb(a)st-andrews.ac.uk wrote: >> Just an update, still present in 2.4.11, backtrace below. Still can't >> work out why it's happening, >> it's something in the way that sendmail uses ldap and not the actual >> queries that cause the crash. >> >> I can replay the connections and searches to the server, and I've used >> Suns ldap load testing software >> to load up the server way over what we ever see and I can't replicate >> the SIGABRT or crash it in any >> other way. >> >> Any help appreciated. > > In frame 5 > print *index > print connections[*index] /usr/local/SUNWspro/bin/dbx /source/openldap-2.4.11/servers/slapd/.libs/slapd ./slapd-2.4.11-core-6-8-08 For information about new features see `help changes' To remove this message, put `dbxenv suppress_startup_message 7.6' in your .dbxrc Reading slapd core file header read successfully Reading ld.so.1 Reading libldap_r-2.4.so.2.1.0 Reading liblber-2.4.so.2.1.0 Reading libltdl.so.3.1.5 Reading libdb-4.2.so Reading libicuuc.so.3 Reading libicudata.so.3 Reading libsasl2.so.2.0.22 Reading libdl.so.1 Reading libssl.so.0.9.8 Reading libcrypto.so.0.9.8 Reading libresolv.so.2 Reading libgen.so.1 Reading libnsl.so.1 Reading libsocket.so.1 Reading libc.so.1 Reading libgcc_s.so.1 Reading libgcc_s.so.1 Reading libpthread.so.1 Reading libm.so.2 Reading libCrun.so.1 Reading libc_psr.so.1 t@2 (l@2) terminated by signal ABRT (Abort) 0xfe2c0f90: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xfe2c0fa0 Current function is connection_next 871 assert( connections[*index].c_conn_state == SLAP_C_INVALID ); (dbx) threads t@1 a l@1 ?() LWP suspended in __lwp_wait() o> t@2 a l@2 slapd_daemon_task() signal SIGABRT in __lwp_kill() t@3 a l@3 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@4 a l@4 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@5 a l@5 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@6 a l@6 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@7 a l@7 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@8 a l@8 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@9 a l@9 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@10 a l@10 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@11 a l@11 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@12 a l@12 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() (dbx) thread t@2 t@2 (l@2) stopped in __lwp_kill at 0xfe2c0f90 0xfe2c0f90: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xfe2c0fa0 (dbx) where current thread: t@2 [1] __lwp_kill(0x0, 0x6, 0x0, 0x6, 0xfc00, 0x0), at 0xfe2c0f90 [2] raise(0x6, 0x0, 0xfe2a4a98, 0xffffffff, 0xfe2e8284, 0x6), at 0xfe25fd78 [3] abort(0xfdfff3f0, 0x1, 0xfe2e9288, 0xa83f0, 0xfe2eb298, 0x0), at 0xfe23ff98 [4] __assert(0x1a1808, 0x1a183c, 0x367, 0x0, 0xa810c, 0x1d7b80), at 0xfe2401d4 =>[5] connection_next(c = (nil), index = 0xfdfff6d4), line 871 in "connection.c" [6] connections_timeout_idle(now = 1217978957), line 225 in "connection.c" [7] slapd_daemon_task(ptr = (nil)), line 2152 in "daemon.c" (dbx) print *index *index = 33 (dbx) print connections[*index] connections[*index] = { c_struct_state = 2 c_conn_state = 1 c_conn_idx = 33 c_sd = 33 c_close_reason = 0x1a11bc "?" c_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_sb = 0x45fbd0 c_starttime = 1217978957 c_activitytime = 1217978957 c_connid = 436161U c_peer_domain = { bv_len = 7U bv_val = 0x48fda0 "unknown" } c_peer_name = { bv_len = 22U bv_val = 0x4b34b8 "IP=138.251.30.31:34746" } c_listener = 0x23ea28 c_sasl_bind_mech = { bv_len = 0 bv_val = (nil) } c_sasl_dn = { bv_len = 0 bv_val = (nil) } c_sasl_authz_dn = { bv_len = 0 bv_val = (nil) } c_authz_backend = (nil) c_authz_cookie = (nil) c_authz = { sai_method = 128U sai_mech = { bv_len = 0 bv_val = (nil) } sai_dn = { bv_len = 0 bv_val = (nil) } sai_ndn = { bv_len = 0 bv_val = (nil) } sai_ssf = 0 sai_transport_ssf = 0 sai_tls_ssf = 0 sai_sasl_ssf = 0 } c_protocol = 0 c_ops = { stqh_first = (nil) stqh_last = 0x2c2664 } c_pending_ops = { stqh_first = (nil) stqh_last = 0x2c266c } c_write_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_write_cv = { __pthread_cond_flags = { __pthread_cond_flag = "" __pthread_cond_type = 0 __pthread_cond_magic = 17238U } __pthread_cond_data = 0 } c_currentber = (nil) c_sasl_bind_in_progress = '\0' c_writewaiter = '\0' c_is_tls = '\0' c_needs_tls_accept = '\0' c_sasl_layers = '\0' c_sasl_done = '\0' c_sasl_authctx = 0x4252d8 c_sasl_sockctx = (nil) c_sasl_extra = 0x43a298 c_sasl_bindop = (nil) c_pagedresults_state = { ps_be = (nil) ps_size = 0 ps_count = 0 ps_cookie = 0 ps_cookieval = { bv_len = 0 bv_val = (nil) } } c_n_ops_received = 0 c_n_ops_executing = 0 c_n_ops_pending = 0 c_n_ops_completed = 0 c_n_get = 0 c_n_read = 0 c_n_write = 0 c_extensions = (nil) c_clientfunc = (nil) c_clientarg = (nil) c_send_ldap_result = 0x67ac8 = &slap_send_ldap_result() c_send_search_entry = 0x68c40 = &slap_send_search_entry() c_send_search_reference = 0x6b320 = &slap_send_search_reference() c_send_ldap_extended = 0x685e8 = &slap_send_ldap_extended() c_send_ldap_intermediate = 0x68968 = &slap_send_ldap_intermediate() } (dbx) A second example in case useful /usr/local/SUNWspro/bin/dbx /source/openldap-2.4.11/servers/slapd/.libs/slapd ./slapd-2.4.11-core-1300-4-8-08 For information about new features see `help changes' To remove this message, put `dbxenv suppress_startup_message 7.6' in your .dbxrc Reading slapd core file header read successfully Reading ld.so.1 Reading libldap_r-2.4.so.2.1.0 Reading liblber-2.4.so.2.1.0 Reading libltdl.so.3.1.5 Reading libdb-4.2.so Reading libicuuc.so.3 Reading libicudata.so.3 Reading libsasl2.so.2.0.22 Reading libdl.so.1 Reading libssl.so.0.9.8 Reading libcrypto.so.0.9.8 Reading libresolv.so.2 Reading libgen.so.1 Reading libnsl.so.1 Reading libsocket.so.1 Reading libc.so.1 Reading libgcc_s.so.1 Reading libgcc_s.so.1 Reading libpthread.so.1 Reading libm.so.2 Reading libCrun.so.1 Reading libc_psr.so.1 t@2 (l@2) terminated by signal ABRT (Abort) 0xfe2c0f90: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xfe2c0fa0 Current function is connection_next 871 assert( connections[*index].c_conn_state == SLAP_C_INVALID ); (dbx) where current thread: t@2 [1] __lwp_kill(0x0, 0x6, 0x0, 0x6, 0xfc00, 0x0), at 0xfe2c0f90 [2] raise(0x6, 0x0, 0xfe2a4a98, 0xffffffff, 0xfe2e8284, 0x6), at 0xfe25fd78 [3] abort(0xfdfff3f0, 0x1, 0xfe2e9288, 0xa83f0, 0xfe2eb298, 0x0), at 0xfe23ff98 [4] __assert(0x1a1808, 0x1a183c, 0x367, 0x0, 0xa810c, 0x1d7b80), at 0xfe2401d4 =>[5] connection_next(c = (nil), index = 0xfdfff6d4), line 871 in "connection.c" [6] connections_timeout_idle(now = 1217851229), line 225 in "connection.c" [7] slapd_daemon_task(ptr = (nil)), line 2152 in "daemon.c" (dbx) threads t@1 a l@1 ?() LWP suspended in __lwp_wait() o> t@2 a l@2 slapd_daemon_task() signal SIGABRT in __lwp_kill() t@3 a l@3 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@4 a l@4 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@5 a l@5 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@6 a l@6 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() (dbx) print *index *index = 21 (dbx) print connections[*index] connections[*index] = { c_struct_state = 2 c_conn_state = 1 c_conn_idx = 21 c_sd = 21 c_close_reason = 0x1a11bc "?" c_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_sb = 0x435300 c_starttime = 1217851229 c_activitytime = 1217851229 c_connid = 6825U c_peer_domain = { bv_len = 7U bv_val = 0x419470 "unknown" } c_peer_name = { bv_len = 22U bv_val = 0x413908 "IP=138.251.30.32:40070" } c_listener = 0x23ea28 c_sasl_bind_mech = { bv_len = 0 bv_val = (nil) } c_sasl_dn = { bv_len = 0 bv_val = (nil) } c_sasl_authz_dn = { bv_len = 0 bv_val = (nil) } c_authz_backend = (nil) c_authz_cookie = (nil) c_authz = { sai_method = 128U sai_mech = { bv_len = 0 bv_val = (nil) } sai_dn = { bv_len = 0 bv_val = (nil) } sai_ndn = { bv_len = 0 bv_val = (nil) } sai_ssf = 0 sai_transport_ssf = 0 sai_tls_ssf = 0 sai_sasl_ssf = 0 } c_protocol = 0 c_ops = { stqh_first = (nil) stqh_last = 0x2c16a4 } c_pending_ops = { stqh_first = (nil) stqh_last = 0x2c16ac } c_write_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_write_cv = { __pthread_cond_flags = { __pthread_cond_flag = "" __pthread_cond_type = 0 __pthread_cond_magic = 17238U } __pthread_cond_data = 0 } c_currentber = (nil) c_sasl_bind_in_progress = '\0' c_writewaiter = '\0' c_is_tls = '\0' c_needs_tls_accept = '\0' c_sasl_layers = '\0' c_sasl_done = '\0' c_sasl_authctx = 0x426680 c_sasl_sockctx = (nil) c_sasl_extra = 0x4346a8 c_sasl_bindop = (nil) c_pagedresults_state = { ps_be = (nil) ps_size = 0 ps_count = 0 ps_cookie = 0 ps_cookieval = { bv_len = 0 bv_val = (nil) } } c_n_ops_received = 0 c_n_ops_executing = 0 c_n_ops_pending = 0 c_n_ops_completed = 0 c_n_get = 0 c_n_read = 0 c_n_write = 0 c_extensions = (nil) c_clientfunc = (nil) c_clientarg = (nil) c_send_ldap_result = 0x67ac8 = &slap_send_ldap_result() c_send_search_entry = 0x68c40 = &slap_send_search_entry() c_send_search_reference = 0x6b320 = &slap_send_search_reference() c_send_ldap_extended = 0x685e8 = &slap_send_ldap_extended() c_send_ldap_intermediate = 0x68968 = &slap_send_ldap_intermediate() } -- The University of St Andrews is a charity registered in Scotland : No SC013532

1 0

Re: (ITS#5641) Segmentation fault - slaptest and slapd
by ando＠sys-net.it 06 Aug '08

06 Aug '08

----- hyc(a)symas.com wrote: > hfranzke(a)tee.toshiba.de wrote: > > Full_Name: Helmut Franzke > > Version: 2.4.11 / 2.4.9 > > OS: Ubuntu server 8.04.1 / Centos 4.6 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (192.109.150.105) > > > > > > I could get slaptest/slapd to produce a segmentation fault by using > the unique > > overlay and a unique_uri with a base dn. This behaviour depends on > the position > > of the overlay/unique_uri in slapd.conf and doesn't appear if you > don't use a > > base dn regardless of the position. (I know an overlay should be > defined after > > the other configuration settings have been set. I encountered this > bug when I > > put it in the first part by mistake, see below) > > We should of course fix the SEGV, but it is already documented that > overlays > must be configured after their corresponding databases. As such, this > is not a > high priority. slapo-unique uses be_nsuffix without testing it, and it's obviously NULL until "suffix" is defined. The fix is trivial, but I can't commit right now. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5586) SLAPD crashing with SIGABRT in connection.c on Solaris - reference through nil pointer
by hyc＠symas.com 05 Aug '08

05 Aug '08

dbb(a)st-andrews.ac.uk wrote: > Just an update, still present in 2.4.11, backtrace below. Still can't > work out why it's happening, > it's something in the way that sendmail uses ldap and not the actual > queries that cause the crash. > > I can replay the connections and searches to the server, and I've used > Suns ldap load testing software > to load up the server way over what we ever see and I can't replicate > the SIGABRT or crash it in any > other way. > > Any help appreciated. In frame 5 print *index print connections[*index] -- -- 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#5641) Segmentation fault - slaptest and slapd
by hyc＠symas.com 05 Aug '08

05 Aug '08

hfranzke(a)tee.toshiba.de wrote: > Full_Name: Helmut Franzke > Version: 2.4.11 / 2.4.9 > OS: Ubuntu server 8.04.1 / Centos 4.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (192.109.150.105) > > > I could get slaptest/slapd to produce a segmentation fault by using the unique > overlay and a unique_uri with a base dn. This behaviour depends on the position > of the overlay/unique_uri in slapd.conf and doesn't appear if you don't use a > base dn regardless of the position. (I know an overlay should be defined after > the other configuration settings have been set. I encountered this bug when I > put it in the first part by mistake, see below) We should of course fix the SEGV, but it is already documented that overlays must be configured after their corresponding databases. As such, this is not a high priority. -- -- 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#5642) Double free on exit, when specific attributetype is defined
by hyc＠symas.com 05 Aug '08

05 Aug '08

stef(a)memberwebs.com wrote: > Full_Name: Stef Walter > Version: 2.4.11 > OS: FreeBSD 6.3-RELEASE-p2 > URL: > Submission from: (NULL) (38.99.5.20) > > > When the following line is present in the schema (or slapd.conf), then upon exit > any slap* process aborts due to a double free of memory: > > attributetype ( 278.1.3.6.1 NAME 'requireClass' SUP objectClass ) > > > The OID is obviously fictional. This can be triggered reliably by running: > > # slaptest > This is now fixed in HEAD. -- -- 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#5639) Digital (PGP-)signature for downloadable sources
by Kurt＠OpenLDAP.org 05 Aug '08

05 Aug '08

On Aug 4, 2008, at 9:56 PM, h.b.furuseth(a)usit.uio.no wrote: > Kurt(a)OpenLDAP.org writes: >> On Aug 4, 2008, at 2:06 PM, h.b.furuseth(a)usit.uio.no wrote: >>> Kurt(a)OpenLDAP.org writes: >>>> I note as well that properly deploying release signing requires >>>> more than script modification. For instance, one does need to >>>> consider that the host to sign the releases might itself been >>>> taken over and the implications of such a takeover. >>> >>> For that part, signatures in the 'https:' site would help. >> >> I think you need to re-think that assertion. > > Er, yes, I was thinking of the "outside" equivalent, hacking DNS and > "taking over" that way. Those mounting such attacks are more likely to take over google.com than openldap.org. > I have the impression that's the most common way to "take over" a > site, but I may be wrong. I would say it's a more commonly talked about "take over" approach at present. Though I don't know if its more common that other major site "take over" approaches. But "take over" of small sites, such are openldap.org, are different because the goal is different. Folks "take over" major sites (generally in an isolated way, such as via a particular ISP) because there is a reasonable chance that users will access the taken over site. These take overs often are attempts to install malware on user systems (be careful, that google search button might not be a true google search button). Take over of small sites is commonly done to deface the site, to gain notoriety or to grind an axe or something. So, I'm not particularly worried about former, but am worried about the latter. But you and others brought up https:// in the context of a PGP signing discussion. This is, I think, confused. -- Kurt

1 0

Re: (ITS#5639) Digital (PGP-)signature for downloadable sources
by Kurt＠OpenLDAP.org 05 Aug '08

05 Aug '08

I figure that an attacker can convince most downloaders who might verify a PGP signature that the project no longer signs releases, making the project's use of PGP signatures moot. While it can be argued that there might be some downloaders who want to establish rigid signature verification procedures and follow them, I simply haven't heard anyone claim to be such a downloader. And even if there where a few that might now claim this, I think the amount of work involved (both initially and on a per release basis) is worth the time spent. I would argue time is better spent on improvements that are benefit most downloaders, such as a more comprehensive web/ftp change detection/notice system. -- Kurt

1 0

Re: (ITS#5642) Double free on exit, when specific attributetype is defined
by hyc＠symas.com 05 Aug '08

05 Aug '08

stef(a)memberwebs.com wrote: > Full_Name: Stef Walter > Version: 2.4.11 > OS: FreeBSD 6.3-RELEASE-p2 > URL: > Submission from: (NULL) (38.99.5.20) > > > When the following line is present in the schema (or slapd.conf), then upon exit > any slap* process aborts due to a double free of memory: > > attributetype ( 278.1.3.6.1 NAME 'requireClass' SUP objectClass ) > > > The OID is obviously fictional. This can be triggered reliably by running: > > # slaptest This also occurs in 2.3, and is specific to objectClass and a few other built in attributes with custom matching rules. -- -- 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#5645) <suffix> invalid DN 21 (Invalid syntax)
by support＠msm-projects.net 05 Aug '08

05 Aug '08

Full_Name: MSM-Projects Support Version: 2.4.11 OS: Debian Linux (2.6.18-6-xen-amd64) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.9.60.153) We installed a ldap server version 2.4.11. With default slapd.conf the server is starting. Changing the default-suffix to a version we need (building a replica with an existing host), we get error: line 54 (suffix "o=my-domain, c=com") >>> dnPrettyNormal: <o=my-domain, c=com> => ldap_bv2dn(o=my-domain, c=com,0) <= ldap_bv2dn(o=my-domain, c=com)=0 ldap_err2string /usr/local/openldap/etc/openldap/slapd.conf: line 54: <suffix> invalid DN 21 (Invalid syntax)

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