https://bugs.openldap.org/show_bug.cgi?id=8476
--- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
Seems like a good idea. For constraints where no custom message was provided,
we could return the constraint number to provide a pointer to which constraint
was triggered.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=6198
--- Comment #6 from Ondřej Kuzník <ondra(a)mistotebe.net> ---
A few open questions I can't resolve yet:
- Do we rely on OID macros from schema or let slap_control/load_extop2 register
it? The suggestions above tend to prefer OID macros but they have to be defined
in the schema (there's only one) and they're currently case-sensitive
For controls:
- Do we want to be able to use ACLs to turn non-critical controls to ignored?
- Do we want to be able to use ACLs to refuse control combinations?
- Apart from the 'to' clause, do we want it allowed in the 'by' clause as well
(when would it be useful? There's control combinations, anything else?)
I'll start with "no" to all 3 of the above for now.
As for combination with other specifiers (especially for exops), ACL checks are
issued with the operation and an entry right now, they do make sense in that
scope so password modify/DDS refresh should be in the clear. Other extops are
more of a problem:
- whoami: technically there is a DN but it doesn't have to correspond to an
entry
- verify credentials: tricky, since it's processed as a bind
- cancel: abandon can't be restricted, so probably the same
- turn: no idea
- ChainedRequest: even less of one
Probably happy for those to be impossible to restrict in this way, at least for
now.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8905
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|bugs(a)openldap.org |gnoe(a)symas.com
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7982
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|bugs(a)openldap.org |ondra(a)mistotebe.net
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8943
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |SUSPENDED
--- Comment #6 from Howard Chu <hyc(a)openldap.org> ---
One major problem here is that overlays assume they all execute in the same
thread for the duration of an operation. Putting the response in the worker
thread would break overlay response callbacks.
It would be quite a lot of refactoring to make overlays thread-independent, and
that's not going to happen soon.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10255
Issue ID: 10255
Summary: OpenLDAP should leak the SSL ctx and not try to free
it in an atexit() handler
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: simon.pichugin(a)gmail.com
Target Milestone: ---
As mentioned in the subject, OpenLDAP incorrectly handles OpenSSL in its
destructor.
Сomprehensive information can be found here (along with a possible solution):
https://github.com/openssl/openssl/issues/25294
--
You are receiving this mail because:
You are on the CC list for the issue.