- openldap-bugs - openldap.org

[Issue 6942] updateref config is inadequate
by openldap-its＠openldap.org 07 Jun '21

07 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=6942 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |enhancement -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6912] support for case sensitive SASL usernames
by openldap-its＠openldap.org 07 Jun '21

07 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=6912 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|authz-regexp DN |support for case sensitive | |SASL usernames -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6776] Control handling in PassMod exop + ppolicy
by openldap-its＠openldap.org 07 Jun '21

07 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=6776 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.6.0 |2.7.0 --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Part of exop refactoring work. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6765] Server-side support of "Verify Credentials" extop
by openldap-its＠openldap.org 07 Jun '21

07 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=6765 --- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Functionality in client/tools is present but the function in libldap is a stub and needs completion before this can work. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6765] Server-side support of "Verify Credentials" extop
by openldap-its＠openldap.org 07 Jun '21

07 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=6765 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.6.0 |2.7.0 --- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Need confirmation as to whether or not the SASL bits were ever implemented or still needs doing. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6765] Server-side support of "Verify Credentials" extop
by openldap-its＠openldap.org 07 Jun '21

07 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=6765 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |enhancement Status|IN_PROGRESS |CONFIRMED --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Appears client side SASL support is still lacking and needs development -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6761] contrib usn overlay broken
by openldap-its＠openldap.org 07 Jun '21

07 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=6761 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|slapd |contrib -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9572] New: OpenLDAP no longer builds against libressl after ITS#9521
by openldap-its＠openldap.org 07 Jun '21

07 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9572 Issue ID: 9572 Summary: OpenLDAP no longer builds against libressl after ITS#9521 Product: OpenLDAP Version: 2.4.59 Hardware: All OS: FreeBSD Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: delphij(a)freebsd.org Target Milestone: --- In #9521, OpenLDAP would be using OpenSSL 1.1 TLSv1.3 API (SSL_CTX_set_ciphersuites and SSL_set_ciphersuites) and is no longer compatible with LibreSSL. Reported by a FreeBSD user at https://bugs.freebsd.org/256433 . -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9574] New: mdb_drop missing from .gitignore
by openldap-its＠openldap.org 07 Jun '21

