openldap-bugs

openldap-bugs@openldap.org

1 participants
21105 discussions

(ITS#5151) certificateListValidate rejects valid lists
by hyc＠OpenLDAP.org 23 Sep '07

23 Sep '07

Full_Name: Howard Chu Version: HEAD/re24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc I ran into a couple problems; the check for timestamps doesn't take into account that Time is a CHOICE of UTCTime and GeneralizedTime. Also the check for the revocation list doesn't verify that it's a SEQUENCE OF SEQUENCE, so it mistakenly skips over closing signatureAlgorithm if the revocation list is absent. Will be fixed in HEAD shortly.

1 0

Re: (ITS#5070) Issues in X.509 certificate parsing
by hyc＠symas.com 23 Sep '07

23 Sep '07

ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: > >> I've an issue with X.509 certificate parsing in HEAD/re24. The certificate, >> according to OpenSSL, has a SerialNumber c8:5b:9a:dd:ea:bf:f9:fa and HEAD fails >> to parse it because it is an integer with length equal to 9, which is larger >> than sizeof(ber_int_t), as tested in ber_getnint() at decode.c:254. The DER >> encoded value is: 2 9 0 200 91 154 221 234 191 249 250. Seems to be time >> to get past the sizeof(ber_int_t) limitation... > > ... which would violate RFC 4511 where it states that INTEGER means from > 0 up to 2^31-1... I have a simple solution for this problem, at the > cost of partially violating rfc 4523: if an integer is larger than > 2^31-1, it could be represented in the certificateExactMatch > normalization in hexadecimal form, much like OpenSSL does. This would > increase interoperability with OpenSSL and be at least self-consistent, > since all serialNumbers that large would be consistently expanded that > way. Another solution, preserving the decimal representation, would > probably require some arbitrary precision support from external > libraries. If there's consensus, I'd post my simple patch. I just got tripped trying to import an LDIF with a cert with 16 byte SerialNumber. I've patched this to just use the same hexadecimal format that OpenSSL uses when the number is larger than ber_int_t. We really don't want the format to change just because someone has a BigNum library available; it needs to stay consistent. Normalizing to a string format like this still seems pretty gross, but I guess that's the best we can do given dumb clients that aren't aware of schema. -- -- Howard Chu Chief Architect, 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#5114) pcache cache results for searches that hit size/timelimit
by ando＠sys-net.it 23 Sep '07

23 Sep '07

Ralf Haferkamp wrote: > Please note that test020 currently fails in HEAD sometime. I think this > depends on the order in which the results for queries that hit the > sizelimit are returned. I added tests for sizelimit that were consistent with my changes; however, I'm now short of time to work on this, so feel free to back out those test changes if you believe the code is working correctly, while we design test improvements that are consistent with all fixes. Thanks, 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5114) pcache cache results for searches that hit size/timelimit
by hyc＠symas.com 22 Sep '07

22 Sep '07

hyc(a)symas.com wrote: > Ralf Haferkamp wrote: >> On Freitag, 21. September 2007, hyc(a)symas.com wrote: >>> It seems to be failing for me more often than not. Why is it >>> non-deterministic? >> It seems that the order in which the entries are inserted into the cache is >> non-deterministic. Because of that the order in which they are returned from >> cache varies as well. The final test that compares the ldapsearch results >> with proxycache.out relies on the order. >> >> I get a lot of DB_LOCK_DEADLOCK in slapd.2.log and if I don't missread the log >> it seems that sometimes the entries from Query 9 get inserted into the cache >> before the entry from Query 5 ("cn=Bjorn Jensen,ou=Information Technology >> Division, ...") and sometimes after. Depending on that the test either fails >> or succeeds. >> > OK, I see that as well. In fact setting a breakpoint on the Deadlock result, I > see 3 threads still trying to add entries to the cache when the deadlock > occurs. This appears to be a consequence of letting the client continue on > before the pcache overlay has finished its work. But, I thought you were > locking the cache so that requests would not run while query processing was > incomplete? I see, you're only locking individual queries. That's certainly inadequate, you'll probably have to lock the entire cache as a whole. Remember that an entry that you're adding may actually satisfy multiple queries. -- -- Howard Chu Chief Architect, 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#5114) pcache cache results for searches that hit size/timelimit
by hyc＠symas.com 22 Sep '07

22 Sep '07

Ralf Haferkamp wrote: > On Freitag, 21. September 2007, hyc(a)symas.com wrote: >> rhafer(a)suse.de wrote: >>> Please note that test020 currently fails in HEAD sometime. I think this >>> depends on the order in which the results for queries that hit the >>> sizelimit are returned. >> It seems to be failing for me more often than not. Why is it >> non-deterministic? > It seems that the order in which the entries are inserted into the cache is > non-deterministic. Because of that the order in which they are returned from > cache varies as well. The final test that compares the ldapsearch results > with proxycache.out relies on the order. > > I get a lot of DB_LOCK_DEADLOCK in slapd.2.log and if I don't missread the log > it seems that sometimes the entries from Query 9 get inserted into the cache > before the entry from Query 5 ("cn=Bjorn Jensen,ou=Information Technology > Division, ...") and sometimes after. Depending on that the test either fails > or succeeds. > OK, I see that as well. In fact setting a breakpoint on the Deadlock result, I see 3 threads still trying to add entries to the cache when the deadlock occurs. This appears to be a consequence of letting the client continue on before the pcache overlay has finished its work. But, I thought you were locking the cache so that requests would not run while query processing was incomplete? -- -- Howard Chu Chief Architect, 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#5150) Patch to add a new config option to force the return of operational attributes in rootDSE
by hyc＠symas.com 22 Sep '07

22 Sep '07

hyc(a)symas.com wrote: > There's no reason to break the core code with misfeatures like this. If you > need this behavior, write an overlay that intercepts the relevant searches and > replaces the empty attribute list with "*" and "+". Scratch that, the contrib/slapd-modules/allop overlay already does this. This ITS will be closed. -- -- Howard Chu Chief Architect, 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#5150) Patch to add a new config option to force the return of operational attributes in rootDSE
by hyc＠symas.com 22 Sep '07

22 Sep '07

mspeder(a)syrtis.net wrote: > Full_Name: Matthieu Speder > Version: Latest HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/Matthieu-Speder-070922.patch > Submission from: (NULL) (82.224.96.182) > > > This patch adds a new global option in configuration > (forceopattrs/olcForceOpAttrs { on | off }). Thanks for the patch. Still, the behavior you're introducing is a violation of the protocol spec. The fact that other vendors don't care to implement conformant servers doesn't really have any bearing on this; clients that expect this behavior are broken and should be fixed. > When answering a search query to rootDSE with an empty attribute query, > forceopattrs forces slapd to return all operational attributes. By default > forceopattrs is off and slapd only returns operational attributes when query > contains a plus (+), see RFC 4533. > > Unfortunately the default behavior is different from other directories (both AD > & Sun) and confuses some client applications which expect the operational > attributes with a blank query. This new config option fixes the issue if > required by client app. > > This patch does NOT change slapd default behavior. > > The patch contains both minor changes to result.c, proto-slap.h, bconfig.c and > the required additions to docs (man & guide). There's no reason to break the core code with misfeatures like this. If you need this behavior, write an overlay that intercepts the relevant searches and replaces the empty attribute list with "*" and "+". -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5150) Patch to add a new config option to force the return of operational attributes in rootDSE
by mspeder＠syrtis.net 22 Sep '07

22 Sep '07

Full_Name: Matthieu Speder Version: Latest HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/Matthieu-Speder-070922.patch Submission from: (NULL) (82.224.96.182) This patch adds a new global option in configuration (forceopattrs/olcForceOpAttrs { on | off }). When answering a search query to rootDSE with an empty attribute query, forceopattrs forces slapd to return all operational attributes. By default forceopattrs is off and slapd only returns operational attributes when query contains a plus (+), see RFC 4533. Unfortunately the default behavior is different from other directories (both AD & Sun) and confuses some client applications which expect the operational attributes with a blank query. This new config option fixes the issue if required by client app. This patch does NOT change slapd default behavior. The patch contains both minor changes to result.c, proto-slap.h, bconfig.c and the required additions to docs (man & guide).

1 0

Re: (ITS#5114) pcache cache results for searches that hit size/timelimit
by rhafer＠suse.de 21 Sep '07

21 Sep '07

On Freitag, 21. September 2007, hyc(a)symas.com wrote: > rhafer(a)suse.de wrote: > > Please note that test020 currently fails in HEAD sometime. I think this > > depends on the order in which the results for queries that hit the > > sizelimit are returned. > > It seems to be failing for me more often than not. Why is it > non-deterministic? It seems that the order in which the entries are inserted into the cache is non-deterministic. Because of that the order in which they are returned from cache varies as well. The final test that compares the ldapsearch results with proxycache.out relies on the order. I get a lot of DB_LOCK_DEADLOCK in slapd.2.log and if I don't missread the log it seems that sometimes the entries from Query 9 get inserted into the cache before the entry from Query 5 ("cn=Bjorn Jensen,ou=Information Technology Division, ...") and sometimes after. Depending on that the test either fails or succeeds. -- Ralf

1 0

Re: (ITS#5114) pcache cache results for searches that hit size/timelimit
by hyc＠symas.com 21 Sep '07

21 Sep '07

rhafer(a)suse.de wrote: > Please note that test020 currently fails in HEAD sometime. I think this > depends on the order in which the results for queries that hit the > sizelimit are returned. It seems to be failing for me more often than not. Why is it non-deterministic? > > Testout put is: > ------------------ > ... > ... > Successfully verified answerability > Filtering ldapsearch results... > Filtering original ldif... > Comparing filter output... > Comparison failed > ------------------ > > # diff testrun/ldif.flt testrun/ldapsearch.flt > 233,235c233,235 > < dn: cn=Bjorn Jensen,ou=Information Technology Division,ou=People,dc=example,dc > < =com > < mail: bjorn(a)mailgw.example.com > --- >> dn: cn=Barbara Jensen,ou=Information Technology Division,ou=People,dc=example, >> dc=com >> mail: bjensen(a)mailgw.example.com > > # > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

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