openldap-bugs November 2010

openldap-bugs@openldap.org

32 participants
103 discussions

Re: (ITS#6703) Patch - Mozilla NSS - reject non-file key and cert files
by rmeggins＠redhat.com 16 Nov '10

16 Nov '10

On 11/15/2010 01:22 PM, Howard Chu wrote: > rmeggins(a)redhat.com wrote: >> On 11/15/2010 12:39 PM, Howard Chu wrote: >>> rmeggins(a)redhat.com wrote: >>>> Full_Name: Rich Megginson >>>> Version: 2.4.23 (current CVS HEAD) >>>> OS: RHEL5 >>>> URL: >>>> ftp://ftp.openldap.org/incoming/openldap-2.4.23-reject_non_file_key_cert_pe… >>>> >>>> Submission from: (NULL) (76.113.111.209) >>>> >>>> >>>> If you specify a directory instead of a file to TLS_CACERT, or if one >>>> of the >>>> items in the TLS_CACERTDIR is a directory, the NSS PEM reader will >>>> crash. This >>>> patch rejects any item which looks like a directory. >>> >>> It sounds like this is a bug that ought to be patched in the NSS PEM >>> reader instead, no? >>> >> Yes, you are correct. I have filed this bug - >> https://bugzilla.redhat.com/show_bug.cgi?id=653619 >> But the patch to openldap will allow it to bypass this problem. > > OK. I've reviewed and committed all of your patches 6703-6706. > Thanks!

1 0

Re: (ITS#6703) Patch - Mozilla NSS - reject non-file key and cert files
by hyc＠symas.com 16 Nov '10

16 Nov '10

rmeggins(a)redhat.com wrote: > On 11/15/2010 12:39 PM, Howard Chu wrote: >> rmeggins(a)redhat.com wrote: >>> Full_Name: Rich Megginson >>> Version: 2.4.23 (current CVS HEAD) >>> OS: RHEL5 >>> URL: >>> ftp://ftp.openldap.org/incoming/openldap-2.4.23-reject_non_file_key_cert_pe… >>> Submission from: (NULL) (76.113.111.209) >>> >>> >>> If you specify a directory instead of a file to TLS_CACERT, or if one >>> of the >>> items in the TLS_CACERTDIR is a directory, the NSS PEM reader will >>> crash. This >>> patch rejects any item which looks like a directory. >> >> It sounds like this is a bug that ought to be patched in the NSS PEM >> reader instead, no? >> > Yes, you are correct. I have filed this bug - > https://bugzilla.redhat.com/show_bug.cgi?id=653619 > But the patch to openldap will allow it to bypass this problem. OK. I've reviewed and committed all of your patches 6703-6706. -- -- 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#6703) Patch - Mozilla NSS - reject non-file key and cert files
by rmeggins＠redhat.com 16 Nov '10

16 Nov '10

On 11/15/2010 12:39 PM, Howard Chu wrote: > rmeggins(a)redhat.com wrote: >> Full_Name: Rich Megginson >> Version: 2.4.23 (current CVS HEAD) >> OS: RHEL5 >> URL: >> ftp://ftp.openldap.org/incoming/openldap-2.4.23-reject_non_file_key_cert_pe… >> Submission from: (NULL) (76.113.111.209) >> >> >> If you specify a directory instead of a file to TLS_CACERT, or if one >> of the >> items in the TLS_CACERTDIR is a directory, the NSS PEM reader will >> crash. This >> patch rejects any item which looks like a directory. > > It sounds like this is a bug that ought to be patched in the NSS PEM > reader instead, no? > Yes, you are correct. I have filed this bug - https://bugzilla.redhat.com/show_bug.cgi?id=653619 But the patch to openldap will allow it to bypass this problem.

1 0

Re: (ITS#6703) Patch - Mozilla NSS - reject non-file key and cert files
by hyc＠symas.com 16 Nov '10

16 Nov '10

rmeggins(a)redhat.com wrote: > Full_Name: Rich Megginson > Version: 2.4.23 (current CVS HEAD) > OS: RHEL5 > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-reject_non_file_key_cert_pe… > Submission from: (NULL) (76.113.111.209) > > > If you specify a directory instead of a file to TLS_CACERT, or if one of the > items in the TLS_CACERTDIR is a directory, the NSS PEM reader will crash. This > patch rejects any item which looks like a directory. It sounds like this is a bug that ought to be patched in the NSS PEM reader instead, no? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6710) Mods already refreshed on a forwarding server is lost by its consumer
by rein＠OpenLDAP.org 16 Nov '10

16 Nov '10

Full_Name: Rein Tollevik Version: CVS head OS: Irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.215.59.121) Submitted by: rein New syncprov consumers connecting to a forwarding server and presenting an apperently up-to-date cookie will loose any mods that have already taken place on the forwarding server if it itself is refreshing from its provider. This should not be a problem if the forwarding server have a sufficiently large syncprov log, but a fix for servers without is coming. -- Rein Tollevik Basefarm AS

1 0

(ITS#6709) Active mods not replicated to new consumers
by rein＠OpenLDAP.org 16 Nov '10

16 Nov '10

Full_Name: Rein Tollevik Version: CVS head OS: Irrelevant URL: Submission from: (NULL) (84.215.59.121) Submitted by: rein New syncprov consumers connecting when there are active mods risk loosing these mods, where an active mod is any mod that have called syncprov_op_mod() but not yet the syncprov_op_response() or syncprov_op_cleanup() callbacks. A fix is coming. -- Rein Tollevik Basefarm AS

1 0

Re: (ITS#6693) Value dependent ACL issues
by rhafer＠suse.de 16 Nov '10

16 Nov '10

I just submitted the fix to HEAD. The changes are in: servers/slapd/acl.c r1.355 servers/slapd/slap.h r1.898 Ralf

1 0

(ITS#6708) Race condition fixing syncprov filter
by rein＠OpenLDAP.org 16 Nov '10

16 Nov '10

Full_Name: Rein Tollevik Version: CVS head OS: Irrelevant URL: Submission from: (NULL) (84.215.59.121) Submitted by: rein In ITS#6555 a fix to skip the and/ge filter stuck in front of the consumers filter was added, but this left a race condition between modifying the filter and noting it in the flags. There is a race both when the filter is stuck in the front and when it gets removed again when the op is detached. A fix is coming. -- Rein Tollevik Basefarm AS

1 0

(ITS#6707) Syncrepl may reuse presentlist
by rein＠OpenLDAP.org 16 Nov '10

16 Nov '10

Full_Name: Rein Tollevik Version: CVS head OS: Irrelevant URL: Submission from: (NULL) (84.215.59.121) Submitted by: rein If syncrepl gets interrupted during the present phase it may reuse the presentlist on the next connection. Any entries in the list that gets deleted on the provider in mean time will not be deleted on the consumer. A fix is coming. -- Rein Tollevik Basefarm AS

1 0

Re: (ITS#6556) test031 core dumps after applying first filter
by ian＠uns.ac.rs 15 Nov '10

15 Nov '10

slap_sl_free dumps core here because it gets passed a bogus bv_val (from the ma_value field of an instance of struct MatchingRuleAssertion). As far as I can see, the original bv_val gets clobbered in get_comp_filter (servers/slapd/component.c), line 350: bv->bv_val = cav.cav_ptr; Commenting that line out fixes the core dump. I suspect that the assignment is there to support nested component filters (see lines 1039 et seq. in the same file). Earlier versions of OpenLDAP had different logic in slap_sl_free, which skipped the offending pointer (and thus probably leaving a memory leak). i.

1 0

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2010