07 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9574 Issue ID: 9574 Summary: mdb_drop missing from .gitignore Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: max(a)davitt.me Target Milestone: --- The .gitignore file contains entries for mdb_copy, mdb_stat, mdb_dump, and mdb_load, but not mdb_drop. This is mildly annoying while building. Normally I would've just created a merge request directly on GitLab to fix something like this but I'm having issues with it (see #9573). Sorry for the inconvenience! -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9027] LMDB: API to retrieve map address
by openldap-its＠openldap.org 05 Jun '21

05 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9027 --- Comment #4 from Howard Chu <hyc(a)openldap.org> --- (In reply to doug from comment #3) > Hi! I would like to voice my support for this feature, and explain how this > API would help me. Sorry but I don't find any of these arguments to be compelling. > > First of all, a bit of background: I'm maintaining C++ bindings for LMDB > (https://github.com/hoytech/lmdbxx), and have been a contributor to the perl > bindings and others. I have published two interface layers that use LMDB, > https://github.com/hoytech/quadrable and > https://github.com/hoytech/rasgueadb and as my colleagues would attest, am a > relentless LMDB advocate. > > Application 1: Testing zero-copy > > That previous link, RasgueaDB, is an indexing and query layer for LMDB. It > uses flatbuffers for its data format, which allows zero-copy access to > fields. Since there are several layers involved, I wanted to make sure that > no copying was happening, and also to add a test to the test-suite to make > sure this remains the case. > > To do this, I have a library called assert_zerocopy: > https://github.com/hoytech/hoytech-cpp/blob/master/hoytech/assert_zerocopy.h > (and also a perl equivalent here: https://metacpan.org/pod/Test::ZeroCopy ) > > However, in order to verify the returned value is actually a zero-copy > reference, I need the pointer to the memory map (and the map's size). I have > added a terrible hack to the lmdbxx bindings to retrieve this: > > https://github.com/hoytech/lmdbxx/blob/ > 08eddafcc4613c7fc8ebd88f5db87c7d7bfb9f52/lmdb%2B%2B.h#L1115-L1118 > > But this is obviously not a good approach (as mentioned by Nic in this > thread) and it would be much better if there was an API to retrieve this > value (like there is for me_mapsize). No. The only thing you need to do, to assert that no copying has occurred, is to also retrieve the record thru the standard LMDB API, and compare value pointers. If they are the same, then no copying has occurred. At any rate, this sounds like only a debugging feature, with no actual production use. > Application 2: Virtual memory controls > > In general I agree that mlock()ing large files like databases is > counter-productive. However, there are other controls that can be applied to > the virtual memory of an application. > > For example, rsync attempts to preserve the filesystem cache state so that > rsync invocations have as small an impact as possible on the cache (since > it's a shared resource): https://insights.oetiker.ch/linux/fadvise/ > > Another example, before restarting a server, Instagram uses my utility > vmtouch to snapshot the virtual memory state (basically the set of "hot" > files). After rebooting, the state is restored before the server is added > back to the active pool of servers. > > I have generalised this with my application/library vmprobe: > https://vmprobe.com/filesystem-cache > > If I had access to me_map within my application, I would be able to > integrate libvmprobe more easily and portably. For instance, this would > allow me to take a snapshot of which pages are resident in memory, perform > some large read query that touches many pages, then restore the original VM > page residency set after the query completes. > > Another variant of this: If you have multiple customers who use the same > server (at different times) then you can restore a customer's previous VM > state when they login. If you know approximately the pages that will be > accessed in advance, sequentially pre-paging them in can have significant > performance benefits. I did some experiments with Postgres pre-paging you > can see here: https://vmprobe.com/database-speedup If you want control over the address that is mmap'd just use MDB_FIXEDMAP and pass in your desired address. The actions you're talking about here are highly system-dependent, you may as well just read /proc/<PID>/maps yourself and work from there. Again, this is a pretty niche case. > > Conclusion > > Although certainly a user could abuse me_map if it were exposed, one of the > reasons why I enjoy LMDB so much is that it generally assumes its users know > what they are doing and doesn't compromise on flexibility or performance for > the sake of users who don't. For example, although it is not recommended to > use MDB_WRITEMAP in most cases, it nevertheless exists. > > As explained above, I have several use-cases for me_map that I feel are > legitimate. I am already accessing it in a hacky way but naturally would > prefer a more portable and future-proof API. > > If this API is added, the documentation should of course make clear that > accessing or modifying (if MDB_WRITEMAP) data through me_map is not > supported in any way, and regular use-cases have no need for this value and > should stick to the supported APIs. > > Thank you! -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9027] LMDB: API to retrieve map address
by openldap-its＠openldap.org 05 Jun '21

05 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9027 --- Comment #3 from doug(a)hcsw.org --- Hi! I would like to voice my support for this feature, and explain how this API would help me. First of all, a bit of background: I'm maintaining C++ bindings for LMDB (https://github.com/hoytech/lmdbxx), and have been a contributor to the perl bindings and others. I have published two interface layers that use LMDB, https://github.com/hoytech/quadrable and https://github.com/hoytech/rasgueadb and as my colleagues would attest, am a relentless LMDB advocate. Application 1: Testing zero-copy That previous link, RasgueaDB, is an indexing and query layer for LMDB. It uses flatbuffers for its data format, which allows zero-copy access to fields. Since there are several layers involved, I wanted to make sure that no copying was happening, and also to add a test to the test-suite to make sure this remains the case. To do this, I have a library called assert_zerocopy: https://github.com/hoytech/hoytech-cpp/blob/master/hoytech/assert_zerocopy.h (and also a perl equivalent here: https://metacpan.org/pod/Test::ZeroCopy ) However, in order to verify the returned value is actually a zero-copy reference, I need the pointer to the memory map (and the map's size). I have added a terrible hack to the lmdbxx bindings to retrieve this: https://github.com/hoytech/lmdbxx/blob/08eddafcc4613c7fc8ebd88f5db87c7d7bfb… But this is obviously not a good approach (as mentioned by Nic in this thread) and it would be much better if there was an API to retrieve this value (like there is for me_mapsize). Application 2: Virtual memory controls In general I agree that mlock()ing large files like databases is counter-productive. However, there are other controls that can be applied to the virtual memory of an application. For example, rsync attempts to preserve the filesystem cache state so that rsync invocations have as small an impact as possible on the cache (since it's a shared resource): https://insights.oetiker.ch/linux/fadvise/ Another example, before restarting a server, Instagram uses my utility vmtouch to snapshot the virtual memory state (basically the set of "hot" files). After rebooting, the state is restored before the server is added back to the active pool of servers. I have generalised this with my application/library vmprobe: https://vmprobe.com/filesystem-cache If I had access to me_map within my application, I would be able to integrate libvmprobe more easily and portably. For instance, this would allow me to take a snapshot of which pages are resident in memory, perform some large read query that touches many pages, then restore the original VM page residency set after the query completes. Another variant of this: If you have multiple customers who use the same server (at different times) then you can restore a customer's previous VM state when they login. If you know approximately the pages that will be accessed in advance, sequentially pre-paging them in can have significant performance benefits. I did some experiments with Postgres pre-paging you can see here: https://vmprobe.com/database-speedup Conclusion Although certainly a user could abuse me_map if it were exposed, one of the reasons why I enjoy LMDB so much is that it generally assumes its users know what they are doing and doesn't compromise on flexibility or performance for the sake of users who don't. For example, although it is not recommended to use MDB_WRITEMAP in most cases, it nevertheless exists. As explained above, I have several use-cases for me_map that I feel are legitimate. I am already accessing it in a hacky way but naturally would prefer a more portable and future-proof API. If this API is added, the documentation should of course make clear that accessing or modifying (if MDB_WRITEMAP) data through me_map is not supported in any way, and regular use-cases have no need for this value and should stick to the supported APIs. Thank you! -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9570] New: Roadmap needs updating now that OpenLDAP 2.5 is released
by openldap-its＠openldap.org 04 Jun '21

04 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9570 Issue ID: 9570 Summary: Roadmap needs updating now that OpenLDAP 2.5 is released Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Need to update the roadmap. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9557] New: syncrepl refreshonly sometimes finishes too early
by openldap-its＠openldap.org 04 Jun '21

