https://bugs.openldap.org/show_bug.cgi?id=10375
Issue ID: 10375
Summary: [patch] minor patch to const up oids array
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: caolanm(a)gmail.com
Target Milestone: ---
Created attachment 1084
--> https://bugs.openldap.org/attachment.cgi?id=1084&action=edit
minor patch to const up oids array
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10379
Issue ID: 10379
Summary: lastbind change prevents ppolicy response from
reaching accesslog
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
When "lastbind on" and ppolicy are configured together, the pwdLastSuccess
update triggers an accesslog entry (using op->o_time, op->o_tincr), then
ppolicy_bind_response issues its own modification and since the time was copied
in lastbind, an entry of the same name already exists. This means the ppolicy
change is lost (and e.g. won't replicate).
Note that slapo-lastbind (=the contrib overlay) probably has the same impact.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10329
Issue ID: 10329
Summary: Additional issues with pcache, and a test
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: aweits(a)rit.edu
Target Milestone: ---
Created attachment 1062
--> https://bugs.openldap.org/attachment.cgi?id=1062&action=edit
test & patches
Hello again!
Further testing revealed some more issues in pcache [re: ITS#10270]. I've
attached an update to test020-proxycache as well. These are based off the
current git HEAD.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10339
Issue ID: 10339
Summary: config_add_internal() use-after-free on failed
cn=config mod
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
If overlay startup/callback fails, bconfig.c:5593 uses the value of ca->argv[1]
despite it being freed already. I guess we can just log the entry's DN.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10344
Issue ID: 10344
Summary: Potential memory leak in function
firstComponentNormalize and objectClassPretty.
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: alexguo1023(a)gmail.com
Target Milestone: ---
Created attachment 1071
--> https://bugs.openldap.org/attachment.cgi?id=1071&action=edit
Patch: Ensure the first argument passed to `ber_dupbv_x` is not `NULL`.
In `firstComponentNormalize`, the code calls `ber_dupbv_x` but ignores its
return value.
```c
ber_dupbv_x(normalized, val, ctx);
```
When `normalized` is `NULL`, `ber_dupbv_x` allocates a new `struct berval` and
returns it; failing to capture that pointer means we lose ownership and leak
the allocation. The same issue arises in `objectClassPretty`. We should follow
the pattern in function `hexNormalize`, which asserts that its `normalized`
argument is non-NULL before use:
```c
assert(normalized != NULL);
```
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10372
Issue ID: 10372
Summary: support lastbind_forward_updates outside of the
lastbind overlay
Product: OpenLDAP
Version: 2.6.10
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: lklement(a)symas.com
Target Milestone: ---
according to the documentation for the LastBind overlay (slapo-lastbind) this
overlay is no longer recommended unless lastbind_forward_updates is used.
Can this functionality be added to the current lastbind configuration
recommendation?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10366
Issue ID: 10366
Summary: Is 'second database definition & config directives'
block duplicated?
Product: website
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: website
Assignee: bugs(a)openldap.org
Reporter: truth_jp_4133(a)yahoo.co.jp
Target Milestone: ---
I have a question about an example of '6.1. Configuration File Format' section
on this page (https://www.openldap.org/doc/admin26/slapdconfig.html).
I think that 'second database definition & config directives' section is
duplicated.
Is the second 'second database definition & config directives' to be 'third
database definition & config directives'?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10384
Issue ID: 10384
Summary: str2entry2() leaks attributes on error
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
If there's error processing attribute values, the attribute list in ahead is
not freed.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10335
Issue ID: 10335
Summary: [PATCH] ldapsearch: fix handling of -LL in
print_reference()
Product: OpenLDAP
Version: 2.6.9
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: bolek(a)live.com
Target Milestone: ---
Created attachment 1066
--> https://bugs.openldap.org/attachment.cgi?id=1066&action=edit
[PATCH] ldapsearch: fix handling of -LL in print_reference()
I, Boleslaw Ciesielski, 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.
The attached patch (against master) fixes a bug in ldapsearch where the -LL (or
-LLL) option is ignored when printing the reference comments in
print_reference().
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10388
Issue ID: 10388
Summary: ldif_parse_line2 is not compliant with RFC2849
Product: OpenLDAP
Version: 2.6.10
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
RFC2849:
Any
value that contains characters other than those defined as
"SAFE-CHAR", or begins with a character other than those
defined as "SAFE-INIT-CHAR", above, MUST be base-64 encoded.
Other values MAY be base-64 encoded.
SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F /
%x21-39 / %x3B / %x3D-7F
; any value <= 127 except NUL, LF, CR,
; SPACE, colon (":", ASCII 58 decimal)
; and less-than ("<" , ASCII 60 decimal)
However, if the value is not base64 encoded, ldif_parse_line2 (and consequently
ldap_parse_ldif_record_x) uses isspace() to just skip any white-space
characters at the beginning of at attribute value, icl. tabs. According to the
RFC, however, such characters are acceptable. In addition, it does not return
an error on LF or CR, just skips them.
On the one hand, LDIFs are supposed to be human readable, and fixing this issue
may lead to unexpected problems (e.g a stray tab being added to the attribute
value). On the other hand, the standard does not exclude %x01-09 and %x0B-0C as
valid characters for a non-encoded value.
How should we proceed?
--
You are receiving this mail because:
You are on the CC list for the issue.