Re: (ITS#6703) Patch - Mozilla NSS - reject non-file key and cert files
by rmeggins@redhat.com
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_...
>>>>
>>>> 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!
11 years, 9 months
(ITS#6710) Mods already refreshed on a forwarding server is lost by its consumer
by rein@OpenLDAP.org
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
11 years, 9 months
(ITS#6709) Active mods not replicated to new consumers
by rein@OpenLDAP.org
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
11 years, 9 months
(ITS#6708) Race condition fixing syncprov filter
by rein@OpenLDAP.org
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
11 years, 9 months
(ITS#6707) Syncrepl may reuse presentlist
by rein@OpenLDAP.org
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
11 years, 9 months
Re: (ITS#6556) test031 core dumps after applying first filter
by ian@uns.ac.rs
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.
11 years, 9 months