https://bugs.openldap.org/show_bug.cgi?id=10368
Issue ID: 10368
Summary: Must revert ITS#9849 license changes
Product: website
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: major
Priority: ---
Component: website
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
The changes related to license.wml made for ITS#9849 must be reverted. There is
only one OpenLDAP Public License and it applies to all OpenLDAP software. There
are not two different licenses for release/LTS. No single person has the right
to alter the existing license.
Currently the website is broken, as
https://openldap.org/software/release/license.html is an empty file.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10337
Issue ID: 10337
Summary: Global TLS options not inherited in context
Product: OpenLDAP
Version: 2.6.9
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: remi(a)fedoraproject.org
Target Milestone: ---
During ldap_create, global options are copied
See
https://github.com/openldap/openldap/blob/OPENLDAP_REL_ENG_2_6_9/libraries/…
/* copy the global options */
AC_MEMCPY(&ld->ld_options, gopts, sizeof(ld->ld_options));
But not the TLS string options
See
https://github.com/openldap/openldap/blob/OPENLDAP_REL_ENG_2_6_9/libraries/…
/* We explicitly inherit the SSL_CTX, don't need the names/paths. Leave
* them empty to allow new SSL_CTX's to be created from scratch.
*/
memset( &ld->ld_options.ldo_tls_info, 0,
sizeof( ld->ld_options.ldo_tls_info ));
ld->ld_options.ldo_tls_ctx = NULL;
Which create inconsistency when trying to generate a newctx
For the context
See
* https://github.com/php/php-src/issues/17776 => why tls_newctx is needed
* https://github.com/php/php-src/issues/18529 => regression
On PHP side a possible workaround is to do the copyu manually
* https://github.com/php/php-src/pull/18547
But should probably be handled at openldap library
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10191
Issue ID: 10191
Summary: backend searches should respond to pause requests
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
A long running search will cause mods to cn=config to wait a long time. Search
ops should periodically check for threadpool pause requests.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9513
Issue ID: 9513
Summary: Enhanced debug output
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: enhancement
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
While debugging ITS#9479 I needed more information on which threads were doing
what actions. Also, when looking for delays/hangs/race conditions, the 1-second
granularity of the debug msg timestamp was inadequate. And also, some of the
debug output for the Search operation was being done in separate Debug calls
for a single line of output. This gets jumbled up pretty badly if other threads
are printing output as well.
New patch set will extend the debug timestamp to have fractional seconds too;
it will use clock_gettime for nanosecond resolution if available, otherwise use
gettimeofday for microsecond resolution. Also tweak the Search debug output to
only use one Debug invocation per line of output.
This is MR!279.
--
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=10371
Issue ID: 10371
Summary: tools don't print useful error codes
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
In tools/common.c, if ldap_result() returns an error, this return value is used
directly as an LDAP error code in the subsequent call to tool_perror(). That is
incorrect; ldap_result() always returns -1 on errors. The actual return code
must be retrieved using ldap_get_option(ld, LDAP_OPT_RESULT_CODE,...). So up
till now the tools have never printed the actual error message that's relevant
to whatever failure occurred.
Other applications appear to have copied this erroneous behavior. E.g., in
investigating ITS#10370 I see that curl's code does the same thing.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10370
Issue ID: 10370
Summary: result.c:930: try_read1msg: Assertion `!BER_BVISEMPTY(
&resoid )' failed.
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: daniel(a)haxx.se
Target Milestone: ---
When using curl built with OpenLDAP to access a broken/malicious ldap server,
OpenLDAP will abort on this assert.
It seems it should rather return a proper error code?
A full reproducer that unfortunately uses curl is available here:
https://hackerone.com/reports/3258022 together with more details about this
problem.
(I'm forwarding this information, I did not discover this.)
--
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.