- openldap-bugs - openldap.org

(ITS#5702) [enhancement] allow cross-attribute constraints in slapo-constraint(5)
by ando＠sys-net.it 17 Sep '08

17 Sep '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando I've added a "set" type to slapo-constraint(5) that allows to write complex constraints like constraint_attribute cn,sn,givenName set "(this/givenName + [ ] + this/sn) & this/cn" forcing a relationship between the values of cn, sn and givenName. The possibility to enforce the same constraint on multiple attributes separated by commas is given to all constraint types, as a side-effect. The check is passed the entry during add operations, while it attempts to build the entry resulting from a set of modifications during modify operations. p.

1 0

Re: (ITS#5663) Declaring substitute syntax as LDAP syntax
by ando＠sys-net.it 16 Sep '08

16 Sep '08

ando(a)sys-net.it wrote: > BTW: there are some minor bugs in that patch; for example, don't start > slapd with -F :). Michael, please try this one instead: <ftp://ftp.openldap.org/incoming/pierangelo-masarati-x-subst-2008-09-17.patch>. I won't probably be able to work at this stuff for a few days. Cheers, 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#5663) Declaring substitute syntax as LDAP syntax
by hyc＠symas.com 16 Sep '08

16 Sep '08

ando(a)sys-net.it wrote: > I'd note rfc4517 does not > mention extensions, either... RFC4512 does. -- -- 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#5663) Declaring substitute syntax as LDAP syntax
by ando＠sys-net.it 16 Sep '08

16 Sep '08

michael(a)stroeder.com wrote: > You rock! I'll give it a try. BTW: there are some minor bugs in that patch; for example, don't start slapd with -F :). I should either submit a new one, or commit the whole stuff, but perhaps I'd wait for 2.4.12 to be out. 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#5663) Declaring substitute syntax as LDAP syntax
by ando＠sys-net.it 16 Sep '08

16 Sep '08

Michael Ströder wrote: > Pierangelo Masarati wrote: >> I have a patch >> <ftp://ftp.openldap.org/incoming/pierangelo-masarati-x-subst-2008-09-16.patch> >> that implements support for "ldapsyntax" (slapd.conf) and >> "olcLdapSyntaxes" (back-config) in order to allow run-time configuration >> of syntaxes that have NULL handlers and thus need to have the X-SUBST >> extension in place. > > You rock! I'll give it a try. > >> ldapsyntax ( <my-syntax-oid> NAME 'MySyntax' >> DESC 'this is the description' >> X-SUBST 1.3.6.1.4.1.1466.115.121.1.15 ) > > Looking at RFC 4512 the SyntaxDescription does not mention NAME > (although I'd appreciate it would). Correct. I was mistaken by the presence of the field in the schema stucture of include/ldap_schema.h: typedef struct ldap_syntax { char *syn_oid; /* REQUIRED */ char **syn_names; /* OPTIONAL */ char *syn_desc; /* OPTIONAL */ LDAPSchemaExtensionItem **syn_extensions; /* OPTIONAL */ } LDAPSyntax; We should probably trim it, although it could (would) break binary interoperability at the libldap level. I'd note rfc4517 does not mention extensions, either... 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#5663) Declaring substitute syntax as LDAP syntax
by michael＠stroeder.com 16 Sep '08

16 Sep '08

Pierangelo Masarati wrote: > > I have a patch > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-x-subst-2008-09-16.patch> > that implements support for "ldapsyntax" (slapd.conf) and > "olcLdapSyntaxes" (back-config) in order to allow run-time configuration > of syntaxes that have NULL handlers and thus need to have the X-SUBST > extension in place. You rock! I'll give it a try. > ldapsyntax ( <my-syntax-oid> NAME 'MySyntax' > DESC 'this is the description' > X-SUBST 1.3.6.1.4.1.1466.115.121.1.15 ) Looking at RFC 4512 the SyntaxDescription does not mention NAME (although I'd appreciate it would). Ciao, Michael.

1 0

Re: (ITS#5701) connection.c asserting during test008
by richton＠nbcs.rutgers.edu 16 Sep '08

16 Sep '08

On Tue, 16 Sep 2008, Howard Chu wrote: > What is the value of c_conn_state in each of these occurrences? In case 1 and 2, connections[*index].c_conn_state = 2 (SLAP_C_ACTIVE). In case 3, connections[*index].c_conn_state = 1 (SLAP_C_INACTIVE).

1 0

Re: (ITS#5701) connection.c asserting during test008
by hyc＠symas.com 16 Sep '08

16 Sep '08

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: RE24 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.6.31.135) > > > Rare connection.c assertion during test008s of RE24. Here are three different > examples: > > t@6 (l@6) terminated by signal ABRT (Abort) > 0xffffffff7f0a8d4c: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! > 0xffffffff7f0a8d5c > Current function is connection_next > 871 assert( connections[*index].c_conn_state == > SLAP_C_INVALID ); What is the value of c_conn_state in each of these occurrences? > I have the testrun directories from each of these runs, if desired. -- -- 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#5663) Declaring substitute syntax as LDAP syntax
by ando＠sys-net.it 16 Sep '08

16 Sep '08

Michael, I have a patch <ftp://ftp.openldap.org/incoming/pierangelo-masarati-x-subst-2008-09-16.patch> that implements support for "ldapsyntax" (slapd.conf) and "olcLdapSyntaxes" (back-config) in order to allow run-time configuration of syntaxes that have NULL handlers and thus need to have the X-SUBST extension in place. The patch is very intrusive, that's why I didn't commit it right now, as I'd like someone to give it a look first. It applies to HEAD as of right now. Please test and report. My current test configuration is something like ldapsyntax ( <my-syntax-oid> NAME 'MySyntax' DESC 'this is the description' X-SUBST 1.3.6.1.4.1.1466.115.121.1.15 ) followed by attributeType ( <my-at-oid> NAME 'MyAttr' SYNTAX <my-syntax-oid> ) It seems to work just fine, although I didn't check many features like deletion of schema via back-config and so. 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

(ITS#5701) connection.c asserting during test008
by richton＠nbcs.rutgers.edu 15 Sep '08

15 Sep '08

Full_Name: Aaron Richton Version: RE24 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.6.31.135) Rare connection.c assertion during test008s of RE24. Here are three different examples: t@6 (l@6) terminated by signal ABRT (Abort) 0xffffffff7f0a8d4c: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xffffffff7f0a8d5c Current function is connection_next 871 assert( connections[*index].c_conn_state == SLAP_C_INVALID ); current thread: t@6 [1] __lwp_kill(0x0, 0x6, 0xffffffffffffffe6, 0x0, 0x0, 0x0), at 0xffffffff7f0a8d4c [2] raise(0x6, 0x0, 0xffffffff76bfeb30, 0x0, 0x0, 0x0), at 0xffffffff7f058dc0 [3] abort(0x62, 0x0, 0x62, 0x7efefeff, 0x81010100, 0xff00), at 0xffffffff7f03e688 [4] __assert(0x100298090, 0x1002980c8, 0x367, 0x0, 0x100427478, 0x100427480), at 0xffffffff7f03e98c =>[5] connection_next(c = (nil), index = 0xffffffff76bfefec), line 871 in "connection.c" [6] monitor_subsys_conn_create(op = 0x103a359b0, rs = 0xffffffff76bff998, ndn = (nil), e_parent = 0x1005c03d8, ep = 0xffffffff76bff230), line 500 in "conn.c" [7] monitor_entry_create(op = 0x103a359b0, rs = 0xffffffff76bff998, ndn = (nil), e_parent = 0x1005c03d8, ep = 0xffffffff76bff230), line 90 in "entry.c" [8] monitor_send_children(op = 0x103a359b0, rs = 0xffffffff76bff998, e_parent = 0x1005c03d8, sub = 1), line 53 in "search.c" [9] monitor_send_children(op = 0x103a359b0, rs = 0xffffffff76bff998, e_parent = 0x1005c0338, sub = 1), line 123 in "search.c" [10] monitor_back_search(op = 0x103a359b0, rs = 0xffffffff76bff998), line 245 in "search.c" [11] fe_op_search(op = 0x103a359b0, rs = 0xffffffff76bff998), line 366 in "search.c" [12] do_search(op = 0x103a359b0, rs = 0xffffffff76bff998), line 217 in "search.c" [13] connection_operation(ctx = 0xffffffff76bffc20, arg_v = 0x103a359b0), line 1084 in "connection.c" [14] connection_read_thread(ctx = 0xffffffff76bffc20, argv = 0xe), line 1211 in "connection.c" [15] ldap_int_thread_pool_wrapper(xpool = 0x100502250), line 663 in "tpool.c" t@18 (l@18) terminated by signal ABRT (Abort) 0xffffffff7f0a8d4c: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xffffffff7f0a8d5c Current function is connection_next 871 assert( connections[*index].c_conn_state == SLAP_C_INVALID ); current thread: t@18 [1] __lwp_kill(0x0, 0x6, 0xffffffffffffffe6, 0x0, 0x0, 0x0), at 0xffffffff7f0a8d4c [2] raise(0x6, 0x0, 0xffffffff6dbfeb20, 0x0, 0x0, 0x0), at 0xffffffff7f058dc0 [3] abort(0x62, 0x0, 0x62, 0x7efefeff, 0x81010100, 0xff00), at 0xffffffff7f03e688 [4] __assert(0x100298090, 0x1002980c8, 0x367, 0x16, 0x1006b9cd8, 0x0), at 0xffffffff7f03e98c =>[5] connection_next(c = (nil), index = 0xffffffff6dbff02c), line 871 in "connection.c" [6] monitor_subsys_rww_update(op = 0x102c3dd70, rs = 0xffffffff6dbff998, e = 0x1005c1b98), line 187 in "rww.c" [7] monitor_entry_update(op = 0x102c3dd70, rs = 0xffffffff6dbff998, e = 0x1005c1b98), line 59 in "entry.c" [8] monitor_send_children(op = 0x102c3dd70, rs = 0xffffffff6dbff998, e_parent = 0x1005c0748, sub = 1), line 88 in "search.c" [9] monitor_send_children(op = 0x102c3dd70, rs = 0xffffffff6dbff998, e_parent = 0x1005c0338, sub = 1), line 123 in "search.c" [10] monitor_back_search(op = 0x102c3dd70, rs = 0xffffffff6dbff998), line 245 in "search.c" [11] fe_op_search(op = 0x102c3dd70, rs = 0xffffffff6dbff998), line 366 in "search.c" [12] do_search(op = 0x102c3dd70, rs = 0xffffffff6dbff998), line 217 in "search.c" [13] connection_operation(ctx = 0xffffffff6dbffc20, arg_v = 0x102c3dd70), line 1084 in "connection.c" [14] connection_read_thread(ctx = 0xffffffff6dbffc20, argv = 0x1e), line 1211 in "connection.c" [15] ldap_int_thread_pool_wrapper(xpool = 0x100502250), line 663 in "tpool.c" t@3 (l@3) terminated by signal ABRT (Abort) 0xffffffff7f0a8d4c: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xffffffff7f0a8d5c Current function is connection_next 871 assert( connections[*index].c_conn_state == SLAP_C_INVALID ); current thread: t@3 [1] __lwp_kill(0x0, 0x6, 0xffffffffffffffe6, 0x0, 0x0, 0x0), at 0xffffffff7f0a8d4c [2] raise(0x6, 0x0, 0xffffffff78ffea50, 0x0, 0x0, 0x0), at 0xffffffff7f058dc0 [3] abort(0x62, 0x0, 0x62, 0x7efefeff, 0x81010100, 0xff00), at 0xffffffff7f03e688 [4] __assert(0x100298090, 0x1002980c8, 0x367, 0x0, 0x0, 0x0), at 0xffffffff7f03e98c =>[5] connection_next(c = (nil), index = 0xffffffff78fff02c), line 871 in "connection.c" [6] connection_first(index = 0xffffffff78fff02c), line 829 in "connection.c" [7] monitor_subsys_rww_update(op = 0x100922640, rs = 0xffffffff78fff998, e = 0x1005c1b98), line 185 in "rww.c" [8] monitor_entry_update(op = 0x100922640, rs = 0xffffffff78fff998, e = 0x1005c1b98), line 59 in "entry.c" [9] monitor_send_children(op = 0x100922640, rs = 0xffffffff78fff998, e_parent = 0x1005c0748, sub = 1), line 88 in "search.c" [10] monitor_send_children(op = 0x100922640, rs = 0xffffffff78fff998, e_parent = 0x1005c0338, sub = 1), line 123 in "search.c" [11] monitor_back_search(op = 0x100922640, rs = 0xffffffff78fff998), line 245 in "search.c" [12] fe_op_search(op = 0x100922640, rs = 0xffffffff78fff998), line 366 in "search.c" [13] do_search(op = 0x100922640, rs = 0xffffffff78fff998), line 217 in "search.c" [14] connection_operation(ctx = 0xffffffff78fffc20, arg_v = 0x100922640), line 1084 in "connection.c" [15] connection_read_thread(ctx = 0xffffffff78fffc20, argv = 0x22), line 1211 in "connection.c" [16] ldap_int_thread_pool_wrapper(xpool = 0x100502250), line 663 in "tpool.c" I have the testrun directories from each of these runs, if desired.

1 0

Re: (ITS#5695) AC syntax in OpenLDAP
by ando＠sys-net.it 15 Sep '08

15 Sep '08

I have uploaded a patch that incorporates yours into the code as after applying my fixes to certificate stuff and the implementation of certificateList matching as of last night (ITS#5700). I have modified your contribution to reflect the functionalities I have added to certificate handling in order to minimize code duplication. <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2008-09-15-pmi.patch> Note that the OIDs used in the above patch are from OpenLDAP's development arc, but I didn't register them yet, because I first want to be sure there are no official OIDs for those syntaxes yet. The patch also includes the complete schema (objectClasses and attributeTypes) concerning PMI as of X.509. I'll commit it as soon as I get some feedback about your copyright notice and OID registration. In the meanwhile, please test. 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#5673) Replication delete problem
by ghenry＠OpenLDAP.org 15 Sep '08

15 Sep '08

Miguel Jinez wrote: > I was making a test deleting 8600 users in my ldap DIT, but I think > meanwhile Master A perform the actions the synchronization doesn't > respect the hierachy and deletes fathers but not his sons. > Why I said that, because I try to upload again the users and in some > cases they alredy exist I think I recall an ITS for this. Will check. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#5700) [enhancement] add support for certificateListExactMatch (RFC4523)
by ando＠sys-net.it 15 Sep '08

15 Sep '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando About to commit... p.

1 0

Re: (ITS#5695) AC syntax in OpenLDAP
by ando＠sys-net.it 15 Sep '08

15 Sep '08

Other comments: - you seem to have hijacked the OIDs for the AttributeCertificate and attributeCertificateExactAssertion syntaxes. I'll generate two under the OpenLDAP experimental arc, unless anyone can point me to any officially assigned. I don't think so, as the only document I could locate on the topic is a draft expired in 2001 (draft-ietf-pkix-ldap-schema), with no OID assigned by IANA. - as far as I can understand, the attributeCertificateExactAssertion allows more options; a fairly generic case would be { serialNumber 'dd'H, issuer { issuerName { directoryName:rdnSequence:"cn=y" }, -- optional baseCertificateID { serial '1d'H, issuer { directoryName:rdnSequence:"cn=z" }, issuerUID "<value>" -- optional }, -- optional objectDigestInfo { ... } -- optional } } while your implementation requires { serialNumber 'dd'H, issuer { baseCertificateID { serial '1d'H, issuer { directoryName:rdnSequence:"cn=z" } } } } nothing more and nothing less. If I'm correct, your implementation would pose some interoperability issues; yet, it represents a good starting point, given the absence of any standard track specification of PMI. 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#5695) AC syntax in OpenLDAP
by ando＠sys-net.it 13 Sep '08

13 Sep '08

tamburo(a)studenti.unina.it wrote: > Sorry for error the correct link is > http://www.studenti.unina.it/~tamburo/tesi/openldap/Luca-Tamburo-AC-08-09-1… > Thanks for the contribution. I gave a look at it, and seems to be fine, although I need to check something with X.509. I wonder if and how much you tested it, since while playing with it I found what I believe is a severe issue in lutil_str2bin(), which is used also in your code... (see ITS#5699). I also have a concern with respect to the IPR declaration on top of your patch, though. You state: > This patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following > patch(es) were developed by Luca Tamburo at ICAR, Branch of Naples, > Italy. Luca Tamburo has not assigned rights and/or interest in this > work to any party. I, Giovanni Schmid, project manager at ICAR, am > authorized by Luca Tamburo, my employer, to release this work under > the following terms. It sounds like you are authorizing Giovanni Schmid, project manager at ICAR, to release your work, or something like that? I think you should clarify it a little bit. In any case, I'd leave all issues about IPR to the OpenLDAP foundation; as soon as it's clarified, I'll commit your patch (with some modifications). 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

(ITS#5699) lutil_str2bin fails for certain hex values
by ando＠sys-net.it 13 Sep '08

13 Sep '08

Full_Name: Pierangelo Masarati Version: HEAD OS: Linux x86 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando When passed "'E31ED28BA060532F'H", lutil_str2bin() fails because calls strtol() passing it the first 8 hex digits ("E31ED28B"), which is larger than the largest long it can handle. Not sure about how to fix it (probably, it should use strtoul instead). p.

1 0

Re: (ITS#5695) AC syntax in OpenLDAP
by tamburo＠studenti.unina.it 12 Sep '08

12 Sep '08

Sorry for error the correct link is http://www.studenti.unina.it/~tamburo/tesi/openldap/Luca-Tamburo-AC-08-09-1… I have a problem with public ftp. Luca Tamburo ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

1 0

(ITS#5698) slapd crashes after trying to add an invalid database entry
by rhafer＠suse.de 12 Sep '08

12 Sep '08

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.152.188) slapd segfaults after trying to add an invalid database entry to cn=config. E.g. I used this one to reproduce the problem (substring index is not allowed for objectclass): dn: olcdatabase=hdb,cn=config objectclass: olchdbconfig olcdatabase: hdb olcsuffix: cn=test olcdbdirectory: /tmp olcdbcheckpoint: 3 5 olcdbindex: objectclass sub It crashes in the checkpoint runqueue task, which it seems has not be removed after the failed ADD operation: #0 0x000000000052303e in hdb_checkpoint (ctx=0x41f81dd0, arg=0xb1bfb0) at config.c:181 #1 0x00007f3cbcdd502f in ldap_int_thread_pool_wrapper (xpool=0x8ec640) at ../../../libraries/libldap_r/tpool.c:663 #2 0x00007f3cb9d73040 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f3cb9ae60cd in clone () from /lib64/libc.so.6 A fix is on the way to HEAD.

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by rmeggins＠redhat.com 12 Sep '08

12 Sep '08

This is a cryptographically signed message in MIME format. --------------ms030502050400050400000609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The following is from the person who developed the patch: This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Robert Relyea am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications 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. --------------ms030502050400050400000609 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJCzCC AuAwggJJoAMCAQICEFcdcRwRB8xs7lDIZBO/bfowDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MTIwNDE2MzM1OVoX DTA4MTIwMzE2MzM1OVowRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAG CSqGSIb3DQEJARYTcm1lZ2dpbnNAcmVkaGF0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBANpEUJJ++jpsDRmNt7cla8gygzXXoOHCPCubSxG0juJoxS/4F1UiyVSy0Gzb C5lVZemRenB+G389Ai11jLKp97S1abeQII26poIkjvYJCjyO92SJNFvb8mz6bkBW9NcH2zBt odjoeCvdlKuwxg1IX/kYsmz4lirjIVPFPSyqx7jgYhuNpjfR3oUuNRLx5Y6i9Ep+1AmTkoWx NNwMNFwRUOh78z/Gvh9exCB8Xldd58egHfYluBraFi5IgkGQneI4+VyFrNwwX1XtjI2EmDrO HnMTZGnkYBH5L6b54bMkIKxMmZrmdzcyQ0JLbz2GZqKo5BUaN4M1M2kTCy0HbKOlhZECAwEA AaMwMC4wHgYDVR0RBBcwFYETcm1lZ2dpbnNAcmVkaGF0LmNvbTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBQUAA4GBAELh1VaZchhZmlX93Wmbu8loeXNOP5/RRJVHCgom1N7g4YZBcBwM 1bmoo5b9gK3IPrPxZu2zYuyxwveNM0KdmaYtLzWiStJyifMDb8FtMNvVc5oewQK5tnDUw3dG MH/TxiE/hEZiRjAVylPiwzq47PjVPIM87Rek8hROvCkaEO6hMIIC4DCCAkmgAwIBAgIQVx1x HBEHzGzuUMhkE79t+jANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDcxMjA0MTYzMzU5WhcNMDgxMjAzMTYzMzU5WjBF MR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSIwIAYJKoZIhvcNAQkBFhNybWVn Z2luc0ByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2kRQkn76 OmwNGY23tyVryDKDNdeg4cI8K5tLEbSO4mjFL/gXVSLJVLLQbNsLmVVl6ZF6cH4bfz0CLXWM sqn3tLVpt5AgjbqmgiSO9gkKPI73ZIk0W9vybPpuQFb01wfbMG2h2Oh4K92Uq7DGDUhf+Riy bPiWKuMhU8U9LKrHuOBiG42mN9HehS41EvHljqL0Sn7UCZOShbE03Aw0XBFQ6HvzP8a+H17E IHxeV13nx6Ad9iW4GtoWLkiCQZCd4jj5XIWs3DBfVe2MjYSYOs4ecxNkaeRgEfkvpvnhsyQg rEyZmuZ3NzJDQktvPYZmoqjkFRo3gzUzaRMLLQdso6WFkQIDAQABozAwLjAeBgNVHREEFzAV gRNybWVnZ2luc0ByZWRoYXQuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEA QuHVVplyGFmaVf3daZu7yWh5c04/n9FElUcKCibU3uDhhkFwHAzVuaijlv2Arcg+s/Fm7bNi 7LHC940zQp2Zpi0vNaJK0nKJ8wNvwW0w29Vzmh7BArm2cNTDd0Ywf9PGIT+ERmJGMBXKU+LD Orjs+NU8gzztF6TyFE68KRoQ7qEwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHR MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRv d24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9u IFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMw NzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftO ucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Va qj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2 0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6 MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENB LmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJl bDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0wh uPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmO jCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDcTCCA20C AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEFcd cRwRB8xs7lDIZBO/bfowCQYFKw4DAhoFAKCCAdAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDgwOTEyMDE1ODU5WjAjBgkqhkiG9w0BCQQxFgQUia3iQGIt gUDrIWJABkXGXDP2uO0wXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQVx1xHBEHzGzuUMhkE79t+jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIx CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSww KgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQVx1xHBEHzGzu UMhkE79t+jANBgkqhkiG9w0BAQEFAASCAQCxIfkCUbjvfwVycRf8HdSbkjTeYjkd18E9+gHw 6Lvbs3UYzlWj8yZSynu15jPPg6KhqwX3kG7mVJybQtGpVLt5PMjp+OgIspDWIHOk5bhw/CW7 0OqtZwEVHH1tCIPKIeCHWlRq367W6DKy0SUs843IRpPa8o1YgxLGIIhp4BBxrdx6/Ep7WUtk PvA1mDRcrVQceTzJoHnwe56bSNXnkCrsYA94NAd4NFmRSoE8JVeWWgBBbgI3IEEvINTC+pM3 nbh1gOxxBMFtw2JFufrWnCGnXyVKy5rfPL8BPI3ul6N1AurDhTNbAXOHJkz+OZLOlMxyKJA9 s7ua54QILncIuSWzAAAAAAAA --------------ms030502050400050400000609--

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by rmeggins＠redhat.com 11 Sep '08

11 Sep '08

This is a cryptographically signed message in MIME format. --------------ms030000020803000108060801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Howard Chu wrote: > rmeggins(a)redhat.com wrote: >> Full_Name: Rich Megginson >> Version: 2.4.11 and current HEAD >> OS: Fedora >> URL: ftp://ftp.openldap.org/incoming/openldap-2.4.11-nss-20080911.patch >> Submission from: (NULL) (76.113.59.19) >> >> >> This patch allows OpenLDAP to use Mozilla NSS for crypto. The >> approach uses the >> nss_compat_ossl library. This library allows the code to use the >> current >> OpenSSL API so that the changes to the actual OpenLDAP code are >> minimized. This >> is the same approach that has been used to port several other >> packages to use >> NSS instead of OpenSSL as part of the Fedora Crypto Consolidation >> project. >> >> The nss_compat_ossl library is here - >> http://svn.fedorahosted.org/svn/identity/common/trunk/nss_compat_ossl/ >> - it is >> also included with Fedora > > Thanks for the patch. Some notes - for future reference, don't include > diffs to generated files (e.g. configure), just include the diffs to > the source (e.g. configure.in). Ok. Sorry about that. I've just been applying this patch for testing, but yeah, you will just regenerate configure. > Since "NSS" already has a well-established meaning in POSIX > environments (Name Service Switch), I've been referring to this as > MozNSS (Mozilla NSS) to avoid confusion. Ok. Yeah, it's very confusing. The nss developers haven't run into this problem that much yet - but nss is used quite heavily in the ldap space (nss_ldap etc.) > > Also, there's already a working implementation of Mozilla NSS support > in HEAD, but your patch covers a lot of areas I didn't look at yet > (SHA1 hashing, etc) so we'll probably cherrypick pieces of your patch > to merge. Ok. Sounds good. --------------ms030000020803000108060801 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJCzCC AuAwggJJoAMCAQICEFcdcRwRB8xs7lDIZBO/bfowDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MTIwNDE2MzM1OVoX DTA4MTIwMzE2MzM1OVowRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAG CSqGSIb3DQEJARYTcm1lZ2dpbnNAcmVkaGF0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBANpEUJJ++jpsDRmNt7cla8gygzXXoOHCPCubSxG0juJoxS/4F1UiyVSy0Gzb C5lVZemRenB+G389Ai11jLKp97S1abeQII26poIkjvYJCjyO92SJNFvb8mz6bkBW9NcH2zBt odjoeCvdlKuwxg1IX/kYsmz4lirjIVPFPSyqx7jgYhuNpjfR3oUuNRLx5Y6i9Ep+1AmTkoWx NNwMNFwRUOh78z/Gvh9exCB8Xldd58egHfYluBraFi5IgkGQneI4+VyFrNwwX1XtjI2EmDrO HnMTZGnkYBH5L6b54bMkIKxMmZrmdzcyQ0JLbz2GZqKo5BUaN4M1M2kTCy0HbKOlhZECAwEA AaMwMC4wHgYDVR0RBBcwFYETcm1lZ2dpbnNAcmVkaGF0LmNvbTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBQUAA4GBAELh1VaZchhZmlX93Wmbu8loeXNOP5/RRJVHCgom1N7g4YZBcBwM 1bmoo5b9gK3IPrPxZu2zYuyxwveNM0KdmaYtLzWiStJyifMDb8FtMNvVc5oewQK5tnDUw3dG MH/TxiE/hEZiRjAVylPiwzq47PjVPIM87Rek8hROvCkaEO6hMIIC4DCCAkmgAwIBAgIQVx1x HBEHzGzuUMhkE79t+jANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDcxMjA0MTYzMzU5WhcNMDgxMjAzMTYzMzU5WjBF MR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSIwIAYJKoZIhvcNAQkBFhNybWVn Z2luc0ByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2kRQkn76 OmwNGY23tyVryDKDNdeg4cI8K5tLEbSO4mjFL/gXVSLJVLLQbNsLmVVl6ZF6cH4bfz0CLXWM sqn3tLVpt5AgjbqmgiSO9gkKPI73ZIk0W9vybPpuQFb01wfbMG2h2Oh4K92Uq7DGDUhf+Riy bPiWKuMhU8U9LKrHuOBiG42mN9HehS41EvHljqL0Sn7UCZOShbE03Aw0XBFQ6HvzP8a+H17E IHxeV13nx6Ad9iW4GtoWLkiCQZCd4jj5XIWs3DBfVe2MjYSYOs4ecxNkaeRgEfkvpvnhsyQg rEyZmuZ3NzJDQktvPYZmoqjkFRo3gzUzaRMLLQdso6WFkQIDAQABozAwLjAeBgNVHREEFzAV gRNybWVnZ2luc0ByZWRoYXQuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEA QuHVVplyGFmaVf3daZu7yWh5c04/n9FElUcKCibU3uDhhkFwHAzVuaijlv2Arcg+s/Fm7bNi 7LHC940zQp2Zpi0vNaJK0nKJ8wNvwW0w29Vzmh7BArm2cNTDd0Ywf9PGIT+ERmJGMBXKU+LD Orjs+NU8gzztF6TyFE68KRoQ7qEwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHR MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRv d24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9u IFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMw NzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftO ucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Va qj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2 0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6 MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENB LmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJl bDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0wh uPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmO jCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDcTCCA20C AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEFcd cRwRB8xs7lDIZBO/bfowCQYFKw4DAhoFAKCCAdAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDgwOTExMjEwMjU3WjAjBgkqhkiG9w0BCQQxFgQUgrlU70hz emgL9UroY5tdya2gFvQwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQVx1xHBEHzGzuUMhkE79t+jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIx CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSww KgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQVx1xHBEHzGzu UMhkE79t+jANBgkqhkiG9w0BAQEFAASCAQAd2tnYv6GJIgrUuiqErc/NxB904FghsimijiCx jd4WqQ6hK4rJMvq39V8ZYThQoSHhp+w6SjztTwjv6PIMibDl9ZyIIp2d8GexMsxemIRWMMp4 K955F5ZcyB9skETGGOV77adbPebwdLHAk8//oNx75bSw786gr8vxaxu9iYR79fuZNsgzQewS 4u/+9vOxAROy6VMQ+2ZW0hcca/gZLGkIjKL16GRVVAdkHmhHSu3zIOQsmrtX9uzuDyPl+Nrj nKySb2vCjn+G/VDeKmtWOHfV0aBbBOUBzdLBG8qvNS2HvNZrAJPxIwv+RTn5sHREGjDe8KWO EOPq+KbmlM06Ccy4AAAAAAAA --------------ms030000020803000108060801--

1 0

(ITS#5697) Typo on contributing guidelines
by hyc＠OpenLDAP.org 11 Sep '08

11 Sep '08

Full_Name: Howard Chu Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc On http://www.openldap.org/devel/contributing.html Index: contributing.wml =================================================================== RCS file: /repo/OpenLDAP/www/pages/devel/contributing.wml,v retrieving revision 1.30 diff -u -r1.30 contributing.wml --- contributing.wml 3 Apr 2008 21:59:54 -0000 1.30 +++ contributing.wml 11 Sep 2008 21:02:23 -0000 @@ -195,7 +195,7 @@ If you have assigned rights and/or interest in this work to another party, such as your employer (possibly through your employment agreement), you must state which rights you have assigned and to -whom. For instance, "By virtual of my employment agreement with +whom. For instance, "By virtue of my employment agreement with EMPLOYER-NAME, I have assigned my rights and interest in this work to EMPLOYER-NAME."

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by hyc＠symas.com 11 Sep '08

11 Sep '08

hyc(a)symas.com wrote: > rmeggins(a)redhat.com wrote: >> Full_Name: Rich Megginson >> Version: 2.4.11 and current HEAD >> OS: Fedora >> URL: ftp://ftp.openldap.org/incoming/openldap-2.4.11-nss-20080911.patch >> Submission from: (NULL) (76.113.59.19) >> This patch allows OpenLDAP to use Mozilla NSS for crypto. The approach uses the >> nss_compat_ossl library. This library allows the code to use the current >> OpenSSL API so that the changes to the actual OpenLDAP code are minimized. This >> is the same approach that has been used to port several other packages to use >> NSS instead of OpenSSL as part of the Fedora Crypto Consolidation project. > Thanks for the patch. Some notes - for future reference, don't include diffs > to generated files (e.g. configure), just include the diffs to the source > (e.g. configure.in). Since "NSS" already has a well-established meaning in > POSIX environments (Name Service Switch), I've been referring to this as > MozNSS (Mozilla NSS) to avoid confusion. Also please read http://www.openldap.org/devel/contributing.html ; you haven't provided any of the required IPR notices. We can't touch the submission without them. -- -- 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#5696) Patch - support Mozilla NSS for crypto operations
by hyc＠symas.com 11 Sep '08

11 Sep '08

rmeggins(a)redhat.com wrote: > Full_Name: Rich Megginson > Version: 2.4.11 and current HEAD > OS: Fedora > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.11-nss-20080911.patch > Submission from: (NULL) (76.113.59.19) > > > This patch allows OpenLDAP to use Mozilla NSS for crypto. The approach uses the > nss_compat_ossl library. This library allows the code to use the current > OpenSSL API so that the changes to the actual OpenLDAP code are minimized. This > is the same approach that has been used to port several other packages to use > NSS instead of OpenSSL as part of the Fedora Crypto Consolidation project. > > The nss_compat_ossl library is here - > http://svn.fedorahosted.org/svn/identity/common/trunk/nss_compat_ossl/ - it is > also included with Fedora Thanks for the patch. Some notes - for future reference, don't include diffs to generated files (e.g. configure), just include the diffs to the source (e.g. configure.in). Since "NSS" already has a well-established meaning in POSIX environments (Name Service Switch), I've been referring to this as MozNSS (Mozilla NSS) to avoid confusion. Also, there's already a working implementation of Mozilla NSS support in HEAD, but your patch covers a lot of areas I didn't look at yet (SHA1 hashing, etc) so we'll probably cherrypick pieces of your patch to merge. -- -- 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#5668) Invalid entryCSN generated, and slapd will not restart
by hyc＠symas.com 11 Sep '08

11 Sep '08

Hallvard B Furuseth wrote: > Looking at liblutil/utils.c:lutil_gettime() led me to > > Beware of QueryPerformanceCounter() > http://www.virtualdub.org/blog/pivot/entry.php?id=106 > > Is warning relevant to slapd? I don't know Windows programming at all. > Yes, it's relevant. People running on Windows should probably boot with /usepmtimer to make sure the ACPI timer is used (which runs at 3.5MHz). Then again, the simplest solution is "don't run mission-critical servers on Windows" because the platform is so completely inadequate, for this and many other reasons. Probably should read this as well http://support.microsoft.com/kb/895980 Of course, not all of this uncertainty is Microsoft's fault - AMD documented that their dual-core processors would keep their TSCs in sync between both cores, but in reality the TSCs never stay in sync. So if you happen to be running an old-enough Windows release, written when the TSC was still believed to be a reliable clock source, you may have problems unless you explicitly tell Windows to use the ACPI PM timer. If you're running on a very old motherboard that doesn't support ACPI, you won't have a PM timer to use; but in that case you're probably also running with a processor that doesn't have TSC issues. -- -- 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#5695) AC syntax in OpenLDAP
by ando＠sys-net.it 11 Sep '08

11 Sep '08

bash-3.2$ wget ftp://ftp.openldap.org/incoming/Tamburo-Luca-AC-08-09-11.tgz --19:53:57-- ftp://ftp.openldap.org/incoming/Tamburo-Luca-AC-08-09-11.tgz => `Tamburo-Luca-AC-08-09-11.tgz' Resolving ftp.openldap.org... 204.152.186.57, 2001:4f8:3:ba:2e0:18ff:fe02:efec Connecting to ftp.openldap.org|204.152.186.57|:21... connected. Logging in as anonymous ... Logged in! ==> SYST ... done. ==> PWD ... done. ==> TYPE I ... done. ==> CWD /incoming ... done. ==> SIZE Tamburo-Luca-AC-08-09-11.tgz ... done. ==> PASV ... done. ==> RETR Tamburo-Luca-AC-08-09-11.tgz ... No such file `Tamburo-Luca-AC-08-09-11.tgz'. Could you please provide a pointer to the exact link? 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

(ITS#5696) Patch - support Mozilla NSS for crypto operations
by rmeggins＠redhat.com 11 Sep '08

11 Sep '08

Full_Name: Rich Megginson Version: 2.4.11 and current HEAD OS: Fedora URL: ftp://ftp.openldap.org/incoming/openldap-2.4.11-nss-20080911.patch Submission from: (NULL) (76.113.59.19) This patch allows OpenLDAP to use Mozilla NSS for crypto. The approach uses the nss_compat_ossl library. This library allows the code to use the current OpenSSL API so that the changes to the actual OpenLDAP code are minimized. This is the same approach that has been used to port several other packages to use NSS instead of OpenSSL as part of the Fedora Crypto Consolidation project. The nss_compat_ossl library is here - http://svn.fedorahosted.org/svn/identity/common/trunk/nss_compat_ossl/ - it is also included with Fedora

1 0

(ITS#5695) AC syntax in OpenLDAP
by tamburo＠studenti.unina.it 11 Sep '08

11 Sep '08

Full_Name: Tamburo Luca Version: cvs OS: URL: ftp://ftp.openldap.org/incoming/Tamburo-Luca-AC-08-09-11.tgz Submission from: (NULL) (82.51.134.108) Hi, I'm a student at University "Federico II" (Napoli, Italy). For my bachelor degree I have worked on LDAP and Attribute Certicates. My main source has been Standard X.509 (2000). More precisely I have implemented a function to validate AC syntax, and the equality matching rule "attribute Certificate Exact Match" as defined in Internet Draft: "Internet X.509 Public Key Infrastructure LDAP Schema and Syntaxes for PMIs" (by D. Chadwick and S.Legg, 27 June 2002). I have changed the file servers/slapd/schema_init.c; I needed to create a new schema file called guest.schema which contains the definitions of objectclass pmiUser and the attribute type attributeCertificateAttribute. Link for the archive is ftp://ftp.openldap.org/incoming/Tamburo-Luca-AC-08-09-11.tgz Thanks in advance for your attention. Best regards, Luca Tamburo

1 0

RE: (ITS#5668) Invalid entryCSN generated, and slapd will not restart
by emmanuel.duru＠atosorigin.com 11 Sep '08

11 Sep '08

OK, it works.

1 0

Re: (ITS#5668) Invalid entryCSN generated, and slapd will not restart
by h.b.furuseth＠usit.uio.no 11 Sep '08

11 Sep '08

Looking at liblutil/utils.c:lutil_gettime() led me to Beware of QueryPerformanceCounter() http://www.virtualdub.org/blog/pivot/entry.php?id=106 Is warning relevant to slapd? I don't know Windows programming at all. -- Hallvard

1 0

Re: (ITS#5668) Invalid entryCSN generated, and slapd will not restart
by hyc＠symas.com 11 Sep '08

11 Sep '08

emmanuel.duru(a)atosorigin.com wrote: > I am running windows 32 bits. > Here is what I get from my debugging session: > After QueryPerformanceCounter(&count ), count.QuadPart is worth > 4243738405535005 > So the overflow comes from count.QuadPart *= 1000000; I see. There's no reason we should be computing against the full value of the count; since we're only looking for the microsecond portion we should have stripped off everything greater. (E.g., count.QuadPart %= cFreq.QuadPart). I'll have to play with this code a bit more, there's probably a better way to isolate the microseconds. PS: I guess that means your Windows machine had an uptime of several days. Quite impressive, for Windows... ;) > > >> -----Message d'origine----- >> De : Howard Chu [mailto:hyc@symas.com] >> Envoyé : mercredi 27 août 2008 13:08 >> À : openldap-its(a)openldap.org; Emmanuel Duru >> Objet : Re: (ITS#5668) Invalid entryCSN generated, and slapd will not >> restart >> >> ando(a)sys-net.it wrote: >>> emmanuel.duru(a)atosorigin.com wrote: >>>> I see that tm->tm_usub is negative, there seems to be overflows between >>>> LARGE_INTEGER and int variables. >> It would take over 4 billion operations in a single timer tick (on the >> order >> of nanoseconds) to make tm_usub overflow. That seems pretty unlikely. >> >>> If the problem disappears by initializing the static variables in >>> lutil_gettime(), then it might be a compiler issue. >> I suppose that's always possible... >> >> The original post shows that the tm_usec field is negative. That could >> happen >> if the offset we computed between the SYSTEMTIME and the >> PerformanceCounter >> was wrong, or if the SYSTEMTIME was adjusted while the process was >> running. >> >> What version of Windows are you running? 32 or 64 bit? Can you singlestep >> through this function with a debugger and verify all of the values? I >> haven't >> run this code on Windows in a long time, would take a bit of effort to >> resurrect my build environment. >> >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/project/ > > > > -- -- 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#5694)
by ando＠sys-net.it 10 Sep '08

10 Sep '08

Works for me, after Howard's fix. 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#5694) Usage of -w with slapadd breaks delta-syncrepl
by ando＠sys-net.it 09 Sep '08

09 Sep '08

Quanah Gibson-Mount wrote: > Just to be clear here, I'm slapcating a provider while it is running, > then stopping the provider and the replica, wiping both their dbs, then > using slapadd -w to reload the *provider* and syncrepl to load the > consumer. Thus I don't see whether or not the CSN is in memory at the > time on the *provider* matters much. Right, it shouldn't matter, since either it is equal to what -w would generate, or -w would overwrite it with the correct value anyway. The only case I see is if the last operation was a delete, then the contextCSN on the provider would be greater than what a slapadd -w would generate. > Particularly given that if I stop > the reloaded provider and restart it (i.e., flushing the context CSN), I > still get the same behavior problems on the replica. I.e., the replica > has never been loaded via slapadd, only the provider, and the provider > has been stopped started since the slapadd. In fact, I could easily reproduce the behavior you pointed out. 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#5694) Usage of -w with slapadd breaks delta-syncrepl
by quanah＠zimbra.com 09 Sep '08

09 Sep '08

--On Tuesday, September 09, 2008 8:59 PM +0200 Pierangelo Masarati <ando(a)sys-net.it> wrote: > Quanah Gibson-Mount wrote: >> --On Tuesday, September 09, 2008 8:50 PM +0200 Pierangelo Masarati >> <ando(a)sys-net.it> wrote: >> >>> I thuink the issue is related to the fact that slapadd -w uses >>> bi_tool_entry_modify() and bi_tool_sync(). However, slapo-accesslog(5) >>> does not implement those hooks. As a consequence, any modification to >>> the context entry is not reflected in slapo-accesslog(5). >>> >>> However, I don't see how this should affect replication, since a >>> consistent database, after slapcatt'ing, should generate a ldif with the >>> correct contextCSN. However, if you slapcat before stopping the >>> producer, the resulting ldif will not contain the contextCSN, because >>> after a fresh slapadd without -w it's kept in memory until the producer >>> is stopped. You should try Just to be clear here, I'm slapcating a provider while it is running, then stopping the provider and the replica, wiping both their dbs, then using slapadd -w to reload the *provider* and syncrepl to load the consumer. Thus I don't see whether or not the CSN is in memory at the time on the *provider* matters much. Particularly given that if I stop the reloaded provider and restart it (i.e., flushing the context CSN), I still get the same behavior problems on the replica. I.e., the replica has never been loaded via slapadd, only the provider, and the provider has been stopped started since the slapadd. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5694) Usage of -w with slapadd breaks delta-syncrepl
by quanah＠zimbra.com 09 Sep '08

09 Sep '08

--On Tuesday, September 09, 2008 12:19 PM -0700 Howard Chu <hyc(a)symas.com> wrote: > quanah(a)zimbra.com wrote: >> --On Tuesday, September 09, 2008 8:59 PM +0200 Pierangelo Masarati >> <ando(a)sys-net.it> wrote: >> >> >>>> I'll give what you suggested a try, but this is still a serious bug. >>> There's something I don't clearly get. As far as I understand, you are >>> saying that consumers lose sync when the log database is purged before >>> they have a chance to sync (because they were down). I don't see how >>> they could sync, then. Of course, there should be a means for >>> slapo-syncprov(5) to tell that, and force a refresh. >> >> Because the consumer is supposed to do a full refresh if they find their >> context CSN doesn't match the contextCSN of the master. > > Not quite. More precisely, the provider is supposed to tell the consumer > that the consumer's cookie is out of date if the cookie is older than > anything in the provider, and the consumer asked for the reload Hint. > Otherwise the provider just sees the consumer is stale and returns a full > dump implicitly. Well, the consumer's definitely not acting on a full dump in either case. :/ In my latest test, after the purge, I have: # accesslog dn: cn=accesslog contextCSN: 20080909190440.484524Z#000000#000#000000 dn: contextCSN: 20080909190440.484524Z#000000#000#000000 on the master and contextCSN: 20080909183254.258851Z#000000#000#000000 on the replica prior to starting it. SO the replica is clearly behind. The new entry on the master is: dn: uid=qtest7,cn=admins,cn=zimbra entryCSN: 20080909190440.484524Z#000000#000#000000 which matches the CSN on both the main DB and accesslog DB. now, staring the replica, we find: contextCSN: 20080909190440.484524Z#000000#000#000000 So, it believes it has sync'd now, but uid=qtest7 doesn't exist! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5694) Usage of -w with slapadd breaks delta-syncrepl
by hyc＠symas.com 09 Sep '08

09 Sep '08

quanah(a)zimbra.com wrote: > --On Tuesday, September 09, 2008 8:59 PM +0200 Pierangelo Masarati > <ando(a)sys-net.it> wrote: > > >>> I'll give what you suggested a try, but this is still a serious bug. >> There's something I don't clearly get. As far as I understand, you are >> saying that consumers lose sync when the log database is purged before >> they have a chance to sync (because they were down). I don't see how >> they could sync, then. Of course, there should be a means for >> slapo-syncprov(5) to tell that, and force a refresh. > > Because the consumer is supposed to do a full refresh if they find their > context CSN doesn't match the contextCSN of the master. Not quite. More precisely, the provider is supposed to tell the consumer that the consumer's cookie is out of date if the cookie is older than anything in the provider, and the consumer asked for the reload Hint. Otherwise the provider just sees the consumer is stale and returns a full dump implicitly. In plain syncrepl the consumer never asks for the reload hint. In delta-sync the consumer does ask for a reload hint, because that tells it to do a sync from the main DB instead of the log DB. It sounds like if there's a bug here, it's caused by the logdb's provider not sending a reload hint when it should. > See ITS#5376, ITS#5378, ITS#5465, ITS#5493, ITS#5282 -- -- 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#5694) Usage of -w with slapadd breaks delta-syncrepl
by quanah＠zimbra.com 09 Sep '08

09 Sep '08

--On Tuesday, September 09, 2008 8:59 PM +0200 Pierangelo Masarati <ando(a)sys-net.it> wrote: >> I'll give what you suggested a try, but this is still a serious bug. > > There's something I don't clearly get. As far as I understand, you are > saying that consumers lose sync when the log database is purged before > they have a chance to sync (because they were down). I don't see how > they could sync, then. Of course, there should be a means for > slapo-syncprov(5) to tell that, and force a refresh. Because the consumer is supposed to do a full refresh if they find their context CSN doesn't match the contextCSN of the master. See ITS#5376, ITS#5378, ITS#5465, ITS#5493, ITS#5282 --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5694) Usage of -w with slapadd breaks delta-syncrepl
by ando＠sys-net.it 09 Sep '08

09 Sep '08

Quanah Gibson-Mount wrote: > --On Tuesday, September 09, 2008 8:50 PM +0200 Pierangelo Masarati > <ando(a)sys-net.it> wrote: > >> I thuink the issue is related to the fact that slapadd -w uses >> bi_tool_entry_modify() and bi_tool_sync(). However, slapo-accesslog(5) >> does not implement those hooks. As a consequence, any modification to >> the context entry is not reflected in slapo-accesslog(5). >> >> However, I don't see how this should affect replication, since a >> consistent database, after slapcatt'ing, should generate a ldif with the >> correct contextCSN. However, if you slapcat before stopping the >> producer, the resulting ldif will not contain the contextCSN, because >> after a fresh slapadd without -w it's kept in memory until the producer >> is stopped. You should try > > It should be possible to restore a working provider/slave relationship > from a hot slapcat taken at any point in time. Well, actually slapadd -w should suffice. As an alternative, slapcat could support -w as well, for symmetry, so that consistent ldifs can be generated. > I'll give what you suggested a try, but this is still a serious bug. There's something I don't clearly get. As far as I understand, you are saying that consumers lose sync when the log database is purged before they have a chance to sync (because they were down). I don't see how they could sync, then. Of course, there should be a means for slapo-syncprov(5) to tell that, and force a refresh. 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#5694) Usage of -w with slapadd breaks delta-syncrepl
by quanah＠zimbra.com 09 Sep '08

09 Sep '08

--On Tuesday, September 09, 2008 8:50 PM +0200 Pierangelo Masarati <ando(a)sys-net.it> wrote: > I thuink the issue is related to the fact that slapadd -w uses > bi_tool_entry_modify() and bi_tool_sync(). However, slapo-accesslog(5) > does not implement those hooks. As a consequence, any modification to > the context entry is not reflected in slapo-accesslog(5). > > However, I don't see how this should affect replication, since a > consistent database, after slapcatt'ing, should generate a ldif with the > correct contextCSN. However, if you slapcat before stopping the > producer, the resulting ldif will not contain the contextCSN, because > after a fresh slapadd without -w it's kept in memory until the producer > is stopped. You should try It should be possible to restore a working provider/slave relationship from a hot slapcat taken at any point in time. I'll give what you suggested a try, but this is still a serious bug. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5694) Usage of -w with slapadd breaks delta-syncrepl
by ando＠sys-net.it 09 Sep '08

09 Sep '08

I thuink the issue is related to the fact that slapadd -w uses bi_tool_entry_modify() and bi_tool_sync(). However, slapo-accesslog(5) does not implement those hooks. As a consequence, any modification to the context entry is not reflected in slapo-accesslog(5). However, I don't see how this should affect replication, since a consistent database, after slapcatt'ing, should generate a ldif with the correct contextCSN. However, if you slapcat before stopping the producer, the resulting ldif will not contain the contextCSN, because after a fresh slapadd without -w it's kept in memory until the producer is stopped. You should try (i) stop the master and replica (j) do a slapcat of the master (k) delete the database on the master and replica (l) Use slapadd -w to restore your slapcat of 5 users (m) start the replica, verify the contents are the same (n) stop the replica (o) add a user on the master (p) wait for the accesslog to expire (q) start the replica In the meanwhile, you should check what contextCSN your consumers have after syncing from a producer loaded without -w. 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#5694) Usage of -w with slapadd breaks delta-syncrepl
by quanah＠zimbra.com 09 Sep '08

09 Sep '08

--On Tuesday, September 09, 2008 6:27 PM +0000 quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24 9/7/2008 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > As reported by David Hawes: > > http://www.openldap.org/lists/openldap-software/200808/msg00163.html > > If you load a server that will become the delta-syncrepl master using > slapadd -w, the slave will not see changes that occur after the accesslog > expires. Additionally did the following: Stopped the replica again, purged its db, restarted it so it got a fresh sync from the master (all users present). stopped the replica, added a new user on the master, let it expire from the accesslog db. started the replica. New user is not replicated. So it essentially appears that once -w is used to slapadd a master, no replica will be consistent if changes occur that are purged before the replica gets them. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5694) Usage of -w with slapadd breaks delta-syncrepl
by quanah＠zimbra.com 09 Sep '08

09 Sep '08

Full_Name: Quanah Gibson-Mount Version: RE24 9/7/2008 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) As reported by David Hawes: http://www.openldap.org/lists/openldap-software/200808/msg00163.html If you load a server that will become the delta-syncrepl master using slapadd -w, the slave will not see changes that occur after the accesslog expires. To confirm this, I did the following: (a) Created a base LDIF file that set up the suffix, a people tree, and a replica user (b) slapadded this LDIF file WITHOUT -w on the master (c) started the master (d) started the replica All data was replicated correctly (e) Stopped the replica (f) Added 6 users, and then deleted one (g) waited for the accesslog to expire (h) started the replica All data was replicated correctly (i) did a slapcat of the master (j) stopped the master and replica (k) deleted the database on the master and replica (l) Used slapadd -w to restore my slapcat of 5 users (m) started the replica, verified the contents were the same (n) stopped the replica (o) added a user on the master (p) waited for the accesslog to expire (q) started the replica The user I added was not replicated, and now the databases are inconsistent.

1 0

Re: (ITS#5690) cn=config cannot be rootdn
by quanah＠zimbra.com 09 Sep '08

09 Sep '08

--On Tuesday, September 09, 2008 4:52 PM +0000 ando(a)sys-net.it wrote: > Quanah Gibson-Mount wrote: >> --On Tuesday, September 09, 2008 10:10 AM +0000 ando(a)sys-net.it wrote: >> >>> quanah(a)zimbra.com wrote: >>> >>>> In OpenLDAP 2.3, it was possible to set the rootdn of the main database >>>> to be cn=config. This no longer works in OpenLDAP 2.4, but seems like >>>> it should be valid to me. >>> >>> ... >>> >>>> cn=config is *clearly* under "" >>> >>> No, cn=config is *clearly* under cn=config, which comes earlier than "". >>> But then you don't need to set rootpw. >> >> Ah, I see. So this is more just a behavior change between 2.3 and 2.4. >> Thanks! > > Well, I don't think they changed that much. If you expose cn=config > then any DN in that namespace will belong to the back-config; if you > don't expose it, then it will belong to "". I think you weren't using > the same slapd.conf with 2.3 and 2.4, if you noticed a different behavior. Hm, you're right, I mixed parts of a stock 2.4 slapd.conf with my 2.3 slapd.conf. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5690) cn=config cannot be rootdn
by ando＠sys-net.it 09 Sep '08

09 Sep '08

Quanah Gibson-Mount wrote: > --On Tuesday, September 09, 2008 10:10 AM +0000 ando(a)sys-net.it wrote: > >> quanah(a)zimbra.com wrote: >> >>> In OpenLDAP 2.3, it was possible to set the rootdn of the main database >>> to be cn=config. This no longer works in OpenLDAP 2.4, but seems like >>> it should be valid to me. >> >> ... >> >>> cn=config is *clearly* under "" >> >> No, cn=config is *clearly* under cn=config, which comes earlier than "". >> But then you don't need to set rootpw. > > Ah, I see. So this is more just a behavior change between 2.3 and 2.4. > Thanks! Well, I don't think they changed that much. If you expose cn=config then any DN in that namespace will belong to the back-config; if you don't expose it, then it will belong to "". I think you weren't using the same slapd.conf with 2.3 and 2.4, if you noticed a different behavior. 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#5690) cn=config cannot be rootdn
by quanah＠zimbra.com 09 Sep '08

09 Sep '08

--On Tuesday, September 09, 2008 10:10 AM +0000 ando(a)sys-net.it wrote: > quanah(a)zimbra.com wrote: > >> In OpenLDAP 2.3, it was possible to set the rootdn of the main database >> to be cn=config. This no longer works in OpenLDAP 2.4, but seems like >> it should be valid to me. > > ... > >> cn=config is *clearly* under "" > > No, cn=config is *clearly* under cn=config, which comes earlier than "". > But then you don't need to set rootpw. Ah, I see. So this is more just a behavior change between 2.3 and 2.4. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5691) Re: malloc without check
by ando＠sys-net.it 09 Sep '08

09 Sep '08

Actually, I see plenty of places where it occurs. I vaguely recall that malloc used to be #defined as ch_malloc within slapd, although I believe it is no longer. In any case, I'm in favor of avoiding those redefinitions, for the sake of clarity. The correct solution should be to replace them with ch_malloc() (same for other memory-related functions, like calloc(), realloc(), strdup() and free(), although the latter is not strictly needed). 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

(ITS#5692) Re: literal constant 8192 used instead of SLAP_LDAPDN_MAXLEN
by ando＠sys-net.it 09 Sep '08

09 Sep '08

In none of the files you indicated the buffer size 8192 is used for a DN, so I see no reason for hijacking SLAP_LDAPDN_MAXLEN for that purpose. It might be good practice to define one or more macros and consistently use them, although in the specific cases there is no repeated use of the value, nor specific consistency constraints for the use of that value. With respect to your second question, OpenLDAP never relies on SLAP_LDAPDN_MAXLEN stability in terms of buffer access; since that macro is local to slapd, if it changes the whole slapd will see it. The only issue could be with redefinition of the macro across module compilation, if you use dynamic modules. Also in that case things shouldn't be critical, as slapd never relies on that macro for accessing buffers, but rather on actual buffer size. The only potentia issue I see is with spurious syntax errors if a module with larger SLAP_LDAPDN_MAXLEN calls a DN-related validation/normalization function passing a DN whose length is larger than the value of SLAP_LDAPDN_MAXLEN slapd was built with. No buffer overflow risk, though; at most, DoS on uncommonly long DNs. 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

(ITS#5693) [enhancement] extension of slapo-translucent filtering approach
by ando＠sys-net.it 09 Sep '08

09 Sep '08

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando I see a few potential issues in current slapo-translucent(5) filtering approach: - if an attribute is marked as local, it will not be used to filter entries on the remote server; however, that attribute might exist in entries on the remote server, resulting in inconsistent search results - the same is also true in the reverse case in those cases, it might be helpful to let the same attribute be listed as local *and* remote, acting accordingly. Also, there is no way to indicate that some attributes are local and *all the others* are remote (and viceversa); it is suggested to allow "*" (and "+"?), as well as "1.1" to indicate no attributes. Wildcards would take effect unless attribute specifications are present. I don't know, right now, how easy it would be to implement those enhancements; I'm just noting them here as a reminder for a feature request. p.

1 0

Re: (ITS#5665) slapd crashing with slapo-pcache when using attrset "*"
by toby＠inf.ed.ac.uk 09 Sep '08

09 Sep '08

Hi again, I haven't been able to reproduce the problem since patching, so I consider it fixed.... Many thanks Toby -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

(ITS#5692) literal constant 8192 used instead of SLAP_LDAPDN_MAXLEN
by andreas.moroder＠gmx.net 09 Sep '08

09 Sep '08

Full_Name: Andreas Moroder Version: 2.4.11 OS: Suse Linux 10.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (151.47.3.213) Hello, in /servers/slapd/bconfig.c /libraries/libldap_r/tls.c /libraries/libldap_r/tls.c ./libraries/liblber/stdio.c /libraries/liblunicode/ucdata/ucgendat.c /contrib/slapd-modules/lastmod/lastmod.c the literal value 8192 is used for array sizes instead of SLAP_LDAPDN_MAXLEN 8192 defined in /servers/slapd/slap.h I think this could become a problem if SLAP_LDAPDN_MAXLEN grows in a future release. A question from a newbie: What happens in a mixed environment with a never version with bigger SLAP_LDAPDN_MAXLEN that replicates his entries to a version with SLAP_LDAPDN_MAXLEN at 8192 ? Isn't it wrong not to check for a buffer owerflow when strings are concantenated and suppose that the data we use does not exceed the limit ? Bye Andreas

1 0

(ITS#5691) malloc withou check
by andreas.moroder＠gmx.net 09 Sep '08

09 Sep '08

Full_Name: Andreas Moroder Version: 2.4.11 OS: Suse Linux 10.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (151.47.3.213) Hello, in servers/slapd/add.c int the function slap_entry2mods() malloc() is called three times and the result is not checked against NULL. Bye Andreas

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs