openldap-devel

openldap-devel@openldap.org

1416 discussions

ITS review 9/12/2017
by Quanah Gibson-Mount 20 Sep '17

20 Sep '17

The following ITSes were mostly supplied with patches and are IPR ok. I've imported them into my openldap-scratch repo for easy review. If they didn't have a supplied patch, I did the related work. Branch names are by ITS. ----------------------- Suggested for RE24: its5048 - Fix documentation for entryCSN with syncprov <https://github.com/quanah/openldap-scratch/tree/its5048> its7100 - Fix slapo-dds with entryTTL currently not decreasing <https://github.com/quanah/openldap-scratch/tree/its7100> its7373 - Fix tls_session reuse when hostname check fails <https://github.com/quanah/openldap-scratch/tree/its7373> its7374 - Fix MozNSS file matching for hashed CA cert directory (RE24 ONLY) <https://github.com/quanah/openldap-scratch/tree/its7374> its7389 - Fix MozNSS to fallback to PEM if cert not found in certdb (RE24 ONLY) <https://github.com/quanah/openldap-scratch/tree/its7389> its7442 - Add debug statements when index_intlen values are out of range <https://github.com/quanah/openldap-scratch/tree/its7442> its7520 - Omit unknown schema option for back-ldap <https://github.com/quanah/openldap-scratch/tree/its7520> its8037 - Fix delta-syncrepl with relax <https://github.com/quanah/openldap-scratch/tree/its8037> its8121 - Add LDAP_SASL_SIMPLE to ldap_bind(3) <https://github.com/quanah/openldap-scratch/tree/its8121> its8167 - Fix nonblocking TLS with referrals <https://github.com/quanah/openldap-scratch/tree/its8167> its8404 - Fix assertion with back-meta when olcDbRewrite is changed <https://github.com/quanah/openldap-scratch/tree/its8404> its8578 - Remove unused variables in RE24 <https://github.com/quanah/openldap-scratch/tree/its8578> its8583 - Fix C++ LDAPCtrl structure <https://github.com/quanah/openldap-scratch/tree/its8583> its8605 - Fix various spelling errors <https://github.com/quanah/openldap-scratch/tree/its8605> ----------------------- Suggested for RE25, possibly RE24: its8153 - olcTimeLimit should be SINGLE-VALUE <https://github.com/quanah/openldap-scratch/tree/its8153> its8692 - Support LDAP_MOD_INCREMENT with back-sock <https://github.com/quanah/openldap-scratch/tree/its8692> ----------------------- Purely for RE25: its7042 - Make it possible to unset TLS options with syncrepl <https://github.com/quanah/openldap-scratch/tree/its7042> its7532 - Add ldap_connection function for asynchronous clients <https://github.com/quanah/openldap-scratch/tree/its7532> its7721 - Allow authTimestamp to be forwarded via updateref <https://github.com/quanah/openldap-scratch/tree/its7721> its8291 - Fix slapmodify with BDB backends <https://github.com/quanah/openldap-scratch/tree/its8291> its8527 - Improve SYNC debug output in certain situations <https://github.com/quanah/openldap-scratch/tree/its8527> its8573 - Add TLS options to ldap* tools <https://github.com/quanah/openldap-scratch/tree/its8573-tables> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

3 2

Re: kqueue support for OpenLDAP (ITS#6300)
by Quanah Gibson-Mount 19 Sep '17

19 Sep '17

--On Tuesday, September 19, 2017 8:17 PM -0700 Quanah Gibson-Mount <quanah(a)symas.com> wrote: > A long long time ago for a release that is now far far away, Apple > submitted a patch adding kqueue support to OpenLDAP. I managed to track > it down and have it working with some changes since the patch was > originally written for OpenLDAP 2.3. In OpenLDAP master, it passed all > tests with back-meta, back-ldap, back-meta backends along with the > accesslog, syncprov, and rwm overlays. That should be "back-mdb, back-ldap, and back-meta". :) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

