https://bugs.openldap.org/show_bug.cgi?id=8861
--- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
(In reply to Howard Chu from comment #3)
> Sounds more like the back-ldap manpage is wrong. The use of "ldaps" is
> implicit in the URI, so there's no point in supporting it here and it should
> be an error to allow it here. In particular it makes no sense to allow it
> here if it differs from the URI.
Ok, although that doesn't entirely answer the rest of my question (i.e., about
tls_reqcert etc missing from back-meta).
Ironically I would note you're literally the person who added the "ldaps"
option to back-ldap.
a6a8fb514b (Howard Chu 2007-01-08 23:36:24 +0000 511) {
BER_BVC( "ldaps" ), LDAP_BACK_F_TLS_LDAPS },
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8861
--- Comment #3 from Howard Chu <hyc(a)openldap.org> ---
(In reply to Quanah Gibson-Mount from comment #0)
> Full_Name: Quanah Gibson-Mount
> Version: HEAD
> OS: N/A
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (47.208.148.239)
>
>
> The slapd-asyncmeta(5) and slapd-meta(5) man pages are missing the fact that
> they support the "ldaps" option to the "tls" keyword. This section should be
> updated along the lines of back-ldap which also has this option as a keyword.
Sounds more like the back-ldap manpage is wrong. The use of "ldaps" is implicit
in the URI, so there's no point in supporting it here and it should be an error
to allow it here. In particular it makes no sense to allow it here if it
differs from the URI.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8861
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
CC| |nivanova(a)symas.com
Status|UNCONFIRMED |CONFIRMED
--- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
Hi Nadya,
In looking over the back-meta man page and code and comparing it to what's in
back-ldap, I think the man page for back-meta needs significant updating for
the TLS option. Can you confirm the following?
In back-ldap, we have:
tls {none|[try-]start|[try-]propagate|ldaps} [starttls=no]
[tls_cert=<file>] [tls_key=<file>] [tls_cacert=<file>]
[tls_cacertdir=<path>]
[tls_reqcert=never|allow|try|demand] [tls_cipher_suite=<ciphers>]
[tls_crlcheck=none|peer|all]
Specify TLS settings for regular connections.
The first parameter only applies to ldap:// connections and so at
the moment, none and ldaps are equivalent.
With propagate, the proxy issues StartTLS operation only
if the original connection has a TLS layer set up. The try- prefix instructs
the proxy to
continue operations if the StartTLS operation failed; its use is
not recommended.
The TLS settings default to the same as the main slapd TLS
settings, except for tls_reqcert which defaults to "demand" and starttls which
is overshadowed
by the first keyword and thus ignored.
I believe all of the above options also apply to back-meta. Are the caveats
about tls_reqcert the same?
For back-meta, all we have currently is:
tls {[try-]start|[try-]propagate}
execute the StartTLS extended operation when the connection is
initialized; only works if the URI directive protocol scheme is not ldaps://.
propagate
issues the StartTLS operation only if the original connection
did. The try- prefix instructs the proxy to continue operations if the
StartTLS operation
failed; its use is highly deprecated. If set before any target
specification, it affects all targets, unless overridden by any per-target
directive.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8861
--- Comment #1 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
"none" is also missing
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9156
--- Comment #9 from David Coutadeur <david.coutadeur(a)gmail.com> ---
Hello,
Thanks Ondřej for your answer to my test results.
Here are some updates!
> - pwdLastSuccess, pwdMaxIdle: KO: the user is able to authenticate after the
> pwdMaxIdle delay. Also, the pwdLastSuccess is never written (see
> https://tools.ietf.org/html/draft-behera-ldap-password-policy-10#section-5.…).
> For information, I have enabled lastbind. The slapo-ppolicy man page does not
> mention pwdLastSuccess by the way.
I finally succeeded in making it work.
Thanks for pointing test022-ppolicy, it was helpfull.
The problem was that I was using old lastbind overlay, which in some way was in
conflict with current lastbind.
If I understand correctly, the current lastbind is now completely included into
OpenLDAP 2.5?
It is very important to me, because as a maintainer of OpenLDAP-LTB, we would
have to warn people that the configuration parameters have changed (overlay
lastbind -> lastbind on) and that the overlay won't be provided any more.
> - pwdStartTime, pwdEndTime: OK, but there is no special ppolicy code returned,
> and if I read correctly the draft
> (https://tools.ietf.org/html/draft-behera-ldap-password-policy-10#section-7.1),
> an "accountLocked" extended error code should be triggered.
I was simply missing the ppolicy_use_lockout parameter.
One remark though: the reason of locking is not very explicit.
I understand that many companies/organizations will consider it is a good thing
to hide this information for security reasons. For the others, maybe could we
have some sort of level?
Configuration example:
lockout_message_description [none|minimal|verbose]
In the specification the extended error code could simply stay as it is:
"(1)Account locked", but we could add a more precise description in case the
verbose mode is enabled: "(1)Account locked (account unused for a too long
time)"
Regards,
David
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8893
Ryan Tandy <ryan(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|FIXED |DUPLICATE
--- Comment #7 from Ryan Tandy <ryan(a)openldap.org> ---
*** This bug has been marked as a duplicate of bug 8847 ***
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8847
Ryan Tandy <ryan(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sudhir.singam(a)gmail.com
--- Comment #30 from Ryan Tandy <ryan(a)openldap.org> ---
*** Bug 8893 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9098
--- Comment #11 from maxime.besson(a)worteks.com <maxime.besson(a)worteks.com> ---
My original report mentions it: candidates[ i ].sr_msgid is -1
(META_MSGID_IGNORE)
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9098
--- Comment #10 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
Ok, it is halting on this check:
assert( candidates[ i ].sr_msgid >= 0 || candidates[ i ].sr_msgid ==
META_MSGID_CONNECTING );
So what we need is in thread 1, frame 2, to know what the value of
candidates[i].sr_msgid is.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9098
--- Comment #8 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
(In reply to maxime.besson(a)worteks.com from comment #7)
> Created attachment 704 [details]
> assert backtrace
>
> A little bird told be this report was missing a backtrace.
What we need is a full backtrace. ;)
thr apply all bt full
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8296
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|FEEDBACK |SUSPENDED
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8296
--- Comment #11 from maurizio.lattuada(a)gmail.com <maurizio.lattuada(a)gmail.com> ---
Hi Quanah,
unfortunately I'm not working on that project anymore (not for that company
too), so I had not anymore the chance to figure it out.
Sorry for that.
Cheers,
Maurizio
Il giorno dom 22 mar 2020 alle ore 01:53 <openldap-its(a)openldap.org> ha
scritto:
> https://bugs.openldap.org/show_bug.cgi?id=8296
>
> Quanah Gibson-Mount <quanah(a)openldap.org> changed:
>
> What |Removed |Added
>
> ----------------------------------------------------------------------------
> Status|UNCONFIRMED |RESOLVED
> Resolution|--- |FEEDBACK
>
> --- Comment #10 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
> Hi Maurizio,
>
> Do you still hit this issue with the current release? I apologize for the
> delay in response. Numerous fixes and changes have been made to syncprov
> since
> this was filed.
>
> Regards,
> Quanah
>
> --
> You are receiving this mail because:
> You reported the bug.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9179
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.openldap.org/s
| |how_bug.cgi?id=9205
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9121
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |TEST
Status|CONFIRMED |RESOLVED
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9121
--- Comment #4 from Howard Chu <hyc(a)openldap.org> ---
(In reply to Quanah Gibson-Mount from comment #3)
> Current code periodically triggers a SEGV in test044:
fixed in 5bfd8d88887eff4581463cb20f9262bf51686908
>
> (gdb) cont
> Continuing.
> [New Thread 0x7fd9d2ce2700 (LWP 18294)]
> [New Thread 0x7fd9d24e1700 (LWP 18295)]
>
> Thread 3 "lt-slapd" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7fd9d2ce2700 (LWP 18294)]
> 0x00007fd9d42a697c in comp_candidates (op=0x7fd9c4002900,
> rtxn=0x7fd9c410ad10, mra=0x7fd9c4005430, f=0x1c, ids=0x7fd9d0c5f018,
> tmp=0x7fd9d095f018, stack=0x7fd9d0d5f018)
> at filterindex.c:464
> 464 filterindex.c: No such file or directory.
>
>
> #0 0x00007fd9d42a697c in comp_candidates (op=0x7fd9c4002900,
> rtxn=0x7fd9c410ad10, mra=0x7fd9c4005430, f=0x1c, ids=0x7fd9d0c5f018,
> tmp=0x7fd9d095f018, stack=0x7fd9d0d5f018)
> at filterindex.c:464
> rc = 1409434333
> #1 0x00007fd9d42a6bb2 in ext_candidates (op=0x7fd9c4002900,
> rtxn=0x7fd9c410ad10, mra=0x7fd9c4005430, ids=0x7fd9d0c5f018,
> tmp=0x7fd9d095f018, stack=0x7fd9d0d5f018)
> at filterindex.c:507
> No locals.
> #2 0x00007fd9d42a5c0f in mdb_filter_candidates (op=0x7fd9c4002900,
> rtxn=0x7fd9c410ad10, f=0x7fd9c4005410, ids=0x7fd9d0c5f018,
> tmp=0x7fd9d095f018, stack=0x7fd9d0d5f018)
> at filterindex.c:206
> rc = 0
> aa = 0x7fd9c40016c0
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8245
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |TEST
Keywords|has_patch, OL_2_5_REQ |
Status|UNCONFIRMED |RESOLVED
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8245
--- Comment #14 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
Commits:
• 6d6a3300
by Ondřej Kuzník at 2020-04-06T20:44:09+00:00
ITS#8245 Use Relax control to avoid uniqueness checks
Still needs to retrieve the entry for ACL resolution until we can
restrict controls with ACLs
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8528
--- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
(In reply to Ondřej Kuzník from comment #5)
> On Thu, Apr 02, 2020 at 04:59:46PM +0000, openldap-its(a)openldap.org wrote:
> >> Not saying it's a bad idea, but the interactions with a delete mod might be
> >> a little confusing:
> >
> > Well, that's why I limited the scope of this bug purely to replace ops where
> > the entire structure is getting replaced. For add/delete, it must not re-order
> > anything.
>
> Not so sure about that, my thinking is a replace: attr should be equal to
>
> delete: attr
> -
> add: attr
> replaced values
>
> And you're now saying that's not the case anymore.
Actually I was agreeing with you. ;) Like in this example:
changetype: modify
delete: olcAccess
olcAccess: {2}
olcAccess: {1}
olcAccess: {0}
It would be a disaster to re-order things, and the correct thing to do is what
you proposed, which is to break them down into individual changes like:
changetype: modify
delete: olcAccess
olcAccess: {2}
-
delete: olcAccess
olcAccess: {1}
-
delete: olcAccess
olcAccess: {0}
I.e., reordering it to 0/1/2 would be very bad. ;)
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=7420
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |CONFIRMED
Ever confirmed|0 |1
Keywords| |OL_2_5_REQ
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=5705
Ryan Tandy <ryan(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
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 bug.
https://bugs.openldap.org/show_bug.cgi?id=8245
Ryan Tandy <ryan(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
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 bug.
https://bugs.openldap.org/show_bug.cgi?id=7084
--- Comment #3 from Michael Ströder <michael(a)stroeder.com> ---
Maybe my original comment was not clear enough.
Of course it is sufficient for most use-cases to just check authz-DN !=
entryDN.
My suggestion was to define a new attribute for a pwdPolicy entry for defining
authz-IDs considered to be an administrator - kind of an additional constraint
to the condition above. The syntax could be similar or the same to that already
implemented for authzTo/authzFrom attributes. But no proxy authorization
allowed at all.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=7596
--- Comment #2 from Ondřej Kuzník <ondra(a)mistotebe.net> ---
I'm not 100% sure that's the wrong number to return (according to the spec) as
we should return "the number of values in that attribute subtracted from the
value of pwdGraceAuthNLimit" and the number of values is one lower that you
would expect while we're still processing the bind.
Might be worth changing the message in the client to reflect that?
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=7084
--- Comment #2 from Ondřej Kuzník <ondra(a)mistotebe.net> ---
How about deciding whether this is an administrator by checking whether the
authorization identity is the same as the entry DN? For those, we can add
pwdReset to the modify unless already specified.
The concern is there might be management frontends that use a common identity
for their LDAP requests and don't do ProxyAuthZ, do we just force them to do
the right thing now?
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=6207
--- Comment #5 from Ondřej Kuzník <ondra(a)mistotebe.net> ---
AFAIK Need to figure out first how to make a windows environment look like
gitlab runner.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8245
--- Comment #13 from Ryan Tandy <ryan(a)openldap.org> ---
(In reply to Michael Ströder from comment #6)
> Please correct if I'm wrong but AFAIK you need 'manage' privilege to
> circumvent constraints (e.g. slapo-constraint and slapo-ppolicy).
That doesn't appear to be the case. A user with only 'write' privilege can
actually use Relax to modify attributes freely, bypassing slapo-constraint.
Personally I find this behaviour quite surprising. I would have expected both
overlays to behave like slapo-unique does (Relax honoured only with manage
access). As an administrator, configuring an overlay such as slapo-constraint
seems fairly pointless if users can simply ignore it any time they choose.
I don't understand the global Relax handling for Add/Rename, but not Modify,
either. If I understand the two options Ondřej described, either we should
require manage access _always_ in the presence of Relax, or only if the request
actually needs some rules to be relaxed. But AFAICT neither of those is
(consistently) the case right now...
(I guess this gets rather off-topic for this ticket, sorry!)
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8454
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|audit-log overlay man pag |slapo-auditlog man page
|needs some improvement |needs some improvement
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8511
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|UNCONFIRMED |IN_PROGRESS
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=7878
Ryan Tandy <ryan(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|slapd |backends
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=7878
Ryan Tandy <ryan(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|VERIFIED |CONFIRMED
Resolution|WORKSFORME |---
Ever confirmed|0 |1
--- Comment #4 from Ryan Tandy <ryan(a)openldap.org> ---
I'm reopening this, because my MSYS2/MinGW environment still reproduces it
(after fixing ITS#8383):
make[3]: Entering directory '/home/ryan/openldap/servers/slapd/back-mdb'
/bin/sh ../../../libtool --tag=disable-shared --mode=compile cc -g -O2
-I../../../include -I../../../include -I.. -I./..
-I./../../../libraries/liblmdb -c init.c
cc -g -O2 -I../../../include -I../../../include -I.. -I./..
-I./../../../libraries/liblmdb -c init.c -o init.o
In file included from ../slap.h:39,
from back-mdb.h:21,
from init.c:25:
../../../include/ac/socket.h:101: warning: "EWOULDBLOCK" redefined
101 | #define EWOULDBLOCK WSAEWOULDBLOCK
|
In file included from ../../../include/ac/errno.h:21,
from init.c:23:
C:/msys64/mingw64/x86_64-w64-mingw32/include/errno.h:166: note: this is the
location of the previous definition
166 | #define EWOULDBLOCK 140
|
In file included from ../slap.h:39,
from back-mdb.h:21,
from init.c:25:
../../../include/ac/socket.h:102: warning: "EINPROGRESS" redefined
102 | #define EINPROGRESS WSAEINPROGRESS
|
In file included from ../../../include/ac/errno.h:21,
from init.c:23:
C:/msys64/mingw64/x86_64-w64-mingw32/include/errno.h:158: note: this is the
location of the previous definition
158 | #define EINPROGRESS 112
|
In file included from ../slap.h:39,
from back-mdb.h:21,
from init.c:25:
../../../include/ac/socket.h:103: warning: "ETIMEDOUT" redefined
103 | #define ETIMEDOUT WSAETIMEDOUT
|
In file included from ../../../include/ac/errno.h:21,
from init.c:23:
C:/msys64/mingw64/x86_64-w64-mingw32/include/errno.h:223: note: this is the
location of the previous definition
223 | #define ETIMEDOUT 138
|
In file included from init.c:25:
back-mdb.h:71:2: error: unknown type name 'uint32_t'
71 | uint32_t mi_dbenv_flags;
| ^~~~~~~~
back-mdb.h:85:2: error: unknown type name 'uint32_t'
85 | uint32_t mi_rtxn_size;
| ^~~~~~~~
back-mdb.h:87:2: error: unknown type name 'uint32_t'
87 | uint32_t mi_txn_cp_min;
| ^~~~~~~~
back-mdb.h:88:2: error: unknown type name 'uint32_t'
88 | uint32_t mi_txn_cp_kbyte;
| ^~~~~~~~
init.c: In function 'mdb_db_open':
init.c:90:2: error: unknown type name 'uint32_t'; did you mean 'wint_t'?
90 | uint32_t flags;
| ^~~~~~~~
| wint_t
make[3]: *** [Makefile:343: init.lo] Error 1
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8753
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords|OL_2_5_REQ |
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8383
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |TEST
--- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
Commits:
• 27545be4
by Ryan Tandy at 2020-04-03T16:59:15+00:00
ITS#8383 Look for socklen_t in <ws2tcpip.h> too
MinGW targets do not have the <sys/socket.h> header. The configure check
would conclude that there is no socklen_t type, resulting in portable.h
containing its own definition of socklen_t, which would later conflict
with the actual definition in <ws2tcpip.h>.
Add <ws2tcpip.h> to the configure check for socklen_t, so that the
defined type is correctly detected.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9181
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|RESOLVED |CONFIRMED
Resolution|FIXED |---
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=6207
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |IN_PROGRESS
Ever confirmed|0 |1
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=6207
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 bug.
https://bugs.openldap.org/show_bug.cgi?id=6207
--- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
• 6d9e9e6c
by Ondřej Kuzník at 2020-04-03T09:47:46+01:00
ITS#6207 Print out test timings
• e0c80d6b
by Ondřej Kuzník at 2020-04-03T10:27:03+01:00
ITS#6207 Add GitLab CI
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8528
--- Comment #5 from Ondřej Kuzník <ondra(a)mistotebe.net> ---
On Thu, Apr 02, 2020 at 04:59:46PM +0000, openldap-its(a)openldap.org wrote:
>> Not saying it's a bad idea, but the interactions with a delete mod might be
>> a little confusing:
>
> Well, that's why I limited the scope of this bug purely to replace ops where
> the entire structure is getting replaced. For add/delete, it must not re-order
> anything.
Not so sure about that, my thinking is a replace: attr should be equal to
delete: attr
-
add: attr
replaced values
And you're now saying that's not the case anymore.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9181
--- Comment #5 from Ryan Tandy <ryan(a)openldap.org> ---
Hi Howard, I'm testing my patch for ITS#8383 and this one seems to have broken
the build in my MSYS2/MinGW environment:
cc -g -O2 -I../../include -I../../include -c -o ntservice.o
ntservice.c
In file included from ../../include/portable.h:1173,
from ntservice.c:20:
../../include/ldap_int_thread.h:156:43: error: unknown type name
'ldap_pvt_thread_mutex_t'; did you mean 'ldap_int_thread_mutex_t'?
156 | ldap_pvt_thread_mutex_init_first LDAP_P(( ldap_pvt_thread_mutex_t
*mutex ));
| ^~~~~~~~~~~~~~~~~~~~~~~
../../include/ldap_cdefs.h:32:25: note: in definition of macro 'LDAP_P'
32 | # define LDAP_P(protos) protos
| ^~~~~~
make[2]: *** [<builtin>: ntservice.o] Error 1
ldap_int_thread.h is included at the top of ldap_pvt_thread.h, so this
declaration is seen before the ldap_pvt_* typedefs.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8383
--- Comment #4 from Ryan Tandy <ryan(a)openldap.org> ---
Thanks Quanah for spending some time on this with me. I note this bug occurs
under MSYS2 when running the "MSYS2 MinGW 64-bit" environment
(MSYSTEM=MINGW64). It does not occur under the "MSYS2 MSYS" environment
(MSYSTEM=MSYS).
Quanah's build system seems a bit unique (MSYSTEM=MSYS but adding /mingw64/bin
to PATH, possibly other differences too). I think my patch is a correct fix for
people wanting to build under a pure MinGW environment.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8729
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 bug.
https://bugs.openldap.org/show_bug.cgi?id=9156
--- Comment #8 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
(In reply to Ondřej Kuzník from comment #5)
>
> Hi David,
> could you show a configuration when this happens? I cannot reproduce
> either issue on master.
>
> I will update the manpage to mention pwdLastSuccess is used.
>
> > - pwdStartTime, pwdEndTime: OK, but there is no special ppolicy code returned,
> > and if I read correctly the draft
> > (https://tools.ietf.org/html/draft-behera-ldap-password-policy-10#section-7.1),
> > an "accountLocked" extended error code should be triggered.
>
> Again, can't seem to be able to reproduce that and test022-ppolicy
> passes for me.
Hi David,
Can you provide the requested info? Thanks!
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9182
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|TEST |FIXED
Target Milestone|--- |2.4.50
--- Comment #10 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
• 727c1a3b
by Howard Chu at 2020-04-02T21:30:51+00:00
ITS#9182 pcache: fix private DB init
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9181
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |2.4.50
Resolution|TEST |FIXED
--- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
• 61bdf0e6
by Howard Chu at 2020-04-02T21:28:37+00:00
ITS#9181 Fix race on Windows mutex init
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9003
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|2.5.0 |2.4.50
Resolution|TEST |FIXED
--- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
• 468c8ee2
by Quanah Gibson-Mount at 2020-04-02T21:18:24+00:00
ITS#9003
Note that with slapd-ldap, the special character "*" actually allows anonymous
rather than denies, as is the case with authz-policy
--
You are receiving this mail because:
You are on the CC list for the bug.