04 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9557 Issue ID: 9557 Summary: syncrepl refreshonly sometimes finishes too early Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: replication Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- In a delta-MMR test environment where conflicts are intentionally introduced, the fallback sessions sometimes cut off, not sending all entries they ought to. Instead LDAP_SUCCESS is sent with the snapshot cookie at some point. That cookie represents the correct contextCSN at the time of the search, so the missing changes are skipped over forever. As of now, the cause of the cutoff is under investigation. Currently, this was only run with 2.5 + persistent sessionlog enabled but there are indications this might not be limited to 2.5, tests with other versions/configs are pending. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9551] New: dnSubtreeMatch and others do not handle empty DN as asserted value
by openldap-its＠openldap.org 04 Jun '21

04 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9551 Issue ID: 9551 Summary: dnSubtreeMatch and others do not handle empty DN as asserted value Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- AFAIK '(reqDN:dnSubtreeMatch:=)' should be equivalent to 'reqDN=*', however it only seems to match the empty dn right now. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9537] New: slap_timestamp() can give a duplicated timestamp across restarts
by openldap-its＠openldap.org 04 Jun '21

04 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9537 Issue ID: 9537 Summary: slap_timestamp() can give a duplicated timestamp across restarts Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- On busy sites, when a slapd restart takes <1s, accesslog can fail to log changes with LDAP_ALREADY_EXISTS. This is because slap_timestamp() only logs timestamps with a 1s precision, disambiguating the rest with a counter that's forgotten across restarts. It is possible my analysis in ITS#9487 is partially invalidated because of this. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9526] New: slapadd -w crashes
by openldap-its＠openldap.org 04 Jun '21

04 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9526 Issue ID: 9526 Summary: slapadd -w crashes Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: grapvar(a)gmail.com Target Milestone: --- Let slapd.conf is: > database mdb > suffix "o=Foo" > sync_use_subentry database is blank and we are adding this foo.ldif: > dn: o=FOO > objectClass:organization Let's load: > slapd -T add -v -l foo.ldif -w then on Solaris: > added: "o=FOO" (00000001) > Segmentation Fault (core dumped) ... on Linux: > added: "o=FOO" (00000001) > => mdb_next_id: get failed: Invalid argument (22) > => mdb_tool_next_id: next_id failed: Invalid argument (22) > => mdb_tool_entry_put: txn_aborted! Invalid argument (22) > slapadd: couldn't create context entry > Closing DB... This is because: * mdb_tool_next_id() takes dead global [tools.c`static MDB_cursor *mcp] for further operations * cursor is dead because mdb_tool_entry_put() didn't initialized it * mdb_tool_entry_put() didn't initialized cursor because it thinks it is initialized, because there is an active global [tools.c`MDB_txn *mdb_tool_txn] * transaction was initialized by mdb_tool_dn2id_get(), which doesn't care about cursors. Long story short: the global state in tools.c is not managed consistently and needs rethinking. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 6467] syncrepl enhancements
by openldap-its＠openldap.org 04 Jun '21

04 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=6467 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9552] New: slapo-accesslog should record new DN after rename
by openldap-its＠openldap.org 04 Jun '21

04 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9552 Issue ID: 9552 Summary: slapo-accesslog should record new DN after rename Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- To use accesslog as a sessionlog source, one needs to be able to resolve whether a modrdn moved an entry in/out of the search scope. Syncprov would either have to examine every modrdn request or, if accesslog were to log the final DN, it could check for entries which crossed the scope. A new attribute 'reqNewDN' should be tracked for modrdn ops. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9529] New: pcache locking issue
by openldap-its＠openldap.org 04 Jun '21

04 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9529 Issue ID: 9529 Summary: pcache locking issue Product: OpenLDAP Version: 2.4.58 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Since ITS#6954 commit ea228495148 the consistency_check function was changed to hold the template t_rwlock for the entire duration of a query expiration. There doesn't appear to be any valid reason for this change, and it causes the cache to be unresponsive to new searches while expiration is removing cached entries. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9295] New: ppolicy and replication: pwdLockedTime replication fails to replicate
by openldap-its＠openldap.org 04 Jun '21

04 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9295 Issue ID: 9295 Summary: ppolicy and replication: pwdLockedTime replication fails to replicate Product: OpenLDAP Version: 2.4.50 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- If you have the following setup, a replica will hit an error during replication. a) ppolicy is configured on provider(s) and replicas. Replica has schemachecking=on in its syncrepl configuration b) account gets locked on the replica, so pwdAccountLockedTime is set on the replica but not on the provider(s) c) admin does a MOD/ADD op against a provider for the user entry to add a value to pwdAccountLockedTime dn: ... changetype: modify add: pwdAccountLockedTime pwdAccountLockedTime: ... d) provider accepts this modification. e) replica rejects this modification because the resulting change means that there would be two pwdAccountLockedTime values on the account in question Generally I believe that in this scenario, the MOD/ADD on the provider should be treated as a replace OP instead of an ADD op -- You are receiving this mail because: You are on the CC list for the issue.

1 18

[Issue 9542] New: wrong OIDs for Authorization Identity Request and Response Controls
by openldap-its＠openldap.org 04 Jun '21

04 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9542 Issue ID: 9542 Summary: wrong OIDs for Authorization Identity Request and Response Controls Product: OpenLDAP Version: 2.5.4 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- The OIDs for Authz Identity controls in ldap.h do not match the values in RFC 3829. This patch fixes it: diff --git a/include/ldap.h b/include/ldap.h index 6877d9fd11..be2d6d577a 100644 --- a/include/ldap.h +++ b/include/ldap.h @@ -273,8 +273,8 @@ typedef struct ldapcontrol { /* non-standard track controls */ #define LDAP_CONTROL_PAGEDRESULTS "1.2.840.113556.1.4.319" /* RFC 2696 */ -#define LDAP_CONTROL_AUTHZID_REQUEST "2.16.840.1.113730.4.16" /* RFC 3829 */ -#define LDAP_CONTROL_AUTHZID_RESPONSE "2.16.840.1.113730.4.15" /* RFC 3829 */ +#define LDAP_CONTROL_AUTHZID_REQUEST "2.16.840.1.113730.3.4.16" /* RFC 3829 */ +#define LDAP_CONTROL_AUTHZID_RESPONSE "2.16.840.1.113730.3.4.15" /* RFC 3829 */ /* LDAP Content Synchronization Operation -- RFC 4533 */ #define LDAP_SYNC_OID "1.3.6.1.4.1.4203.1.9.1" -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9530] New: double-free in options.c
by openldap-its＠openldap.org 04 Jun '21

04 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9530 Issue ID: 9530 Summary: double-free in options.c Product: OpenLDAP Version: 2.4.58 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: norm.green(a)gemtalksystems.com Target Milestone: --- I've been seeing double-free errors in valgrind when calling ldap_set_option(lc, LDAP_OPT_DEFBASE) I tracked it down to code in ldap_create() in open.c. When we copy the global options to the new LDAP *, we create new versions of some but not all malloced options. The ldo_defbase and ldo_defbinddn option members are strings that are *not* reallocated (ldo_defbase may not be important). This diff appears to fix the problem: diff --git a/libraries/libldap/open.c b/libraries/libldap/open.c index 5882b6336..0828d334e 100644 --- a/libraries/libldap/open.c +++ b/libraries/libldap/open.c @@ -139,6 +139,14 @@ ldap_create( LDAP **ldp ) ld->ld_options.ldo_defludp = NULL; ld->ld_options.ldo_conn_cbs = NULL; + /* Norm Green, April 20, 2021 - fix pointers that get copied. + * must realloc these to prevent double-free errors */ + + ld->ld_options.ldo_defbase = gopts->ldo_defbase ? + LDAP_STRDUP(gopts->ldo_defbase) : NULL; + ld->ld_options.ldo_defbinddn = gopts->ldo_defbinddn ? + LDAP_STRDUP(gopts->ldo_defbinddn) : NULL; + -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 9521] New: libldap doesn't configure TLS1.3 ciphersuites for OpenSSL
by openldap-its＠openldap.org 04 Jun '21

04 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9521 Issue ID: 9521 Summary: libldap doesn't configure TLS1.3 ciphersuites for OpenSSL Product: OpenLDAP Version: 2.4.58 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- OpenSSL 1.1 uses a separate API for configuring TLSv1.3 cipher suites. The current code in libldap doesn't call this API so those suites are always left at their compiled-in default. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9559] New: ldap_modify manpage LDAPMod incorrect
by openldap-its＠openldap.org 04 Jun '21