kqueue support for OpenLDAP (ITS#6300)
by Quanah Gibson-Mount 19 Sep '17

19 Sep '17

A long long time ago for a release that is now far far away, Apple submitted a patch adding kqueue support to OpenLDAP. I managed to track it down and have it working with some changes since the patch was originally written for OpenLDAP 2.3. In OpenLDAP master, it passed all tests with back-meta, back-ldap, back-meta backends along with the accesslog, syncprov, and rwm overlays. I think it generally is good to go in as a 2.5 feature. If anyone else would like to test it, they would need to run autoconf first to pick up the configure changes. Branch is: <https://github.com/quanah/openldap-scratch/tree/its6300> Commits are: <https://github.com/quanah/openldap-scratch/commit/d0c29a30c4cd7c0ab192d9301…> <https://github.com/quanah/openldap-scratch/commit/7ebbf79a07e684696f75c912e…> The only real changes are to servers/slapd/daemon.c, the rest are basically the header check & function check for configure. The one bit I wasn't sure on is if the handling of SLAP_EVENT_IS_(READ|WRITE) in slapd_daemon_task is the best way to address that KQUEUE requires the thread id while event/poll do not (Starting around line 2942). If there's a better way to do this other than the ifdefs, let me know, and I'll update accordingly. Thanks! --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

test061 failing
by Quanah Gibson-Mount 19 Sep '17

19 Sep '17

test061 in master is routinely failing. It doesn't happen every iteration, but it is fairly trivial to reproduce. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

New Committer
by Howard Chu 19 Sep '17

19 Sep '17

We are pleased to announce that Ondrej Kuznik has joined the OpenLDAP Engineering Team. Ondrej has been working on a variety of tasks, including syncrepl, new overlays, and other good stuff. Welcome, Ondrej! -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: Status of ldap_init_fd and LDAP_PROTO_EXT?
by Quanah Gibson-Mount 19 Sep '17

19 Sep '17

--On Wednesday, June 07, 2017 8:09 AM +0300 Alexander Bokovoy <abokovoy(a)redhat.com> wrote: >> We'd like to use ldap_init_fd() in Samba and if it is OK to use it, may >> be moving it to <ldap.h> is a good solution? > A small update -- get back to use 'struct ldap **ldp' in ldap_pvt.h > header instead of 'LDAP **ldp' as that one is not defined in the private > header. Also re-format ldap_init_fd() definition in ldap.h to follow the > rest of the header. Hi Alexander, Just as a reminder, for us to consider this patch for inclusion, we need the relevent IPR statement, as I noted to you in ITS#8671. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: ITS review 9/12/2017
by Quanah Gibson-Mount 19 Sep '17

19 Sep '17

--On Monday, September 18, 2017 10:29 PM +0200 Michael Ströder <michael(a)stroeder.com> wrote: >> ITS#8051: >> 2fbecdd756a288c787d8326d6630ab8500058e2f >> 129299a9337287527f2046fe5385cdb2afb35f0b > > Ah, it seems to be complete. IMO this would also be an interesting > candiate for RE24. If you port it to RE24 I will test it. They apply cleanly to RE24 for me. You can grab a squashed commit at: <https://github.com/quanah/openldap-scratch/commit/328612d3370290c7f42ad835e…> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: ITS review 9/12/2017
by Quanah Gibson-Mount 18 Sep '17

18 Sep '17

--On Wednesday, September 13, 2017 9:50 AM +0200 Michael Ströder <michael(a)stroeder.com> wrote: > Quanah Gibson-Mount wrote: >> ----------------------- >> Suggested for RE25, possibly RE24: >> [..] >> its8692 - Support LDAP_MOD_INCREMENT with back-sock >> <https://github.com/quanah/openldap-scratch/tree/its8692> > > Yes, please. > > It would be also helpful if this could land in RE24: > > (ITS#8714) RFE: Sendout EXTENDED operation message in back-sock > > I'm already using it with my own patched 2.4.45 builds. > > I'm willing to extensively test back-sock in RE24 to make sure it fully > works with the above changes. Ok, I'll discuss w/ Howard. > There is also a 'sockdnpat' config directive in git-master. But it seems > only the config. This would be very helpful for my deployments. I don't > know which ITS though. ITS#8051: 2fbecdd756a288c787d8326d6630ab8500058e2f 129299a9337287527f2046fe5385cdb2afb35f0b --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Documentation format for cn=config in man pages?
by Quanah Gibson-Mount 18 Sep '17

18 Sep '17

There are some outstanding ITSes that patch existing man pages to add cn=config bits, such as: ITS#7288, ITS#7335, ITS#6277 However, they've gone nowhere as there has been no definitive way decided on how to present cn=config information in the man pages. Currently, we have only 3 man pages (outside of slapd-config(5)) that have some reference olc* slapd-ldap(5) has a random comment about olcDbQuarantine, but zero other reference to cn=config slapo-auditlog(5) is purely written for cn=config, and may be what we want for our standard slapo-unique(5) has a reference to olcUniqueURI mixed in with unique_uri, but no other reference to cn=config Going with slapo-auditlog(5), I wonder if it would make more sense to group the keywords together: auditlog <filename> olcAuditlogFile <filename> description of attribute/keyword rather than having two sections like is currently done. I'd really like to get started on getting these updated, so feedback welcome. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: LMDB encryption support
by Howard Chu 10 Aug '17

10 Aug '17

Greg Hudson wrote: > On 08/10/2017 11:55 AM, Howard Chu wrote: >> Thoughts? Hardcode 1 algorithm, or leave it pluggable? > > Some thoughts, without advocating for either option: > > * If support isn't built-in, then generic LMDB tools (including > mdb_copy/dump/load/stat) can't operate on encrypted databases, if they > need plaintext pages to work. Yeah, already thought about that. We can add an option to the generic tools to dynamically load a user-supplied module for such cases. I always wanted this for BerkeleyDB as well, to safely operate on DBs with custom comparators. > * Built-in support doesn't necessarily mean hardcoding an algorithm for > all time, if the meta pages can include an algorithm selector. One of > the selector values could even mean "use application callbacks". > > * Is the page size guaranteed to be a multiple of 16 bytes? 32 bytes? > I would assume yes to both; documenting that would make it easier to use > block ciphers since ciphertext expansion isn't allowed. Yes, page sizes are always large powers of 2. 4096 bytes is typical (but on the small side). SPARC uses 8192, some MIPS systems use 32768 or 65536. > * Application writers are more likely to get encryption callbacks wrong > than Howard is. They could ignore the IV (making it easy to detect > duplicate initial blocks within a page) or even do pure ECB encryption > (making it easy to detect duplicate blocks anywhere). Less egregiously, > applications might not make the ideal choice of cipher mode. I would > personally have to think about the best choice to use. If I were using > a block cipher, CBC with the provided ivec seems like it should be okay, > but assuming 128-bit cipher blocks, after around 2^64 blocks one would > expect to experience a block collision which reveals the XOR of the > plaintexts of the preceding two blocks[1]. Deriving a key with > HKDF(key, ivec) and using counter mode might be safer, unless I'm > missing something, which I easily could be. If I were using a stream > cipher, I would have to do research to figure out how to incorporate the > ivec. The user-supplied IV is really just a seed, it will be hashed with some other uniqifiers (pageID,txnID) before being passed to the cipher. I suppose we could make some recommendations on ciphers and modes, but really I think it's up to the user to determine what kind of strength/speed tradeoffs they'll accept. I would expect stream ciphers to be used, in general. > * Not wanting to depend on crypto libraries seems like a valid concern. > Teaching the LMDB code how to dynamically load encryption plugins > doesn't necessarily seem attractive either. We'll probably do the dynamic loading anyway, as noted above. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel