Hello,
Thanks for the report. Unfortunately, your submission does not follow the
ITS guidelines, meaning we can't really move forward with it at this time.
Please read over <http://www.openldap.org/devel/contributing.html>,
particularly the IPR notice requirements as well as patch submission
requirements. If you can correct these issues, then the project can move
forward with including your work in the project.
Thanks!
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
Full_Name: Quanah Gibson-Mount
Version: 2.4.44
OS: N/A
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (47.208.148.239)
We should remove support for LANMAN hashes from OpenLDAP starting with the 2.5
release series.
--On Thursday, April 13, 2017 9:58 AM +0000 james(a)turnersoft.co.uk wrote:
> A more appropriate definition would be something like:
>
> DESC 'RFC2587: delta CRL'
Technically RFC2587 has been obsoleted by RFC4523. It looks like the core
schema file has never been appropriately updated to reflect this, however.
RFC4523 has an explicit DESC field for deltaCRL that's probably better to
use. Will discuss with the team to see what we want to do.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
Ond=C5=99ej Kuzn=C3=ADk wrote:
> On Fri, Apr 14, 2017 at 01:14:08PM +0000, hyc(a)symas.com wrote:
>> okuznik(a)symas.com wrote:
>>> Integrating with libevent, I would find it useful if libldap_r provid=
ed a
>>> recursive mutex as well, since this is what libevent uses.
>>
>> You mean libldap_r/rmutex.c ?
>
> Hmm, I see that now, but is quite heavy weight if this already exists i=
n
> many implementations natively, often at no cost at all. What if I
> renamed the current ldap_pvt_*_rmutex_* functions to ldap_int_* and
> deferred to them in the two implementations that can't do recursive
> mutexes only?
>
> This would be an ABI break for rmutex users, other than that, there
> seems to be no expectation that two versions of libldap_r compiled
> against a different thread implementation should be ABI compatible
> already.
IMO using recursive mutexes means your code is broken. We introduced thes=
e for=20
accesslog.c but in fact we could avoid them at zero cost. Also I don't se=
e the=20
relevance of libevent to this discussion. We use our own event mechanism =
and=20
it is more efficient than libevent.
--=20
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
On Fri, Apr 14, 2017 at 01:14:08PM +0000, hyc(a)symas.com wrote:
> okuznik(a)symas.com wrote:
>> Integrating with libevent, I would find it useful if libldap_r provided a
>> recursive mutex as well, since this is what libevent uses.
>
> You mean libldap_r/rmutex.c ?
Hmm, I see that now, but is quite heavy weight if this already exists in
many implementations natively, often at no cost at all. What if I
renamed the current ldap_pvt_*_rmutex_* functions to ldap_int_* and
deferred to them in the two implementations that can't do recursive
mutexes only?
This would be an ABI break for rmutex users, other than that, there
seems to be no expectation that two versions of libldap_r compiled
against a different thread implementation should be ABI compatible
already.
--
OndÅ™ej KuznÃk
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Full_Name: Ondrej Kuznik
Version: master
OS:
URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170414-libldap_r-recursive-…
Submission from: (NULL) (2a02:c7f:2247:ec00:a3e:8eff:fe52:dac5)
Integrating with libevent, I would find it useful if libldap_r provided a
recursive mutex as well, since this is what libevent uses.
Attached is an implementation. Platforms included:
- POSIX (the only one I could test properly)
- Win NT (regular mutexes, since they're recursive already, according to the
docs)
- GNU pth (same as NT, documentation says that all mutexes are recursive)
- stub (noop)
Not included:
- thr_thr.c - not sure what that is
- thr_cthreads.c - does not seem to support a recursive thread implementation
I'm not sure who still uses the older platforms, I suppose only POSIX and Win NT
are being used in the wild? Not that any users should be impacted by this since
it's not referenced anywhere in the project yet.