https://bugs.openldap.org/show_bug.cgi?id=9384
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Group|OpenLDAP-devs |
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9383
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Group|OpenLDAP-devs |
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9379
Issue ID: 9379
Summary: slapd should reject invalid listener URLs
Product: OpenLDAP
Version: 2.4.53
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: trivial
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
Most common instance of invalid listener URLs is specifying an ldapi URL
without URLencoding the socket pathname. Then the slashes in the pathname are
treated as URL field separators, which yields a pathname quite different from
what was intended.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9387
Issue ID: 9387
Summary: Support C++ Linkage
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: kriszyp(a)gmail.com
Target Milestone: ---
Created attachment 777
--> https://bugs.openldap.org/attachment.cgi?id=777&action=edit
Add directive for supporting C++ linking
The chacha8.h and module.h header files won't link properly (at least for me)
with a C++ compiler/linker. I think they just need the linkage directives.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9156
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.openldap.org/s
| |how_bug.cgi?id=9386
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8125
--- Comment #19 from OndÅ™ej KuznÃk <ondra(a)mistotebe.net> ---
(In reply to OndÅ™ej KuznÃk from comment #12)
> This is my understanding of the above discussion:
> - deltasync consumer has just switched to full refresh (but is ahead
> from this provider in some ways)
> - provider sends the present list
> - consumer deletes extra entries, builds a new cookie
> - problem is that the new cookie is built to reflect the union of both
> the local and received cookies even though we may have undone some of
> the changes which we then ignore
>
> If that's accurate, there are some approaches that could fix it:
>
> 1. Simple one is to remember the actual cookie we got from the server
> and refuse to delete entries with entryCSN ahead of the provided CSN
> set. Problem is that we get even further from being able to replicate
> from a generic RFC4533 provider.
This has actually been done in ITS#9282.
> 2. Instead, when present phase is initiated, we might terminate all
> other sessions, adopt the complete CSN set and restart them only once
> the new CSN set has been fully established.
>
> Also, whenever we fall back from deltasync into plain syncrepl, we
> should make sure that the accesslog entries we generate from this are
> never used for further replication which might be thought to be a
> separate issue. Maybe the ITS#8486 work might be useful for this if
> we have a way of signalling to accesslog to reset minCSN accordingly
> to the new CSN set.
>
> The former is simpler, but the latter feels like the only one that
> actually addresses these problems in full.
I have some code to do this, terminate only persist sessions when we detect
getting into a present refresh.
Need a way to reproduce this in current master since a lot of the issues would
have been fixed in ITS#9282 and might only be diverging in relayed deltasync,
possibly if we're refreshing from two other providers at the same time.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=5808
--- Comment #4 from klasen(a)gmx.net ---
The same problem can be observed, if a non-default SocketFactory (e.g. for
LDAPS connections) is used:
See https://bugs.openldap.org/show_bug.cgi?id=5808 (SocketFactory does not
support a connect timeout.)
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9370
--- Comment #4 from Howard Chu <hyc(a)openldap.org> ---
(In reply to Salvatore Bonaccorso from comment #3)
> CVE-2020-25692 was assigned for this issue.
Fyi, the official OpenLDAP Project policy is that only unintended information
disclosures count as security issues, and this item does not qualify.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9370
--- Comment #3 from Salvatore Bonaccorso <carnil(a)debian.org> ---
CVE-2020-25692 was assigned for this issue.
--
You are receiving this mail because:
You are on the CC list for the issue.