04 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9559 Issue ID: 9559 Summary: ldap_modify manpage LDAPMod incorrect Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- ldap_modify(3) suggests that struct ldapmod has a mod_next parameter, where ldap.h defines no such thing, nor is it even mentioned in RFC1823 for what that's worth. So I think it is the manpage that needs updating. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 8820] ldap_get_attribute_ber() function needs to be documented
by openldap-its＠openldap.org 04 Jun '21

04 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=8820 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9554] New: Finish retiring configure.in in OpenLDAP 2.5 and later
by openldap-its＠openldap.org 04 Jun '21

04 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9554 Issue ID: 9554 Summary: Finish retiring configure.in in OpenLDAP 2.5 and later Product: OpenLDAP Version: 2.5.4 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Update configure.in to configure.ac for contrib modules: ./contrib/ldaptcl/configure.in ./contrib/ldapc++/configure.in -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9494] New: Segfault after modify olcDbMaxSize w/ autogroup
by openldap-its＠openldap.org 04 Jun '21

04 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9494 Issue ID: 9494 Summary: Segfault after modify olcDbMaxSize w/ autogroup Product: OpenLDAP Version: 2.4.49 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: louis.chanouha(a)univ-toulouse.fr Target Milestone: --- Hello, Yet another crash when modifying olcDbMaxSize. Seems not to be related to other similar reports. autogroup works fine until : - attempt to modify olcDbMaxSize - attempt to modify olcAGattrSet (segfault to, need to delete the overlay and add it again) - do not rely on olcMemberOfMemberAD (extra memberof module) requested change --------------------------------------------: dn: olcDatabase={1}mdb,cn=config changetype: modify replace: olcDbMaxSize olcDbMaxSize: 4294967296 openldap logs -----------------------------------------------: 6046b5c3 ==> autogroup_db_close 6046b5c3 ==> autogroup_db_close 6046b5c3 mdb_db_open: database "dc=domain,dc=fr": dbenv_open(/var/lib/ldap). 6046b5c3 ==> autogroup_db_open 6046b5c3 ==> autogroup_build_def_filter put_filter: "(objectClass=groupOfURLs)" put_filter: simple put_simple_filter: "objectClass=groupOfURLs" ber_scanf fmt ({mm}) ber: 6046b5c3 => mdb_search 6046b5c3 mdb_dn2entry("dc=domain,dc=fr") 6046b5c3 => mdb_dn2id("dc=domain,dc=fr") 6046b5c3 <= mdb_dn2id: got id=0x1 6046b5c3 => mdb_entry_decode: 6046b5c3 <= mdb_entry_decode 6046b5c3 search_candidates: base="dc=domain,dc=fr" (0x00000001) scope=2 6046b5c3 => mdb_equality_candidates (objectClass) 6046b5c3 => key_read 6046b5c3 <= mdb_index_read: failed (-30798) 6046b5c3 <= mdb_equality_candidates: id=0, first=0, last=0 6046b5c3 => mdb_equality_candidates (objectClass) 6046b5c3 => key_read 6046b5c3 <= mdb_index_read 5 candidates 6046b5c3 <= mdb_equality_candidates: id=5, first=18173, last=18177 6046b5c3 mdb_search_candidates: id=5 first=18173 last=18177 6046b5c3 => mdb_entry_decode: 6046b5c3 <= mdb_entry_decode 6046b5c3 ==> autogroup_group_add_cb <cn=cxxx,ou=groups,dc=domain,dc=fr> 6046b5c3 ==> autogroup_add_group <cn=xxx,ou=groups,dc=domain,dc=fr> Thread 3 "slapd" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7feb7d42c700 (LWP 37453)] GDB dump -------------------------------------- (gdb) info frame Stack level 0, frame at 0x7feb7d297fd0: rip = 0x55b4569bcba0 in dnMatch; saved rip = 0x7feb9e5f768b called by frame at 0x7feb7d298070 Arglist at 0x7feb7d297f88, args: Locals at 0x7feb7d297f88, Previous frame's sp is 0x7feb7d297fd0 Saved registers: rbx at 0x7feb7d297f98, rbp at 0x7feb7d297fa0, r12 at 0x7feb7d297fa8, r13 at 0x7feb7d297fb0, r14 at 0x7feb7d297fb8, r15 at 0x7feb7d297fc0, rip at 0x7feb7d297fc8 (gdb) bt #0 0x000055b4569bcba0 in dnMatch () #1 0x00007feb9e5f768b in ?? () from /usr/lib/ldap/autogroup.so.0 #2 0x00007feb9e5f98fb in ?? () from /usr/lib/ldap/autogroup.so.0 #3 0x000055b4569b6eb8 in ?? () #4 0x000055b4569b8a31 in slap_send_search_entry () #5 0x00007feb9e63dbf6 in mdb_search () from /usr/lib/ldap/back_mdb-2.4.so.2 #6 0x000055b456a16c68 in overlay_op_walk () #7 0x000055b456a16d97 in ?? () #8 0x00007feb9e5f9be0 in ?? () from /usr/lib/ldap/autogroup.so.0 #9 0x000055b456a15dd8 in ?? () #10 0x00007feb9e632eb8 in ?? () from /usr/lib/ldap/back_mdb-2.4.so.2 #11 0x000055b4569908b6 in ?? () #12 0x000055b4569be8aa in fe_op_modify () #13 0x000055b4569c0930 in do_modify () #14 0x000055b4569a66ed in ?? () #15 0x000055b4569a722c in ?? () #16 0x00007feb9fa5ea03 in ?? () from /lib/x86_64-linux-gnu/libldap_r-2.4.so.2 #17 0x00007feb9f990609 in start_thread (arg=<optimized out>) at pthread_create.c:477 #18 0x00007feb9f8b7293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 cn=config overlays ---------------------------------- 22 olcOverlay={0}memberof,olcDatabase={1}mdb,cn=config objectClass: olcConfig objectClass: olcMemberOf objectClass: olcOverlayConfig objectClass: top olcOverlay: memberof olcMemberOfDangling: ignore olcMemberOfRefInt: TRUE olcMemberOfGroupOC: groupOfNames olcMemberOfMemberAD: member olcMemberOfMemberOfAD: memberOf 23 olcOverlay={1}ppolicy,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: {1}ppolicy olcPPolicyDefault: cn=orga_default,ou=Policies,dc=domain,dc=fr olcPPolicyHashCleartext: FALSE olcPPolicyUseLockout: TRUE olcPPolicyForwardUpdates: TRUE 24 olcOverlay={2}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {2}syncprov 25 olcOverlay={3}memberof,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcMemberOf objectClass: olcConfig olcOverlay: {3}memberof olcMemberOfDangling: ignore olcMemberOfRefInt: TRUE olcMemberOfGroupOC: groupOfNames olcMemberOfMemberAD: member 26 olcOverlay={4}autogroup,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcAutomaticGroups olcOverlay: {4}autogroup olcAGattrSet: {0}groupOfURLs memberURL member olcAGmemberOfAd: memberOf 27 olcOverlay={5}memberof,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcMemberOf objectClass: olcConfig olcOverlay: {5}memberof olcMemberOfDangling: ignore olcMemberOfRefInt: TRUE olcMemberOfGroupOC: groupOfURLs olcMemberOfMemberAD: member 28 olcOverlay={6}autogroup,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcAutomaticGroups olcOverlay: {6}autogroup olcAGattrSet: {0}groupOfURLs memberUidURL memberUid -- You are receiving this mail because: You are on the CC list for the issue.

1 14

[Issue 9561] New: Error doing 'make test': fails on 'test001-slapadd for mdb' test
by openldap-its＠openldap.org 04 Jun '21

04 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9561 Issue ID: 9561 Summary: Error doing 'make test': fails on 'test001-slapadd for mdb' test Product: OpenLDAP Version: 2.5.4 Hardware: x86_64 OS: FreeBSD Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: sydbarrett74(a)gmail.com Target Milestone: --- FreeBSD 13.0 x86_64 I was attempting to build the latest version in the master git branch and when I issued the 'gmake test' command, I got the following errors: >>>>> Starting test001-slapadd for mdb... running defines.sh Running slapadd to build slapd database... Fatal error 'mutex 0x801018040 own 0x0 is on list 0x5952414e49422d58 0x312e312e' at line 154 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 0) Abort trap (core dumped) slapadd failed (134)! >>>>> test001-slapadd failed for mdb after 1 seconds (exit 134) gmake[2]: *** [Makefile:301: mdb-yes] Error 134 gmake[2]: Leaving directory '/usr/home/bsduser/openldap/tests' gmake[1]: *** [Makefile:287: test] Error 2 gmake[1]: Leaving directory '/usr/home/bsduser/openldap/tests' gmake: *** [Makefile:299: test] Error 2 Please advise. TIA. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9548] New: argon2 module is not installed
by openldap-its＠openldap.org 04 Jun '21

04 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9548 Issue ID: 9548 Summary: argon2 module is not installed Product: OpenLDAP Version: 2.5.4 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- 2.5.4, configured with --enable-argon2. 'make install' installs the argon2 man page, but not the module itself. Confirmed by Quanah. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9544] New: Compilation error when enabling SLAPI
by openldap-its＠openldap.org 04 Jun '21

04 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9544 Issue ID: 9544 Summary: Compilation error when enabling SLAPI Product: OpenLDAP Version: 2.5.4 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: jcarmona(a)vmware.com Target Milestone: --- OpenLDAP 2.5.4 fails to build when enabling SLAPI support for SLAPD: /bin/sh ../../../libtool --mode=compile cc -g -O2 -I../../../include -I.. -I. -I../../../include -I./.. -I. -DSLAPI_LIBRARY -c plugin.c libtool: compile: cc -g -O2 -I../../../include -I.. -I. -I../../../include -I./.. -I. -DSLAPI_LIBRARY -c plugin.c -fPIC -DPIC -o .libs/plugin.o plugin.c:37:16: error: unknown type name 'lt_dlhandle'; did you mean 'sa_handler'? SLAPI_FUNC *, lt_dlhandle * ); ^~~~~~~~~~~ sa_handler plugin.c: In function 'plugin_pblock_new': plugin.c:73:2: error: unknown type name 'lt_dlhandle'; did you mean 'sa_handler'? lt_dlhandle hdLoadHandle; ^~~~~~~~~~~ sa_handler plugin.c:103:7: warning: implicit declaration of function 'slapi_int_load_plugin'; did you mean 'slapi_int_get_plugins'? [-Wimplicit-function-declaration] rc = slapi_int_load_plugin( pPlugin, path, initfunc, 1, NULL, &hdLoadHandle ); ^~~~~~~~~~~~~~~~~~~~~ slapi_int_get_plugins plugin.c: At top level: plugin.c:557:2: error: unknown type name 'lt_dlhandle'; did you mean 'sa_handler'? lt_dlhandle *pLdHandle ) ^~~~~~~~~~~ sa_handler make[3]: *** [Makefile:388: plugin.lo] Error 1 make[3]: Leaving directory '/wig/openldap-2.5.4/servers/slapd/slapi' make[2]: *** [Makefile:524: slapi/libslapi.la] Error 2 make[2]: Leaving directory '/wig/openldap-2.5.4/servers/slapd' make[1]: *** [Makefile:300: all-common] Error 1 make[1]: Leaving directory '/wig/openldap-2.5.4/servers' make: *** [Makefile:321: all-common] Error 1 ---- In order to reproduce it, simply download the latest release and use the flag --enable-slapi when calling configure: $ wget https://www.openldap.org/software/download/OpenLDAP/openldap-release/openld… $ tar xfz openldap-2.5.4.tgz && cd openldap-2.5.4 $ ./configure --enable-slapi $ make depend $ make The compilation fails and binaries are not generated. This does not seem to happen on version 2.4.58, whose compilation runs smoothly with this flag activated. Additional Information: $ gcc --version gcc (Debian 8.3.0-6) 8.3.0 Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ uname -a Linux af3c371dbbbf 4.15.0-128-generic #131~16.04.1-Ubuntu SMP Wed Dec 9 17:33:47 UTC 2020 x86_64 GNU/Linux $ date Mon May 3 12:36:10 UTC 2021 -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9541] New: Typos in ldap_pvt_gettimeofday() in libraries/libldap/util-int.c
by openldap-its＠openldap.org 04 Jun '21

04 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9541 Issue ID: 9541 Summary: Typos in ldap_pvt_gettimeofday() in libraries/libldap/util-int.c Product: OpenLDAP Version: 2.5.4 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: brecht(a)sanders.org Target Milestone: --- In openldap 2.544 there appear to be some typos in libraries/libldap/util-int.c - there is an int between the ldap_pvt_gettimeofday() function definition and the next curly brace - tv_spec is not a member of struct timeval, should be tv_sec patch -ulbf libraries/libldap/util-int.c << EOF @@ -300,3 +300,2 @@ ldap_pvt_gettimeofday( struct timeval *tv, void *unused ) -int { @@ -304,3 +303,3 @@ ldap_pvt_clock_gettime( 0, &ts ); - tv->tv_sec = ts.tv_spec; + tv->tv_sec = ts.tv_sec; tv->tv_usec = ts.tv_nsec / 1000; EOF -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9555] New: Introduce a default operations timeout for back-asyncmeta
by openldap-its＠openldap.org 04 Jun '21

04 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9555 Issue ID: 9555 Summary: Introduce a default operations timeout for back-asyncmeta Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- Currently, if no operation timeout is configured, the default asyncmeta behavior is to have no timeout. This is potentially unsafe - if for some reason a target server does not return a response, the operation will stay in the queue until the connection is reset due to some network error (idle-timeout is not honored if there are pending operations). In the case of many such operations, the queues can get filled up and asyncmeta will become unable to process new operations for some time. Therefore, a setting of "0" should be used carefully and with intent. To prevent accidental configuration of 0, the default operations timeout should be a value larger than 0. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9531] New: change RootDSE
by openldap-its＠openldap.org 04 Jun '21

04 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9531 Issue ID: 9531 Summary: change RootDSE Product: OpenLDAP Version: 2.4.57 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: niko(a)dwolfix.ru Target Milestone: --- Created attachment 816 --> https://bugs.openldap.org/attachment.cgi?id=816&action=edit RootDSE OS Linux Debian 10, slapd 2.4.57+dfsg-2 When installing openldap, a RootDSE is formed with the objectClass 'organization' (2.5.6.4). The root entry cannot be deleted. How can the RootDSE be changed so that the objectClass becomes 'domain' (0.9.2342.19200300.100.4.13)? -- You are receiving this mail because: You are on the CC list for the issue.

1 25

[Issue 8721] Quarantine in meta backend
by openldap-its＠openldap.org 04 Jun '21

04 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=8721 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED Resolution|TEST |FIXED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6531] Modify updateref to generate referrals on the backend
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=6531 --- Comment #9 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Created attachment 826 --> https://bugs.openldap.org/attachment.cgi?id=826&action=edit rein-ITS6531 patch from FTP server -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6683] slapo-ddds fails with expired branches
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=6683 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs(a)openldap.org |quanah(a)openldap.org -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6531] Modify updateref to generate referrals on the backend
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=6531 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |enhancement -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6289] CARS service crashes when stopping in windows
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=6289 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|ondra(a)mistotebe.net |hyc(a)openldap.org -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6289] CARS service crashes when stopping in windows
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=6289 Quanah Gibson-Mount <quanah(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.

1 0

[Issue 6248] Support multiple CA Cert directories
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=6248 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|OL_2_6_REQ | Assignee|bugs(a)openldap.org |hyc(a)openldap.org -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6198] Authorization for extensions
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=6198 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.7.0 |2.6.0 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6198] Authorization for extensions
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=6198 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.6.0 |2.7.0 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6198] Authorization for extensions
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=6198 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9211 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6198] Authorization for extensions
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=6198 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |enhancement See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9204 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7966] OpenLDAP server 2.4.40 crashes with rwm and ppolicy overlay during bind
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=7966 --- Comment #7 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Needs testing to see if this still occurs -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6166] Overlay/backend restructuring
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=6166 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.6.0 |3.0.0 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6138] Bad Cancel/Abandon/"internal abandon"/Syncprov interactions
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=6138 --- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> --- slapd async op return code, specifically -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6138] Bad Cancel/Abandon/"internal abandon"/Syncprov interactions
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=6138 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs(a)openldap.org |hyc(a)openldap.org --- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Can make use of new asyncmeta op code -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6128] slapd pcache assert
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=6128 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.6.0 |--- -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6128] slapd pcache assert
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=6128 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs